On Wed, 28 May 2014, Ulf Tigerstedt wrote:
> The specs says the IPv6 address should be returned in place of
> aaa.bbb.ccc.ddd, not in place of ::aaa.bbb.ccc.ddd.
> Since I'm the tester of the other implementation of the xrootd server, the
> devil is truly in the details.. and we are currently contemplating follwing a
> confusing spec or making it bug-compatible with the original documentation.
> Fixing the spec would be better.
I will change it to be very clear that either an IPV4 mapped IPV6 address,
an IPv6 address, or hostname is returned.
> Another issue that popped up: Is a terminating 0x00 needed for the response
> to kXr_locate? xrootd sends it, but it's actually not in the specs. Is it
> needed for everything?
I check in the old client and it always terminates a message with a null
byte unbder the assumption that one is never sent. So, if the
documentation does not specifically say that a null byte must be sent the
assumption should be it can be omitted. Lukasz can weigh in w.r.t. to the
> [csculf@aesyle bin]$ ./xrootd
> 140522 12:40:36 21348 Starting on Linux 2.6.32-431.11.2.el6.x86_64
> Copr. 2004-2012 Stanford University, xrd version v4.0.0-rc3
> ++++++ xrootd [log in to unmask] initialization started.
> aesyle.fgi.csc.fi is the box mentioned in my first email (220.127.116.11). It
> is also 2001:708:10:0:7ae7:d1ff:fe24:11b9, but lacks DNS for IPv6.
OK, so you are using a "server" that has a registered IPv4 address but
there is nothing there to indicate that it has an IPv6 address other than
just "knowing" this is the case. I'm not suprised that this could cause
inconsistencies. Have you tried repeating this with the machine getting a
real AAAA record into its DNS entry?
> I then contact it:
> ./xrdfs [2001:708:10:0:7ae7:d1ff:fe24:11b9]
> [[2001:708:10:0:7ae7:d1ff:fe24:11b9]:1094] / > cd /tmp
> [[2001:708:10:0:7ae7:d1ff:fe24:11b9]:1094] /tmp > ls
> <more files>
> However, this is where it goes wrong: (log from xrootd)
> 140528 07:56:23 21452 XrootdXeq:
> csculf.21457:21@[2001:708:10:0:7ae7:d1ff:fe24:11b9] pub IPv6 login
> 140528 07:56:23 21368 XrootdXeq: csculf.21457:22@aesyle pub IPv4 login
The case here is that the new client actually logs in twice for directory
listings. It would appear that the firt login used the IPv6 address and
hence was recognized as an IPv6 client. The second login used the IPv4
address and so the client was considered to be an IPv4 client.
> The server always responds with an IPv4 address to kXR_locate , but it can't
> know that the client actually has an IPv4 address to use. It might be
> IPv6-only, and in that case it won't work.
If the client comes in as mapped IPv4 then we need to respond with a
mapped IPv4 address. If the client comes in as IPv6 then we can respond
with an IPv6 address. Of course, all this is predicated on the fact that
the server knows it has an IPv6 address and that generally comes out of
DNS. To help sort this out, could you run the xrootd with the -d option
and snip out the sequence from the login to the locate response?
> From a more verbose tcpdump I can see that the answer always is:
> Sw[::18.104.22.168]:1094, even if I specify -I v6 on the commandline of
> So it starts out on IPv6, then switches to IPv4 as soon as possible. -I v6 is
> supposed to deny any IPv4 traffic according to the documentation.
The -I v6 option actually does not restrict the server to IPv6. Instead,
it allows a dual-stack mode of operation (that is what is meant when it
says "When v6 is specified, the default, hosts using IPV6 or IPV4
addresses can connect or be connected to.") The -I v4 actually restricts
the server to IPv4 mode only.
Anyway, our attempt here was to provide backward compatability to the old
client that only knew how to process IPv4 mapped responses. We may have
taken that to a bit of an extreme and we will look into that. That said,
it would still be useful to see a) the debug output of the server for
locate, and b) what happens when the server's IPv6 address is actually in
Use REPLY-ALL to reply to list
To unsubscribe from the XROOTD-L list, click the following link: