QNX / libpcap / wpa_supplicant -- packet loss

[Jouni Malinen]

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.

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 ;-).

-- 
Jouni Malinen                                            PGP id EFC895FA