Folks, (This message relates to linux libpcap based applications.)
I think the issues with my beta release have been taken care of. But, I must say, I haven't had much FEEDBACK! Note, I copied tcpdump.org just for drill. I realize that it's not of too much interest to that crowd. But, don't get me wrong they're a good crowd. %^) As a reminder, the version 0.7.MMDD indicates that it was built using any significant changes found at tcpdump.org for that month and day. Next year I'll have to think of a different mechanism. http://public.lanl.gov/cpw says it all. But, I'll summarize: 1. Non blocking works as advertised (see pcap_{set|get}nonblock features at tcpdump.org). You can also create a non blocking situation by calling pcap_open_live with to_ms==0. 2. PCAP_FRAMES=0 turns off the memory mapped feature and reverts to the linux mechanism supplied by tcpdump.org. 3. You can set the device to "any" in pcap_open_live and get expected result while using mmap feature. 4. PCAP_VERBOSE=1 trys to explain a bit more about where your application is at after a call to pcap_open_live and then pcap_setfilter. 5. Reverted the pcap_setfilter return code to just -1 and 0 returns. It was returning a 1 to indicate you were using a kernel filter in mmap'd mode. Examples: # printenv | grep PCAP # # ./tcpdump -qttn -c 1 udp tcpdump: listening on eth0 1024097176.833397 128.165.114.100.138 > 128.165.114.255.138: udp 241 2 packets received by filter 0 packets dropped by kernel The next example shows that the default is now MMAP mode. # PCAP_VERBOSE=1 ./tcpdump -qttn -c 1 udp libpcap version: 0.7.0614 Kernel filter, Protocol 0003, MMAP mode (616 frames, snapshot 68), socket type: Raw tcpdump: listening on eth0 1024097191.313309 128.165.177.48.138 > 128.165.177.255.138: udp 174 1 packets received by filter 0 packets dropped by kernel Here we go back to non MMAP mode # PCAP_FRAMES=0 PCAP_VERBOSE=1 ./tcpdump -qttn -c 1 udp libpcap version: 0.7.0614 Kernel filter, Protocol 0003, NORMAL mode (snapshot 68), socket type: Raw tcpdump: listening on eth0 1024097404.174004 128.165.114.34.138 > 128.165.114.255.138: udp 193 2 packets received by filter 0 packets dropped by kernel Here I use the "any" device. # PCAP_VERBOSE=1 ./tcpdump -qttn -c 1 -i any udp libpcap version: 0.7.0614 Kernel filter, Protocol cooked, Ubiquitous MMAP mode (600 frames, snapshot 68), socket type: Datagram tcpdump: listening on any 1024098091.439664 128.165.114.91.138 > 128.165.114.255.138: udp 201 2 packets received by filter 0 packets dropped by kernel And, you can do the Ubiquitous mode which should be pretty much like tcpdump.org current libpcap. # PCAP_FRAMES=0 PCAP_VERBOSE=1 ./tcpdump -qttn -c 1 -i any udp libpcap version: 0.7.0614 Kernel filter, Protocol cooked, Ubiquitous NORMAL mode (snapshot 68), socket type: Datagram tcpdump: listening on any 1024098129.561160 128.165.114.92.138 > 128.165.114.255.138: udp 174 4 packets received by filter 0 packets dropped by kernel And, finally, the statistics option with all interfaces. # PCAP_STATS=0x21fff PCAP_FRAMES=max PCAP_VERBOSE=1 ./tcpdump -w /dev/null -i any libpcap version: 0.7.0614 Kernel filter, Protocol cooked, Ubiquitous MMAP mode (32750 frames, snapshot 68), socket type: Datagram tcpdump: listening on any S:1024098249.613439 5 0 5 0 5 375 305 0 5 1 0 000000001.201998 5 S:1024098250.815437 1 0 1 0 1 76 62 0 6 1 0 000000001.001202 1 S:1024098251.816639 2 0 2 0 2 170 142 0 8 1 0 000000001.201770 2 S:1024098253.018409 1 0 1 0 1 76 62 0 9 1 0 000000001.001439 1 S:1024098254.019848 2 0 2 0 2 170 142 0 11 1 0 000000001.201771 2 S:1024098255.221619 3 0 3 0 3 196 154 0 14 1 0 000000001.001439 1 S:1024098256.223058 4 0 4 0 4 290 234 0 18 1 0 000000001.201773 2 S:1024098257.424831 4 0 4 0 4 274 218 0 22 1 0 000000001.001437 2 S:1024098258.426268 5 0 5 0 5 951 881 0 27 1 0 000000001.096208 2 S:1024098259.522476 6 0 6 0 6 647 563 0 33 1 0 000000001.074159 4 S:1024098260.596635 5 0 5 0 5 350 280 0 38 1 0 000000002.006863 2 S:1024098262.603498 1 0 1 0 1 94 80 0 39 1 0 000000002.006630 1 39 packets received by filter 0 packets dropped by kernel You can read more about the what those fields are in the README.ring. The seventh (starting at 1) field is actually the delta number of packets seen on both the lo and eth0 summed together (that's all I got this trip). Hmmm, this indicates a problem with this initial release. So, unless you want to help me make this better. Just, think of it as a work in progress. Later, Phil - 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
