On 28/05/14 00:32, Andrew Hanushevsky wrote: > Hi Ulf, Good morning! > Indeed, the documentation (as Lukasz points out) is not completely > precise. If the server has an IPV4 address, locate returns "[::<ipv4>]" > as the response. The documentation is clear on that. I should also point > out that this form of the address is deprecated now but we continue to > return the deprecated version for backward compatibility. > > If the server has only an IPV6 address, the the documentation says the > "true" IPV6 address should be returned. By "true" address it was meant > that "[<ipv6>]" is returned (notice there is no leading "::" as this > would not be a true address). 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. 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? > In the end after reading the whole thread I am now confused as to what > is being returned by whom when the server has only an IPV6 address. So, > could you clarify. My verfication system (all xrootd4.0.0rc3) is not behaving properly. [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. 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 and a cleaned up tcpdump: 07:56:23.440735 IP6 2001:708:10:0:7ae7:d1ff:fe24:11b9.47950 > 2001:708:10:0:7ae7:d1ff:fe24:11b9.rootd: Flags [P.], seq 07:56:23.440916 IP6 2001:708:10:0:7ae7:d1ff:fe24:11b9.rootd > 2001:708:10:0:7ae7:d1ff:fe24:11b9.47950: Flags [P.], seq 1:34, ack 29, 07:56:23.440933 IP6 2001:708:10:0:7ae7:d1ff:fe24:11b9.47950 > 2001:708:10:0:7ae7:d1ff:fe24:11b9.rootd: Flags [.], ack 34, win 256, 07:56:23.441179 IP 193.166.0.114.39025 > 193.166.0.114.rootd: Flags 07:56:23.441412 IP 193.166.0.114.rootd > 193.166.0.114.39025: Flags 07:56:23.441432 IP 193.166.0.114.39025 > 193.166.0.114.rootd: Flags 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. 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. With -I v6 it still logs: 140528 08:01:42 32371 XrootdXeq: csculf.32383:20@[2001:708:10:0:7ae7:d1ff:fe24:11b9] pub IPv6 login 140528 08:01:43 32372 XrootdXeq: csculf.32383:21@aesyle pub IPv4 login 140528 08:02:50 32391 XrootdXeq: csculf.32383:21@aesyle disc 0:01:07 140528 08:02:50 32371 XrootdXeq: csculf.32383:20@[2001:708:10:0:7ae7:d1ff:fe24:11b9] disc 0:01:08 140528 08:05:59 32389 XrootdXeq: csculf.32471:22@[2001:708:10:0:7ae7:d1ff:fe24:11b9] pub IPv6 login 140528 08:06:05 32372 XrootdXeq: csculf.32471:20@aesyle pub IPv4 login 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. -- Ulf Tigerstedt || CSC Oy || NDGF Computing Environments group (NGI_FI and NGI_NDGF) deputy manager GSM +358503818558 || +35894572279 Keilaranta 14 || Espoo || Finland ######################################################################## 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