[
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
[email protected]
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
