On 12/4/06, Jefferson Ogata <[EMAIL PROTECTED]> wrote:
I was merely suggesting that perhaps one of the several tools available for this purpose doesn't properly set snaplen on its output file to the max of all input snaplens.
That's likely the case. Of course I have to wonder why libpcap even stores the snaplen? Why not just create malloc a buffer 65535 bytes long (or pick another reasonable value) and validate that the capen <= that size. If not, realloc to the appropriate size. Storing (or processing) the snaplen seems to open the door for problems with little benefit (the cost of wasting a few thousand bytes or incurring the performance penalty of a realloc if the default is to small). Actually, if you took the snaplen as merely a hint to the max stored packet size and did a realloc on demand, the problem would appear to be solved rather gracefully. Basically, users don't understand why libpcap truncated their packet- or in my case they don't understand why my application truncated their packet. People want things to "just work" and it's asking a lot for most people look at hex dumps of their pcap's to understand why this is happening. And telling people "run this tool to fix your pcap" is only useful if they know this is why it's broken. Honestly, I haven't taken a close enough look to see what the effort would be to "fix" this as I've described, but if I submitted a patch would it be accepted? -- Aaron Turner http://synfin.net/ - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
