ath5k: set mac address in add_interface

PATCH In review Bob Copeland 5 participants 18 messages Nov 18, 2008 – Dec 20, 2008 1 message not in the archive Networking drivers (wireless)

lore

Share & tools

lore

Bob Copeland

author

2008-11-18 04:41 UTC #0 lore raw

PATCH 1/1 ath5k: set mac address in add_interface

Hi Maxim,

Please try this patch. I didn't have a problem changing the mac address after it was set to something else. I did kick it to re-associate with the AP, though.

Subject: [PATCH] ath5k: set mac address in add_interface

Configure the mac address in add_interface and clear it in remove_interface so that users can change the mac address to something other than the one in the eeprom. Also avoid setting it at attach time so that we won't ack packets until fully set up.

Signed-off-by Bob Copeland <[email protected]>

---
 drivers/net/wireless/ath5k/attach.c |   12 +++---------
 drivers/net/wireless/ath5k/base.c   |   13 +++++++++++--
 2 files changed, 14 insertions(+), 11 deletions(-)

drivers/net/wireless/ath5k/attach.c +3 -9

index 51d5698..49d82d7 100644
@@ -106,7 +106,7 @@ struct ath5k_hw *ath5k_hw_attach(struct ath5k_softc *sc, u8 mac_version)
 {
 	struct ath5k_hw *ah;
 	struct pci_dev *pdev = sc->pdev;
-	u8 mac[ETH_ALEN];
+	u8 mac[ETH_ALEN] = {};
 	int ret;
 	u32 srev;

@@ -317,15 +317,9 @@ struct ath5k_hw *ath5k_hw_attach(struct ath5k_softc *sc, u8 mac_version)
 		goto err_free;
 	}
 
-	/* Set MAC address */
-	ret = ath5k_eeprom_read_mac(ah, mac);
-	if (ret) {
-		ATH5K_ERR(sc, "unable to read address from EEPROM: 0x%04x\n",
-			sc->pdev->device);
-		goto err_free;
-	}
-
+	/* MAC address is cleared until add_interface */
 	ath5k_hw_set_lladdr(ah, mac);
+
 	/* Set BSSID to bcast address: ff:ff:ff:ff:ff:ff for now */
 	memset(ah->ah_bssid, 0xff, ETH_ALEN);
 	ath5k_hw_set_associd(ah, ah->ah_bssid, 0);

drivers/net/wireless/ath5k/base.c +11 -2

