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 > ___________________________________________________________________________ Sent via: Wireshark-dev mailing list <[email protected]> Archives: https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:[email protected]?subject=unsubscribe
