[Snort-devel] Yet more data corruption in stream4/snort-2.0.5

Jim Cervantes jcervant at ...2278...
Wed Dec 3 19:46:00 EST 2003

Regarding out-of-order packets in a TCP conversation, are you sure this
isn't merely an artifact of how you have captured packets from your network?
Are you mirroring ports on a switch?  If so, I don't see how you can safely
assume that the merged packet stream will *always* preserve a conversation's
packet order, particularly under load.  Furthermore, consider the following

client: seq 1 / 1024 data
server: ack 1025
client: seq 1025 / 1024 data  (sensor doesn't see this)
server: ack 2049              (client doesn't see this)
client: seq 1025 / 1024 data  (client retransmits)

In this case the packets seen by the sensor merely appear to be out of
conversational order.


-----Original Message-----
From: snort-devel-admin at lists.sourceforge.net
[mailto:snort-devel-admin at lists.sourceforge.net]On Behalf Of Andrew
Rucker Jones
Sent: Wednesday, December 03, 2003 3:37 PM
To: Martin Olsson; snort-devel at lists.sourceforge.net
Subject: Re: [Snort-devel] Yet more data corruption in

Hash: SHA1

Hi Martin (and everyone else)!
	No, dude, i know TCP better than that. :) That is also perfectly normal
TCP behavior, and would not cause the data corruption that i briefly
mentioned. I must have expressed myself poorly. It was late when i wrote
my e-mail yesterday.
	What i mean is, the client sends a packet with the sequence number 1
(for example), and 1024 bytes of data. Then the server sends an
acknowledge for sequence number 1025 (still normal). Immediately after
that, the server sends another acknowledge for sequence number 2049,
AFTER which the client sends a data packet with the sequence number 1025
and 1024 bytes of data. Should never happen, but i saw it. It's not
impossible that it's a bug somewhere in my sensor, but Linux+tcpdump
doesn't seem to me to be that suspicious where bugs like that are concerned.


|>2) Has anyone ever seen a case where one side of a connection
|>acknowledges data that have not yet been sent? I swear that i have a
|>real world capture (an e-mail to a Yahoo! address) in which the client
|>sends data up to sequence number X, after which the server sends two
|>ACKs right after each other: one for X, and one for X+1024 or so. Right
|>after that, the client sends the next 1024 bytes. There are no
|>retransmits involved. Of course, that causes data corruption, too, but
|>snort can hardly be blamed for that. That entire conversation was just
|>as weird as can be, i have to say.
| Now, you seem to know your RFCs and TCP/IP in general, so I guess it is
| not as easy as this, but given your description it could be:
| If your client send a TCP packet with 1024 bytes of data, and this packet
| have sequence number X, then the server will acknowledge this packet with
| an ack number of X+1024.
| Take a look at the three way handshake plus 1024 bytes of data:
| ---> SYN       Seq: X      Ack: 0 (nothing to ack yet)
| <--- SYN ACK   Seq: Y      Ack: X+1 (SYN counts as 1)
| ---> ACK       Seq: X+1    Ack: Y+1
| ---> PSH ACK   Seq: X+1    Ack: Y+1   Data: <1024 bytes>
| <--- ACK       Seq: Y+1    Ack: X+1+1024

- --
GPG key / Schlüssel -- http://simultan.dyndns.org/~arjones/gpgkey.txt
Encrypt everything. / Alles verschlüsseln.

Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


This SF.net email is sponsored by OSDN's Audience Survey.
Help shape OSDN's sites and tell us what you think. Take this
five minute survey and you could win a $250 Gift Certificate.
Snort-devel mailing list
Snort-devel at lists.sourceforge.net

More information about the Snort-devel mailing list