We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Noticed that justniffer drops some requests, supposedly those that weren't correctly closed.
Example: https://vos.uz/f/t/1.pcap — drops this request https://vos.uz/f/t/2.pcap — parses this one fine
NIDS state transition on a normal stream: 7 → 1 → 2 → 2 → 3 (NIDS_CLOSE) On a buggy stream: 7 → 1 → 2 → 2 → 6 (NIDS_EXITING)
I also noticed that -t (bool handle_truncated) isn't used anywhere. Perhaps NIDS_EXITING should be handled like that:
-t
diff --git a/src/formatter.cpp b/src/formatter.cpp old mode 100644 new mode 100755 index 7f45024..aff0342 --- a/src/formatter.cpp +++ b/src/formatter.cpp @@ -60,6 +60,9 @@ void parser::nids_handler(struct tcp_stream *ts, void **yoda, struct timeval* t, } break; case NIDS_EXITING: + if (theOnlyParser->handle_truncated) { + theOnlyParser->process_timedout_connection(ts, t, packet); + } break; case NIDS_OPENING: theOnlyParser->process_opening_connection(ts, t, packet);
I didn't look into the architecture though, this one outputs the postponed line after all the other ones of the dump file, out of order
The text was updated successfully, but these errors were encountered:
No branches or pull requests
Noticed that justniffer drops some requests, supposedly those that weren't correctly closed.
Example:
https://vos.uz/f/t/1.pcap — drops this request
https://vos.uz/f/t/2.pcap — parses this one fine
NIDS state transition on a normal stream: 7 → 1 → 2 → 2 → 3 (NIDS_CLOSE)
On a buggy stream: 7 → 1 → 2 → 2 → 6 (NIDS_EXITING)
I also noticed that
-t
(bool handle_truncated) isn't used anywhere. Perhaps NIDS_EXITING should be handled like that:I didn't look into the architecture though, this one outputs the postponed line after all the other ones of the dump file, out of order
The text was updated successfully, but these errors were encountered: