chaning mode only when interface down?
Hello,
I noticed that I have to do ifdown wlan0 before I can change the mode with iwconfig. When I do it while the interface is up I get a error that the device is busy. It seems to happen with ad-hoc, master and back from them to managed.
Is this a bug in the iwlwifi driver or in mac80211 ?
Because of this NM can't create ad-hoc networks because it does it while the device is up. Any ideas?
Quoted 4 lines · dragoran
I noticed that I have to do ifdown wlan0 before I can change the mode with iwconfig.
When I do it while the interface is up I get a error that the device is busy.
It is busy.
Quoted 2 lines
It seems to happen with ad-hoc, master and back from them to managed. Is this a bug in the iwlwifi driver or in mac80211 ?
Neither, it is expected behaviour. Blame it on Jean that wireless extensions are ill-defined and don't mandate this.
Quoted 3 lines
Because of this NM can't create ad-hoc networks because it does it while the device is up.
Any ideas?
Fix NM?
johannes
Quoted 9 lines · Johannes Berg
Quoted 3 lines · dragoran
I noticed that I have to do ifdown wlan0 before I can change the mode with iwconfig. When I do it while the interface is up I get a error that the device is busy.
It is busy.
ok
Quoted 5 lines
Quoted 3 lines
It seems to happen with ad-hoc, master and back from them to managed. Is this a bug in the iwlwifi driver or in mac80211 ?
Neither, it is expected behaviour.
ok thx for this info.
Quoted 11 lines
Blame it on Jean that wireless
extensions are ill-defined and don't mandate this.Quoted 3 lines
Because of this NM can't create ad-hoc networks because it does it while the device is up. Any ideas?
Fix NM?
Dan, something for you ;)
does NM knows if the driver is a mac80211 one?
Quoted 3 lines
-----Original Message-----
From: [email protected]
[mailto:ipw3945-devel-
Quoted 4 lines
[email protected]] On Behalf Of dragoran
Sent: Thursday, August 02, 2007 12:17 PM
To: Johannes Berg
Cc: Dan Williams; [email protected]; network manager;
ipw3945-
Quoted 7 lines
[email protected]
Subject: Re: [ipw3945-devel] chaning mode only when interface down?Quoted 3 lines · Johannes Berg
Quoted 1 line · dragoran
I noticed that I have to do ifdown wlan0 before I can change the
mode
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
with iwconfig.
When I do it while the interface is up I get a error that the device
is
Quoted 8 lines
Quoted 6 lines
Quoted 2 lines
busy.
It is busy.
ok
Quoted 1 line
Quoted 1 line
It seems to happen with ad-hoc, master and back from them to
managed.
Quoted 10 lines
Quoted 4 lines
Quoted 2 lines
Is this a bug in the iwlwifi driver or in mac80211 ?
Neither, it is expected behaviour.
ok thx for this info.
Quoted 5 lines
Blame it on Jean that wireless
extensions are ill-defined and don't mandate this.Quoted 1 line
Because of this NM can't create ad-hoc networks because it does it
while
Quoted 11 lines
Quoted 7 lines
Quoted 3 lines
the device is up.
Any ideas?Fix NM?
Dan, something for you ;)
does NM knows if the driver is a mac80211 one?
There is a definitely a known issue in the driver that we still need to resolve, but I agree with Johannes that there is a problem in design of the configuration as well.
Unfortunately as this is in lower priority on my list now it will take few weeks till I get to solve this.
Tomas
Quoted 1 line
-----------------------------------------------------------------------
--
Quoted 8 lines
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Ipw3945-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/ipw3945-devel
Quoted 3 lines · Tomas
There is a definitely a known issue in the driver that we still need to resolve, but I agree with Johannes that there is a problem in design of the configuration as well.
Nono, you cannot solve it in the driver. The whole design of mac80211 mandates that assumption and I think it is a valid one to make. If userspace breaks because of that it's their fault.
johannes
Quoted 10 lines
-----Original Message-----
From: Johannes Berg [mailto:[email protected]]
Sent: Thursday, August 02, 2007 3:34 PM
To: Winkler, Tomas
Cc: dragoran; Dan Williams; [email protected]; network manager; [email protected]
Subject: RE: [ipw3945-devel] chaning mode only when interface down?
Quoted 3 lines
Quoted 1 line · Tomas
There is a definitely a known issue in the driver that we still need
to
Quoted 1 line
Quoted 1 line
resolve, but I agree with Johannes that there is a problem in design
of
Quoted 6 lines
Quoted 1 line
the configuration as well.
Nono, you cannot solve it in the driver. The whole design of mac80211 mandates that assumption and I think it is a valid one to make. If userspace breaks because of that it's their fault.
I know for sure there is an issue in our driver for moving to master (AP) mode. I'm just cleaning up this patch...
I'm really not an expert on the configuration but I think at least the transition from STA to IBSS mode and back should be smooth without reloading the driver. What you do if the driver is compiled to kernel will we reboot?
I hope we are talking about the same issue here... Thansk
Tomas
Quoted 1 line
johannes
Quoted 4 lines · Tomas
I'm really not an expert on the configuration but I think at least the transition from STA to IBSS mode and back should be smooth without reloading the driver. What you do if the driver is compiled to kernel will we reboot?
Oh you don't have to reload the driver, you only have to down the interface. If you have to reload it that's a driver bug, but the fact that you have to down the interface is a mac80211 "limitation"
johannes
Quoted 9 lines · Johannes Berg
Quoted 4 lines · Tomas
I'm really not an expert on the configuration but I think at least the transition from STA to IBSS mode and back should be smooth without reloading the driver. What you do if the driver is compiled to kernel will we reboot?
Oh you don't have to reload the driver, you only have to down the interface.
I suspected we are not talking about the same :)
If you have to reload it that's a driver bug, but the fact
Quoted 2 lines
that you have to down the interface is a mac80211 "limitation"
Yes it is
Quoted 14 lines
johannes
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Ipw3945-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/ipw3945-devel
Quoted 10 lines · Johannes Berg
Quoted 4 lines · Tomas
There is a definitely a known issue in the driver that we still need to resolve, but I agree with Johannes that there is a problem in design of the configuration as well.
Nono, you cannot solve it in the driver. The whole design of mac80211 mandates that assumption and I think it is a valid one to make.
why? did the old way (allow mode changing while up) caused any problems?
Quoted 3 lines · dragoran
Quoted 2 lines
Nono, you cannot solve it in the driver. The whole design of mac80211 mandates that assumption and I think it is a valid one to make.
why? did the old way (allow mode changing while up) caused any problems?
Why should it be allowed? Can you come up with a good reason for that since you lose all state anyway when doing mode transitions?
Until then (and I guess somebody *really* wants it) it's just a lot easier to not even try to change these low-level things while the interface is operating.
johannes
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 8 lines · dragoran
On 8/2/07, Johannes Berg <[email protected]> wrote:
On Thu, 2007-08-02 at 14:48 +0200, dragoran wrote:
> > Nono, you cannot solve it in the driver. The whole design of mac80211 > > mandates that assumption and I think it is a valid one to make. > why? did the old way (allow mode changing while up) caused any problems?
Quoted 8 lines
Why should it be allowed? Can you come up with a good reason for that since you lose all state anyway when doing mode transitions?
Until then (and I guess somebody *really* wants it) it's just a lot easier to not even try to change these low-level things while the interface is operating.
ok fair enough
Well, for one thing in many cases the interface needs to be "up" in order to scan. Also, many times the driver itself will incorrectly associate on insert before NetworkManager gets a chance to chime in and then you're stuck in a situation where you never get to the band you want.
Regardless, you should NEVER require a driver reload to switch bands and if you do that's a bug. If mac80211 requires a driver reload then that's a MAJOR flaw in that layer.
Still, NM keeps the interface "up" even when there's no packets, because it's required to scan. So that may be why I've had trouble going between 802.11(a) and 802.11(b/g) networks at times. It's quite frustrating.
-derek
Signature · 4 lines
Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
Member, MIT Student Information Processing Board (SIPB)
URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH
[email protected] PGP key availableQuoted 5 lines · Derek Atkins
Well, for one thing in many cases the interface needs to be "up" in order to scan. Also, many times the driver itself will incorrectly associate on insert before NetworkManager gets a chance to chime in and then you're stuck in a situation where you never get to the band you want.
Driver bug?
Quoted 3 lines
Regardless, you should NEVER require a driver reload to switch bands and if you do that's a bug. If mac80211 requires a driver reload then that's a MAJOR flaw in that layer.
Have you read the original mail? We were talking about requiring an ifdown/ifup cycle.
johannes
Quoted 8 lines · Johannes Berg
Quoted 3 lines · dragoran
Quoted 2 lines
Nono, you cannot solve it in the driver. The whole design of mac80211 mandates that assumption and I think it is a valid one to make.
why? did the old way (allow mode changing while up) caused any problems?
Why should it be allowed? Can you come up with a good reason for that since you lose all state anyway when doing mode transitions?
Um, what state? Sure you lose your layer 2 state, but why force a layer 3 lossage when you don't necessarily have to do so? For example, I've seen plenty of networks that have both 802.11(a) and 802.11(b/g) networks that share absolutely everything at layer 3. Indeed, at home I have an a/b/g AP where layer 3 is always shared. At the IETF last week it was also shared. I could easily roam from the 802.11(a) to the 802.11(b/g) network if my wireless driver would let me; the IP Address I've got is certainly valid on both networks. Why should the driver try to be smarter than I am?
Quoted 3 lines
Until then (and I guess somebody *really* wants it) it's just a lot easier to not even try to change these low-level things while the interface is operating.
Easier for the driver developer or easier for the user? In general it's better to implement more challenging code in order to make life easier for the end user. In this case it certainly looks like you're foresaking your users to make the developer's life (maybe) a tiny bit easier.
Quoted 1 line
johannes
-derek
Signature · 4 lines
Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
Member, MIT Student Information Processing Board (SIPB)
URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH
[email protected] PGP key availableQuoted 9 lines · Derek Atkins
Um, what state? Sure you lose your layer 2 state, but why force a layer 3 lossage when you don't necessarily have to do so? For example, I've seen plenty of networks that have both 802.11(a) and 802.11(b/g) networks that share absolutely everything at layer 3. Indeed, at home I have an a/b/g AP where layer 3 is always shared. At the IETF last week it was also shared. I could easily roam from the 802.11(a) to the 802.11(b/g) network if my wireless driver would let me; the IP Address I've got is certainly valid on both networks. Why should the driver try to be smarter than I am?
Can you please re-read the original mail?
Thanks,
johannes
Quoted 8 lines · Derek Atkins
Quoted 6 lines · Johannes Berg
Quoted 3 lines · dragoran
Quoted 2 lines
Nono, you cannot solve it in the driver. The whole design of mac80211 mandates that assumption and I think it is a valid one to make.
why? did the old way (allow mode changing while up) caused any problems?
Quoted 7 lines
Quoted 2 lines
Why should it be allowed? Can you come up with a good reason for that since you lose all state anyway when doing mode transitions?
Um, what state? Sure you lose your layer 2 state, but why force a layer 3 lossage when you don't necessarily have to do so? For example, I've seen plenty of networks that have both 802.11(a) and 802.11(b/g) networks that share absolutely everything at layer 3.
I think you are confusing a/b/g "mode" (which is _not_ the topic) with AP/STA/IBSS/monitor "mode" (which is the topic).
John
Signature · 2 lines
John W. Linville [email protected]
Quoted 12 lines · John W. Linville
Quoted 11 lines · Derek Atkins
Quoted 8 lines · Johannes Berg
Quoted 3 lines · dragoran
Quoted 2 lines
Nono, you cannot solve it in the driver. The whole design of mac80211 mandates that assumption and I think it is a valid one to make.
why? did the old way (allow mode changing while up) caused any problems?
Why should it be allowed? Can you come up with a good reason for that since you lose all state anyway when doing mode transitions?
Quoted 7 lines
Quoted 4 lines
Um, what state? Sure you lose your layer 2 state, but why force a layer 3 lossage when you don't necessarily have to do so? For example, I've seen plenty of networks that have both 802.11(a) and 802.11(b/g) networks that share absolutely everything at layer 3.
I think you are confusing a/b/g "mode" (which is _not_ the topic) with AP/STA/IBSS/monitor "mode" (which is the topic).
Indeed I am, mea culpa. I'll go shut up now.
Quoted 1 line
John
-derek
Signature · 4 lines
Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
Member, MIT Student Information Processing Board (SIPB)
URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH
[email protected] PGP key availableQuoted 9 lines · Johannes Berg
Quoted 3 lines · Tomas
There is a definitely a known issue in the driver that we still need to resolve, but I agree with Johannes that there is a problem in design of the configuration as well.
Nono, you cannot solve it in the driver. The whole design of mac80211 mandates that assumption and I think it is a valid one to make. If userspace breaks because of that it's their fault.
Well, to be honest none of the drivers before mac80211 required you to down the device to change modes. But they were mostly fullmac, or half-mac like ipw2x00. Since mac80211 has only just become useful in the past couple of months for most people, it's not really fair to expect versions of NM that were out before mac80211 landed to play nice with what mac80211 expects, which is different from what other drivers implement.
Not to say NM shouldn't be fixed for this. The other problem is that there's really not a good way to determine whether the driver is actually _ready_ after down it and bringing it back up. You basically have to spin & block until the interface gets IFF_UP set on it again, and even then that's not entirely reliable.
Dan
Quoted 7 lines · Dan Williams
Well, to be honest none of the drivers before mac80211 required you to down the device to change modes. But they were mostly fullmac, or half-mac like ipw2x00. Since mac80211 has only just become useful in the past couple of months for most people, it's not really fair to expect versions of NM that were out before mac80211 landed to play nice with what mac80211 expects, which is different from what other drivers implement.
True.
Quoted 5 lines
Not to say NM shouldn't be fixed for this. The other problem is that there's really not a good way to determine whether the driver is actually _ready_ after down it and bringing it back up. You basically have to spin & block until the interface gets
IFF_UPset on it again, and even then that's not entirely reliable.
Not sure I understand? Drivers can fully well block the userspace task that is doing the IFF_UP until they're read? bcm43xx does that.
johannes
Quoted 12 lines · Johannes Berg
Quoted 7 lines · Dan Williams
Well, to be honest none of the drivers before mac80211 required you to down the device to change modes. But they were mostly fullmac, or half-mac like ipw2x00. Since mac80211 has only just become useful in the past couple of months for most people, it's not really fair to expect versions of NM that were out before mac80211 landed to play nice with what mac80211 expects, which is different from what other drivers implement.
True.
Quoted 8 lines
Quoted 5 lines
Not to say NM shouldn't be fixed for this. The other problem is that there's really not a good way to determine whether the driver is actually _ready_ after down it and bringing it back up. You basically have to spin & block until the interface gets
IFF_UPset on it again, and even then that's not entirely reliable.Not sure I understand? Drivers can fully well block the userspace task that is doing the
IFF_UPuntil they're read? bcm43xx does that.
Well, I'd rather that the driver actually not block (NM uses netlink here anyway, not an ioctl) but there be some flag to look for when the device actually is up. That implies that the device not set IFF_UP on itself until it actually _is_ up. I think the biggest offender for up-misbehavior used to be prism54 FullMAC, because it had to reload the firmware for almost every operation, and that could take over a second or two to load & reboot the firmware. There wasn't a good way of telling when that was done and the firmware was ready for business. So you end up having sleep(2) calls littering the code to deal with these sorts of little things.
Dan
blocking in dev->open (was: [ipw3945-devel] chaning mode only when interface down?)
[picking up on this old mail again, somehow remembered it]
Quoted 7 lines · Dan Williams
Quoted 2 lines
Not sure I understand? Drivers can fully well block the userspace task that is doing the
IFF_UPuntil they're read? bcm43xx does that.Well, I'd rather that the driver actually not block (NM uses netlink here anyway, not an ioctl) but there be some flag to look for when the device actually is up. That implies that the device not set
IFF_UPon itself until it actually _is_ up.
Well, since IFF_UP is set by the networking core after ->open() returns there isn't much a device can do about when to set it. However, if it blocks in ->open() until it is ready, the right behaviour falls out automatically, IFF_UP is only set when it's ready. I think blocking there is definitely the right behaviour. NM simply needs to wait for the netlink reply a little longer then.
How do you think not blocking should work? The device can't influence IFF_UP, when its open() callback returns IFF_UP is set and it is assumed that the device is operating. It's designed to be blocking. And besides, if you don't like that, you can spawn a thread to do the flag setting, no?
Quoted 7 lines
I think the biggest offender for
up-misbehavior used to be prism54 FullMAC, because it had to reload the firmware for almost every operation, and that could take over a second or two to load & reboot the firmware. There wasn't a good way of telling when that was done and the firmware was ready for business. So you end up having sleep(2) calls littering the code to deal with these sorts of little things.
Well, I think it should just block for all that and you should simply do it out of the main thread if it's such a big deal.
johannes
Quoted 5 lines · Somebody in the thread at some point
Quoted 3 lines
Because of this NM can't create ad-hoc networks because it does it while the device is up.
Any ideas?Fix NM?
It can easily try it one way and if it fails, try the other.
NM has some other things that needed fixing last time I looked at it... it thought it knew better than I did if a wireless interface was in Monitor mode that I "really wanted it" to be in Managed.
-Andy
Quoted 3 lines · Andy Green
NM has some other things that needed fixing last time I looked at it... it thought it knew better than I did if a wireless interface was in Monitor mode that I "really wanted it" to be in Managed.
Hah yeah that is *really* annoying. Especially if you already have one virtual managed interface and it insists on changing the other one. Luckily, as long as it's up, it doesn't succeed :)
johannes
Quoted 6 lines · Andy Green
Quoted 4 lines · Somebody in the thread at some point
Quoted 3 lines
Because of this NM can't create ad-hoc networks because it does it while the device is up.
Any ideas?
Quoted 7 lines
Quoted 1 line
Fix NM?
It can easily try it one way and if it fails, try the other.
NM has some other things that needed fixing last time I looked at it... it thought it knew better than I did if a wireless interface was in Monitor mode that I "really wanted it" to be in Managed.
Monitor mode is inconsistently implemented across drivers. If the device is in monitor mode, I assume you're not actually using it for any traffic or anything? NM has to set the mode on the device (adhoc or infra) before doing any connection stuff, and NM also used to set the mode to infra before scanning, because older cards don't deliver good scan results when in adhoc mode. Plus, NM scans periodically and keeps the card up during that time.
It's only with mac80211 and prism54 that you really have to take the card down to change from infra -> adhoc or back. That's a _new_ requirement, even if it is a valid one. I think it's fine, but expecting existing NM to magically support that is sorta wrong. Doesn't mean we shouldn't change it though.
For example, if the device isn't being used, NM is still scanning on the device, but the device doesn't actually need to (a) be up or (b) be put into infra mode between the periodic scans.
dan