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
asked 28 Jun '11, 16:51 mitch_feaster edited 28 Jun '11, 16:56 |
2 Answers:
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 ♦♦ edited 29 Jun '11, 18:44 |
Try setting the environment variable answered 29 Jun '11, 00:08 Jaap ♦ Still nothing... (29 Jun '11, 09:39) mitch_feaster |
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...
@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.
@mitch_feaster: You might try setting a breakpoint in epan/dissectors/packet-frame.c's show_reported_bounds_error() function.