I like the idea of logging gap ranges for a connection. Could a vector be used to store gap start and gap stop offsets?
-AK On Tue, Apr 9, 2019, 11:01 Jim Mellander <jmellan...@lbl.gov> wrote: > Thanks. I was thinking of something a bit different - the total amount of > the content gap is useful, but in some cases it might be useful to know > where the content gaps occurred, whether in the head of the connection, > which likely is impactful for protocol analysis, or in a long tail, where > it probably doesn't affect analysis. > > Perhaps some tunable setting indicating that "I only care about content > gaps in the first 10K (or whatever) of the connection" could address that... > > On Tue, Apr 9, 2019 at 9:36 AM Justin Azoff <jus...@corelight.com> wrote: > >> >> >> On Mon, Apr 8, 2019 at 8:13 PM Jim Mellander <jmellan...@lbl.gov> wrote: >> >>> It might be valuable to have some (optional) way of accessing the byte >>> counts consisting the content gap(s). If the content gap is somewhere in a >>> long tail, but DPD still fails, then the explanation could be something >>> other than a content gap. >>> >>> On the other hand, maybe you're just thinking about content gaps at the >>> head of a connection before it has been fully analyzed. >>> >> >> This is the missed_bytes field: >> >> missed_bytes: count &log &default = 0 &optional >> Indicates the number of bytes missed in content gaps, which is >> representative of packet loss. A value other than zero will normally cause >> protocol analysis to fail but some analysis may have been completed prior >> to the packet loss. >> >> -- >> Justin >> > _______________________________________________ > zeek-dev mailing list > zeek-dev@zeek.org > http://mailman.icsi.berkeley.edu/mailman/listinfo/zeek-dev >
_______________________________________________ zeek-dev mailing list zeek-dev@zeek.org http://mailman.icsi.berkeley.edu/mailman/listinfo/zeek-dev