Wireshark-bugs: [Wireshark-bugs] [Bug 12826] usage http-tcp dissector from lua dissector lead to
Comment # 10
on bug 12826
from Peter Wu
(In reply to Michael Mann from comment #9)
> (In reply to Peter Wu from comment #8)
> > Maybe we should drop this data parameter and use p_add_proto_data:
>
> I would rather rewrite the dissector function signature (to have "data
> pointer + type") than use p_add_proto_data. It makes code flow MUCH harder
> to follow (and easier to create bugs as a result). It was one of the
> reasons I tried to rid dissectors of using pinfo->private_data (and other
> members than have since been removed).
If a dissector documents what data it provides or requires, then how would it
be harder to follow the code flow? The data is per-packet and you are supposed
to set the field before invoking the subdissector.
> For this particular bug, I would prefer that http have 2 function signatures
> - one that expects TCP data and one that doesn't. Then both functions would
> call a "common" function where necessary TCP data would be passed in
> (defaulted in function with NULL data)
HTTP has already multiple signatures (http-over-tls, http-over-sctp,
http-over-tcp and just "http"). IIRC only the "http-over-tcp" uses the data
parameter at the moment. Alternative functions will not solve the problem of
Lua being able to obtain a dissector handle and then invoking that with a NULL
data parameter.
For this case where the "tcp" dissector always provides the data, we could add
this special case in the Lua dissector:
If the original dissector table matches the one of the subdissector, pass the
data parameter. E.g. the original http dissector is registered on "tcp.port",
the new dissector function is likely registered to this as well, so propagate
the tcp_info. If the new dissector function was registered through
"usb.product" (for example), then just pass NULL.
This does not help though in cases like the modbus (mbtcp) dissector since that
is not registered through a dissector table. The current APIs unfortunately do
not have the information on the expected type.
You are receiving this mail because:
- You are watching all bug changes.
