 |
 |
Hi Andy, On 12/03/13 14:45, Andrew Hanushevsky wrote: > Hi Matevz, > > Thanks for helping me dig into this. While following your questions I realized > that the original address on first connection 169.228.130.92 somehow gets > transmuted into 169.228.230.92 which is a nonexistent host, does not have a DNS > record, either. I feel somewhat stupid for not spotting this earlier, sorry :( > > How can this happen? Does server tell the client to which IP to connect? >>>> Yes, the server responds with IP addresses for a locate request (historic >>>> stuff). The question is the server responding that way or is the client >>>> mangling the address. This will be one tough cookie to track down if it's >>>> the client. So, try using the old client in the same way and see if the same >>>> thing happens there. If so, it's a server issue. If not, it's a client issue >>>> (assuming a sample of 2 is enough :-) Thanks! Yes, it happens with the old client, too (xrd) ... I'll try to catch this at the server tomorrow. Matevz > Andy > >> Also, what is the result of: >> >> ]==> netstat -nt | grep 169.228.230.92 >> >> when the connections are 'in progress'? > > It just shows the connection in established state. Tried several times to catch > some short-lived sockets but had no luck. > > For master / fedora 19 client (connection timeout error) I see this (apparently > going through ip6): > > matevz@desire matevz> netstat -ntp | pcregrep '169.228.[12]30.92' > tcp6 0 1 132.239.186.42:49331 169.228.230.92:9940 SYN_SENT > 23539/xrdfs > tcp6 0 0 132.239.186.42:52532 169.228.130.92:9940 ESTABLISHED > 23539/xrdfs > matevz@desire matevz> ll /proc/23539/fd | grep socket > lrwx------ 1 matevz zh 64 Dec 3 14:03 10 -> socket:[6225802] > lrwx------ 1 matevz zh 64 Dec 3 14:03 9 -> socket:[6225797] > matevz@desire matevz> cat /proc/net/tcp6 > sl local_address remote_address st tx_queue rx_queue > tr tm->when retrnsmt uid timeout inode > 8: 0000000000000000FFFF00002ABAEF84:CC72 0000000000000000FFFF00005C82E4A9:26D4 > 01 00000000:00000000 00:00000000 00000000 411 0 6225797 1 > ffff88058335cd80 20 4 24 10 -1 > 9: 0000000000000000FFFF00002ABAEF84:BFF1 0000000000000000FFFF00005CE6E4A9:26D4 > 02 00000001:00000000 01:00000176 00000004 411 0 6225802 2 > ffff88058335ae80 1600 0 0 1 5 > ^ > | > !!! how come this is different ?? > How could I have missed this :) Apparently 169.228.130.92 (the correct ip) is > somehow changed into 169.228.230.92 (non-existent). > This is also why Andy got confused > > For 3.3.3 client on slc5 (no route to host) I only see the established socket in > the fd list. And it's an ip4 socket, there is no /proc/net/tcp6 on machine at all. > > My program that connects to the host several times shows up in ip4, /proc/net/tcp. > > > Thanks a lot & cheers, > Matevz > > > >>>> Lukasz >>>> >>>> On 03.12.2013 11:39, Lukasz Janyst wrote: >>>>> Hi Andy, >>>>> >>>>> no, b is not the problem. There was an issue like the one you >>>>> mention, but it was introduced after migration to IPv6 in master only >>>>> and fixed immediately after it was discovered. It was never introduced >>>>> to the stable-3.3.x branch. >>>>> >>>>> Matevz, what you see is really strange. It looks like the system >>>>> won't let you connect to the host twice... A router issue perhaps? Can >>>>> you telnet twice to this host:port from your test box? >>>>> >>>>> Cheers, >>>>> Lukasz > > <snip> > ######################################################################## Use REPLY-ALL to reply to list To unsubscribe from the XROOTD-DEV list, click the following link: https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-DEV&A=1