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
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
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
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
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
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
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
<[email protected]> wrote:
> Dear Guido,
>
> Do you have any progress regarding your problem that you described on
> http://www.mail-archive.com/[email protected]/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