Possible bug, saved WEP security network will try to associate with SAME SSID but wpa security network
dcbw at redhat.com
Fri Oct 16 12:05:38 EDT 2009
On Fri, 2009-10-16 at 13:40 +0300, Jouni Malinen wrote:
> On Fri, Oct 16, 2009 at 04:43:20PM +0800, Zheng BaoZhong-E13358 wrote:
> > I have one AP with "test" SSID, and wpapsk security.
> > I add one network with "test" SSID and WEP security.
> > >From log, AP is found by scan and wpa_supplicant tries to associate with
> > AP, even the security is not matching.
> Well.. That depends on how you define matching for WEP operations. If
> you were to consider a legacy device that only supports WEP, it would
> see the Privacy flag set in the Beacon frames and would not know
> anything about WPA/RSN IE. For such a device, the security seems to be
> matching its own expectations and it would likely try to associate.
> An AP that advertises WPA/RSN IE could also enable WEP. I do not expect
> this to be a common use case, but still, it is possible. Because of
> that, just blindly refusing any network with WPA/RSN IE when configured
> to use WEP may not be that good of an idea.
I've heard of that specific configuration in businesses where there are
still legacy devices (inventory barcode readers, old palmpilots,
whatever) that cannot do WPA. I think it's mainly that the same WEP
multicast key is used for everything, and then the TKIP capable clients
can use unicast TKIP with the AP but still talk to the WEP ones.
To the legacy clients, it looks like a WEP AP because they ignore the
WPA IEs. To the TKIP clients, it looks like a WPA-TKIP AP with a really
long group rekey interval.
> It is trivial to great this type of scenario in a test environment, but
> does this really show up as any real world issues? The blacklist
> mechanism in wpa_supplicant should allow the correct WEP network to be
> found even if there are WPA/WPA2 networks using the same SSID present in
> the scan results.
More information about the HostAP