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_at_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_at_sweden.hp.com>
> To: tcpdump-workers_at_sandelman.ottawa.on.ca
> cc: stevesk_at_sweden.hp.com
> Subject: Re: [tcpdump-workers] patch to print TCP RST data with -v option
> In-Reply-To: <20000713222154.G348_at_quadrajet.flashcom.com>
> Message-ID: <Pine.HPP.4.10.10007150625020.5318-100000_at_b0fh.sweden.hp.com>
> Sender: owner-tcpdump-workers_at_sandelman.ottawa.on.ca
> Precedence: bulk
> Reply-To: tcpdump-workers_at_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_at_tcpdump.org?body=unsubscribe
>
> ----- End of forwarded message from Kevin Steves -----
Received on Jul 15 2000
Intro
