ignoring auth_80211_auth_alg not correct solution

http://article.gmane.org/gmane.linux.drivers.madwifi.cvs/1101

And the comments from Jouni:

http://article.gmane.org/gmane.linux.drivers.madwifi.cvs/1102

The commit of r1527 ( specifically just the change to ieee80211_proto.c ) is partially responsible for the problem I reported in ticket #646 ( scan results delayed to wpa_supplicant ).

iirc, that specific change you mention was a revert of the initial WEXT implementation in r1499.

@ brian, do you have any ideas about this issue?

Yeah. The simple fix is to change the way madwifi interprets the authentication algorithm ioctls so that the authentication algorithm and the privacy flags are completely separate. I'm going to write that up and send a note to madwifi-devel. The reason I want to involve the list in the discussion is because the most obvious way to decouple authalg and privacy might break people's configuration scripts. If that turns out to be likely, we'll probaby need to introduce a separate ioctl so that iwpriv authmode keeps the old behavior.

I'll have a look at ticket #646 when I write up the other changes.

fix for this bug

Just attached a fix for both problems. I need to get access to a LEAP AP to finish up the testing. I should be able to do that tomorrow.

Problem 1 - unencrypted EAPOL frames were accepted even when they shouldn't be. This is fixed by the changes to ieee80211_input.c

Problem 2 - method of specifying the authentication type (open vs WEP shared) was very funky. For example, consider these two sets of commands for configuring access to a WEP enabled AP using "open system" authentication.

Example A:
iwconfig ath0 key <key>
iwpriv ath0 authmode 1

Example B:
iwpriv ath0 authmode 1
iwconfig ath0 key <key>

Example A would fail. Example B would work. The reason A failed was that the "authmode" command was tampering with the "privacy" flag on the VAP. I've changed things so that the authentication algorithm and the privacy flag are decoupled. The privacy flag was already being set as soon as the encryption keys were specified.

Just had a look at ticket 646. The history of that new_state function is like this:

- Changed the new_state function for improved wext support
- That broke things.
- Backed out the change

I can see why the state machine change may have helped ticket #646, but that doesn't make the change to the new_state function correct. ;). It looks to me like the changesets that Kel put in today should help that problem.

Brian committed a change in r1676 that states to close this ticket. If this is not the case, feel free to reopen it.