[ https://bro-tracker.atlassian.net/browse/BIT-700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15542#comment-15542 ]
grigorescu commented on BIT-700: -------------------------------- What I was hoping to do was to use the timestamp IP option to sort the packets, but I'm still trying to figure out if that's reliable with Cisco routers. Alternatively, for TCP the sorting by sequence number would also be useful. As for whether or not this belongs in Bro - I could see an argument for both sides. I think the fundamental question is how commonly does this occur? Is this an artifact of some issue with the tapping infrastructure, or are out of order packets expected traffic on most networks? If the current PacketSorter implementation needs reworking, perhaps the TCP reassembler should be extended to deal with out of order packets? I'm not trying to advocate for one particular approach, as long as I have some mechanism of dealing with this. :-) > PacketSorter > ------------ > > Key: BIT-700 > URL: https://bro-tracker.atlassian.net/browse/BIT-700 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Reporter: gregor > Assignee: Robin Sommer > Labels: BroV6,, IPv6 > Fix For: 2.3 > > > (from an e-mail I sent a while ago) > Might relevant for IPv6 so setting milestone to 2.1 > Hi, > 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? > Opinions? -- This message was sent by Atlassian JIRA (v6.2-OD-09-036#6252) _______________________________________________ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev