Hi,
Glib logging won't help you much, as in, malformed packet dissection isn't a
problem in the underlying infrastructure of the program (which would cause said
log messages to be generated), but a exception caught by the dissection engine
itself. The common way to get forward is to retrieve the source code for the
dissector the malformation is detected in and find the lines of code on which
this exception is raised. The code, together with the packet bytes usually
expose the problem as perceived by the dissector. If implemented correctly this
would show the problem in the encoding of the information in the packet, or
expose a bug in the dissector, for which a bug report could be filed. But first
make sure the relevant dissector preferences are set correctly.
Thanks,
Jaap
On 03-03-17 17:56, Remy Leone wrote:
> Hello,
>
> I'm trying to debug a malformed packet.
> I've increased the log level to the level of 252 as mention in the following
> link: (https://wiki.wireshark.org/Development/Tips).
> I don't see anything helpful showing up in the stdout when I dissect the
> problematic frame.
> Most of my logs are composed of those kind of messages:
>
> 17:54:44 Capture Dbg read 16 ok indicator: P len: 3 msg: 15
> 17:54:44 Capture Dbg sync_pipe_input_cb: new packets 15
> 17:54:44 Main Dbg Callback: capture update continue
> 17:54:44 Dbg FIX: capture_info_ui_update
>
> How can I enable as much helpful information as possible to help me understand
> what went wrong during the dissection?
>
> Best regards
>
> R�my
>
