[ https://bro-tracker.atlassian.net/browse/BIT-348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16227#comment-16227 ]
Robin Sommer commented on BIT-348: ---------------------------------- I did some more testing on a large trace, and I am seeing differences in the duration of a few connections. Have you seen that as well / do you have an idea where that's coming from? Here's an example: {code} before: 1359400833.646398 CHrUQS2wXshH59NEb6 XXXX 35752 YYYY 80 tcp http 3.497443 380 428 SF 429 ShADaFfRR 8 712 4 172 (empty) after: 1359400833.646398 C9yL7F1JnxhPtfoLMi XXXX 35752 YYYY 80 tcp http 0.240429 380 428 SF 429 ShADaFfRR 8 712 4 172 (empty) {code} (I didn't sync the rnd seed for the uids). I'll provide the trace if you want to look at it. > Reassembler integer overflow issues. Data not delivered after 2GB > ----------------------------------------------------------------- > > Key: BIT-348 > URL: https://bro-tracker.atlassian.net/browse/BIT-348 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master > Reporter: gregor > Assignee: Robin Sommer > Priority: High > Labels: inttypes > Fix For: 2.3 > > > {noformat} > #!rst > The TCP Reassembler does not deliver any data to analyzers after the first > 2GB due to signed integer overflow (Actually it will deliver again between > 4--6GB, etc.) This happens silently, i.e., without content_gap events or > Undelivered calls. > This report superseded BIT-315, BIT-137 > The TCP Reassembler (and Reassem) base class use ``int`` to keep track of > sequence numbers and ``seq_delta`` to check for differences. If a connection > exceeds 2GB, the relative sequence numbers (int) used by the Reassembler > become negative. While many parts of the Reassembler still work (because > seq_delta still reports the correct difference) some parts do not. In > particular ``seq_to_skip`` is broken (and fails silently). There might well > be other parts of the Reassembler that fail > silently as well, that I haven't found yet. > See Comments in TCP_Reassembler.cc for more details. > The Reassembler should use int64. However this will require deep changes to > the Reassembler and the TCP Analyzer and TCP_Endpoint classes (since we also > store sequence numbers there). Also, the analyzer framework will need tweaks > as well (e.g., Undelivered uses ``int`` for sequence numbers, also has to go > to 64 bit) > As a hotfix that seems to work I disabled the ``seq_to_skip`` features. It > wasn't used by any analyzer or policy script (Note, that seq_to_skip is > different from skip_deliveries). Hotfix is in > topic/gregor/reassembler-hotfix > {noformat} -- This message was sent by Atlassian JIRA (v6.3-OD-02-026#6318) _______________________________________________ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev