[Snort-devel] Yet more data corruption in stream4/snort-2.0.5
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
From: snort-devel-admin at lists.sourceforge.net
[mailto:snort-devel-admin at lists.sourceforge.net]On Behalf Of Andrew
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
-----BEGIN PGP SIGNED MESSAGE-----
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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
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