Does not capture under linux

[guyharris]

Converted from SourceForge issue 600755, submitted by renhoek

I need an up-to-date libpcap due to the nonblocking support. I compiled a simple program with the libpcap.a standard on my distro and it worked. I renamed the old lib, compiled the 0.7.1 and now the program fails. I tried the daily 2002.08.27 which also fails.

I'm compiling this program:

http://www.cet.nau.edu/~mc8/Socket/Tutorials/testpcap1.c

with cc -Wall testpcap1.c -o testpcap1 -lpcap

I have straces of the program compiled against the new and old lib.. here are the most interesting parts:

OLD

brk(0)                                  = 0x805cf98
brk(0x805d138)                          = 0x805d138
brk(0x805e000)                          = 0x805e000
socket(PF_PACKET, SOCK_RAW, 768)        = 3
ioctl(3, 0x8933, 0xbffff6fc)            = 0
ioctl(3, SIOCGIFHWADDR, 0xbffff6fc)     = 0
ioctl(3, 0x8933, 0xbffff6fc)            = 0
bind(3, {sin_family=AF_PACKET, proto=0x03, if2, pkttype=0, addr(0)={0, }, 20) = 0
setsockopt(3, 0x107 /* IPPROTO_??? */1, [2], 16) = 0
ioctl(3, SIOCGIFMTU, 0xbffff6fc)        = 0
recvfrom(3, "\0\20\247\2{\333\0\2D-k\25\10\0E\0\0Lt@@\0\200\6\3\0\300"...,
    8192, MSG_TRUNC, {sin_family=AF_PACKET, proto=0x800, if2, pkttype=0, addr(6)={1, }, [20]) = 90
ioctl(3, SIOCGSTAMP, 0xbffff708)        = 0

NEW

brk(0)                                  = 0x8062678
brk(0x8062818)                          = 0x8062818
brk(0x8063000)                          = 0x8063000
socket(PF_PACKET, SOCK_RAW, 3)          = 3
ioctl(3, 0x8933, 0xbffff56c)            = 0
ioctl(3, SIOCGIFHWADDR, 0xbffff56c)     = 0
ioctl(3, 0x8933, 0xbffff56c)            = 0
bind(3, {sin_family=AF_PACKET, proto=0x300, if2, pkttype=0, addr(0)={0, }, 20) = 0
getsockopt(3, SOL_SOCKET, SO_ERROR, [0], [4]) = 0
setsockopt(3, 0x107 /* IPPROTO_??? */1, [2], 16) = 0
brk(0x8066000)                          = 0x8066000
recvfrom(3,

As you can see the new version just hangs on the recvfrom, and I can't figure out why.

I'm using gcc 2.95.3, Linux 2.2.19 on an i386 platform. My distro is Slackware 8.0.0. I'm unsure what pcap version is distributed with this distro, but I found this header in the original pcap.a, maybe that will tell you enough:

$Header: /tcpdump/master/libpcap/pcap-linux.c,v 1.51 2001 /01/03 01:06:16 guy Exp $ (LBL).

[infrastation]

Closing and adding a lost comment that Guy Harris added to the original issue on 2002-09-04:

It appears that the new libpcap was somehow miscompiled.

The third argument to socket(), in the version that works, is 768; 768 is hex 300, which is 3, treated as a 16-bit quantity and byte-swapped.

The third argument to socket(), in the version that doesn't work, is 3.

Both pcap-linux.c 1.51 (the version from the 0.6[.x] release) and pcap-linux.c 1.73 (the version from the 0.7.1 release) pass htons(ETH_P_ALL) as the third argument to the socket() call; the third argument to socket(PF_PACKET, SOCK_RAW, ...) specifies which particular protocols should be delivered on the socket, and htons(ETH_P_ALL) specifies that all protocols should be delivered.

That argument is supposed to be in network byte order (see the packet(7) man page).

It appears that, somehow, htons() wasn't actually converting between host (little-endian, on x86) and network (always big-endian) byte order when you compiled libpcap.

Perhaps that was a bug with Slackware 8.0.0, fixed in 8.1; if you want to know what caused this, you should ask the Slackware people about it.

I'll treat this as a Slackware problem for now (a system on which a call to htons(), on a little-endian processor, doesn't byte-swap the 16-bit quantity passed to htons() is very badly broken, and there's probably lots of other software that wouldn't work, either), and close this.