This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

dissector debugging – how to find the exact line of a “malformed packet” exception

0

I'm developing a dissector for a custom protocol and have been getting "Malformed Packet" messages like the one shown below. From what I understand this is usually caused by overflowing a tvb. Is there any way to get some sort of stack trace so I can see exactly where my dissector/protocol is throwing the error?

Expert Info (Error/Malformed): Malformed Packet (Exception occurred)
Message: Malformed Packet (Exception occurred)
Severity level: Error
Group: Malformed

asked 28 Jun '11, 16:51

mitch_feaster's gravatar image

mitch_feaster
6114
accept rate: 0%

edited 28 Jun '11, 16:56


2 Answers:

3

You could try stepping through execution of your dissector using a debugger. If you have a capture file and you want to narrow down the problem, use editcap (or Wireshark, I suppose) to "divide-and-conquer". Keep splitting the file in half until you isolate the offending packet. That may or may not make it obvious as to what part of your code is mis-behaving, but if not, it will still make stepping through execution in the debugger easier.

answered 29 Jun '11, 10:38

cmaynard's gravatar image

cmaynard ♦♦
9.4k1038142
accept rate: 20%

edited 29 Jun '11, 18:44

Hmmm, well I already know the offending packets (I can even do a filter on "malformed" to find them) but those packets are decoding hundreds of messages, so using the debugger will be a bit of a pain... But it looks like that's my only option right now :). It would at least be nice if I could set a breakpoint in the exception handling code and then look at the stack trace from there but I can't quite pin down where that happens...

(29 Jun '11, 13:43) mitch_feaster

@mitch_feaster: So long as the error isn't dependent on a complete conversation, you could filter your capture so that only the malformed packets are displayed, then save only the displayed packets and debug using that file. That way, you could step with the debugger in a minimal subset. Probably not a totally optimal solution, but at least better than debugging with a full capture.

(29 Jun '11, 15:08) multipleinte...

@mitch_feaster: You might try setting a breakpoint in epan/dissectors/packet-frame.c's show_reported_bounds_error() function.

(29 Jun '11, 18:44) cmaynard ♦♦

0

Try setting the environment variable WIRESHARK_ABORT_ON_DISSECTOR_BUG before running Wireshark.

answered 29 Jun '11, 00:08

Jaap's gravatar image

Jaap ♦
11.7k16101
accept rate: 14%

Still nothing...

(29 Jun '11, 09:39) mitch_feaster