Why does the client send a RST packet in the handshake?
Thomas S. Iversen
there has been no connections for a while I get
ssh: connect to host 213.98.208.60 port 22: Connection refused
If I then retry after that, I get a connection as I should. Puzzled by
this I then ran tcpdump on both the server and the client. The
sequences (rather short) can be seen below. I have limited practical
experience with troubleshooting tcp/ip problems, so I can not see why
the client would send an RST packet when the server (or something
else) has been idle for a while.
I should mention that this happends with different client machines. I
should also mention that I observed the same when I had another server
on the same cable (although still a variant of Linux). So my first
take would be some routing, switch, cable problem, but can that really
be the case? Could a guru please enlightnen me as to why the RST
packet is sent and what the cause could be.
Best regards Thomas, denmark
Server:
Linux bell 2.6.18-6-powerpc64 #1 SMP Wed Jun 18 06:03:18 UTC 2008 ppc64 GNU/Linux
1 0.000000 86.81.228.141 213.98.208.60 TCP 22923 > ssh [SYN] Seq=0 Win=5840 Len=0 MSS=1460 TSV=4493491 TSER=0 WS=7
2 0.002246 Ibm_76:ab:fc Broadcast ARP Who has 213.98.208.126? Tell 213.98.208.60
3 0.002495 All-HSRP-routers_00 Ibm_76:ab:fc ARP 213.98.208.126 is at 00:00:0c:07:ac:00
4 0.002524 213.98.208.60 86.81.228.141 TCP ssh > 22923 [SYN, ACK] Seq=0 Ack=1 Win=5792 Len=0 MSS=1460 TSV=103519414 TSER=4493491 WS=7
5 0.013271 86.81.228.141 213.98.208.60 TCP 22923 > ssh [RST] Seq=1 Win=0 Len=0
Client:
Linux laptop 2.6.24-16-generic #1 SMP Thu Apr 10 13:23:42 UTC 2008 i686 GNU/Linux
206 3.668773 10.0.0.8 212.242.40.3 DNS Standard query A <hostname>
207 3.745613 212.242.40.3 10.0.0.8 DNS Standard query response A 213.96.208.60
208 3.745856 10.0.0.8 213.96.208.60 TCP 33749 > ssh [SYN] Seq=0 Win=5840 Len=0 MSS=1460 TSV=4493491 TSER=0 WS=7
209 3.758447 213.96.208.60 10.0.0.8 TCP ssh > 33749 [RST, ACK] Seq=1 Ack=1 Win=0 Len=0
--
"There are two ways of constructing a software design: One way is to
make it so simple that there are obviously no deficiencies, and the
other way is to make it so complicated that there are no obvious
deficiencies. The first method is far more difficult." -C.A.R. Hoare
Barry Margolin
"Thomas S. Iversen" <zens...@zensonic.dk> wrote:
> I have set up a little server at work. It runs an ssh daemon. When
> there has been no connections for a while I get
>
> ssh: connect to host 213.98.208.60 port 22: Connection refused
>
> If I then retry after that, I get a connection as I should. Puzzled by
> this I then ran tcpdump on both the server and the client. The
> sequences (rather short) can be seen below. I have limited practical
> experience with troubleshooting tcp/ip problems, so I can not see why
> the client would send an RST packet when the server (or something
> else) has been idle for a while.
>
> I should mention that this happends with different client machines. I
> should also mention that I observed the same when I had another server
> on the same cable (although still a variant of Linux). So my first
> take would be some routing, switch, cable problem, but can that really
> be the case? Could a guru please enlightnen me as to why the RST
> packet is sent and what the cause could be.
Looks to me like a firewall or IDS between the devices is blocking the
connection. Neither device is sending an RST, but they're both
receiving one.
The fact that the original SYN got through is unusual, though. This
makes me think it's a passive sniffing device, not an inline router or
firewall, because they usually block the entire connection.
--
Barry Margolin, bar...@alum.mit.edu
Arlington, MA
*** PLEASE don't copy me on replies, I'll read them in the group ***
Thomas S. Iversen
> connection. Neither device is sending an RST, but they're both
> receiving one.
But what about the connection being established seconds later with a
normal SYN, SYN/ACK, ACK squence? Does that still fit into the above
scenario?
Thomas
--
I don't mind coming to work, but that eight hour wait to go home is a bitch!
Digital Mercenary For Honor -2-
>> Looks to me like a firewall or IDS between the devices is blocking the
>> connection. Neither device is sending an RST, but they're both
>> receiving one.
Not sure if this applies, insufficient info, but check in your traces
if you're being round-robin DNS'd to the destination host (from your
ssh error message, no, so if you're doing it by IP, forget the rest of
this paragraph), check to see if the IP address of the host changes in
your trace sometimes? Would not expect it to be, it should be cached by
somebody after the first resolve, and a few seconds gone by is not a
typical TTL, but, just in case.
I guess the second example from your trace is a second attempt, since
the TCP high-ports don't match up between the traces?
In the obscure, obscure case, I could see a bad firewall rule blocking
traceroutes and mistakenly including UDP, the base UDP traceroute port
number I think is 33434 and counts up, etc.
Barry's got the best scoop so far though, and that makes me think about
a transparent bridge firewall in the way.
/dmfh
--
_ __ _
__| |_ __ / _| |_ 01100100 01101101
/ _` | ' \| _| ' \ 01100110 01101000
\__,_|_|_|_|_| |_||_| dmfh(-2)dmfh.cx