Home page logo

Nmap Announce mailing list archives

Re: [tcpdump-workers] patch to print TCP RST data with -v option (fwd)
From: Darren Reed <darrenr () reed wattle id au>
Date: Sat, 15 Jul 2000 17:53:10 +1000 (EST)

Hmmm, those ascii messages in RST packets should be very fruitful when it
comes to doing system identification :-)

Even more, if you get messages like the one below from HP-UX 11.0, it gives
big clues on what's open, etc.


----- Forwarded message from Kevin Steves -----

From owner-tcpdump-workers-outgoing () lox sandelman ottawa on ca Sat Jul 15 15:30:01 2000
Date: Sat, 15 Jul 2000 07:16:40 +0200 (METDST)
From: Kevin Steves <stevesk () sweden hp com>
To: tcpdump-workers () sandelman ottawa on ca
cc: stevesk () sweden hp com
Subject: Re: [tcpdump-workers] patch to print TCP RST data with -v option
In-Reply-To: <20000713222154.G348 () quadrajet flashcom com>
Message-ID: <Pine.HPP.4.10.10007150625020.5318-100000 () b0fh sweden hp com>
Sender: owner-tcpdump-workers () sandelman ottawa on ca
Precedence: bulk
Reply-To: tcpdump-workers () sandelman ottawa on ca

On Thu, 13 Jul 2000, Guy Harris wrote:
On Thu, Jul 13, 2000 at 07:31:30PM +0200, Kevin Steves wrote:
If the segment has RST set, should we dissect the payload based on the
source and destination ports, or should we just treat it as an error
message and dissect it with "print_tcp_rst_data()"?

I think the latter.

RFC1122 says:

    It has been suggested that a RST segment could contain
    ASCII text that encoded and explained the cause of the
    RST.  No standard has yet been established for such

I'm not sure what is meant by using ASCII text to encode the message, but
print_tcp_rst_data() is printing the ASCII text (isgraph()+' ') in the
segment.  I'm not sure how further it could be disected given the lack of
a standard.

I.e., is there any reason to expect that an RST segment's data is
regular traffic for the protocol that's running atop TCP?  RFC 793 says:

  As a general rule, reset (RST) must be sent whenever a segment arrives
  which apparently is not intended for the current connection.  A reset
  must not be sent if it is not clear that this is the case.

which I'd be inclined to read as an indication that the data would never
be data for a connection, as the reason for the RST is that the incoming
packet was for some *other* connection.

The text in RST segments I've seen (primarily from HP-UX 11.0), try to
convey the reason for the RST.

07:00:37.980230 rush.49426 > S 2722062812:2722062812(0)
win 32768 <mss 1460,wscale 0,nop> (DF) (ttl 64, id 47976)
07:00:41.050629 rush.49426 > S 2722062812:2722062812(0)
win 32768 <mss 1460,wscale 0,nop> (DF) (ttl 64, id 47977)
07:00:41.357825 rush.49426 > R 2722062813:2722062838(25)
win 0 [RST tcp_close, during connect] (DF) (ttl 64, id 47978)

Here I terminated a TCP in SYN_SENT.

Some vendors do other interesting things:

07:10:47.766867 stkseagw1.1999 > rush.49431: R 0:5(5) ack
2800975579 win 0 [RST cisco] (ttl 252, id 42623)

That is a Cisco router.

This is the TCPDUMP workers list. It is archived at
To unsubscribe use mailto:tcpdump-workers-request () tcpdump org?body=unsubscribe

----- End of forwarded message from Kevin Steves -----

  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]