Please note: This project is no longer active. The website is kept online for historic purposes only.
If you´re looking for a Linux driver for your Atheros WLAN device, you should continue here .

Ticket #566 (closed defect: fixed)

Opened 13 years ago

Last modified 13 years ago

ignoring auth_80211_auth_alg not correct solution

Reported by: kelmo Assigned to:
Priority: major Milestone: version 0.9.2
Component: madwifi: 802.11 stack Version: trunk
Keywords: Cc: eaton.lists@gmail.com
Patch is attached: 0 Pending:

Description

The commit of r1527 ignores siwauth_80211_auth_alg and giwauth_80211_auth_alg, and as pointed out recently on madwifi-devel, this is not the correct solution.

When these postings are available on gmane or madwifi-devel archives, a link to the thread will be added here.

Attachments

566.patch (11.0 kB) - added by eaton.lists@gmail.com on 07/04/06 23:13:31.
fix for this bug

Change History

04/25/06 07:33:38 changed by kelmo

06/21/06 23:45:50 changed by espy@pepper.com

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 ).

06/27/06 14:24:25 changed by kelmo

  • cc set to eaton.lists@gmail.com.

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?

06/28/06 18:23:33 changed by eaton.lists@gmail.com

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.

07/04/06 23:13:31 changed by eaton.lists@gmail.com

  • attachment 566.patch added.

fix for this bug

07/04/06 23:22:24 changed by eaton.lists@gmail.com

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.

07/04/06 23:27:10 changed by eaton.lists@gmail.com

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.

07/06/06 05:48:11 changed by mrenzmann

  • status changed from new to closed.
  • resolution set to fixed.
  • milestone changed from version 0.9.x - progressive release candidate phase to version 0.9.2.

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