On Fri, Jul 25, 2008 at 5:36 PM, Herton Ronaldo Krzesinski
<[email protected]> wrote:
<snipped>
> The patch didn't help, but I reached a set of commands where I'm always able
> to reproduce the problem, I found out that is the order of commands that
> makes the issue happen here:
>
> [1] /sbin/ip link set dev wlan0 down
> [2] /sbin/ip link set dev wlan0 up
> [3] /sbin/iwconfig wlan0 power on
> [4] /sbin/iwconfig wlan0 essid any
> [5] /sbin/iwconfig wlan0 power on
> [6] /sbin/iwconfig wlan0 essid <my AP>
> [7] /sbin/iwconfig wlan0 key open <my key>
>
> With these commands the interface doesn't associate with AP.
> If I remove only command 3, I still can't associate.
> If I remove only command 4, no problems.
> If I remove only command 5, no problems.
>
> So it seems there is a bug when trying to do a "power on" after "essid <key>"
> command, are you able to reproduce this too?
- I have added linux-wireless back to CC:, since I have reproduced the
problem you saw,
exactly as you described. (you mean "power on after essid <any>" is
problematic, I think)
I have also had a look at the code and while I don't understand most
of it, I thought maybe
I have a guess of how adding power management wext hooks can break association.
What the power management hooks + enabling power management does, is
to buffer for up to
STA_MAX_TX_BUFFER frames of certain types; also, if a iwconfig essid
<any> is issued before
iwconfig essid <some_ap>, the <any> result is cached for look-up, I
think. so the 3 situations you out-lined are this:
-use a lot of frames to find any APs, (power saving on, start
buffering) send a small number of frames to
associate with one among the known APs but these frames are buffered,
so no association
- (power saving on, start buffering), use a lot of frames to find any
APs, a few more to associate to one.
- (power saving on, start buffering), doesn't know any APs, so use a
lot of frames to find a particular one.
Does this make sense, or am I talking nonsense? In any case, there is
a MAC80211_VERBOSE_PS_DEBUG
in net/mac80211/tx.c, which should be relevant.
Hin-Tak
"ext Hin-Tak Leung" <[email protected]> writes:
> On Fri, Jul 25, 2008 at 5:36 PM, Herton Ronaldo Krzesinski
>
>> So it seems there is a bug when trying to do a "power on" after "essid <key>"
>> command, are you able to reproduce this too?
>
> - I have added linux-wireless back to CC:, since I have reproduced
> the problem you saw, exactly as you described. (you mean "power on
> after essid <any>" is problematic, I think)
>
> I have also had a look at the code and while I don't understand most
> of it, I thought maybe I have a guess of how adding power management
> wext hooks can break association.
Do you mean this patch from Samuel which is in wireless-testing:
commit 8f87dd7e540d455f8e7f11478133b85edc969c67
Author: Samuel Ortiz <[email protected]>
Date: Fri Jul 4 10:49:31 2008 +0200
mac80211: power management wext hooks
This patch implements the power management routines wireless extensions
for mac80211.
For now we only support switching PS mode between on and off.
> What the power management hooks + enabling power management does, is
> to buffer for up to STA_MAX_TX_BUFFER frames of certain types; also,
> if a iwconfig essid <any> is issued before iwconfig essid <some_ap>,
> the <any> result is cached for look-up, I think.
No, the only thing Samuel's patch adds is support for SIOCSIWPOWER and
SIOCGIWPOWER ioctls. It also adds IEEE80211_CONF_PS flag which
mac80211 driver's can use to check if Power Save Mode is enabled by
the user. But currently there are no drivers using it.
Of course this patch may very well break something, but it's related
to something else than Power Save Mode itself. It's not obvious how
this patch can break rtl18187. For me iwl3945 has worked perfectly,
with which patch included.
The only thing which might break it is an extra call to
ieee80211_hw_config() when issueing 'iwconfig wlan0 power on', but
that might be a bit far fetched. If you have the time, please try to
debug this more. For example you could try reverting the patch with
'git revert --no-commit 8f87dd7e54' and see if it really makes a
difference.
> so the 3 situations you out-lined are this:
>
> -use a lot of frames to find any APs, (power saving on, start
> buffering) send a small number of frames to
> associate with one among the known APs but these frames are buffered,
> so no association
>
> - (power saving on, start buffering), use a lot of frames to find any
> APs, a few more to associate to one.
>
> - (power saving on, start buffering), doesn't know any APs, so use a
> lot of frames to find a particular one.
>
> Does this make sense, or am I talking nonsense? In any case, there is
> a MAC80211_VERBOSE_PS_DEBUG
> in net/mac80211/tx.c, which should be relevant.
You are confusing AP and client mode PSM here,
MAC80211_VERBOSE_PS_DEBUG is used for debugging PSM support in AP
mode. Client mode PSM support is usually implemented in the driver or
the firmware. We are planning to add some PSM support to mac80211, but
it's still in the works.
--
Kalle Valo
On Tue, Jul 29, 2008 at 10:42 AM, Kalle Valo <[email protected]> wrote:
<snipped>
> Do you mean this patch from Samuel which is in wireless-testing:
>
> commit 8f87dd7e540d455f8e7f11478133b85edc969c67
> Author: Samuel Ortiz <[email protected]>
> Date: Fri Jul 4 10:49:31 2008 +0200
>
> mac80211: power management wext hooks
Yes.
<snipped>
> You are confusing AP and client mode PSM here,
> MAC80211_VERBOSE_PS_DEBUG is used for debugging PSM support in AP
> mode. Client mode PSM support is usually implemented in the driver or
> the firmware. We are planning to add some PSM support to mac80211, but
> it's still in the works.
Yes, I realised I was talking rubbish :-). But as you said, enabling
PS should have no effect whatsoever.
The other possibility is IEEE80211_HW_HOST_BROADCAST_PS_BUFFERING, but that
also seems to be AP mode -specific.