[PATCH] ath5k: set mac address in add_interface

[PATCH] ath5k: set mac address in add_interface

[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

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 <me@bobcopeland.com>
---
 drivers/net/wireless/ath5k/attach.c |   12 +++---------
 drivers/net/wireless/ath5k/base.c   |   13 +++++++++++--
 2 files changed, 14 insertions(+), 11 deletions(-)

diff --git a/drivers/net/wireless/ath5k/attach.c b/drivers/net/wireless/ath5k/attach.c
index 51d5698..49d82d7 100644
--- a/drivers/net/wireless/ath5k/attach.c
+++ b/drivers/net/wireless/ath5k/attach.c
@@ -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);
diff --git a/drivers/net/wireless/ath5k/base.c b/drivers/net/wireless/ath5k/base.c
index 34cd1a4..d5bf62a 100644
--- a/drivers/net/wireless/ath5k/base.c
+++ b/drivers/net/wireless/ath5k/base.c
@@ -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

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

[Maxim Levitsky]

Bob Copeland wrote:
> 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

Re: [ath5k-devel] [PATCH] ath5k: set mac address in add_interface

[Bob Copeland]

On Fri, Nov 21, 2008 at 2:49 PM, Maxim Levitsky <maximlevitsky@gmail.com> wrote:
> Bob Copeland wrote:
>> 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

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.

-- 
Bob Copeland %% www.bobcopeland.com

Re: [ath5k-devel] [PATCH] ath5k: set mac address in add_interface

[Maxim Levitsky]

Bob Copeland wrote:
> On Fri, Nov 21, 2008 at 2:49 PM, Maxim Levitsky <maximlevitsky@gmail.com> wrote:
>> Bob Copeland wrote:
>>> 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
> 
> 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

Re: [ath5k-devel] [PATCH] ath5k: set mac address in add_interface

[Maxim Levitsky]

Maxim Levitsky wrote:
> Bob Copeland wrote:
>> On Fri, Nov 21, 2008 at 2:49 PM, Maxim Levitsky 
>> <maximlevitsky@gmail.com> wrote:
>>> Bob Copeland wrote:
>>>> 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
>>
>> 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).

compiled kernel again, and installed it, same results.

Best regards,
	Maxim Levitsky

Re: [ath5k-devel] [PATCH] ath5k: set mac address in add_interface

[Bob Copeland]

On Fri, Nov 21, 2008 at 11:45:18PM +0200, Maxim Levitsky wrote:
>> 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:

diff --git a/drivers/net/wireless/ath5k/pcu.c b/drivers/net/wireless/ath5k/pcu.c
index d7f0c10..f401691 100644
--- a/drivers/net/wireless/ath5k/pcu.c
+++ b/drivers/net/wireless/ath5k/pcu.c
@@ -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;
 }

-- 
Bob Copeland %% www.bobcopeland.com

Re: [ath5k-devel] [PATCH] ath5k: set mac address in add_interface

[Maxim Levitsky]

Bob Copeland wrote:
> On Fri, Nov 21, 2008 at 11:45:18PM +0200, Maxim Levitsky wrote:
>>> 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:

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

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

[Stefanik Gábor]

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


On Tue, Nov 18, 2008 at 5:40 AM, Bob Copeland <me@bobcopeland.com> wrote:
> 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 <me@bobcopeland.com>
> ---
>  drivers/net/wireless/ath5k/attach.c |   12 +++---------
>  drivers/net/wireless/ath5k/base.c   |   13 +++++++++++--
>  2 files changed, 14 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/net/wireless/ath5k/attach.c b/drivers/net/wireless/ath5k/attach.c
> index 51d5698..49d82d7 100644
> --- a/drivers/net/wireless/ath5k/attach.c
> +++ b/drivers/net/wireless/ath5k/attach.c
> @@ -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);
> diff --git a/drivers/net/wireless/ath5k/base.c b/drivers/net/wireless/ath5k/base.c
> index 34cd1a4..d5bf62a 100644
> --- a/drivers/net/wireless/ath5k/base.c
> +++ b/drivers/net/wireless/ath5k/base.c
> @@ -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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>



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

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

[Dan Williams]

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!
>=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=
ch
> 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

