Add stream following capability #9
Conversation
The -J option will print packets following a match but only those that are in the same TCP stream as the match. If another packet matches during the following, the number counter is reset. This helps mitigate problems with a match not having enough packets after it in the same stream (which could mean ngrep prints nothing forever after the match). This functionality can be defeated with the -Q option.
|
Hot damn, nice! Thanks for the patch! Here's a thought -- Anyway, what do you think about modifying |
|
While I haven't personally needed it, I could see |
|
I think changing Will merge sometime this week, when I hunt down the SIP trailing chars bug in #10. |
|
So So now I'm thinking, what might be the most memorable/relevant/defensible option names for your |
|
|
||
| if (keep_matching && follow_stream) { | ||
| if (follow_ip_src == NULL) { | ||
| follow_ip_src = ip_src; |
There was a problem hiding this comment.
How much have you tested this functionality?
You introduce the global pointer follow_ip_src and set it to ip_src, which itself is a stack-based variable in the caller process() - thus ip_src deallocates with every call. This would make for a dangling global pointer on the next call, possibly creating a crash or a secvuln. I can see it maybe working anyway, either due to things just lining up with the same stack address for ip_src, or subsequent matches still happening due to a port match.
Do I misunderstand?
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!