Re: Output goes weird!

[Guy Harris <guy () alum mit edu>]

On Sep 10, 2003, at 5:34 PM, Justin Robinson wrote:

> This is not the problem, because I'm positive that the payload contains
> purely textual information.

...unless somebody happened to post their latest Pamela Anderson 
pictures without uuencoding them. :-)

(I.e., better safe then sorry - your program probably shouldn't 
*assume* the payload is purely text.)

> However, I did manage to fix the problem. Thought it would be nice to 
> share
> what I discovered....
> My C program called the pcap_open_live function like this:
>
> handle = pcap_open_live(dev, BUFSIZ, 1, 100, errbuf);
>
> However this doesn't work and for some reason the output goes all 
> wrong.

Actually, I suspect it works, from the standpoint of what a call such 
as that is supposed to do, anbd what it's documented as doing, in that 
any packet whose length is less than or equal to BUFSIZ will have its 
entire contents supplied and any packet whose length is greater than 
BUFSIZ will have its contents cut off at BUFSIZ.

On FreeBSD, BUFSIZ will be 1024, which means that you won't get a full 
Ethernet packet, for example.  If, however, your application 
incorrectly assumes it *does* get a full packet in that case, your 
application won't work correctly - it might treat whatever happens to 
be in memory past the end of the packet data as part of the packet, in 
which case it might well be printing non-text characters.

On Linux, BUFSIZ might be larger, in which case you're more likely to 
get a full packet, and thus less likely, if the code is assuming it's 
getting a full packet, to print random junk that's not part of the 
packet as if it *were* part of the packet.

Using a #define such as BUFSIZ that isn't guaranteed to have the same 
value on all platforms is the wrong thing to do.

Your application should use the "caplen" field of the "pcap_pkthdr" 
structure to determine how many bytes of packet data were delivered to 
it by libpcap; it should not assume that you have as many bytes of IP 
datagram as the IP header's total length field says are present.

> The following does work though!
>
> handle = pcap_open_live(dev, 2048, 1, 100, errbuf);
>
> I think 2048 is enough for the packets on the connections I will 
> monitor, so
> that should be ok.

Memory, these days, is probably cheap enough that 65535 is a reasonable 
value.  (That's what "tcpdump -s 0", in sufficiently recent versions of 
tcpdump, does, and it's what Ethereal does if not told to cut off the 
packets at a particular length.)

-
This is the TCPDUMP workers list. It is archived at
http://www.tcpdump.org/lists/workers/index.html
To unsubscribe use mailto:tcpdump-workers-request () tcpdump org?body=unsubscribe