Incorrect usage of libpcap in pcapportcpp, results in live lock.

[lunn]

Please see the thread:

https://www.mail-archive.com/netdev@vger.kernel.org/msg163532.html

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.

[pstavirs]

@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 pthread_kill works well with QThread), but we need a solution for Windows too. A single cross-platform solution would be nice, but not sure if one exists.

I'm open to ideas.

[lunn]

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.