Wireshark-bugs: [Wireshark-bugs] [Bug 10064] dumpcap regression: 1.10.6 says Capturing on 'Loopb

Date: Wed, 30 Apr 2014 12:54:42 +0000

Comment # 2 on bug 10064 from
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.


You are receiving this mail because:
  • You are watching all bug changes.