[ath9k-devel] ath9k_htc 1mbps in IBSS mode

[ath9k-devel] ath9k_htc 1mbps in IBSS mode

[Nicolás Echániz]

I'd like to bump this thread:

https://lists.ath9k.org/pipermail/ath9k-devel/2012-March/008335.html

...and add some more data and context.

Guido, myself and a group of people are involved in a project to build
community networks in small towns all over the country. It's a
project[0] from the National Ministry of Education that involves not
only the deployment of a number of nodes in each town in order to get
the networks started but also a process of theoretical and practical
training mainly targeted at young people in each town.

The networks need to meet two important characteristics:
1) easy replication of the network design
2) very low per-node cost

We have achieved the second goal with the hardware setup that Guido
mentioned but we are having difficulty with the ease of deployment due
to the increased complexity of designing mixed ad-hoc/infrastructure
networks.

We have tested a big number of usb wifi dongles but those based on
ath9k_htc have proven to be by far the most stable.

On the technical side of this issue, I can add to guido's report that in
rev.29960 of Openwrt, with the same configuration, our WN722N dongles
were capable of establishing 150Mbit/s HT mode links, although they did
not behave as stable as the internal ath9k based radios from the MR3220
routers.

With current revs of OpenWRT trunk, the behavior of ath9k-htc dongles in
ad-hoc mode has become unusable (always running at 1Mbit/s) so we are
forced to mixed mode network designs.


We are greatly interested in helping out in any way we can to help solve
this issue. We are in charge of three community network deployments that
can be used as test beds; these are at your disposal, but please let us
know if we can be of assistance in any other way.


Cheers!

NicoEch?niz
codigosur.org


[0] http://www.arraigodigital.org.ar

google (poorly) translated link:
http://translate.google.com/translate?js=n&sl=es&tl=en&u=http://www.arraigodigital.org.ar

[ath9k-devel] ath9k_htc 1mbps in IBSS mode

[Adrian Chadd]

Hi,

Anyone who is willing to sit down and help us debug ath9k_htc firmware
and driver side issues should contact us (Atheros people) privately
and ask about the open source NDA.

We'll try to get you enabled with the relevant bits to help us improve
the firmware support.



Adrian


On 10 June 2012 21:02, Nicol?s Ech?niz <nicoechaniz@codigosur.org> wrote:
> I'd like to bump this thread:
>
> https://lists.ath9k.org/pipermail/ath9k-devel/2012-March/008335.html
>
> ...and add some more data and context.
>
> Guido, myself and a group of people are involved in a project to build
> community networks in small towns all over the country. It's a
> project[0] from the National Ministry of Education that involves not
> only the deployment of a number of nodes in each town in order to get
> the networks started but also a process of theoretical and practical
> training mainly targeted at young people in each town.
>
> The networks need to meet two important characteristics:
> 1) easy replication of the network design
> 2) very low per-node cost
>
> We have achieved the second goal with the hardware setup that Guido
> mentioned but we are having difficulty with the ease of deployment due
> to the increased complexity of designing mixed ad-hoc/infrastructure
> networks.
>
> We have tested a big number of usb wifi dongles but those based on
> ath9k_htc have proven to be by far the most stable.
>
> On the technical side of this issue, I can add to guido's report that in
> rev.29960 of Openwrt, with the same configuration, our WN722N dongles
> were capable of establishing 150Mbit/s HT mode links, although they did
> not behave as stable as the internal ath9k based radios from the MR3220
> routers.
>
> With current revs of OpenWRT trunk, the behavior of ath9k-htc dongles in
> ad-hoc mode has become unusable (always running at 1Mbit/s) so we are
> forced to mixed mode network designs.
>
>
> We are greatly interested in helping out in any way we can to help solve
> this issue. We are in charge of three community network deployments that
> can be used as test beds; these are at your disposal, but please let us
> know if we can be of assistance in any other way.
>
>
> Cheers!
>
> NicoEch?niz
> codigosur.org
>
>
> [0] http://www.arraigodigital.org.ar
>
> google (poorly) translated link:
> http://translate.google.com/translate?js=n&sl=es&tl=en&u=http://www.arraigodigital.org.ar
>
>
>
>
>
>
>
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel at lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel

[ath9k-devel] ath9k_htc 1mbps in IBSS mode

[Guido Iribarren]

On Mon, Jun 11, 2012 at 3:28 AM, Adrian Chadd <adrian@freebsd.org> wrote:
> Hi,
>
> Anyone who is willing to sit down and help us debug ath9k_htc firmware
> and driver side issues should contact us (Atheros people) privately
> and ask about the open source NDA.

Will definitely do,
thanks a lot!
>
> We'll try to get you enabled with the relevant bits to help us improve
> the firmware support.
>
>
>

[ath9k-devel] ath9k_htc 1mbps in IBSS mode

[Guido Iribarren]

Bumping this thread again, with new observations:

I've done tests with 3 routers running openwrt trunk r31316, each with
a tplink wn722n dongle connected to the usb port
all of them in IBSS mode, HT20, channel 11 in an otherwise silent environment.

turn on node 1, then turn on node 2:
node 2 transmits at 54mbit towards node 1,
but node1 transmits at 1mbit only towards node 2

then start node 3:
node 3 can trasmit at 54mbit towards nodes 1 and 2,
node 2 still transmits at 54mbit towards node 1,
but node 1 and 2 transmit at 1mbit towards node 3

So it looks like the *new* nodes in the adhoc cloud can negotiate
54mbit towards *old* nodes.
To put it in other terms: nodes already partitipating of an adhoc
cloud, don't negotiate more than 1 mbit speed towards nodes that join
later.
So, the first node that joins the IBSS, is not be able to send at more
than 1mbit/s towards anyone.
But will receive from everyone else at 54mbit.

I know nothing about the internal workings of the driver, but i get
the feeling that nodes are somehow not acknowledging supported speeds
of newly joined nodes, but instead only check other hosts speeds when
they join the IBSS cloud for the first time, and so it's limited to
nodes already present at the moment of the join.

Maybe this sheds some light on the issue?
Please note that I'm talking about 54mbit although the radios are
N-capable and set to HT20. But so far I haven't found a case where
they reach N speeds on IBSS mode.
Even if not ideal, 54mbit would be a huge leap from current unusable
1mbit speeds.

Guido

[ath9k-devel] ath9k_htc 1mbps in IBSS mode

[Sujith Manoharan]

Guido Iribarren wrote:
> I know nothing about the internal workings of the driver, but i get
> the feeling that nodes are somehow not acknowledging supported speeds
> of newly joined nodes, but instead only check other hosts speeds when
> they join the IBSS cloud for the first time, and so it's limited to
> nodes already present at the moment of the join.

It looks like commit 6d810f10 changed the behavior.

The station addition notification is now passed to the driver before the
supported rates are updated for the peer (which happens via ieee80211_rx_bss_info()).
Drivers which offload rate control to the firmware but depend on mac80211 for
station management would be affected, I think.

Sujith

[ath9k-devel] ath9k_htc 1mbps in IBSS mode

[Nicolás Echániz]

On 07/09/2012 12:31 AM, Sujith Manoharan wrote:
> Guido Iribarren wrote:
>> I know nothing about the internal workings of the driver, but i get
>> the feeling that nodes are somehow not acknowledging supported speeds
>> of newly joined nodes, but instead only check other hosts speeds when
>> they join the IBSS cloud for the first time, and so it's limited to
>> nodes already present at the moment of the join.
> 
> It looks like commit 6d810f10 changed the behavior.
> 
> The station addition notification is now passed to the driver before the
> supported rates are updated for the peer (which happens via ieee80211_rx_bss_info()).
> Drivers which offload rate control to the firmware but depend on mac80211 for
> station management would be affected, I think.


Sujith, does this mean that the problem is outside the scope of the
ath9k_htc driver itself or could it be fixed?

we are doing some heavy use of hardware based on this driver for many
projects; any further debugging work you might need, we are more than
willing to help.


Cheers,
NicoEch?niz

[ath9k-devel] ath9k_htc 1mbps in IBSS mode

[Sujith Manoharan]

Nicol?s Ech?niz wrote:
> Sujith, does this mean that the problem is outside the scope of the
> ath9k_htc driver itself or could it be fixed?
> 
> we are doing some heavy use of hardware based on this driver for many
> projects; any further debugging work you might need, we are more than
> willing to help.

This is a regression introduced by this commit:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=6d810f10325522cfcf498dc6d64b9f96e1f5153f

Fixing this requires either introducing a new mac80211 callback or
revert to the older behavior which issued a station notification only
after the supported rates have been setup.

Sujith

[ath9k-devel] ath9k_htc 1mbps in IBSS mode

[Antonio Quartulli]

