Comment # 2
on bug 10064
from jrmthackray
This can be confirmed with an strace, which shows the message being printed
before actually creating a SOCK_RAW on fd 3, and then running lots of
setsockopt()s to grab all the header fields:
write(2, "Capturing on 'eth0'\n", 20Capturing on 'eth0'
) = 20
open("/proc/net/dev", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7faa1dafe000
read(3, "Inter-| Receive "..., 1024) = 706
close(3) = 0
munmap(0x7faa1dafe000, 4096) = 0
socket(PF_PACKET, SOCK_RAW, 768) = 3
ioctl(3, SIOCGIFINDEX, {ifr_name="lo", ifr_index=1}) = 0
ioctl(3, SIOCGIFHWADDR, {ifr_name="eth0", ifr_hwaddr=00:50:56:a6:56:c2}) = 0
ioctl(3, SIOCGIFINDEX, {ifr_name="eth0", ifr_index=2}) = 0
bind(3, {sa_family=AF_PACKET, proto=0x03, if2, pkttype=PACKET_HOST, addr(0)={0,
}, 20) = 0
getsockopt(3, SOL_SOCKET, SO_ERROR, [0], [4]) = 0
setsockopt(3, SOL_PACKET, PACKET_ADD_MEMBERSHIP,
"\2\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0", 16) = 0
setsockopt(3, SOL_PACKET, PACKET_AUXDATA, [1], 4) = 0
getsockopt(3, SOL_PACKET, PACKET_HDRLEN, [36], [4]) = 0
setsockopt(3, SOL_PACKET, PACKET_VERSION, [2], 4) = 0
setsockopt(3, SOL_PACKET, PACKET_RESERVE, [4], 4) = 0
setsockopt(3, SOL_PACKET, PACKET_RX_RING,
"\0\0\2\0\20\0\0\0\0\0\2\0\20\0\0\0\372\0\0\0\0\0\0\0\0\0\0\0", 28) = 0
However, the previous version in Ubuntu 13.10 (dumpcap 1.10.2) also has a
similar strace, so there must be some other reason why some packets are being
missed (and it's a minute window between printing the message and opening the
raw socket)
Our test code waits for the "Capturing" message on stdout, then forks another
process to make an HTTP request and capture the response, and yet we will miss
the HTTP response from a webserver on a local LAN.
So this definitely looks like a regression from earlier dumpcap binaries.
