Re: Output goes weird!

["" <csmjmr () bath ac uk>]

Guy, Michael

Thanks so much for your help.

I'm in a bit of trouble actually. This software is for my dissertation -- I 
developed on Linux and am trying to port to FreeBSD for testing.

The testing failed miserably :o(

I've done nearly all that you suggested. I've checked the datalink protocol and 
its ethernet. I'm reading the IP total length and TCP data offset fields to 
find out where the payload is.

The reason I don't check the output in the C program is that stdout is 
eventually redirected to a Java program that filters out the text characters.

The program worked fine under Linux, but in FreeBSD... so many packets are 
being dropped by the kernel so I can't read the complete NNTP conversation.

Guy... the things you said about snaplen, and buffers --- how do I increase the 
buffer size in FreeBSD to reduce the number of packets that get dropped?

The test machine is (supposed to) be of server specs, and there were very few 
programs running and network connections at the time of testing.

Thanks again
Justin



Quoting 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