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.