Guy
The 70% that I can load has a bunch of helen packets in it and every one
of the helen packets has the
"Packet size limited during capture" message. Even the very first helen
packet.
I do not believe that one packet relies on one another. A packet is just
a packet.
I will have to use the debugger to dig deeper into this one.
Thanks,
Brian
Guy Harris wrote:
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.
___________________________________________________________________________
Sent via: Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives: http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe