Why does the client send a RST packet in the handshake? - TCP-IP

This is a discussion on Why does the client send a RST packet in the handshake? - TCP-IP ; 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, ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: Why does the client send a RST packet in the handshake?

  1. Why does the client send a RST packet in the handshake?

    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.

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


  2. Re: Why does the client send a RST packet in the handshake?

    In article ,
    "Thomas S. Iversen" 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.

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


    --
    Barry Margolin, barmar@alum.mit.edu
    Arlington, MA
    *** PLEASE don't copy me on replies, I'll read them in the group ***

  3. Re: Why does the client send a RST packet in the handshake?

    > 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.


    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!

  4. Re: Why does the client send a RST packet in the handshake?

    On 2008-08-23 14:41:58 -0400, "Thomas S. Iversen" said:

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


+ Reply to Thread