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

Andrew Rucker Jones arjones at ...2237...
Wed Dec 3 19:59:02 EST 2003

Hash: SHA1

There are definitely no dropped packets. The four packets i'm talking
about all occur within milliseconds of each other. Yes, i was sniffing
on a mirrored port on a switch. Does that have the potential to mix up
the ordering of packets? Doesn't seem like it should... This switch
isn't under high load, either. It is the switch between our firewall and
our router to the Internet. Average usage is around 4-5Mbps. I suspect a
100Mbps switch can mirror that without too many problems, especially
when that's the only real traffic going over it. Personally, i'm voting
for Jeff's explanation: some stupid "optimization". Like i say, the rest
of that one conversation was also really wacky, at least from the remote


Jim Cervantes wrote:
| 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
| Are you mirroring ports on a switch?  If so, I don't see how you can
| assume that the merged packet stream will *always* preserve a
| packet order, particularly under load.  Furthermore, consider the
| conversation:
| 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.
| Jim

- --
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


More information about the Snort-devel mailing list