Andreas Fenkart
|
Re: QNX / libpcap / wpa_supplicant -- packet loss
|
Andreas Fenkart
10/04/2010 7:09 AM
post69395
|
Re: QNX / libpcap / wpa_supplicant -- packet loss
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);
}
|
|
|
Patrik Lahti
|
Re: QNX / libpcap / wpa_supplicant -- packet loss
|
Patrik Lahti
10/18/2010 12:04 PM
post71081
|
Re: QNX / libpcap / wpa_supplicant -- packet loss
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
>
|
|
|