Ssh connection hangs. Ignored ACK packet?
I have intermittent problems in transferring files between two
machines via scp. Symptomps are: when transferring a large file from
the server to the client, scp transfers a few Kbytes and then says
"stalled".
After a while I was having this problem, I tried to investigate it,
and captured the TCP packets on both machines. Here you can find a
sample of a hanging connection (dump taken from the server side):
http://home.dei.polimi.it/dalseno/dumpssh-broken .
>From what I recall of TCP, it seems a puzzling behavior to me. After
the first packets are transmitted without any problem, a packet from
the server doesn't get through (the bandwidth limit of the client DSL
connection has been hit?), and the client sends ACKs requesting a
retransmission (packets 145--162 in the dump). After the server
retransmits the lost packet (163), the client asks for the
retransmission of another, more recent packet (164), but the server
keeps retransmitting the first lost packet, as if subsequent ACKs were
ignored. But the dump has been taken on the server, so the ACKs have
definetely been received, and the first rule of iptable INPUT table is
-m state --state RELATED,ESTABLISHED -j ACCEPT
The same connection on the client side:
http://home.dei.polimi.it/dalseno/dumpssh-broken-client . (Please
notice that the client is NATted)
What is possibly going wrong?
Searching with Google didn't help me. I've found only very old posts
(more than 2-3 years ago) or problems with MTU discovery. Any help is
appreciated, as I don't know how to handle this.
Additional information.
The server is a desktop AMD Sempron running an Ssh server, with a
public IP, behind a firewall; the client is an AMD Duron connected to
a DSL line and is double NATted (NAT is used by my ISP, and I have a
NATting firewall between my local lan and a non-NATting DSL router).
Both machines run Debian Sid; I tried to update the kernel (which
contains the TCP/IP stack) and also use the Debian stock kernel image
(2.6.24-4) and build the latest 2.6.24.3 from kernel.org.
Some software versions:
server: ssh 1:4.7p1-4, libc6 2.7-6, kernel: linux-image-2.6.24-1-686 (2.6.24-4)
client: ssh 1:4.7p1-4, libc6 2.7-8, kernel: custom-built,
linux-source-2.6.23: 2.6.23-2
Server network interface:
eth0: RealTek RTL8139 at 0xd000, 00:05:5d:4c:66:0d, IRQ 18
eth0: Identified 8139 chip type 'RTL-8100B/8139D'
Client network interface:
eth0: VIA Rhine II at 0x19000, 00:0e:a6:1d:45:ca, IRQ 18.
eth0: MII PHY found at address 1, status 0x786d advertising 01e1 Link 45e1.
I used the command
tcpdump -c 100000 -s 0 -p -w <filename> tcp port 22 or icmp
to capture packets, and then I used Wireshark to select the packets
belonging to one connection. No Icmp packets had been captured.
Best regards,
Bernardo
Reply to: