QNX / libpcap / wpa_supplicant -- packet loss

Patrik Lahti plahti at qnx.com
Fri Oct 22 10:23:34 EDT 2010

On 10-10-18 03:11 PM, Jouni Malinen wrote:
> On Mon, Oct 18, 2010 at 02:43:15PM -0400, Patrik Lahti wrote:
>> Indeed, you're right, the supplicant should loop calling pcap_next() and
>> process all packets until NULL is returned. The packets don't get lost,
>> but get severely delayed, but it isn't a QNX-specific problem. It may be
>> specific to using l2_packet_freebsd.c or only cause a problem if using
>> BPF to implement libpcap, but I haven't investigated.
> If I remember correctly, there were some issues with pcap using blocking
> operations at least in some cases. Is it clear that this can be done in
> non-blocking mode? At least man page for pcap_setnonblock() seems to
> indicate that pcap_next() will not work in non-blocking mode.

I am not aware of what the issue might have been. But when the 
supplicant has done a select() and it indicated the fd was readable, 
then the read() shouldn't block, right? (again, only looking at pcap as 
implemented by BPF here)

> l2_packet_winpcap.c uses a separate thread to work around related issues
> (and lack of select() option for that matter) and I would expect that it
> does not have this type of problem. However, I would prefer not to add a
> new thread just for this.
> I don't really like the pcap API for this and was very pleased to be
> able to replace that with Linux packet sockets and proper wait on the
> socket without having to figure out what exactly is needed with pcap to
> provided packets immediately and without blocking the thread in any
> case.
> If someone has code that provides a non-blocking and reliable way of
> getting packet out from pcap, I would like to get this fixed in
> wpa_supplicant. My own interest on this is somewhat limited taking into
> account the past history of having to fight with pcap and the current
> situation of not having to worry about it on the main platforms I worked
> with ;-).

I guess you don't mind if l2_packet_freebsd.c gets this fix then? :-) Or 
is there someone else which maintains that file?


More information about the HostAP mailing list