ath9k_htc 1mbps in IBSS mode
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
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
Quoted 63 lines · 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 costWe 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_htchave 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
Quoted 5 lines · Adrian Chadd
Hi,
Anyone who is willing to sit down and help us debug
ath9k_htcfirmware and driver side issues should contact us (Atheros people) privately and ask about the open source NDA.
Will definitely do,
thanks a lot!
Quoted 6 lines
We'll try to get you enabled with the relevant bits to help us improve the firmware support.
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
Quoted 5 lines · Guido Iribarren
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
Quoted 7 lines · Sujith Manoharan
Quoted 5 lines · Guido Iribarren
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.
Quoted 6 lines
It looks like commit
6d810f10changed 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
Quoted 6 lines · Nicol?s Ech?niz
Sujith, does this mean that the problem is outside the scope of the
ath9k_htcdriver 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
Quoted 8 lines · Sujith Manoharan
Quoted 6 lines · Nicolás Echániz
Sujith, does this mean that the problem is outside the scope of the
ath9k_htcdriver 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.
Quoted 6 lines
This is a regression introduced by this commit:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=6d810f10325522cfcf498dc6d64b9f96e1f5153fFixing 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,
Signature · 4 lines
Antonio Quartulli ..each of us alone is worth nothing.. Ernesto "Che" Guevara
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
Quoted 29 lines · Antonio Quartulli
Quoted 8 lines · Sujith Manoharan
Quoted 6 lines · Nicol?s Ech?niz
Sujith, does this mean that the problem is outside the scope of the
ath9k_htcdriver 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.
Quoted 6 lines
This is a regression introduced by this commit:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=6d810f10325522cfcf498dc6d64b9f96e1f5153fFixing 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_ratesthing 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
Quoted 2 lines · Guido Iribarren
Antonio,
do you like "dulce de leche"[0]?
Yes, please. A jar would be good! :D
Quoted 7 lines
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,
Quoted 36 lines
Cheers!
Gui
[0] https://en.wikipedia.org/wiki/Dulce_de_leche
Quoted 29 lines · Antonio Quartulli
Quoted 8 lines · Sujith Manoharan
Quoted 6 lines · Nicol?s Ech?niz
Sujith, does this mean that the problem is outside the scope of the
ath9k_htcdriver 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.
Quoted 6 lines
This is a regression introduced by this commit:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=6d810f10325522cfcf498dc6d64b9f96e1f5153fFixing 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_ratesthing 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
Signature · 11 lines
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
Quoted 8 lines · Sujith Manoharan
Quoted 6 lines · Nicol?s Ech?niz
Sujith, does this mean that the problem is outside the scope of the
ath9k_htcdriver 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.
Quoted 7 lines
This is a regression introduced by this commit:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=6d810f10325522cfcf498dc6d64b9f96e1f5153fFixing 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,
Signature · 11 lines
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
Quoted 8 lines · Sujith Manoharan
Quoted 6 lines · Nicol?s Ech?niz
Sujith, does this mean that the problem is outside the scope of the
ath9k_htcdriver 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.
Quoted 7 lines
This is a regression introduced by this commit:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=6d810f10325522cfcf498dc6d64b9f96e1f5153fFixing 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,
Signature · 11 lines
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
Hi Pedro and everyone,
Sorry for the thread necromancy, just to close this as 'solved':
Quoted 4 lines · Pedro Antonio
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.
Quoted 9 lines
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