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 :-)
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
