(libpcap and tcpdump are now developed and maintained by the Tcpdump Group at tcpdump.org, not by the people at LBL; "[EMAIL PROTECTED]" and "[EMAIL PROTECTED]" are forwarded to "[EMAIL PROTECTED]".)
On Wed, Sep 11, 2002 at 11:20:23AM -0400, Dahlene,William wrote: > I'm developing an IP packet sniffer tool and have run into an apparent > problem, possibly with pcap_loop. Two NICs are hooked into a CISCO ethernet > switch. The lines are both monitoring 1 ethernet switch port. So, in > essence, two packets with the same ID (ip_id) extracted from the ip > structure (see ip.h) are basically the same exact packet read at the same > time by both lines. When compared, the two sniffers reporting the unique > packet match up the first couple hundred or so bytes of data. After that, > all bytes are inconsistant and apparantly random. What value is your sniffer tool passing to "pcap_open_live()" as the "snaplen" argument? Whatever value is passed will be the maximum number of bytes of packet data supplied to the callback routine called by "pcap_loop()", so if you want the entire packet, you should pass a sufficiently large value, e.g. 65535. Is your sniffer tool using the "caplen" member of the "struct pcap_pkthdr" pointed to by the argument to the callback routine as the length of the packet's data? If not, it has a bug, as the "caplen" member of that structure contains the number of bytes of packet data passed to the callback - *even if that value is less than the value of the "len" member of the structure*, as the "caplen" value is the number of bytes of packet data captured, which might be limited by the "snaplen" value to "pcap_open_live()". - This is the TCPDUMP workers list. It is archived at http://www.tcpdump.org/lists/workers/index.html To unsubscribe use mailto:[EMAIL PROTECTED]?body=unsubscribe
