Add stream following capability
I have a cluster of machines handling nearly a million packets a second. I wanted to get the HTTP responses to HTTP requests that matched a regexp. Check the commit message for details.
Super-cool utility!
Hot damn, nice! Thanks for the patch!
Here's a thought -- -A has always been a useful grep parity option, but back in my netops days I'd regularly pass a higher number to it when looking at busy flows, to increase the chances of actually catching the subsequent packets from the stream I was interested in. Not sure why it didn't occur to me to do the logical equivalent of your patch, I guess maybe I compensated for it with more restrictive BPF filters as I zeroed in on it.. dunno.
Anyway, what do you think about modifying -A's behavior instead of creating a new one with -J? Can you think of a use case where -A's behavior is ever better/desired over -J's?
While I haven't personally needed it, I could see -A being useful to grab DNS transactions or other non-TCP stuff. Maybe if -A worked as today when it matches in a non-TCP packet but follows the stream when it is TCP?
I think changing -A only some of the time has the potential to be surprising (ergo not good). So I think I'll stick with a new flag. Appreciate the help thinking it through.
Will merge sometime this week, when I hunt down the SIP trailing chars bug in #10.
So -A should be the anchoring behavior - show packets following a match. Your -J and -Q are modifiers of that behavior. So -J shouldn't take an option - otherwise you could specify -A and -J at the same time and that doesn't make sense.
So now I'm thinking, what might be the most memorable/relevant/defensible option names for your -J and -Q, as a complement to -A. Ideas?