index 34cd1a4..d5bf62a 100644
@@ -707,7 +707,7 @@ ath5k_attach(struct pci_dev *pdev, struct ieee80211_hw *hw)
 {
 	struct ath5k_softc *sc = hw->priv;
 	struct ath5k_hw *ah = sc->ah;
-	u8 mac[ETH_ALEN];
+	u8 mac[ETH_ALEN] = {};
 	int ret;
 
 	ATH5K_DBG(sc, ATH5K_DEBUG_ANY, "devid 0x%x\n", pdev->device);

@@ -777,7 +777,13 @@ ath5k_attach(struct pci_dev *pdev, struct ieee80211_hw *hw)
 	tasklet_init(&sc->restq, ath5k_tasklet_reset, (unsigned long)sc);
 	setup_timer(&sc->calib_tim, ath5k_calibrate, (unsigned long)sc);
 
-	ath5k_hw_get_lladdr(ah, mac);
+	ret = ath5k_eeprom_read_mac(ah, mac);
+	if (ret) {
+		ATH5K_ERR(sc, "unable to read address from EEPROM: 0x%04x\n",
+			sc->pdev->device);
+		goto err_queues;
+	}
+	
 	SET_IEEE80211_PERM_ADDR(hw, mac);
 	/* All MAC address bits matter for ACKs */
 	memset(sc->bssidmask, 0xff, ETH_ALEN);

@@ -2765,6 +2771,7 @@ static int ath5k_add_interface(struct ieee80211_hw *hw,
 	/* Set to a reasonable value. Note that this will
 	 * be set to mac80211's value at ath5k_config(). */
 	sc->bintval = 1000;
+	ath5k_hw_set_lladdr(sc->ah, conf->mac_addr);
 
 	ret = 0;
 end:

@@ -2777,11 +2784,13 @@ ath5k_remove_interface(struct ieee80211_hw *hw,
 			struct ieee80211_if_init_conf *conf)
 {
 	struct ath5k_softc *sc = hw->priv;
+	u8 mac[ETH_ALEN] = {};
 
 	mutex_lock(&sc->lock);
 	if (sc->vif != conf->vif)
 		goto end;
 
+	ath5k_hw_set_lladdr(sc->ah, mac);
 	sc->vif = NULL;
 end:
 	mutex_unlock(&sc->lock);

Signature · 4 lines

1.5.4.2.182.gb3092

-- 
Bob Copeland %% www.bobcopeland.com

Maxim Levitsky

2008-11-21 19:50 UTC #1 lore raw

Quoted 5 lines · Bob Copeland

Hi Maxim,
Please try this patch. I didn't have a problem changing the mac address after it was set to something else. I did kick it to re-associate with the AP, though.

Tested it, this still doesn't work:

iwconfig wlan0 down
macchanger wlan0
iwconfig wlan0 up

......
at that point card doesn't associate.

if I now set mac back to original, it works.

setting the mac before first ifconfig up (or networkmanager) works.

I did some more testing on wireless transfer speeds, I post a separate message about that, very soon.

Best regards,
Maxim Levitsky

Bob Copeland

author

2008-11-21 20:01 UTC #2 lore raw

Quoted 8 lines · Maxim Levitsky

Quoted 6 lines · Bob Copeland
Hi Maxim,
Please try this patch. I didn't have a problem changing the mac address after it was set to something else. I did kick it to re-associate with the AP, though.

Quoted 5 lines

Tested it, this still doesn't work:
iwconfig wlan0 down
macchanger wlan0
iwconfig wlan0 up

Wait, don't you want to do ifconfig here? Or was that just a typo?

I did exactly that (ifconfig down/macchanger/ifconfig up) and it worked here. In particular if you have mac80211 debugging on it should show the mac address changing. In my case, it didn't matter whether I'd previously associated or not. I did have to tell NetworkManager to re-associate though.

Signature · 1 line

Bob Copeland %% www.bobcopeland.com

Maxim Levitsky

2008-11-21 20:53 UTC #3 lore raw

Quoted 14 lines · Bob Copeland

Quoted 7 lines · Maxim Levitsky
Quoted 6 lines · Bob Copeland
Hi Maxim,
Please try this patch. I didn't have a problem changing the mac address after it was set to something else. I did kick it to re-associate with the AP, though.
Quoted 5 lines
Tested it, this still doesn't work:
iwconfig wlan0 down
macchanger wlan0
iwconfig wlan0 up

Quoted 8 lines

Wait, don't you want to do ifconfig here? Or was that just a typo?
I did exactly that (ifconfig down/macchanger/ifconfig up) and it worked here. In particular if you have mac80211 debugging on it should show the mac address changing. In my case, it didn't matter whether I'd previously associated or not. I did have to tell NetworkManager to re-associate though.

Yep, I intended to use ifconfig.

First change after module reload works, second doesn't.

I double check that I use right kernel (install it again).

Best regards,
Maxim Levitsky

Maxim Levitsky

2008-11-21 21:45 UTC #4 lore raw

Quoted 24 lines · Maxim Levitsky

Quoted 14 lines · Bob Copeland
Quoted 7 lines · Maxim Levitsky
Quoted 6 lines · Bob Copeland
Hi Maxim,
Please try this patch. I didn't have a problem changing the mac address after it was set to something else. I did kick it to re-associate with the AP, though.
Quoted 5 lines
Tested it, this still doesn't work:
iwconfig wlan0 down
macchanger wlan0
iwconfig wlan0 up
Quoted 8 lines
Wait, don't you want to do ifconfig here? Or was that just a typo?
I did exactly that (ifconfig down/macchanger/ifconfig up) and it worked here. In particular if you have mac80211 debugging on it should show the mac address changing. In my case, it didn't matter whether I'd previously associated or not. I did have to tell NetworkManager to re-associate though.

Quoted 5 lines

Yep, I intended to use ifconfig.
First change after module reload works, second doesn't.
I double check that I use right kernel (install it again).

compiled kernel again, and installed it, same results.

Best regards,
Maxim Levitsky

Bob Copeland

author

2008-11-21 23:16 UTC #5 lore raw

Quoted 3 lines · Maxim Levitsky

Quoted 1 line
I double check that I use right kernel (install it again).
compiled kernel again, and installed it, same results.

Can you confirm that the proper mac address shows up if you do ifconfig or macchanger -s? I think it's just not associating.

Also can you try specifying the ap again to trigger a probe after ifconfig up:

    $ iwconfig wlan0 ap <your AP's mac address>

Though I did forget about this gem, try this too:

drivers/net/wireless/ath5k/pcu.c +4 -5

index d7f0c10..f401691 100644
@@ -267,24 +267,23 @@ void ath5k_hw_get_lladdr(struct ath5k_hw *ah, u8 *mac)
  * @mac: The card's mac address
  *
  * Set station id on hw using the provided mac address
- *
- * NOTE: This is only called during attach, don't call it
- * on reset because it overwrites all AR5K_STA_ID1 settings.
- * We have set_opmode (above) for reset.
  */
 int ath5k_hw_set_lladdr(struct ath5k_hw *ah, const u8 *mac)
 {
 	u32 low_id, high_id;
+	u32 pcu_reg;
 
 	ATH5K_TRACE(ah->ah_sc);
 	/* Set new station ID */
 	memcpy(ah->ah_sta_id, mac, ETH_ALEN);
 
+	pcu_reg = ath5k_hw_reg_read(ah, AR5K_STA_ID1) & 0xffff0000;
+
 	low_id = AR5K_LOW_ID(mac);
 	high_id = AR5K_HIGH_ID(mac);
 
 	ath5k_hw_reg_write(ah, low_id, AR5K_STA_ID0);
-	ath5k_hw_reg_write(ah, high_id, AR5K_STA_ID1);
+	ath5k_hw_reg_write(ah, pcu_reg | high_id, AR5K_STA_ID1);
 
 	return 0;
 }

Signature · 1 line

Bob Copeland %% www.bobcopeland.com

Maxim Levitsky

2008-11-22 13:25 UTC #6 lore raw

Quoted 4 lines · Bob Copeland

Quoted 2 lines · Maxim Levitsky
Quoted 1 line
I double check that I use right kernel (install it again).
compiled kernel again, and installed it, same results.

Quoted 8 lines

Can you confirm that the proper mac address shows up if you do ifconfig or macchanger -s? I think it's just not associating.
Also can you try specifying the ap again to trigger a probe after ifconfig up:
    $ iwconfig wlan0 ap <your AP's mac address>
Though I did forget about this gem, try this too:

Mystery solved, and sorry for the noise,
short answer is, wpa_supplicant.

My network is WPA2 protected, and I only test against it, and
it takes time to go to AP settings, change encryption to WEP, and not forget to change it back, etc...

So, wpa_supplicant wasn't aware of new mac, but I remember that WPA uses mac as part of encryption.

restarting it solved the problem.

I also applied (by hand) your latest patch, so maybe it did help, I'll check without it too.

Best regards,
Maxim Levitsky

Stefanik Gábor

2008-12-15 15:47 UTC #7 lore raw

In reply to Bob Copeland

This patch regressed support for aireplay-ng's "fragmentation attack" feature!

Prior to the landing of this patch (as commit caeb36d73b23b52a0ea2a8368502ef8230fa67b3), applying the patch @
http://patches.aircrack-ng.org/mac80211_2.6.28-rc4-wl_frag+ack_v2.patch
allowed aireplay-ng's fragmentation attack to work with almost all mac80211 drivers, including ath5k. After the landing of this patch, the attack fails with "No answer, repeating...". (Regression found using git bisect, and verified by local backout of commit caeb36d73b23b52a0ea2a8368502ef8230fa67b3.)

Quoted 112 lines · Bob Copeland

Hi Maxim,

Please try this patch. I didn't have a problem changing the mac address after it was set to something else. I did kick it to re-associate with the AP, though.

Subject: [PATCH] ath5k: set mac address in add_interface

Signed-off-by Bob Copeland <[email protected]>

---
 drivers/net/wireless/ath5k/attach.c |   12 +++---------
 drivers/net/wireless/ath5k/base.c   |   13 +++++++++++--
 2 files changed, 14 insertions(+), 11 deletions(-)

drivers/net/wireless/ath5k/attach.c +3 -9

index 51d5698..49d82d7 100644
@@ -106,7 +106,7 @@ struct ath5k_hw *ath5k_hw_attach(struct ath5k_softc *sc, u8 mac_version)
 {
       struct ath5k_hw *ah;
       struct pci_dev *pdev = sc->pdev;
-       u8 mac[ETH_ALEN];
+       u8 mac[ETH_ALEN] = {};
       int ret;
       u32 srev;

@@ -317,15 +317,9 @@ struct ath5k_hw *ath5k_hw_attach(struct ath5k_softc *sc, u8 mac_version)
               goto err_free;
       }
 
-       /* Set MAC address */
-       ret = ath5k_eeprom_read_mac(ah, mac);
-       if (ret) {
-               ATH5K_ERR(sc, "unable to read address from EEPROM: 0x%04x\n",
-                       sc->pdev->device);
-               goto err_free;
-       }
-
+       /* MAC address is cleared until add_interface */
       ath5k_hw_set_lladdr(ah, mac);
+
       /* Set BSSID to bcast address: ff:ff:ff:ff:ff:ff for now */
       memset(ah->ah_bssid, 0xff, ETH_ALEN);
       ath5k_hw_set_associd(ah, ah->ah_bssid, 0);

drivers/net/wireless/ath5k/base.c +11 -3

index 34cd1a4..d5bf62a 100644
@@ -707,7 +707,7 @@ ath5k_attach(struct pci_dev *pdev, struct ieee80211_hw *hw)
 {
       struct ath5k_softc *sc = hw->priv;
       struct ath5k_hw *ah = sc->ah;
-       u8 mac[ETH_ALEN];
+       u8 mac[ETH_ALEN] = {};
       int ret;
 
       ATH5K_DBG(sc, ATH5K_DEBUG_ANY, "devid 0x%x\n", pdev->device);

@@ -777,7 +777,13 @@ ath5k_attach(struct pci_dev *pdev, struct ieee80211_hw *hw)
       tasklet_init(&sc->restq, ath5k_tasklet_reset, (unsigned long)sc);
       setup_timer(&sc->calib_tim, ath5k_calibrate, (unsigned long)sc);
 
-       ath5k_hw_get_lladdr(ah, mac);
+       ret = ath5k_eeprom_read_mac(ah, mac);
+       if (ret) {
+               ATH5K_ERR(sc, "unable to read address from EEPROM: 0x%04x\n",
+                       sc->pdev->device);
+               goto err_queues;
+       }
+
       SET_IEEE80211_PERM_ADDR(hw, mac);
       /* All MAC address bits matter for ACKs */
       memset(sc->bssidmask, 0xff, ETH_ALEN);

@@ -2765,6 +2771,7 @@ static int ath5k_add_interface(struct ieee80211_hw *hw,
       /* Set to a reasonable value. Note that this will
        * be set to mac80211's value at ath5k_config(). */
       sc->bintval = 1000;
+       ath5k_hw_set_lladdr(sc->ah, conf->mac_addr);
 
       ret = 0;
 end:

@@ -2777,11 +2784,13 @@ ath5k_remove_interface(struct ieee80211_hw *hw,
                       struct ieee80211_if_init_conf *conf)
 {
       struct ath5k_softc *sc = hw->priv;
+       u8 mac[ETH_ALEN] = {};
 
       mutex_lock(&sc->lock);
       if (sc->vif != conf->vif)
               goto end;
 
+       ath5k_hw_set_lladdr(sc->ah, mac);
       sc->vif = NULL;
 end:
       mutex_unlock(&sc->lock);
--

1.5.4.2.182.gb3092

--
Bob Copeland %% www.bobcopeland.com

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Signature · 1 line

Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)

Dan Williams

2008-12-15 16:06 UTC #8 lore raw

Quoted 1 line · On Mon, 2008-12-15 at 16:47 +0100, Stefanik G=C3=A1bor wrote:

This patch regressed support for aireplay-ng's "fragmentation attack"=

feature!

Quoted 4 lines

=20
Prior to the landing of this patch (as commit caeb36d73b23b52a0ea2a8368502ef8230fa67b3), applying the patch @
http://patches.aircrack-ng.org/mac80211_2.6.28-rc4-wl_frag+ack_v2.pat=

Quoted 5 lines

allowed aireplay-ng's fragmentation attack to work with almost all mac80211 drivers, including ath5k. After the landing of this patch, the attack fails with "No answer, repeating...". (Regression found using git bisect, and verified by local backout of commit caeb36d73b23b52a0ea2a8368502ef8230fa67b3.)

Unless I misunderstand... but not all drivers will report their MAC address until they have opened the device (ie, add_interface time), because not all devices load firmware until the interface is opened, an= d
thus some cannot read their MAC address until that time.

So aireplay-ng is broken if it relies on the device having a valid mac address before the device is opened.

Dan

Quoted 1 line

On Tue, Nov 18, 2008 at 5:40 AM, Bob Copeland <[email protected]> wr=

ote:

Quoted 3 lines

Quoted 3 lines
Hi Maxim,
Please try this patch. I didn't have a problem changing the mac ad=

dress

Quoted 1 line

Quoted 1 line
after it was set to something else. I did kick it to re-associate =

with

Quoted 10 lines

Quoted 10 lines
the AP, though.
Subject: [PATCH] ath5k: set mac address in add_interface
Configure the mac address in add_interface and clear it in remove_interface so that users can change the mac address to something other than the one in the eeprom. Also avoid setting it at attach time so that we won't ack packets until fully set up.

Quoted 7 lines

drivers/net/wire=
Quoted 7 lines
Signed-off-by Bob Copeland <[email protected]>
---
 drivers/net/wireless/ath5k/attach.c |   12 +++---------
 drivers/net/wireless/ath5k/base.c   |   13 +++++++++++--
 2 files changed, 14 insertions(+), 11 deletions(-)
drivers/net/wire= renamed from drivers/net/wireless/ath5k/attach.c +0 -0

less/ath5k/attach.c

Quoted 4 lines

drivers/net/wireless/ath5k/attach.c struct ath5k_hw *ath5k_hw_attach(struct ath5k_s=
Quoted 4 lines
index 51d5698..49d82d7 100644
drivers/net/wireless/ath5k/attach.c +0 -0
@@ -106,7 +106,7 @@ struct ath5k_hw *ath5k_hw_attach(struct ath5k_s=

oftc *sc, u8 mac_version)

Quoted 9 lines

drivers/net/wireless/ath5k/attach.c struct ath5k_hw *ath5k_hw_attach(struct ath5k_=

Quoted 9 lines

drivers/net/wireless/ath5k/attach.c +1 -1

 {
       struct ath5k_hw *ah;
       struct pci_dev *pdev =3D sc->pdev;
-       u8 mac[ETH_ALEN];
+       u8 mac[ETH_ALEN] =3D {};
       int ret;
       u32 srev;

@@ -317,15 +317,9 @@ struct ath5k_hw *ath5k_hw_attach(struct ath5k_=

softc *sc, u8 mac_version)

Quoted 7 lines

drivers/net/wireless/ath5k/attach.c struct ath5k_hw *ath5k_hw_attach(struct ath5k_softc *sc, u8 mac_version)
Quoted 7 lines
drivers/net/wireless/ath5k/attach.c +0 -4
               goto err_free;
       }
 
-       /* Set MAC address */
-       ret =3D ath5k_eeprom_read_mac(ah, mac);
-       if (ret) {
-               ATH5K_ERR(sc, "unable to read address from EEPROM: =

0x%04x\n",

Quoted 11 lines

drivers/net/wirele=

Quoted 11 lines

drivers/net/wireless/ath5k/attach.c +2 -4

-                       sc->pdev->device);
-               goto err_free;
-       }
-
+       /* MAC address is cleared until add_interface */
       ath5k_hw_set_lladdr(ah, mac);
+
       /* Set BSSID to bcast address: ff:ff:ff:ff:ff:ff for now */
       memset(ah->ah_bssid, 0xff, ETH_ALEN);
       ath5k_hw_set_associd(ah, ah->ah_bssid, 0);

drivers/net/wirele= renamed from drivers/net/wireless/ath5k/base.c +0 -0

ss/ath5k/base.c

Quoted 4 lines

drivers/net/wireless/ath5k/base.c ath5k_attach(struct pci_dev *pdev, struct ieee8=
Quoted 4 lines
index 34cd1a4..d5bf62a 100644
drivers/net/wireless/ath5k/base.c +0 -0
@@ -707,7 +707,7 @@ ath5k_attach(struct pci_dev *pdev, struct ieee8=

0211_hw *hw)

Quoted 8 lines

drivers/net/wireless/ath5k/base.c ath5k_attach(struct pci_dev *pdev, struct ieee8= · line 713

Quoted 8 lines

drivers/net/wireless/ath5k/base.c +1 -1

 {
       struct ath5k_softc *sc =3D hw->priv;
       struct ath5k_hw *ah =3D sc->ah;
-       u8 mac[ETH_ALEN];
+       u8 mac[ETH_ALEN] =3D {};
       int ret;
 
       ATH5K_DBG(sc, ATH5K_DEBUG_ANY, "devid 0x%x\n", pdev->device)=

;

Quoted 1 line

drivers/net/wireless/ath5k/base.c ath5k_attach(struct pci_dev *pdev, struct ieee=
Quoted 1 line
drivers/net/wireless/ath5k/base.c +0 -0
@@ -777,7 +777,13 @@ ath5k_attach(struct pci_dev *pdev, struct ieee=

80211_hw *hw)

Quoted 1 line

drivers/net/wireless/ath5k/base.c ath5k_attach(struct pci_dev *pdev, struct ieee= · line 777
Quoted 1 line
drivers/net/wireless/ath5k/base.c +0 -0
       tasklet_init(&sc->restq, ath5k_tasklet_reset, (unsigned long=

)sc);

Quoted 1 line

drivers/net/wireless/ath5k/base.c ath5k_attach(struct pci_dev *pdev, struct ieee= · line 778
Quoted 1 line
drivers/net/wireless/ath5k/base.c +0 -0
       setup_timer(&sc->calib_tim, ath5k_calibrate, (unsigned long)=

sc);

Quoted 5 lines

drivers/net/wireless/ath5k/base.c ath5k_attach(struct pci_dev *pdev, struct ieee80211_hw *hw)
Quoted 5 lines
drivers/net/wireless/ath5k/base.c +3 -1
-       ath5k_hw_get_lladdr(ah, mac);
+       ret =3D ath5k_eeprom_read_mac(ah, mac);
+       if (ret) {
+               ATH5K_ERR(sc, "unable to read address from EEPROM: =

0x%04x\n",

Quoted 8 lines

drivers/net/wireless/ath5k/base.c static int ath5k_add_interface(struct ieee802=

Quoted 8 lines

drivers/net/wireless/ath5k/base.c +4 -0

+                       sc->pdev->device);
+               goto err_queues;
+       }
+
       SET_IEEE80211_PERM_ADDR(hw, mac);
       /* All MAC address bits matter for ACKs */
       memset(sc->bssidmask, 0xff, ETH_ALEN);

@@ -2765,6 +2771,7 @@ static int ath5k_add_interface(struct ieee802=

11_hw *hw,

Quoted 8 lines

drivers/net/wireless/ath5k/base.c ath5k_remove_interface(struct ieee80211_hw =

Quoted 8 lines

drivers/net/wireless/ath5k/base.c +1 -0

       /* Set to a reasonable value. Note that this will
        * be set to mac80211's value at ath5k_config(). */
       sc->bintval =3D 1000;
+       ath5k_hw_set_lladdr(sc->ah, conf->mac_addr);
 
       ret =3D 0;
 end:

@@ -2777,11 +2784,13 @@ ath5k_remove_interface(struct ieee80211_hw =

*hw,

Quoted 16 lines

drivers/net/wireless/ath5k/base.c +2 -1

                       struct ieee80211_if_init_conf *conf)
 {
       struct ath5k_softc *sc =3D hw->priv;
+       u8 mac[ETH_ALEN] =3D {};
 
       mutex_lock(&sc->lock);
       if (sc->vif !=3D conf->vif)
               goto end;
 
+       ath5k_hw_set_lladdr(sc->ah, mac);
       sc->vif =3D NULL;
 end:
       mutex_unlock(&sc->lock);
--

1.5.4.2.182.gb3092

Quoted 5 lines

Quoted 5 lines
--
Bob Copeland %% www.bobcopeland.com
--
To unsubscribe from this list: send the line "unsubscribe linux-wir=

eless" in

Quoted 6 lines

Quoted 3 lines
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
=20
=20
=20

--
To unsubscribe from this list: send the line "unsubscribe linux-wireles= s" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Stefanik Gábor

2008-12-15 16:12 UTC #9 lore raw

Quoted 2 lines · Dan Williams

Quoted 1 line · On Mon, 2008-12-15 at 16:47 +0100, Stefanik G=E1bor wrote:
This patch regressed support for aireplay-ng's "fragmentation attack=

" feature!

Quoted 4 lines

Quoted 4 lines
Prior to the landing of this patch (as commit caeb36d73b23b52a0ea2a8368502ef8230fa67b3), applying the patch @
http://patches.aircrack-ng.org/mac80211_2.6.28-rc4-wl_frag+ack_v2.pa=

tch

Quoted 9 lines

Quoted 5 lines
allowed aireplay-ng's fragmentation attack to work with almost all mac80211 drivers, including ath5k. After the landing of this patch, the attack fails with "No answer, repeating...". (Regression found using git bisect, and verified by local backout of commit caeb36d73b23b52a0ea2a8368502ef8230fa67b3.)
Unless I misunderstand... but not all drivers will report their MAC address until they have opened the device (ie, add_interface time), because not all devices load firmware until the interface is opened, =

and

Quoted 3 lines

thus some cannot read their MAC address until that time.
So aireplay-ng is broken if it relies on the device having a valid ma=

Quoted 4 lines

address before the device is opened.
Dan

That is not the problem - aireplay-ng operates on a monitor interface that is already up. Likely this patch somehow misses monitor interfaces.

--=20
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-) --
To unsubscribe from this list: send the line "unsubscribe linux-wireles= s" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Dan Williams

2008-12-15 16:24 UTC #10 lore raw

Quoted 1 line · On Mon, 2008-12-15 at 17:12 +0100, Stefanik G=C3=A1bor wrote:

On Mon, Dec 15, 2008 at 5:04 PM, Dan Williams <[email protected]> wrote=

Quoted 2 lines

Quoted 2 lines · On Mon, 2008-12-15 at 16:47 +0100, Stefanik G=C3=A1bor wrote:
Quoted 1 line
This patch regressed support for aireplay-ng's "fragmentation atta=

ck" feature!

Quoted 4 lines

Quoted 4 lines
Quoted 4 lines
Prior to the landing of this patch (as commit caeb36d73b23b52a0ea2a8368502ef8230fa67b3), applying the patch @
http://patches.aircrack-ng.org/mac80211_2.6.28-rc4-wl_frag+ack_v2.=

patch

Quoted 2 lines

Quoted 2 lines
Quoted 2 lines
allowed aireplay-ng's fragmentation attack to work with almost all mac80211 drivers, including ath5k. After the landing of this patch=

Quoted 5 lines

Quoted 5 lines
Quoted 3 lines
the attack fails with "No answer, repeating...". (Regression found using git bisect, and verified by local backout of commit caeb36d73b23b52a0ea2a8368502ef8230fa67b3.)
Unless I misunderstand... but not all drivers will report their MA=

Quoted 2 lines

Quoted 2 lines
address until they have opened the device (ie, add_interface time), because not all devices load firmware until the interface is opened=

, and

Quoted 3 lines

Quoted 3 lines
thus some cannot read their MAC address until that time.
So aireplay-ng is broken if it relies on the device having a valid =

mac

Quoted 8 lines

Quoted 4 lines
address before the device is opened.
Dan
=20
That is not the problem - aireplay-ng operates on a monitor interface that is already up. Likely this patch somehow misses monitor interfaces.

Ah, ok. Ignore my mail then :)

dan

--
To unsubscribe from this list: send the line "unsubscribe linux-wireles= s" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Bob Copeland

author

2008-12-15 17:16 UTC #11 lore raw

In reply to Stefanik Gábor

Quoted 3 lines · On Mon, Dec 15, 2008 at 11:12 AM, Stefanik G=E1bor <[email protected]>…

That is not the problem - aireplay-ng operates on a monitor interface that is already up. Likely this patch somehow misses monitor interfaces.

Agreed, that is probably the case. Reverting that hunk makes it come u= p
with the eeprom mac without adding any interface. Looking at the add_interface() code, it 'should' program the mac for monitor interface= s
too, so offhand I'm not sure, will take a look tonight.

--=20
Bob Copeland %% www.bobcopeland.com
--
To unsubscribe from this list: send the line "unsubscribe linux-wireles= s" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Bob Copeland

author

2008-12-16 14:58 UTC #12 lore raw

On Mon, Dec 15, 2008 at 12:16 PM, Bob Copeland <[email protected]> wro= te:

Quoted 3 lines

Quoted 1 line · On Mon, Dec 15, 2008 at 11:12 AM, Stefanik G=E1bor <[email protected]>…
That is not the problem - aireplay-ng operates on a monitor interfac=

Quoted 4 lines

Quoted 2 lines
that is already up. Likely this patch somehow misses monitor interfaces.
Agreed, that is probably the case. Reverting that hunk makes it come=

Quoted 2 lines

with the eeprom mac without adding any interface. Looking at the add_interface() code, it 'should' program the mac for monitor interfa=

ces

Quoted 1 line

too, so offhand I'm not sure, will take a look tonight.

Okay, so that I understand the problem a bit better: what used to happe= n
and what does not happen now? Is the ath5k device not sending ACKs, or not passing any frames back to the host?

The code, for mac address setting at least, looks to be working as
designed: the mac address is only set up at add_interface time to avoid automatically acking packets before an interface is brought up (see the kerneldoc comments in mac80211 on add/remove_interface).

The ath5k rx filter for unicast frames requires mac addresses to match = in
order to accept or ack frames. However, in monitor mode, mac80211 will never call add_interface(). Instead, it should configure the filter to put the card in promiscuous mode which then should enable all packets to be passed back to the host.

Does the fragmentation attack also work with e.g. b43 (which also only sets up the mac at add_interface time)?

Johannes Berg

maintainer

2008-12-16 15:01 UTC #13 lore raw

Quoted 10 lines · Bob Copeland

The code, for mac address setting at least, looks to be working as
designed: the mac address is only set up at add_interface time to avoid automatically acking packets before an interface is brought up (see the kerneldoc comments in mac80211 on add/remove_interface).
The ath5k rx filter for unicast frames requires mac addresses to match in order to accept or ack frames. However, in monitor mode, mac80211 will never call add_interface(). Instead, it should configure the filter to put the card in promiscuous mode which then should enable all packets to be passed back to the host.

FWIW, this is as designed, if you need to have ACKs then you need to bring up a monitor as well as a regular interface. Stefanik, please do that and report whether it works.

johannes

Bob Copeland

author

2008-12-19 15:17 UTC #14 lore raw

On Tue, 16 Dec 2008 16:01:09 +0100, Johannes Berg wrote

Quoted 9 lines

Quoted 5 lines
The ath5k rx filter for unicast frames requires mac addresses to match in order to accept or ack frames. However, in monitor mode, mac80211 will never call add_interface(). Instead, it should configure the filter to put the card in promiscuous mode which then should enable all packets to be passed back to the host.
FWIW, this is as designed, if you need to have ACKs then you need to bring up a monitor as well as a regular interface. Stefanik, please do that and report whether it works.

So in that case, ath5k definitely should not upload a mac until a normal interface is brought up, i.e. we should keep the current functionality?

It's interesting that b43 works without a regular interface, by my reading of its code the mac is also loaded and cleared at add/remove interface time.

Signature · 1 line

Bob Copeland %% www.bobcopeland.com

Johannes Berg

maintainer

2008-12-20 09:46 UTC #15 lore raw

Quoted 3 lines

So in that case, ath5k definitely should not upload a mac until a normal interface is brought up, i.e. we should keep the current functionality?

yes.

Quoted 1 line

It's interesting that b43 works without a regular interface, by my

reading

Quoted 2 lines

of
its code the mac is also loaded and cleared at add/remove interface time.

I suspect there's some filtering going wrong.

johannes

Stefanik Gábor

2008-12-16 15:42 UTC #16 lore raw

In reply to Bob Copeland

Quoted 27 lines · Bob Copeland

Quoted 10 lines · Bob Copeland
Quoted 3 lines · Stefanik Gábor
That is not the problem - aireplay-ng operates on a monitor interface that is already up. Likely this patch somehow misses monitor interfaces.
Agreed, that is probably the case. Reverting that hunk makes it come up with the eeprom mac without adding any interface. Looking at the add_interface() code, it 'should' program the mac for monitor interfaces too, so offhand I'm not sure, will take a look tonight.
Okay, so that I understand the problem a bit better: what used to happen and what does not happen now? Is the ath5k device not sending ACKs, or not passing any frames back to the host?
The code, for mac address setting at least, looks to be working as
designed: the mac address is only set up at add_interface time to avoid automatically acking packets before an interface is brought up (see the kerneldoc comments in mac80211 on add/remove_interface).
The ath5k rx filter for unicast frames requires mac addresses to match in order to accept or ack frames. However, in monitor mode, mac80211 will never call add_interface(). Instead, it should configure the filter to put the card in promiscuous mode which then should enable all packets to be passed back to the host.

Quoted 6 lines

Does the fragmentation attack also work with e.g. b43 (which also only sets up the mac at add_interface time)?
--
Bob Copeland %% www.bobcopeland.com

The fragmentation attack works perfectly in b43, regardless of whether I set the main interface to monitor mode, or create a secondary monitor interface. In the second case, it also doesn't matter whether the main interface is up or down.

With the "buggy" ath5k, it only works if I use a secondary interface, and also bring the main (managed) interface up.

About the attachments: ath5k-debug-sent.cap was captured on the monitor interface set up on the ath5k device, while ath5k-debug-mon.cap was captured on my rtl8187. They are not from the same session, but they were created the same way: I started a fragmentation attack with ath5k's managed interface down, then while it was retrying, brought up the managed interface using ifconfig.

Signature · 1 line

Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)

A message that is not in the archive (sent off-list or not yet received): [email protected]

Stefanik Gábor

2008-12-15 16:30 UTC #18 lore raw

On Mon, Dec 15, 2008 at 5:17 PM, Bob Copeland <[email protected]> wrot= e:

Quoted 2 lines

On Mon, 15 Dec 2008 16:47:48 +0100, Stefanik G=E1bor wrote
Quoted 1 line
This patch regressed support for aireplay-ng's "fragmentation attack=

" feature!

Quoted 7 lines

Does reverting just the following hunk make it work again?
Quoted 2 lines
Quoted 2 lines
drivers/net/wireless/ath5k/attach.c +0 -0
[...]
Quoted 1 line
drivers/net/wireless/ath5k/attach.c struct ath5k_hw *ath5k_hw_attach(struct ath5k=
Quoted 1 line
drivers/net/wireless/ath5k/attach.c +0 -0
@@ -317,15 +317,9 @@ struct ath5k_hw *ath5k_hw_attach(struct ath5k=

_softc

Quoted 8 lines

*sc, u8 mac_version)

Quoted 7 lines

drivers/net/wireless/ath5k/attach.c +0 -4

               goto err_free;
       }
 
-       /* Set MAC address */
-       ret =3D ath5k_eeprom_read_mac(ah, mac);
-       if (ret) {
-               ATH5K_ERR(sc, "unable to read address from EEPROM:=

0x%04x\n",

Quoted 5 lines

drivers/net/wireless/ath5k/attach.c +1 -4

-                       sc->pdev->device);
-               goto err_free;
-       }
-
+       /* MAC address is cleared until add_interface */

Quoted 11 lines

Quoted 5 lines
drivers/net/wireless/ath5k/attach.c struct ath5k_hw *ath5k_hw_attach(struct ath5k_softc *sc, u8 mac_version) · line 325
Quoted 5 lines
drivers/net/wireless/ath5k/attach.c +1 -0
       ath5k_hw_set_lladdr(ah, mac);
+
       /* Set BSSID to bcast address: ff:ff:ff:ff:ff:ff for now */
       memset(ah->ah_bssid, 0xff, ETH_ALEN);
       ath5k_hw_set_associd(ah, ah->ah_bssid, 0);
--
Bob Copeland %% www.bobcopeland.com

Yes, this fixes it.