Hello nice people,
we've recently found a bug when using infrastructure mode with tplink
wn722n usb dongles (ath9k_htc driver)
on the latest compat mac80211 we could find (2012-06-14) compiled
against a 3.3.8 kernel, it has a problem with receiving broadcast
while in client mode.
That is, if the card is in Managed mode, it associates correctly,
sends and receives unicast packets perfectly, and can send broadcast
packets too. But no packets sent to broadcast from the AP will be
understood.
This has been observed with a simple arping
[x.x.x.x being the ap, and y.y.y.y being the dongle in client mode.]
sta# arping -b -I wlan1 x.x.x.x
ARPING to x.x.x.x from y.y.y.y via wlan1
Unicast reply from x.x.x.x [f8:d1:11:c0:ef:72] 108.579ms
Unicast reply from x.x.x.x [f8:d1:11:c0:ef:72] 108.157ms
ap# arping -b -I wlan1 y.y.y.y
ARPING to y.y.y.y from x.x.x.x via wlan1
[no replies]
wireshark running on a separate laptop confirmed that the ap is indeed
transmitting the broadcast, but a tcpdump running on client station
shows no trace of the packet.
unicasts, on the other hand, are received perfectly (both seen by
wireshark on the air, and tcpdump in the station)
This behaviour does not happen with mac80211 2012-02-27 compiled against 3.2.14
I've recompiled many different versions of openwrt in a "bisecting"
manner and managed to narrow it down to commit r31322 of openwrt,
"mac80211: update to wireless-testing 2012-04-13"
so the regression has been introduced somewhere between 2012-02-27
(ok) and 2012-04-13 (bug)
I *could* try to narrow it further, by cherrypicking revisions of
wireless-testing between those dates, and try to compile a custom
openwrt (i'm not sure how would that work) but I have already spent a
lot more time than i was expecting to get to this point :(
So maybe some developer, or someone more familiar with the changelog,
might have an idea when /where (commit) could this bug have crept in,
and have a kind soul as to find a fix, or revert it?
We would be most grateful, we are building wifi community networks in
Argentina, with very low cost mesh nodes, based on tplink mr3220 and
these wn722n dongles, and the model we are using is being adopted by
many local WCN, so a fix would be of great help!
Guido
ps. I'm crossposting to compat-wireless since i don't entirely
understand where the problem lies. Sorry for the noise!
Guido Iribarren wrote:
> Hello nice people,
> we've recently found a bug when using infrastructure mode with tplink
> wn722n usb dongles (ath9k_htc driver)
Can you try this patch : http://tinyurl.com/7ywqzoz ?
Sujith
Guido Iribarren wrote:
> thanks for the patch, i found it strange because it seems related to
> IBSS, but i just tried it anyway
> unfortunately it didn't solve the problem :(
>
> Please note the bug I described happens when in client (managed) mode,
> and it is in fact a regression because it was working fine on 2012-02-27
>
> something along the development up to 2012-04-13 caused the bug
You had mentioned earlier that you were recompiling OpenWRT for bisecting,
are you using an AP running OpenWRT ? On what platform is the dongle being used ?
Sujith
On Tue, Jun 26, 2012 at 4:26 PM, Guido Iribarren
<[email protected]> wrote:
> On Sun, Jun 24, 2012 at 9:59 PM, Sujith Manoharan
> <[email protected]> wrote:
>> Guido Iribarren wrote:
>>> Hello nice people,
>>> we've recently found a bug when using infrastructure mode with tplink
>>> wn722n usb dongles (ath9k_htc driver)
>>
>> Can you try this patch : http://tinyurl.com/7ywqzoz ?
>
> Hello Sujith!
> thanks for the patch, i found it strange because it seems related to
> IBSS, but i just tried it anyway
> unfortunately it didn't solve the problem :(
Well, turns out I wasn't applying the patch correctly.
That is, I applied it manually in the build_dir of openwrt, and when I
ran "make" it was overwritten with the vanilla (unpatched)
compat-wireless
So the tests were null :-$
I just applied the patch correctly, and it works!
ath9k_htc in client mode now correctly accepts broadcast packets,
after applying the patch you sent Sujith!
Thanks a lot,
Now, i see this comes from linville tree: is this going to be (or has
already been) applied in trunk?
Thanks again for the help Sujith,
Guido
On Sun, Jun 24, 2012 at 9:59 PM, Sujith Manoharan
<[email protected]> wrote:
> Guido Iribarren wrote:
>> Hello nice people,
>> we've recently found a bug when using infrastructure mode with tplink
>> wn722n usb dongles (ath9k_htc driver)
>
> Can you try this patch : http://tinyurl.com/7ywqzoz ?
Hello Sujith!
thanks for the patch, i found it strange because it seems related to
IBSS, but i just tried it anyway
unfortunately it didn't solve the problem :(
Please note the bug I described happens when in client (managed) mode,
and it is in fact a regression because it was working fine on 2012-02-27
something along the development up to 2012-04-13 caused the bug
In any case, thanks a lot for the help!
I'll be at your disposal to try other patches or reverts you consider
relevant, to further debug this down :)
Guido
>
> Sujith
Yes, i'm doing the tests using the dongle connected to a tplink mr3220
running openwrt trunk for ar71xx.
The mr3220 has a usb port where i connect a tplink wn722n usb dongle.
The internal wifi of the router uses ath9k driver and works just fine.
The dongle uses ath9k_htc and presents the problem described, from the
moment openwrt devs upgraded trunk to use compat-wireless 2012-04-13
On 6/28/12, Sujith Manoharan <[email protected]> wrote:
> Guido Iribarren wrote:
>> thanks for the patch, i found it strange because it seems related to
>> IBSS, but i just tried it anyway
>> unfortunately it didn't solve the problem :(
>>
>> Please note the bug I described happens when in client (managed) mode,
>> and it is in fact a regression because it was working fine on 2012-02-27
>>
>> something along the development up to 2012-04-13 caused the bug
>
> You had mentioned earlier that you were recompiling OpenWRT for bisecting,
> are you using an AP running OpenWRT ? On what platform is the dongle being
> used ?
>
> Sujith
>