[lkml]   [2000]   [Oct]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
Subjectack number in a connection-refused RST
Usually, when I try to connect to a port with nothing listening on it, it
looks like this:

17:11:20.809712 eth0 > MYHOST.2514 > OTHERHOST.auth: S 2807001202:2807001202(0) win 32120 <mss 1460,sackOK,timestamp 39176091 0,nop,wscale 0> (DF)
17:11:20.819712 eth0 < OTHERHOST.auth > MYHOST.2514: R 0:0(0) ack 2807001203 win 0

MYHOST is my Linux box. The OTHERHOST can be almost anything. The ECONNREFUSED
error comes immediately on receipt of the RST packet. Just as it should be.

But I've found one host, BADHOST, which times out instead of giving
ECONNREFUSED. And at first I couldn't figure out why, since it too sends a
RST packet:

17:11:23.599564 eth0 > MYHOST.2515 > BADHOST.auth: S 2805193937:2805193937(0) win 32120 <mss 1460,sackOK,timestamp 39176370 0,nop,wscale 0> (DF)
17:11:23.719558 eth0 < BADHOST.auth > MYHOST.2515: R 0:0(0) ack 2805193937 win 0

Then I looked at the sequence numbers. In OTHERHOST's RST packet, the ack
number was 1 higher than the sequence number in the SYN packet. in BADHOST's
RST packet, the ack number is the *same* as the sequence number in the SYN


1. Could/should the Linux kernel be patched to recognize the one-off sequence
number and return ECONNREFUSED?
2. If the BADHOST behavior is incorrect, can a TCP expert please explain
exactly why, so a bug report can be filed...
3. Does anybody know where to file a bug report on the Sega Dreamcast TCP?
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:39    [W:0.060 / U:2.060 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site