 |
 |
Hi everybody, So, it turns out our sysadmin botched up the entry in /etc/hosts file. He claims that the ip addres and hostname always get written in there during redhat installation ... which is not what I remember from years back ... but ok. I'll find a subtle way to get back at him :) Andy, Lukasz thanks for your help and sorry for the trouble! Best, Matevz On 12/03/13 21:58, Matevz Tadel wrote: > 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 > ######################################################################## 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