> On Tue, Nov 18, 2008 at 5:40 AM, Bob Copeland <me@bobcopeland.com> wr=
ote:
> > Hi Maxim,
> >
> > Please try this patch.  I didn't have a problem changing the mac ad=
dress
> > 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 <me@bobcopeland.com>
> > ---
> >  drivers/net/wireless/ath5k/attach.c |   12 +++---------
> >  drivers/net/wireless/ath5k/base.c   |   13 +++++++++++--
> >  2 files changed, 14 insertions(+), 11 deletions(-)
> >
> > diff --git a/drivers/net/wireless/ath5k/attach.c b/drivers/net/wire=
less/ath5k/attach.c
> > index 51d5698..49d82d7 100644
> > --- a/drivers/net/wireless/ath5k/attach.c
> > +++ b/drivers/net/wireless/ath5k/attach.c
> > @@ -106,7 +106,7 @@ struct ath5k_hw *ath5k_hw_attach(struct ath5k_s=
oftc *sc, u8 mac_version)
> >  {
> >        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)
> >                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",
> > -                       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);
> > diff --git a/drivers/net/wireless/ath5k/base.c b/drivers/net/wirele=
ss/ath5k/base.c
> > index 34cd1a4..d5bf62a 100644
> > --- a/drivers/net/wireless/ath5k/base.c
> > +++ b/drivers/net/wireless/ath5k/base.c
> > @@ -707,7 +707,7 @@ ath5k_attach(struct pci_dev *pdev, struct ieee8=
0211_hw *hw)
> >  {
> >        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)=
;
> > @@ -777,7 +777,13 @@ ath5k_attach(struct pci_dev *pdev, struct ieee=
80211_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 =3D 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 ieee802=
11_hw *hw,
> >        /* 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,
> >                        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
> >
> > --
> > Bob Copeland %% www.bobcopeland.com
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-wir=
eless" in
> > the body of a message to majordomo@vger.kernel.org
> > 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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Stefanik Gábor]

On Mon, Dec 15, 2008 at 5:04 PM, Dan Williams <dcbw@redhat.com> wrote:
> On Mon, 2008-12-15 at 16:47 +0100, Stefanik G=E1bor wrote:
>> 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.pa=
tch
>> 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
> 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=
c
> 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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Dan Williams]

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 <dcbw@redhat.com> wrote=
:
> > On Mon, 2008-12-15 at 16:47 +0100, Stefanik G=C3=A1bor wrote:
> >> This patch regressed support for aireplay-ng's "fragmentation atta=
ck" 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.)
> >
> > Unless I misunderstand...  but not all drivers will report their MA=
C
> > address until they have opened the device (ie, add_interface time),
> > because not all devices load firmware until the interface is opened=
, and
> > 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
> >
>=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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [ath5k-devel] [PATCH] ath5k: set mac address in add_interface

[Bob Copeland]

On Mon, Dec 15, 2008 at 11:12 AM, Stefanik G=E1bor
<netrolller.3d@gmail.com> wrote:
> 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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [ath5k-devel] [PATCH] ath5k: set mac address in add_interface

[Bob Copeland]

On Mon, Dec 15, 2008 at 12:16 PM, Bob Copeland <me@bobcopeland.com> wro=
te:
> On Mon, Dec 15, 2008 at 11:12 AM, Stefanik G=E1bor
> <netrolller.3d@gmail.com> wrote:
>> That is not the problem - aireplay-ng operates on a monitor interfac=
e
>> 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 interfa=
ces
> 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)?

--=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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [ath5k-devel] [PATCH] ath5k: set mac address in add_interface

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 867 bytes --]

On Tue, 2008-12-16 at 09:58 -0500, Bob Copeland wrote:

> 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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [ath5k-devel] [PATCH] ath5k: set mac address in add_interface

[Bob Copeland]

On Tue, 16 Dec 2008 16:01:09 +0100, Johannes Berg wrote
> > 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.

-- 
Bob Copeland %% www.bobcopeland.com

Re: [ath5k-devel] [PATCH] ath5k: set mac address in add_interface

[Johannes Berg]

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

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

I suspect there's some filtering going wrong.

johannes

Re: [ath5k-devel] [PATCH] ath5k: set mac address in add_interface

[Stefanik Gábor]

[-- Attachment #1: Type: text/plain, Size: 2514 bytes --]

On Tue, Dec 16, 2008 at 3:58 PM, Bob Copeland <me@bobcopeland.com> wrote:
> On Mon, Dec 15, 2008 at 12:16 PM, Bob Copeland <me@bobcopeland.com> wrote:
>> On Mon, Dec 15, 2008 at 11:12 AM, Stefanik Gábor
>> <netrolller.3d@gmail.com> wrote:
>>> 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.
>
> 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.

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

[-- Attachment #2: ath5k-debug-mon.cap --]
[-- Type: application/octet-stream, Size: 227833 bytes --]

[-- Attachment #3: ath5k-debug-sent.cap --]
[-- Type: application/octet-stream, Size: 216550 bytes --]

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

[Stefanik Gábor]

On Mon, Dec 15, 2008 at 5:17 PM, Bob Copeland <me@bobcopeland.com> wrot=
e:
> On Mon, 15 Dec 2008 16:47:48 +0100, Stefanik G=E1bor wrote
>> This patch regressed support for aireplay-ng's "fragmentation attack=
" feature!
>
> Does reverting just the following hunk make it work again?
>
>> > --- a/drivers/net/wireless/ath5k/attach.c
>> > +++ b/drivers/net/wireless/ath5k/attach.c
> [...]
>> > @@ -317,15 +317,9 @@ struct ath5k_hw *ath5k_hw_attach(struct ath5k=
_softc
> *sc, u8 mac_version)
>> >                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",
>> > -                       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);
>
> --
> Bob Copeland %% www.bobcopeland.com
>
>
>

Yes, this fixes it.

--=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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html