tcp resets sent without apparent reason?

[Patrick Byrne]

Hi,

I use putty & winscp to connect from my windows laptop to a debian server in my home. Several weeks ago I started getting frequent problems where the connection was reset. My putty session would die every couple of minutes with 'network error caused software abort' or 'network connection reset by peer'.

Today I tried to use winscp and found that the connection was reset each time I tried to copy a file to the server.

Currently I have a reproducible way to prompt the error. If I type 'dmesg -T' then it tries to list the system log and the connection always dies - seemingly always in the same place.

I used wireshark and it shows a RST packet being sent from my laptop (192.168.1.6) to the server (192.168.1.2):
113 5.008441000 192.168.1.6 192.168.1.2 TCP 54 61711?21 [RST, ACK] Seq=545 Ack=56805 Win=0 Len=0

So, can someone explain what is going on? I would guess that some sequence of bytes which happens to be in the system log is somehow causing a RST to be sent, but why that might be is quite beyond me and I don't think google can get me much further. Could someone please advise?

The server is running up-to-date debian Jessie. The laptop is running windows 7.

Thanks
--
Patrick Byrne

[Richard Kettlewell]

Post by Patrick Byrne
Currently I have a reproducible way to prompt the error. If I type
'dmesg -T' then it tries to list the system log and the connection
always dies - seemingly always in the same place.
I used wireshark and it shows a RST packet being sent from my laptop
113 5.008441000 192.168.1.6 192.168.1.2 TCP 54 61711?21 [RST, ACK] Seq=545 Ack=56805 Win=0 Len=0

Can you turn on MAC addresses for the packet capture?

Can you do a packet capture at the other endpoint to check for
consistency?

Post by Patrick Byrne
So, can someone explain what is going on? I would guess that some
sequence of bytes which happens to be in the system log is somehow
causing a RST to be sent, but why that might be is quite beyond me and
I don't think google can get me much further. Could someone please
advise?

The packet contents on the wire should be different every time (SSH is
encrypted), but the length might be the same each time.

Post by Patrick Byrne
The server is running up-to-date debian Jessie. The laptop is running windows 7.

Is there anything else on the same network?

Does the server have any iptables rules?

[Patrick Byrne]

Thanks for your response.

Post by Richard Kettlewell
Can you turn on MAC addresses for the packet capture?

The MAC addresses match those reported by the wireless adaptor on my laptop and the ethernet adaptor on the server. Is that enough?

Post by Richard Kettlewell
Can you do a packet capture at the other endpoint to check for
consistency?

I get:
***@nelly /home/anselm # tcpdump -n -v 'tcp[tcpflags] & (tcp-rst) != 0'
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
17:59:06.806626 IP (tos 0x0, ttl 52, id 40671, offset 0, flags [DF], proto TCP (6), length 40)
37.59.8.102.7028 > 192.168.1.2.46324: Flags [R], cksum 0xd4dd (correct), seq 879683296, win 0, length 0
17:59:09.853029 IP (tos 0x0, ttl 49, id 0, offset 0, flags [DF], proto TCP (6), length 40)
184.75.220.122.62455 > 192.168.1.2.52546: Flags [R.], cksum 0x9199 (correct), seq 0, ack 1045481531, win 0, length 0
17:59:12.673877 IP (tos 0x0, ttl 128, id 25006, offset 0, flags [DF], proto TCP (6), length 40)
192.168.1.6.63095 > 192.168.1.2.21: Flags [R.], cksum 0xb4a8 (correct), seq 255234418, ack 3962238062, win 0, length 0
17:59:13.336204 IP (tos 0x0, ttl 54, id 26036, offset 0, flags [DF], proto TCP (6), length 52)
5.79.64.69.54638 > 192.168.1.2.49152: Flags [R.], cksum 0x1248 (correct), seq 2124211532, ack 2521790198, win 351, options [nop,nop,TS val 1542228049 ecr 776356529], length 0
17:59:13.787767 IP (tos 0x0, ttl 50, id 21256, offset 0, flags [DF], proto TCP (6), length 52)
199.115.113.101.49909 > 192.168.1.2.49152: Flags [R.], cksum 0x887d (correct), seq 2846332746, ack 654602304, win 348, options [nop,nop,TS val 1580058541 ecr 776356622], length 0

Post by Richard Kettlewell
Is there anything else on the same network?

I unplugged two windows 8.1 machines - still goes wrong

Post by Richard Kettlewell
Does the server have any iptables rules?

I didn't set any up, I see:
# iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination

Chain FORWARD (policy ACCEPT)
target prot opt source destination

Chain OUTPUT (policy ACCEPT)
target prot opt source destination

[Richard Kettlewell]

Post by Patrick Byrne

Post by Richard Kettlewell
Can you turn on MAC addresses for the packet capture?

The MAC addresses match those reported by the wireless adaptor on my
laptop and the ethernet adaptor on the server. Is that enough?

Yes - it (mostly) rules out the possibility of some other host
interfering.

Post by Patrick Byrne

Post by Richard Kettlewell
Can you do a packet capture at the other endpoint to check for
consistency?

tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
17:59:12.673877 IP (tos 0x0, ttl 128, id 25006, offset 0, flags [DF], proto TCP (6), length 40)
192.168.1.6.63095 > 192.168.1.2.21: [....]

^^

Are you really running SSH on port 21?

[Patrick Byrne]

Post by Richard Kettlewell
Are you really running SSH on port 21?

I am afraid so. This is so I can login from work - which has an unbelievable number of annoying & restrictive security practices, but still leaves the ftp port open!

[Richard Kettlewell]

Post by Patrick Byrne

Post by Richard Kettlewell
Are you really running SSH on port 21?

I am afraid so. This is so I can login from work - which has an
unbelievable number of annoying & restrictive security practices, but
still leaves the ftp port open!

Try a different port number and see if you the same behavior.

This isn’t totally random suggestion, FTP includes IP addresses in the
protocol, which need translating if you FTP across a NAT, so it might be
that some translation component is getting confused by seeing the SSH
wire protocol when it’s expecting FTP.

[Patrick Byrne]

Post by Richard Kettlewell
Try a different port number and see if you the same behavior.

Yes! I change the port back to 22 and it is okay.

Is this a bug which can be reported do you think?

[Richard Kettlewell]

Post by Patrick Byrne

Post by Richard Kettlewell
Try a different port number and see if you the same behavior.

Yes! I change the port back to 22 and it is okay.

If you can figure out what’s interpreting traffic on the FTP port as FTP
you may be able to disable it. (“lsmod|grep ftp” on the server might be
a good starting point.)

Post by Patrick Byrne
Is this a bug which can be reported do you think?

I find it difficult hard to argue that treating traffic on the
registered FTP port as FTP is a bug.