(from an e-mail I sent a while ago)
Might relevant for IPv6 so setting milestone to 2.1
I was wondering about Bro's packet sorter. From a quick glance it
appears that it's only enabled if packet_sort_window is set to a non
zero value. When enabled it will sort packets
a) based on timestamps and
b) for TCP packets based on SEQ/ACK numbers (I presume to ensure that
ACKs are delivered after the data packet)
Note, this is independent from Bro's ability to process multiple trace
files (or multiple interfaces) in order. So I was wondering about the
use cases for PacketSorter, especially (a)
If the packet sorter is enabled Bro's behavior will slightly change: It
won't pass ARP packets to the ARP analyzer, and it won't create a weird
if it's not an IP packet.
I was just wondering whether anybody has recently used the packet
sorter. If not I'm wondering whether we should test this code path to
see whether it works correctly esp wrt IPv6.
Or, actually, whether the packet sorter is worth keeping or whether we
should remove the code.
And another question would be if the TCP sorting would better be handled
by the TCP analyzer?
I agree that this is better solved at the point of (multi-interface) packet capture. We added the sorter, however, so as to not presume that users can indeed change their kernels. It's certainly valid to consider that it might be more complexity than the benefits merit.
Moving this to Click should solve that as well, it can run in user-land there, though not as efficiently as if in kernel space (but probably not worse than inside Bro).
I think this actually fits very nicely with the envisioned Click-layer giving us more control over packet land stuff, so I keep up my proposal of removing the code from Bro.
patch to remove the packet sorter is in topic/bernhard/remove-packetsort
What's this? Delete?
sorry, me bad. Yes, delete. That was kind of the motivation for the patch