Steve Woodford
2008-04-18 21:05:50 UTC
Hi,
Since the last import back in January, wpa_supplicant(8) in
NetBSD-current has been unable to maintain a WPA session with a
wireless AP due to lossage during re-keying. The work-around thus far
has been to keep a wpa_cli(8) instance running for the duration of the
session.
After some playing around this evening, I believe I have tracked down
the cause of the bug to lossage within bpf(4)'s bpf_poll() function.
The bottom line is that wpa_supplicant(8) does not receive the re-key
packet from the AP because the select(2) call in
dist/wpa/src/utils/eloop.c does not report the event promptly. The
wpa_cli(8) hack works because it sends a PING request over
wpa_supplicant's control socket once per second, resulting in the
select(2) call returning each time. The next call to select(2) returns
a bpf(2) readable status, so re-keying proceeds normally albeit delayed
slightly.
The attached patch to sys/net/bpf.c contains two changes lifted from
FreeBSD's bpf.c:
- A "fix" for bpf_poll() to address the above problem (but see below).
- A fix for catchpacket() which delays calling bpf_wakeup() until
the state has been updated.
I'd like someone with more bpf(4) clue to look over the first fix, as
I'm somewhat perplexed as to why it fixes the problem. (Maybe it's the
beer, maybe I need to spend more time staring at it, or maybe I'm just
getting too old ;-)
In anycase, if you have been experiencing this wpa_supplicant(8)
problem, please try the patch and report back.
Cheers, Steve
Since the last import back in January, wpa_supplicant(8) in
NetBSD-current has been unable to maintain a WPA session with a
wireless AP due to lossage during re-keying. The work-around thus far
has been to keep a wpa_cli(8) instance running for the duration of the
session.
After some playing around this evening, I believe I have tracked down
the cause of the bug to lossage within bpf(4)'s bpf_poll() function.
The bottom line is that wpa_supplicant(8) does not receive the re-key
packet from the AP because the select(2) call in
dist/wpa/src/utils/eloop.c does not report the event promptly. The
wpa_cli(8) hack works because it sends a PING request over
wpa_supplicant's control socket once per second, resulting in the
select(2) call returning each time. The next call to select(2) returns
a bpf(2) readable status, so re-keying proceeds normally albeit delayed
slightly.
The attached patch to sys/net/bpf.c contains two changes lifted from
FreeBSD's bpf.c:
- A "fix" for bpf_poll() to address the above problem (but see below).
- A fix for catchpacket() which delays calling bpf_wakeup() until
the state has been updated.
I'd like someone with more bpf(4) clue to look over the first fix, as
I'm somewhat perplexed as to why it fixes the problem. (Maybe it's the
beer, maybe I need to spend more time staring at it, or maybe I'm just
getting too old ;-)
In anycase, if you have been experiencing this wpa_supplicant(8)
problem, please try the patch and report back.
Cheers, Steve