 |
 |
On 28/05/14 09:24, Andrew Hanushevsky wrote: > 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. Thanks! > 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. Yes, since it uses the response from kXr_locate, which is always IPv4. > > 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. Ok, test server moved to usva.fgi.csc.fi which has IPv6 + IPv4 and the firewall also now open. No difference: ./xrootd -d <snip a lot> 140528 11:14:17 23292 XrdSched: running csculf.2905:19@[2001:708:10:0:7ae7:d1ff:fe24:11b9] inq=0 140528 11:14:17 23292 csculf.2905:19@[2001:708:10:0:7ae7:d1ff:fe24:11b9] XrootdProtocol: 0100 req=3027 dlen=5 140528 11:14:17 23292 csculf.2905:19@[2001:708:10:0:7ae7:d1ff:fe24:11b9] XrootdProtocol: 0100 locate */tmp 140528 11:14:17 23292 csculf.2905:19@[2001:708:10:0:7ae7:d1ff:fe24:11b9] ofs_fsctl: fn=*/tmp 140528 11:14:17 23292 csculf.2905:19@[2001:708:10:0:7ae7:d1ff:fe24:11b9] XrootdProtocol: 0100 rc=-1024 locate */tmp 140528 11:14:17 23292 csculf.2905:19@[2001:708:10:0:7ae7:d1ff:fe24:11b9] XrootdResponse: 0100 sending 25 data bytes 140528 11:14:17 23291 XrdSched: running csculf.2905:22@aesyle inq=0 140528 11:14:17 23291 csculf.2905:22@aesyle XrootdProtocol: 0100 req=3004 dlen=4 140528 11:14:17 23291 csculf.2905:22@aesyle ofs_opendir: fn=/tmp 140528 11:14:17 23291 csculf.2905:22@aesyle oss_Opendir: lcl path /tmp (/tmp) 140528 11:14:17 23291 csculf.2905:22@aesyle XrootdResponse: 0100 sending 487 data bytes 140528 11:14:17 23291 csculf.2905:22@aesyle ofs_closedir: fn=/tmp 140528 11:14:17 23291 csculf.2905:22@aesyle XrootdProtocol: 0100 dirlist entries=35 path=/tmp 140528 11:14:20 23292 csculf.2905:19@[2001:708:10:0:7ae7:d1ff:fe24:11b9] XrootdProtocol: 0100 request timeout; read 0 of 24 bytes a tcpdump on aesyle shows that the first handshake (up until kXr_locate) is on IPv6, then it switches to IPv4 for the rest. Here aesyle is the client (still without AAAA record, and usva is the server) Full debug output from xrootd is available from: xrootd://[2001:708:10:30:5652:ff:fe05:99e5]:1094/tmp/out (or usva.fgi.csc.fi) -- 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