-
Notifications
You must be signed in to change notification settings - Fork 896
New issue
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
RESP protocol dissector implementation #2287
Comments
Is it possible to use the field length for a successful detection? // EDIT: Did not read the protocol specs yet. 😄 |
Well, I'm not sure about that. Btw, here are some pcap samples resp.zip |
Something like (in pseudo code)?
It should be enough... |
So, you mean something like this?
|
We can have a number bigger than 9... Just the idea (without all the necessary checks on payload length)
|
Lol, I just noticed that nDPI has a RESP protocol dissector, but it's just called "Redis" for some reason. Ofc it doesn't work, so this question is still relevant. |
@IvanNardi Thanks for your help, now I have figured out how to solve this issue. |
RESP = Redis serialization protocol |
Yeah, I know. RESP sounds more correct than just Redis. |
@IvanNardi @utoni hey guys. Atm I'm working on a RESP protocol dissector, but I've encountered some issues and I'm looking for expert advice.
RESP PDUs start with
*
followed by the field length and\r\n
, so the first thing that came to mind was this check:But I suspect that such a simple check could potentially cause a lot of false positives - even if I haven't seen it on pcap examples from nDPI, it doesn't guarantee anything. Or maybe I'm worrying for nothing?
I thought about adding a check like
if (flow->l4.tcp.resp_valid_packets > 2) {...} if(flow->packet_counter > 5) { NDPI_EXCLUDE_PROTO(ndpi_struct, flow); }
, but that breaks the detection of some flows since* .. \r\n
is often located not at the start of the segment.The text was updated successfully, but these errors were encountered: