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 <[email protected]> > Archives: http://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev > mailto:[email protected]?subject=unsubscribe > ___________________________________________________________________________ Sent via: Wireshark-dev mailing list <[email protected]> Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:[email protected]?subject=unsubscribe
