pcap_next_ex does not time out

Bug #1825106 reported by Werner Henze
22
This bug affects 3 people
Affects Status Importance Assigned to Milestone
libpcap
New
Unknown
libpcap (Ubuntu)
Won't Fix
Undecided
Unassigned

Bug Description

$ lsb_release -rd
Description: Ubuntu 18.04.2 LTS
Release: 18.04

$ apt-cache policy libpcap0.8
libpcap0.8:
  Installiert: 1.8.1-6ubuntu1
  Installationskandidat: 1.8.1-6ubuntu1
  Versionstabelle:
 *** 1.8.1-6ubuntu1 500
        500 http://de.archive.ubuntu.com/ubuntu bionic/main amd64 Packages
        100 /var/lib/dpkg/status

I have a tool that opens the local LAN interfaces via pcap_open_live with a timeout of 1 ms and then reads from all interfaces. The tool used to work on Ubuntu 16.04 but hangs on Ubuntu 18.04.
When using libpcap0.8 1.7.4-2 (https://launchpad.net/ubuntu/+archive/primary/+files/libpcap0.8_1.7.4-2_amd64.deb) the program also works on Ubuntu 18.04.

Comparing the sources at https://launchpad.net/ubuntu/+source/libpcap I saw that a change from 1.7.4-2 to 1.8.1-6 is related to TPACKET3. Further gdb analysis suggests that this change is the root cause (or that TPACKET3 is broken in Ubuntu 18.04).
Please find attached a small program that you can compile and run with "g++ pcap_test.cpp -lpcap; sudo ./a.out". On a working Ubuntu/pcap when opening an interface without traffic we see 42 times that pcap_next_ex returns 0 (timeout, no packet available). In case of the malfunction the program waits until a packet is available and the program either outputs no pcap_next_ex return (no packets received) or it outputs that pcap_next_ex returns 1 (one packet read).

Attaching gdb to the hanging program show this backtrace (after "sudo apt install libpcap0.8-dbg"):
#0 0x00007f3335fd5bc4 in __GI___poll (fds=fds@entry=0x7ffe5b2d4d50, nfds=nfds@entry=1, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
#1 0x00007f33364d09da in poll (__timeout=<optimized out>, __nfds=1, __fds=0x7ffe5b2d4d50) at /usr/include/x86_64-linux-gnu/bits/poll2.h:46
#2 pcap_wait_for_frames_mmap (handle=handle@entry=0x55920d9d92d0) at ./pcap-linux.c:4557
#3 0x00007f33364d0c05 in pcap_read_linux_mmap_v3 (handle=0x55920d9d92d0, max_packets=1, callback=0x7f33364cf3c0 <pcap_oneshot_mmap>, user=0x7ffe5b2d4de0 "Д\235\r\222U") at ./pcap-linux.c:5055
#4 0x00007f33364d866a in pcap_next_ex (p=<optimized out>, pkt_header=<optimized out>, pkt_data=<optimized out>) at ./pcap.c:295

poll with timeout=-1 waits without timeout, so blocks until a packet is read. Comments in the function for calculating the poll-timeout suggest that this is OK and that TPACKET3 is taking care of handling the timeout, but not having heard of TPACKET3 before I have no idea how that could/should work.

Revision history for this message
Werner Henze (beinhart) wrote :
Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in libpcap (Ubuntu):
status: New → Confirmed
Paride Legovini (paride)
tags: added: server-triage-discuss
Revision history for this message
Paride Legovini (paride) wrote :

Thank you for taking the time to report this bug and helping to make Ubuntu better. I appreciate the quality of this bug report and I'm sure it'll be helpful to others experiencing the same issue.

This sounds like an upstream bug to me. Please can you verify this by building directly from the relevant upstream releases? It would be especially interesting to see if the bug is still present in libpcap 1.9.0 (not yet packaged in Ubuntu). If this can be confirmed as an upstream bug, the best route to getting it fixed in Ubuntu in this case would be to file an upstream bug if you're able to do that. Otherwise, I'm not sure what we can do directly in Ubuntu to fix the problem.

If you do end up filing an upstream bug, please link to it from here. Thanks!

Changed in libpcap (Ubuntu):
status: Confirmed → Triaged
tags: removed: server-triage-discuss
Revision history for this message
Werner Henze (beinhart) wrote :

Hi Paride!

Thanks for your mail. I am not familiar with all the Jargon, so do I understand you right that?
With upstream bug you mean that Ubuntu is taking an official (upstream) libpcap and delivering it with Ubuntu, but the bug is not something that Ubuntu introduced but is present in the upstream libpcap? So the right place to file this bug is not here but at the upstream libpcap repository?
Looking here https://launchpad.net/ubuntu/disco/+source/libpcap the "Show upstream links" leads me to https://launchpad.net/libpcap/+packages where I do not find 1.9.0 version. What is the upstream? Is it https://www.tcpdump.org/? Shall I download the version from there and try it out?

Regards
Werner

Revision history for this message
Paride Legovini (paride) wrote :

Hello Werner,

That's exactly what I meant, however the actual upstream development happens here:

  https://github.com/the-tcpdump-group/libpcap

where you will find version 1.9.0 and the upstream issue tracker.

Revision history for this message
Werner Henze (beinhart) wrote :

The problem still exists in the latest libpcap version.
An issue report already exists: https://github.com/the-tcpdump-group/libpcap/issues/572
The solution seems to be not to use `pcap_open_live` but replace it with newer pcap functions.
In my opinion we can close this issue here. I would have done so, but I am uncertain what the right status would be that I should set (it is a valid concern, has no committed fix, will not get one, user should change code).

Changed in libpcap:
status: Unknown → New
Revision history for this message
Paride Legovini (paride) wrote :

Thanks for your follow-up. While not ideal, it seems that the current behavior is the intended and documented[1] one, so I'm setting the status of this report to "Won't Fix", as it is very unlikely to be fixed with an Ubuntu-specific patch. Should the situation change feel free to set the bug status back to New and reopen the discussion.

[1] http://www.tcpdump.org/manpages/pcap.3pcap.html, "packet buffer timeout"

Changed in libpcap (Ubuntu):
status: Triaged → Won't Fix
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Bug attachments

Remote bug watches

Bug watches keep track of this bug in other bug trackers.