Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Incorrect usage of libpcap in pcapportcpp, results in live lock. #215
Please see the thread:
PcapPort::PortCapturer::stop() sets a flag and then waits for PcapPort::PortCapturer::run() to wake up, notice the flag, and exist. However, there is no guarantee pcap_next_ex() will exist in bounded time, on an idle network. And since Ostinator is often used on a network where it is the only source of traffic, this is a problem.
You probably need to send the thread running PcapPort::PortCapturer::run() a signal so that it exists from the poll system call.
@lunn Thank you for not just reporting the issue, but for researching and investigating it beforehand by writing a test program and talking to the libpcap and Kernel developers!
A signal might work for *nix platforms (need to check if
I'm open to ideas.
I thought about it for a while, but cannot find a simple solution...
It is possible to put libpcap into non-blocking mode, and then get an file descriptor which you can use select()/poll() on. But the man page says poll() it does not work correctly on MacOS 10.4 and 10.5, but will work on later versions. However you cannot get a file descriptor for Windoze.
As you say, a signal/pthread_kill is unlikely to work on Windoze, and i don't see anything in QT to do this.
The only idea i have come up with, which should be portable, is to set the stop_ member, and then send a frame. libpcap will then capture that frame and exit from pcap_next_ex(), see the flag, and exit the loop. The down side is you have an extra frame on the wire.