Hi Ulf, 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 new client. > [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 (193.166.0.114). 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 > /tmp/.ICE-unix > /tmp/.xrootd > /tmp/ssh-wKaMS12947 > <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[::193.166.0.114]:1094, even if I specify -I v6 on the commandline of > ./xrootd. > 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 DNS. Andy ######################################################################## Use REPLY-ALL to reply to list To unsubscribe from the XROOTD-L list, click the following link: https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-L&A=1