Wireshark-dev: Re: [Wireshark-dev] Packet Size limited during capture message
From: Guy Harris <[email protected]>
Date: Tue, 23 Mar 2010 17:55:06 -0700
On Mar 23, 2010, at 5:40 PM, Brian Oleksa wrote:

> The snaplen was set to 150 when using tshark.
> I see a Frame that says (for example):     Frame 7 (341 bytes on wire, 
> 150 bytes captured).

Yup.  That'll certainly give you "Packet size limited during capture".

> And NO... the pcap file doesn't crash when the dissector is removed.

So that suggests that it's a bug somewhere in your dissector.

> I 
> can load about 70% of it and hit stop....but
> if I let it go any further it will crash wireshark.

So is the packet with "Packet size limited during capture" in that 70%?

And is it a Helen packet, or a packet for some other protocol?

> Like I said in my email to martin.... if I followed all the wireshark 
> coding standards... shouldn't the code handle this..??

As long as you follow all the Wireshark coding standards, it should not crash as a result of running past the end of the packet and attempting to refer to a non-existent region of memory past the buffer for the packet.  (This is one reason why getting a pointer to the packet data, and then extracting data yourself, is not the right thing to do - you'd have to do all the checks, not only for the on-the-wire packet size but also for the captured size, yourself.)

*However*, if, for example:

	for some Helen packets, the dissector requires information from earlier Helen packets in the capture;

	that information is in the part of the packet that got cut off;

	the dissector is *assuming* the information was stored somewhere when the earlier packet was dissected, rather than *checking* whether it was stored and doing whatever it can if the information wasn't stored;

the dissector could still crash - the low-level boundary checking done by proto_tree_add_item() and the various tvb_get_ routines won't protect you from a problem such as that.  (That's just an example of a crash that could happen with a dissector that follows the low-level rules if a packet is cut short; it's not *the one and only* reason, so, even if that's *not* the case for your dissector, there could be some other problem of that sort.)

> What should be my next step..??

Find out where it's crashing - for example, by using a debugger - and fix it not to crash.