Wrapping pcap_next in a while loop, till no more packet available.

wpa_supplicant being a single-threaded applicantion, using select, no side effect is expected.

diff --git a/io-pkt/6.4.1/trunk/dist/wpa/src/l2_packet/l2_packet_freebsd.c b/io-pkt/6.4.1/trunk/dist/wpa/src/l2_packet/
l2_packet_freebsd.c
index be672b2..600393a 100644
--- a/io-pkt/6.4.1/trunk/dist/wpa/src/l2_packet/l2_packet_freebsd.c
+++ b/io-pkt/6.4.1/trunk/dist/wpa/src/l2_packet/l2_packet_freebsd.c
@@ -86,18 +86,19 @@ static void l2_packet_receive(int sock, void *eloop_ctx, void *sock_ctx)
 
        packet = pcap_next(pcap, &hdr);
 
-       if (packet == NULL || hdr.caplen < sizeof(*ethhdr))
-               return;
-
-       ethhdr = (struct l2_ethhdr *) packet;
-       if (l2->l2_hdr) {
-               buf = (unsigned char *) ethhdr;
-               len = hdr.caplen;
-       } else {
-               buf = (unsigned char *) (ethhdr + 1);
-               len = hdr.caplen - sizeof(*ethhdr);
+       while (packet != NULL && hdr.caplen >= sizeof(*ethhdr)) {
+               ethhdr = (struct l2_ethhdr *) packet;
+               if (l2->l2_hdr) {
+                       buf = (unsigned char *) ethhdr;
+                       len = hdr.caplen;
+               } else {
+                       buf = (unsigned char *) (ethhdr + 1);
+                       len = hdr.caplen - sizeof(*ethhdr);
+               }
+               l2->rx_callback(l2->rx_callback_ctx, ethhdr->h_source, buf, len);
+
+               packet = pcap_next(pcap, &hdr);
        }
-       l2->rx_callback(l2->rx_callback_ctx, ethhdr->h_source, buf, len);
 }

Thanks Andreas for digging into this and for posting your findings!

I finally had time to look deeper into this and I found that your 
observations are correct. Although the packets aren't actually lost, 
they're still in the pcap_t's buffer and will be read next time 
pcap_next() is called. I.e. next time select() indicates the fd is 
readable, the supplicant will go and call pcap_next() again and get an 
old packet already queued in the pcap_t's buffer but not read more. 
Since nothing is read, select() will again say the fd is readable and 
again the supplicant calls pcap_next(), and so on until there are no 
more old packets, and the fd will read another packet(s) into the 
pcap_t's buffer and pcap_next() then returns the first of them to the 
supplicant. If there were several packets, then the situation repeats.

The packets are likely delayed until the peer times out and retransmit 
their EAP packet. Usually the EAP negotiation should recover but 
depending on the timing I can see various effects, maybe it causes so 
many timeouts that authentication takes much longer than expected. Since 
there is timing involved it likely has different effects depending on 
what hardware you're running.

Certainly a bug in the supplicant and I've committed a for it which will 
be in the next release of QNX.

AFAICT the bug is actually present in the latest wpa_supplicant code. I 
see you've already reported the problem to the hostap mailing list so 
I'll respond to you there as well...

Cheers!
/P

On 10-10-01 08:35 AM, Andreas Fenkart wrote:
> Hi
>
> I observed a problem, when bpf queues 3 packages for
> wpa_supplicant. Only the first package is received, then
> wpa_supplicant blocks in select without reading the other 2
> packages.
>
> The is what I debugged so far:
>
> wpa_supplicant io-pkt
> ------------------------------------------------------
> select:
> - - - - | -> bpf_poll
> <- - - - | - <data available
> -> pcap_next " |
> -> pcap_dispatch |
> -> pcap_read_bpf |
> - - - | -> bpf_read
> <- - - | - <pass all queued data>
>
> --> libpcap extracts 1 packet queues remaining data <--
>
> <- 1 packet
> <- 1 packet
> ..
> process packet
> ..
> do select:
> - - - - | -> bpf_poll
> <- - - - | - <no data available
> repeat
>
>
> The problem is that the data is queued in pcap, but the
> supplicant checking this before calling 'select' again. Select
> will fail, since it checks for available data in io-pkt which in
> my case has none.
>
> Any suggestions, hints to existing patches very welcome.
>
> kind regards
>
> Andreas
>
>
> ---- configuration --------------------------------------------
>
> QNX 6.4.1 / wpa_supplicant 0.6.4 / libpcap 0.9.8
>
> network={
> ssid="MotorolaWPA-EAP"
> scan_ssid=1
> # IEEE 802.1X (i.e., no WPA) with dynamic WEP keys
> key_mgmt=IEEE8021X
> eap=TTLS
> identity="xxxx"
> password="xxxx"
> priority=1
> }
>
>
>
>
> _______________________________________________
>
> General
> http://community.qnx.com/sf/go/post69244
>