> Very slow, but no losses. A TCP connection should work... I ran 'ncftp
> ftp.kernel.org':
>
> tcpdump tells me (just added a few linefeeds):
> python:~# tcpdump host ftp.kernel.org
> 14:24:07.206547 python.wohnheim.uni-ulm.de.1114 > linux.kernel.org.ftp:
> S 85727615:85727615(0) win 31856 <mss 1460,sackOK,timestamp 1701016 0,
> nop,wscale 0> (DF)
Connection start
>
> 14:24:10.197859 python.wohnheim.uni-ulm.de.1114 > linux.kernel.org.ftp:
> S 85727615:85727615(0) win 31856 <mss 1460,sackOK,timestamp 1701316 0,
> nop,wscale 0> (DF)
No, answer, tries again.
>
> 14:24:11.573002 linux.kernel.org.ftp > python.wohnheim.uni-ulm.de.1114:
> S 4240735359:4240735359(0) ack 85727616 win 31856 <mss 1460,sackOK,
> timestamp 40912065 0,nop,wscale 0> (DF)
Finally an answer.
>
> 14:24:11.573254 python.wohnheim.uni-ulm.de.1114 > linux.kernel.org.ftp:
> .. ack 1 win 31856 <nop,nop,timestamp 1701453 40912065> (DF)
Final ack for three-way handshake -> connection established.
>
> 14:24:11.582760 linux.kernel.org.ftp > python.wohnheim.uni-ulm.de.1114:
> .. ack 1 win 31856 <nop,nop,timestamp 40912102 1701016> (DF) [tos 0x10]
>
> 14:24:13.547741 linux.kernel.org.ftp > python.wohnheim.uni-ulm.de.1114:
> .. ack 1 win 31856 <nop,nop,timestamp 40912355 1701316> (DF) [tos 0x10]
>
> 14:24:14.311683 linux.kernel.org.ftp > python.wohnheim.uni-ulm.de.1114:
> .. ack 1 win 31856 <nop,nop,timestamp 40912402 1701316> (DF) [tos 0x10]
>
> 14:24:15.666549 linux.kernel.org.ftp > python.wohnheim.uni-ulm.de.1114:
> .. ack 1 win 31856 <nop,nop,timestamp 40912511 1701453> (DF) [tos 0x10]
>
> 14:25:05.732392 linux.kernel.org.ftp > python.wohnheim.uni-ulm.de.1114:
> .. ack 1 win 31856 <nop,nop,timestamp 40917528 1701453> (DF) [tos 0x10]
Now it starts to be come strange. The other end floods us with ACKs.
>
> [.. other console and a 'killall ncftp']
>
> 14:25:13.555511 python.wohnheim.uni-ulm.de.1114 > linux.kernel.org.ftp:
> F 1:1(0) ack 1 win 31856 <nop,nop,timestamp 1707651 40917528> (DF) [tos 0x10]
>
> After state "ESTABLISHED" according to netstat, "python" doesn't like to talk
> any further to ftp.kernel.org. But what's the reason for this?
Can't see yet why. Is this reproducible? If yes, could you change ncftp
to set the SO_DEBUG option on the socket
(with int flag=1; setsockopt(sockfd, SOL_SOCKET, &flag, sizeof flags) and
send me the resulting kernel log. ncftp must run as root then. Please also
add a netstat -to output after the connection is established.
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu