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. Darren
----- 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 data. 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 > 15.1.1.1.telnet: S 2722062812:2722062812(0) win 32768 <mss 1460,wscale 0,nop> (DF) (ttl 64, id 47976) 07:00:41.050629 rush.49426 > 15.1.1.1.telnet: S 2722062812:2722062812(0) win 32768 <mss 1460,wscale 0,nop> (DF) (ttl 64, id 47977) 07:00:41.357825 rush.49426 > 15.1.1.1.telnet: 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 http://www.tcpdump.org/lists/workers/index.html To unsubscribe use mailto:tcpdump-workers-request () tcpdump org?body=unsubscribe ----- End of forwarded message from Kevin Steves -----
Current thread:
- Re: [tcpdump-workers] patch to print TCP RST data with -v option (fwd) Darren Reed (Jul 15)
- Re: [tcpdump-workers] patch to print TCP RST data with -v option (fwd) Kevin Steves (Jul 17)