ieee80211_sta_work is disabled while network interface
is down. Therefore, if you configure wireless parameters
before bringing the interface up, these configurations are
not yet effective and association fails.
A workaround from userspace is calling a command like
'iwconfig wlan0 ap any' after the interface is brought up.
To fix this behaviour, trigger execution of ieee80211_sta_work from
ieee80211_open when in STA or IBSS mode.
Signed-off-by: Jan Niehusmann <[email protected]>
---
diff --git a/net/mac80211/ieee80211.c b/net/mac80211/ieee80211.c
index 28bcdf9..8e58639 100644
--- a/net/mac80211/ieee80211.c
+++ b/net/mac80211/ieee80211.c
@@ -286,6 +286,18 @@ static int ieee80211_open(struct net_device *dev)
if (need_hw_reconfig)
ieee80211_hw_config(local);
+ /*
+ * ieee80211_sta_work is disabled while network interface
+ * is down. Therefore, some configuration changes may not
+ * yet be effective. Trigger execution of ieee80211_sta_work
+ * to fix this.
+ */
+ if(sdata->vif.type == IEEE80211_IF_TYPE_STA ||
+ sdata->vif.type == IEEE80211_IF_TYPE_IBSS) {
+ struct ieee80211_if_sta *ifsta = &sdata->u.sta;
+ queue_work(local->hw.workqueue, &ifsta->work);
+ }
+
netif_start_queue(dev);
return 0;
On Sun, 2008-03-23 at 20:23 +0100, Jan Niehusmann wrote:
> ieee80211_sta_work is disabled while network interface
> is down. Therefore, if you configure wireless parameters
> before bringing the interface up, these configurations are
> not yet effective and association fails.
>
> A workaround from userspace is calling a command like
> 'iwconfig wlan0 ap any' after the interface is brought up.
>
> To fix this behaviour, trigger execution of ieee80211_sta_work from
> ieee80211_open when in STA or IBSS mode.
What happens with this patch when you haven't set any configuration
items before bringing the interface up? We want it to do nothing, if
that behaviour is kept the patch should be fine.
johannes
On Mon, Mar 24, 2008 at 12:16 AM, Johannes Berg
<[email protected]> wrote:
>
> On Sun, 2008-03-23 at 20:23 +0100, Jan Niehusmann wrote:
> > ieee80211_sta_work is disabled while network interface
> > is down. Therefore, if you configure wireless parameters
> > before bringing the interface up, these configurations are
> > not yet effective and association fails.
> >
> > A workaround from userspace is calling a command like
> > 'iwconfig wlan0 ap any' after the interface is brought up.
> >
> > To fix this behaviour, trigger execution of ieee80211_sta_work from
> > ieee80211_open when in STA or IBSS mode.
>
> What happens with this patch when you haven't set any configuration
> items before bringing the interface up? We want it to do nothing, if
> that behaviour is kept the patch should be fine.
Why should be possible to configure device when it's not up. Shouldn't
be there some order in which things are happening?
Thanks
Tomas
> johannes
>
On Mon, 2008-03-24 at 00:28 +0200, Tomas Winkler wrote:
> On Mon, Mar 24, 2008 at 12:16 AM, Johannes Berg
> <[email protected]> wrote:
> >
> > On Sun, 2008-03-23 at 20:23 +0100, Jan Niehusmann wrote:
> > > ieee80211_sta_work is disabled while network interface
> > > is down. Therefore, if you configure wireless parameters
> > > before bringing the interface up, these configurations are
> > > not yet effective and association fails.
> > >
> > > A workaround from userspace is calling a command like
> > > 'iwconfig wlan0 ap any' after the interface is brought up.
> > >
> > > To fix this behaviour, trigger execution of ieee80211_sta_work from
> > > ieee80211_open when in STA or IBSS mode.
> >
> > What happens with this patch when you haven't set any configuration
> > items before bringing the interface up? We want it to do nothing, if
> > that behaviour is kept the patch should be fine.
>
> Why should be possible to configure device when it's not up. Shouldn't
> be there some order in which things are happening?
This was the way that wireless-tools/WEXT worked with older fullmac type
cards; the driver would usually cache the value until the device came up
(and then blast all cached values to the card and try to associate) or
the firmware would still accept commands while the interface was down
because the firmware was already on the card and didn't have to be
loaded at runtime.
These days, of course, with cards that load firmware on open() (ex iwl
to save power, and others) this isn't possible unless the driver caches
the values until the device is brought up.
Personally, I don't really think this is an issue. Things change, some
cards don't allow scanning when they are down, etc. It's a lot of code
to cache the values in the driver that isn't really needed if people
just start setting the device up before configuring it. I think the
tradeoff of having to modify userspace tool behavior versus having to
maintain more code in the drivers/stack is quite clear: less code in
mac80211/drivers.
Dan
> Thanks
> Tomas
>
> > johannes
> >
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Mar 24, 2008 at 12:28:07AM +0200, Tomas Winkler wrote:
> Why should be possible to configure device when it's not up. Shouldn't
> be there some order in which things are happening?
I don't know if it should be possible, but the debian ifup scripts seem to
do it that way. I just configured the interface in /etc/network/interfaces
using the wireless_* config options, and 'ifup wlan0' fails to start the
network as the interface doesn't associate. It does work if I manually
call 'iwconfig wlan0 ap any' after the scripts brought the interface up.
With the patch, 'ifup wlan0' works perfectly for me.
Also, I'm not the only one with this problem, as I found exactly the
same hint with google:
http://bayleshanks.com/tips-computer-lenovoX61t-gnuLinuxSetup
"I found that I have to do "iwconfig wlan0 ap any" before it will
associate with my router. Dunno if that's a general problem or if I did
something wrong in /etc/network/interfaces."
(Please not that I'm using a Lenovo x61s, and the mentioned link talks
about an x61t, which are quite similar. So it may be that this behaviour
is only visible with some hardware configurations.)
Jan
> BTW, after doing this, I noticed that setting essid first and the WEP
> encryption key later didn't lead to associated state. Again, I had to
> trigger association by calling 'iwconfig wlan0 essid ...' or 'iwconfig
> wlan0 ap any' after setting the key. Is this behaviour expected?
Yes, and for sure not going to change.
johannes
On Sun, Mar 23, 2008 at 11:16:35PM +0100, Johannes Berg wrote:
> On Sun, 2008-03-23 at 20:23 +0100, Jan Niehusmann wrote:
> > To fix this behaviour, trigger execution of ieee80211_sta_work from
> > ieee80211_open when in STA or IBSS mode.
>
> What happens with this patch when you haven't set any configuration
> items before bringing the interface up? We want it to do nothing, if
> that behaviour is kept the patch should be fine.
As far as I can tell (without knowing mac80211 very well), ifsta->state
should be IEEE80211_DISABLED on an unconfigured interface. With
ifsta->state==IEEE80211_DISABLED, ieee80211_sta_work only does the
following:
[...]
while ((skb = skb_dequeue(&ifsta->skb_queue)))
ieee80211_sta_rx_queued_mgmt(dev, skb);
[...]
if (test_and_clear_bit(IEEE80211_STA_REQ_AUTH, &ifsta->request)) {
if (ieee80211_sta_config_auth(dev, ifsta))
return;
clear_bit(IEEE80211_STA_REQ_RUN, &ifsta->request);
} else if (!test_and_clear_bit(IEEE80211_STA_REQ_RUN, &ifsta->request))
return;
This looks quite safe, especially as ifsta->skb_queue should be empty
in DISABLED state (ieee80211_rx_h_mgmt doesn't enqueue packets unless
mode is STA or IBSS).
I also just tried it, calling 'ifconfig wlan0 up' on an otherwise
unconfigured interface didn't have any obvious effect.
BTW, after doing this, I noticed that setting essid first and the WEP
encryption key later didn't lead to associated state. Again, I had to
trigger association by calling 'iwconfig wlan0 essid ...' or 'iwconfig
wlan0 ap any' after setting the key. Is this behaviour expected?
Jan
On Mon, Mar 24, 2008 at 4:32 PM, Dan Williams <[email protected]> wrote:
>
> On Mon, 2008-03-24 at 00:28 +0200, Tomas Winkler wrote:
> > On Mon, Mar 24, 2008 at 12:16 AM, Johannes Berg
> > <[email protected]> wrote:
> > >
> > > On Sun, 2008-03-23 at 20:23 +0100, Jan Niehusmann wrote:
> > > > ieee80211_sta_work is disabled while network interface
> > > > is down. Therefore, if you configure wireless parameters
> > > > before bringing the interface up, these configurations are
> > > > not yet effective and association fails.
> > > >
> > > > A workaround from userspace is calling a command like
> > > > 'iwconfig wlan0 ap any' after the interface is brought up.
> > > >
> > > > To fix this behaviour, trigger execution of ieee80211_sta_work from
> > > > ieee80211_open when in STA or IBSS mode.
> > >
> > > What happens with this patch when you haven't set any configuration
> > > items before bringing the interface up? We want it to do nothing, if
> > > that behaviour is kept the patch should be fine.
> >
> > Why should be possible to configure device when it's not up. Shouldn't
> > be there some order in which things are happening?
>
> This was the way that wireless-tools/WEXT worked with older fullmac type
> cards; the driver would usually cache the value until the device came up
> (and then blast all cached values to the card and try to associate) or
> the firmware would still accept commands while the interface was down
> because the firmware was already on the card and didn't have to be
> loaded at runtime.
I'm stopping to like the idea of having firmware loaded in open, there
is conceptual
problem with this as we've seen in rfkill and now the configuration.
Probe is a problem because the filesystem is not available so there
have to be something in between.
> These days, of course, with cards that load firmware on open() (ex iwl
> to save power, and others) this isn't possible unless the driver caches
> the values until the device is brought up.
>
> Personally, I don't really think this is an issue. Things change, some
> cards don't allow scanning when they are down, etc. It's a lot of code
> to cache the values in the driver that isn't really needed if people
> just start setting the device up before configuring it. I think the
> tradeoff of having to modify userspace tool behavior versus having to
> maintain more code in the drivers/stack is quite clear: less code in
> mac80211/drivers.
Aggree
Tomas