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 #439 (assigned defect)

Opened 16 years ago

Last modified 13 years ago

Global WEP keys shared across all VAPs

Reported by: Ron Dippold Assigned to: mentor (accepted)
Priority: minor Milestone:
Component: madwifi: driver Version: trunk
Keywords: Cc:
Patch is attached: 0 Pending:

Description

When creating multiple vaps, it seems that the last wep key you assign to any vap is used for all the vaps. I've changed the first key in the report just because it's our default key, even though I know wep is pathetic. 

iwconfig wlan1 key s:wubba
iwconfig wlan2 key s:other
iwconfig wlan3 key s:vwxyz
iwconfig wlan4 key s:abcde

Now the keys look correct: 

GW-154:~# iwconfig
wlan1 IEEE 802.11g ESSID:"gw154ap" Nickname:"GW-154"
          Mode:Master Frequency:2.412 GHz Access Point: 00:02:6F:21:E8:C6
          Bit Rate:0 kb/s Tx-Power:19 dBm Sensitivity=0/3
          Retry:off RTS thr:off Fragment thr:off
          Encryption key:XXXX-XXXX-XX Security mode:restricted
          Power Management:off
          Link Quality=0/94 Signal level=-95 dBm Noise level=-95 dBm
          Rx invalid nwid:756 Rx invalid crypt:0 Rx invalid frag:0
          Tx excessive retries:0 Invalid misc:0 Missed beacon:0

wlan2 IEEE 802.11g ESSID:"gw154ap2" Nickname:"GW-154"
          Mode:Master Frequency:2.412 GHz Access Point: 06:02:6F:21:E8:C6
          Bit Rate:0 kb/s Tx-Power:19 dBm Sensitivity=0/3
          Retry:off RTS thr:off Fragment thr:off
          Encryption key:6F74-6865-72 Security mode:restricted
          Power Management:off
          Link Quality=0/94 Signal level=-95 dBm Noise level=-95 dBm
          Rx invalid nwid:772 Rx invalid crypt:0 Rx invalid frag:0
          Tx excessive retries:0 Invalid misc:0 Missed beacon:0

wlan3 IEEE 802.11g ESSID:"gw154ap3" Nickname:"GW-154"
          Mode:Master Frequency:2.412 GHz Access Point: 0A:02:6F:21:E8:C6
          Bit Rate:0 kb/s Tx-Power:31 dBm Sensitivity=0/3
          Retry:off RTS thr:off Fragment thr:off
          Encryption key:7677-7879-7A Security mode:restricted
          Power Management:off
          Link Quality=0/94 Signal level=-95 dBm Noise level=-95 dBm
          Rx invalid nwid:785 Rx invalid crypt:0 Rx invalid frag:0
          Tx excessive retries:0 Invalid misc:0 Missed beacon:0

wlan4 IEEE 802.11g ESSID:"gw154ap4" Nickname:"GW-154"
          Mode:Master Frequency:2.412 GHz Access Point: 0E:02:6F:21:E8:C6
          Bit Rate:0 kb/s Tx-Power:31 dBm Sensitivity=0/3
          Retry:off RTS thr:off Fragment thr:off
          Encryption key:6162-6364-65 Security mode:restricted
          Power Management:off
          Link Quality=0/94 Signal level=-95 dBm Noise level=-95 dBm
          Rx invalid nwid:787 Rx invalid crypt:0 Rx invalid frag:0
          Tx excessive retries:0 Invalid misc:0 Missed beacon:0

But you can't connect properly to wlan1 with key s:wubba. It looks like it's associated but no messages go through, you never get an ip... exactly what you get with the wrong wep key. Now I try to associate with wlan1 using the key s:abcde and it works. If I only create the first 3 aps, then I can connect to wlan1 only with the key s:vwxyz (for wlan3). So it's pretty consistent.

A quick look at struct ieee80211vap shows a 

	u_int16_t		iv_def_txkey;	/* default/group tx key index */
	struct ieee80211_key	iv_nw_keys[IEEE80211_WEP_NKID];

which seems to indicate that in theory the driver would support separate keys per virtual station, and they do indeed look different when you do an iwconfig.

I may try debugging this myself later, but don't have the time now so just making a note of it.

Change History

03/07/06 04:43:30 changed by Wang wenjuan

Hi, I got the same issue like you. Thanks for your report.

I guess there are only a group of 4 key registers for WEP in atheros chip, we can modify the registers by "iwconfig wlan0 key s:12345".

Furthermore it seems that no need reset and ieee80211_new_state when modifying the registers, right?

If wanted to assign a set different keys to each VAP, we need do ieee80211_crypto_setkey continuously maybe.

04/26/06 11:18:51 changed by yewchai@gmail.com

Hi, can try setting each VAP with different ID of key. Example. iwconfig ath1 key [1] 0123456789 iwconfig ath1 key [1] iwconfig ath2 key [2] 1234567890 iwconfig ath2 key [2]

This should solve your problem. Your client station that associated to ath1 should use key ID 1 (0123456789), Your client station that associated to ath2 should use key ID 2 (1234567890),

I hope new patches will be release soon for this problem:)

Thank you...

06/10/06 03:59:28 changed by mentor

  • status changed from new to assigned.
  • owner set to mentor.

Ummm, yeah, it looks like the 4 WEP keys are shared across all VAPs, which probably isn't ideal.

07/14/06 02:46:48 changed by mentor

Right, there appears to be some logic that will allow the WEP key to be set independently for each VAP, but I need to get more information from Atheros/Sam Leffler about this. This may not be available for all chipsets, so I am going to implement logic to show the actual sharing of hardware key cache sharing across VAPs.

10/05/06 11:16:52 changed by Bas

Hi, I just ran into the same problem when testing 2 VAPs with different WEP keys, and found this ticket while looking if the problem was already reported. Any updates/news on this ticket?

Best regards,

Bas

10/25/06 00:02:04 changed by tharvey

I looked into this as well using an AR5212 card (SR5). This same card can support 4+ AP's each with their own set of WEP keys using Microtik so I wouldn't say that the hardware doesn't support this.

What I found is that if_ath.c uses the first 4 keycache slots of a device for WEP, so even though each VAP has 4 unique key's setting them simply overwrites the first 4 keycache slots for the device. A one-line change removing k->wk_keyix = kid in 'ieee80211_ioctl_siwencode' is enough to make each VAP allocate its own keycache slot, however this breaks WEP. An additional change is required in ath_newstate to obtain the correct keycache slot prior to calling ath_hal_keysetmac but doing so still does not sovle the issue. I did verify that these changes work if SW WEP decrypt is used.

I'm uncertain exacly how the HW WEP decrypt decides what key to use to decrypt a frame and how that interacts with the keycache. One would assume that in the case of WEP using the wep key index ad the keycache slot is a hardware limitation, but then how does Microtik's driver handle more than 4 WEP keys?

10/25/06 00:09:44 changed by tharvey

I should also mention that I attemped Wang's suggestion of resetting the keys however this proved ineffective as apparently by the time ath_rx_tasklet is called with a frame, the HW has already attempted a decrypt (and failed if the key needed swaping). Furthermore, I'm uncertain how to determine if HW decrypt failed

12/20/07 01:00:17 changed by mentor

  • summary changed from Last wep key gets used with multiple stations to Global WEP keys shared across all VAPs.

06/24/09 12:04:08 changed by darkspeed666@gmail.com

Same problem in 0.9.4 ... suggesting priority to from "minor" to "major" => WEP cannot be used in VAPS !