On Sun, Jul 15, 2012 at 11:09:49AM +0530, Sujith Manoharan wrote:
> Nicol?s Ech?niz wrote:
> > Sujith, does this mean that the problem is outside the scope of the
> > ath9k_htc driver itself or could it be fixed?
> > 
> > we are doing some heavy use of hardware based on this driver for many
> > projects; any further debugging work you might need, we are more than
> > willing to help.
> 
> This is a regression introduced by this commit:
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=6d810f10325522cfcf498dc6d64b9f96e1f5153f
> 
> Fixing this requires either introducing a new mac80211 callback or
> revert to the older behavior which issued a station notification only
> after the supported rates have been setup.

In my opinion a proper callback is better. However, the all basic_rates thing
needs a restyling...I think this is a good moment to counter the issue :-)
If nobody else is going to work on this, I will try to propose a solution in
the following days.


Cheers,

-- 
Antonio Quartulli

..each of us alone is worth nothing..
Ernesto "Che" Guevara
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20120715/76d1ec05/attachment.pgp 

[ath9k-devel] ath9k_htc 1mbps in IBSS mode

[Guido Iribarren]

Antonio,
do you like "dulce de leche"[0]?
I don't know if it's correct to offer such a "bounty" in exchange for
a patch :P but it's something within my reach (as opposed to kernel
driver hacking...)

having a proper fix for this would result in the first (AFAIK) 802.11n
usb dongle working in ibss mode.

Cheers!

Gui

[0] https://en.wikipedia.org/wiki/Dulce_de_leche

On Sun, Jul 15, 2012 at 5:28 AM, Antonio Quartulli <ordex@autistici.org> wrote:
> On Sun, Jul 15, 2012 at 11:09:49AM +0530, Sujith Manoharan wrote:
>> Nicol?s Ech?niz wrote:
>> > Sujith, does this mean that the problem is outside the scope of the
>> > ath9k_htc driver itself or could it be fixed?
>> >
>> > we are doing some heavy use of hardware based on this driver for many
>> > projects; any further debugging work you might need, we are more than
>> > willing to help.
>>
>> This is a regression introduced by this commit:
>> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=6d810f10325522cfcf498dc6d64b9f96e1f5153f
>>
>> Fixing this requires either introducing a new mac80211 callback or
>> revert to the older behavior which issued a station notification only
>> after the supported rates have been setup.
>
> In my opinion a proper callback is better. However, the all basic_rates thing
> needs a restyling...I think this is a good moment to counter the issue :-)
> If nobody else is going to work on this, I will try to propose a solution in
> the following days.
>
>
> Cheers,
>
> --
> Antonio Quartulli
>
> ..each of us alone is worth nothing..
> Ernesto "Che" Guevara

[ath9k-devel] ath9k_htc 1mbps in IBSS mode

[Antonio Quartulli]

On Sun, Jul 22, 2012 at 11:52:31AM -0300, Guido Iribarren wrote:
> Antonio,
> do you like "dulce de leche"[0]?

Yes, please. A jar would be good! :D

> I don't know if it's correct to offer such a "bounty" in exchange for
> a patch :P but it's something within my reach (as opposed to kernel
> driver hacking...)
> 
> having a proper fix for this would result in the first (AFAIK) 802.11n
> usb dongle working in ibss mode.
> 


I'm already working on this. I'll try to come up with a patchset (I'm working on
the whole basic_rates/mcast_rate thing) as soon as possible :-)

Thank you.
Cheers,

> Cheers!
> 
> Gui
> 
> [0] https://en.wikipedia.org/wiki/Dulce_de_leche
> 
> On Sun, Jul 15, 2012 at 5:28 AM, Antonio Quartulli <ordex@autistici.org> wrote:
> > On Sun, Jul 15, 2012 at 11:09:49AM +0530, Sujith Manoharan wrote:
> >> Nicol?s Ech?niz wrote:
> >> > Sujith, does this mean that the problem is outside the scope of the
> >> > ath9k_htc driver itself or could it be fixed?
> >> >
> >> > we are doing some heavy use of hardware based on this driver for many
> >> > projects; any further debugging work you might need, we are more than
> >> > willing to help.
> >>
> >> This is a regression introduced by this commit:
> >> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=6d810f10325522cfcf498dc6d64b9f96e1f5153f
> >>
> >> Fixing this requires either introducing a new mac80211 callback or
> >> revert to the older behavior which issued a station notification only
> >> after the supported rates have been setup.
> >
> > In my opinion a proper callback is better. However, the all basic_rates thing
> > needs a restyling...I think this is a good moment to counter the issue :-)
> > If nobody else is going to work on this, I will try to propose a solution in
> > the following days.
> >
> >
> > Cheers,
> >
> > --
> > Antonio Quartulli
> >
> > ..each of us alone is worth nothing..
> > Ernesto "Che" Guevara

-- 
Antonio Quartulli

..each of us alone is worth nothing..
Ernesto "Che" Guevara
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20120723/8f56cba8/attachment.pgp 

[ath9k-devel] ath9k_htc 1mbps in IBSS mode

[Antonio Quartulli]

On Sun, Jul 15, 2012 at 11:09:49AM +0530, Sujith Manoharan wrote:
> Nicol?s Ech?niz wrote:
> > Sujith, does this mean that the problem is outside the scope of the
> > ath9k_htc driver itself or could it be fixed?
> > 
> > we are doing some heavy use of hardware based on this driver for many
> > projects; any further debugging work you might need, we are more than
> > willing to help.
> 
> This is a regression introduced by this commit:
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=6d810f10325522cfcf498dc6d64b9f96e1f5153f
> 
> Fixing this requires either introducing a new mac80211 callback or
> revert to the older behavior which issued a station notification only
> after the supported rates have been setup.
> 


Hello everybody,

sorry for the very late response on this topic.
I am performing some tests now using mac80211_hwsim.
I'm first letting wlan0 join the ibss and then I let wlan1 join the same ibss.
In the log I clearly read that the basic rates get updated by means of a
beacon/probe response (actually this is what I expected).

Then I tried to send frames from wlan0 to wlan1 passing through the emulated
link and I can see with "iw dev wlan0 station dump" that the tx rate gets higher
and higher up to 54mbps. Therefore I do not see any problem with the update of
the basic rates.

Am I missing/overlooking something?
@Sujith, do you have a more clear idea of what the problem is?

Cheers,

-- 
Antonio Quartulli

..each of us alone is worth nothing..
Ernesto "Che" Guevara
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20120808/8023616a/attachment.pgp 

[ath9k-devel] ath9k_htc 1mbps in IBSS mode

[Antonio Quartulli]

On Sun, Jul 15, 2012 at 11:09:49AM +0530, Sujith Manoharan wrote:
> Nicol?s Ech?niz wrote:
> > Sujith, does this mean that the problem is outside the scope of the
> > ath9k_htc driver itself or could it be fixed?
> > 
> > we are doing some heavy use of hardware based on this driver for many
> > projects; any further debugging work you might need, we are more than
> > willing to help.
> 
> This is a regression introduced by this commit:
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=6d810f10325522cfcf498dc6d64b9f96e1f5153f
> 
> Fixing this requires either introducing a new mac80211 callback or
> revert to the older behavior which issued a station notification only
> after the supported rates have been setup.
> 

Hello people, Sujith,

after having read your previous email in the mail-archive (I was not in the
thread since then) I realised that the problem concerns only some drivers. I
better looked at the code and I realised where the problem is.

Thank you.
Cheers,

-- 
Antonio Quartulli

..each of us alone is worth nothing..
Ernesto "Che" Guevara
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20120809/924573a2/attachment.pgp 

[ath9k-devel] ath9k_htc 1mbps in IBSS mode

[Gui Iribarren]

Hi Pedro and everyone,
Sorry for the thread necromancy, just to close this as 'solved':

On Wed, Sep 19, 2012 at 11:12 AM, Pedro Antonio
<pedro.st.antonio@gmail.com> wrote:
> Dear Guido,
>
> Do you have any progress regarding your problem that you described on
> http://www.mail-archive.com/ath9k-devel at lists.ath9k.org/msg08934.html?

Here are the two resulting original patches against compat-wireless of
that time.
http://comments.gmane.org/gmane.linux.drivers.ath9k.devel/9540
https://patchwork.kernel.org/patch/1309961/

They have already been merged upstream since then,
http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=commit;h=e687f61eedab8895e5669cb82cebe0253631cd8c
http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=commit;h=6957802944ec8244cdcfbf50ffbfccf8eceaa413

so any current compat-wireless doesn't exhibit the issue (since
2012-08-21). Thanks Antonio!

in openwrt in particular, it's fixed since (at least, maybe earlier
than) r33331, a rev that updated compat-wireless package.


> I am having the same issue: in one direction I have 54Mbps and on the other
> I get just 1Mbps.
>
> I need to solve it. If you can give me a lead, I would appreciate a lot.
>
> Thanks in advanced for your time.
>
> Pedro Antonio
>

Hope that helps Pedro and others,

Cheers!

Gui

[ath9k-devel] ath9k_htc 1mbps in IBSS mode

[Guido Iribarren]

Hi everyone,
I have a couple of usb dongles tplink wn722n spaced 150mts apart,
outdoors, with clear LOS.
and i'm facing issues with IBSS mode
(i've repeated the tests indoors, with dongles in the same room, 2 mts
apart... same results)

when set in adhoc mode, the link never reaches HT speeds.
In fact, most of the times they don't negotiate more than 1mbps speed.
The best i've seen happening is, one of them reaches 54mbps, and the
other one stays at 1mbps. (Both of them at 54mbps, never happened)
iperf measures confirm that it's not an "iw wlan0 station dump"
display issue, throughput is consistent with the speeds reported.

If I put one dongle as ap (hostapd) and the other one in managed mode,
the link works flawlessly with HT40 and negotiates 150mbps both ways
(iperf measures 30mbit/s throughput both ways)

# iw wlan1 station dump
Station 56:e6:fc:be:29:d4 (on wlan1)
	inactive time:	10 ms
[snip]
	signal:  	-70 dBm
	signal avg:	-69 dBm
	tx bitrate:	135.0 MBit/s MCS 6 40Mhz short GI
	rx bitrate:	150.0 MBit/s MCS 7 40Mhz short GI


each dongle is connected to its own tplink mr3220, on the usb port ,
running openwrt trunk r30919
# grep r30919 /etc/banner
 ATTITUDE ADJUSTMENT (bleeding edge, r30919) ----------
# uname -a
Linux bochita-muelle 3.2.9 #1 Tue Mar 13 20:33:19 MST 2012 mips GNU/Linux
# opkg list kmod-ath9k-htc
kmod-ath9k-htc - 3.2.9+2012-02-27-1

# OpenWRT radio config follow: (equal on both nodes, and kept the same
in infrastructure or adhoc mode)
config 'wifi-device' 'radio1'
	option 'type' 'mac80211'
	option 'hwmode' '11ng'
	list 'ht_capab' 'SHORT-GI-20'
	list 'ht_capab' 'SHORT-GI-40'
	list 'ht_capab' 'RX-STBC1'
	list 'ht_capab' 'DSSS_CCK-40'
	option 'htmode' 'HT40-'
	option 'channel' '9'
	option 'disabled' '0'
	option 'phy' 'phy1'

# Config used when testing infrastructure mode (Works flawlessly with
150mbps speeds)
config 'wifi-iface'
	option 'device' 'radio1'
	option 'encryption' 'none'
	option 'mode' 'sta' # Other node has this set to "ap"
	option 'ssid' 'mesh9.dl'
	option 'bssid' '56:E6:FC:BE:29:D4'

# Config used when testing adhoc mode (mostly works at 1mbps, sometimes 54mbps)
config 'wifi-iface'
	option 'device' 'radio1'
	option 'encryption' 'none'
	option 'mode' 'adhoc'
	option 'ssid' 'mesh9.dl'
	option 'bssid' '02:AA:BB:CC:DD:EE'

Those exact config snippets, when applied to the internal interface of
mr3220 (radio0, ath9k driver) work perfectly fine, reaching 150mbps
speeds , with no difference between working in IBSS mode or
infrastructure.

I've googled somewhat similar problems in the past, but with ath9k,
which for me it's already solved with that driver (the last post
mentions some patch, which has been included upstream, which is also
evident since I'm not having problems with ath9k ibss mode)
[1] https://forum.openwrt.org/viewtopic.php?id=29876

I'm aware that ath9k_htc is mostly a one- or two-men masterpiece [2]
(thanks a lot Sujith and Luis!), so i understand there's limited
support capacity, but any pointer will be greatly appreciated.
If any additional info or testing is needed I will be more than glad
to provide it.
[2] https://lists.ath9k.org/pipermail/ath9k-devel/2012-March/008226.html

I'm using these dongles in building a community mesh network in
argentina, in order to add a second interface to the nodes and
overcome the bandwidth degradation issue widespread in big
single-radio MANETs, while keeping the budget low so that everyone can
have their own two-radio node
I'm combining tplink mr3220 with these wn722n (32+12 usd), openwrt +
batman-adv, and so far it looks very promising, since (with the
"infrastructure mode" workaround) p2p links reach 30mbps speeds along
the mesh.
Getting the usb dongles to work in ibss mode would add the much wanted
redundancy, since in the current mixed setup, if a node in ap mode
goes offline, the nodes set to client mode cannot recover from it,
even though they could hear each other in ibss mode.

Thanks in advance, and have a great week!

Guido