On Fri, Jun 15, 2018 at 9:54 PM, Vern Paxson <v...@corelight.com> wrote:
> > it unclear on the logarithmic > > counts. Take, for instance SaDtTtT. If I'm reading this correctly, I > think > > that means 10-99 retransmissions from orig, followed by 10-99 from resp, > > then more retransmissions from orig (enough to reach a total of 100-999), > > and similarly more from resp. > > Correct in principle. (1) These would be 1-9 followed by enough to > get to 10-99, since a single retransmission is already a 't' / 'T', and > (2) lower letters are responders rther than originators. > Ah, right. Thanks for clearing that up. > > Maybe we add the > > new letters, but don't repeat them and also add new fields for exact > > bytecounts? > > I'm not following this. If we add new letters that don't repeat *and* we > add new fields, why do we need the letters given that the fields are there? > My thought for this was simply if it mattered *where* in the state history the trouble occurred. For instance, if I'm seeing retransmissions at the very end of a connection, that might indicate that one side abruptly terminated the connection (I'd see this with things like fail2ban inserting an iptables rule to block a brute-forcer). Similarly, if I see a zero window at the start of a connection, that would tell me that the buffer was full due to another connection or connections, as opposed to filling up due the connection I'm looking at. I'm having a tough time thinking up additional use-cases without having some sample data, so perhaps the best course is to add what you proposed, and then revisit it if we feel like anything's missing. --Vlad
_______________________________________________ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev