[PATCH 3/3]: wpa_gui-qt4: use bss ctrl interface command to get scan results
Sun Feb 3 20:05:11 PST 2008
On Fri, Feb 01, 2008 at 02:52:41PM +1000, Kel Modderman wrote:
> This change has introduced a condition where in infinite loop of bss
> ctrl interface commands are possible.
> In a noisy environment, with a configuration that allows association to any
> open access point, the "BSS next <bssid>" ctrl interface command may carry
> on infinitely sometimes.
Hmm.. I can see a theoretical case for this type of loop, but I'm
somewhat surprised if this happens in real world scenario unless there
is a bug somewhere..
> I could reproduce this by opening scan dialog. The environment contained
> a reliable access point, a hidden access point on the fringe of acceptable
> range from my location, and my hostapd access point which was on a put on
> periodic loop with intervals of between 5 to 9 seconds to toggle
> interface up/down. So there were a few bss's coming and going from scan
For the infinite loop to occur, the scan results in wpa_supplicant would
need to be changed before the external program has completed its
iteration. Taken into account that such an iteration should not really
take that long, the scan results should not really change multiple times
during an BSS iteration.
> When the interface would attempt to connect with the hidden network that
> occasionally popped in and out (but fail), the "bss next <bssid>" ctrl
> interface command would continue in an infinite loop, wpa_gui process would
> go out of control.
Do you have (or can you easily generate) a wpa_supplicant debug log with
timestamps (-ddt on command line) showing this kind of case? I would
like to understand what exactly happens before trying to introduce
mechanisms to skip this case since I do not think this should really
happen in the first place.. I would hope that this can be avoided by
fixing something that is triggering this behavior without having to work
around the issue.
> I have a two patch workaround for this problem, but I'm not sure if its the
> best solution, you can decide:
> 1. introduce "bss count" ctrl interface command, that returns the number
> of bss's in scan results
This would only be a snapshot count at the time this command is
executed which may not be the same count that is present at the end of
the iteration.. I would rather not add this type of extra complexity.
> 2. wpa_gui: before attempting to iterate through scan results, get the number
> of bss's expected to be in scan results. Count each loop until we processed
> same number of bss's as expected than break from loop.
There could be a hardcoded limit (say, 1000 or so) to avoid the infinite
loop and as an extra safety, the loop could be stopped if the same BSSID
is received more than once. That would hopefully avoid this without
having to introduce any new commands to the ctrl_iface.
Jouni Malinen PGP id EFC895FA
More information about the Hostap