Guy, thank you very much for your help! I was using a version which was slightly modified by my colleague here. It turns out it's his change that caused this problem. Mystery solved :)
Best, Joshua On Tue, Jul 21, 2009 at 3:06 AM, Guy Harris <[email protected]> wrote: > > On Jul 20, 2009, at 3:41 PM, Joshua (Shiwei) Zhao wrote: > > > I believe it's a bug there, at least in 1.0.4 I'm using. > > I don't believe all packets have that big headers over 500 bytes. > > What matters is whether all the data dissected in the packet is bigger > than the snapshot length; in an SMB request or response, for example, > that would include any radio header the packet has, the 802.11 header, > the IP header, the TCP header, the NetBIOS-over-TCP or SMB-over-TCP > header, and the entire SMB message, with the possible exception of > data in a read reply or write request. > > > The code must checked the whole data payload size, instead of only > > checking the header length when it tries to dissect and throw an > > execption. > > I'll try to debug. Meanwhile any hints/suggestions are welcome. > > Could you extract from the capture file one of the packets that's > claimed to have been cut short and send it to us? > > ___________________________________________________________________________ > 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
