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?
On Fri, 2007-08-03 at 10:33 -0400, Derek Atkins wrote:
> 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
"John W. Linville" <[email protected]> writes:
> On Fri, Aug 03, 2007 at 10:33:07AM -0400, Derek Atkins wrote:
>> Johannes Berg <[email protected]> writes:
>>
>> > 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?
>> >
>> > 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).
Indeed I am, mea culpa. I'll go shut up now.
> John
-derek
--
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 available
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?
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
>-----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?
>
>On Thu, 2007-08-02 at 15:17 +0300, Winkler, Tomas wrote:
>
>> 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.
>
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
>johannes
On Thu, 2007-08-02 at 10:18 +0100, Andy Green wrote:
> 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
Somebody in the thread at some point said:
>> 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
Johannes Berg wrote:
> On Thu, 2007-08-02 at 15:17 +0300, Winkler, Tomas wrote:
>
>
>> 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?
On 8/2/07, Johannes Berg <[email protected]> wrote:
> On Thu, 2007-08-02 at 15:41 +0300, Winkler, Tomas wrote:
>
> > 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
> that you have to down the interface is a mac80211 "limitation"
>
Yes it is
> 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
>
>
>
On Thu, 2007-08-02 at 10:18 +0100, Andy Green wrote:
> Somebody in the thread at some point said:
>
> >> 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.
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
Johannes Berg wrote:
> On Thu, 2007-08-02 at 09:44 +0200, dragoran wrote:
>
>> 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
>> 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.
> Blame it on Jean that wireless
> extensions are ill-defined and don't mandate this.
>
>
>> 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?
On Fri, Aug 03, 2007 at 10:33:07AM -0400, Derek Atkins wrote:
> Johannes Berg <[email protected]> writes:
>
> > 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?
> >
> > 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
--
John W. Linville
[email protected]
On Thu, 2007-08-02 at 15:17 +0300, Winkler, Tomas wrote:
> 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
On Thu, 2007-08-02 at 09:44 +0200, dragoran wrote:
> 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.
> 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.
> Because of this NM can't create ad-hoc networks because it does it while
> the device is up.
> Any ideas?
Fix NM?
johannes
[picking up on this old mail again, somehow remembered it]
On Fri, 2007-08-03 at 07:20 -0400, Dan Williams wrote:
> > 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.
>
> 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.
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?
> 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
On Thu, 2007-08-02 at 15:41 +0300, Winkler, Tomas wrote:
> 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
>-----Original Message-----
>From: [email protected]
[mailto:ipw3945-devel-
>[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-
>[email protected]
>Subject: Re: [ipw3945-devel] chaning mode only when interface down?
>
>Johannes Berg wrote:
>> On Thu, 2007-08-02 at 09:44 +0200, dragoran wrote:
>>
>>> 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
>>> 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.
>> Blame it on Jean that wireless
>> extensions are ill-defined and don't mandate this.
>>
>>
>>> 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?
>
>
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
>-----------------------------------------------------------------------
--
>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
On Fri, 2007-08-03 at 11:42 +0200, Johannes Berg wrote:
> On Thu, 2007-08-02 at 14:51 -0400, Dan Williams wrote:
>
> > 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.
>
> > 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.
>
> 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.
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
On Thu, 2007-08-02 at 14:51 -0400, Dan Williams wrote:
> 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.
> 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.
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
Johannes Berg <[email protected]> writes:
> 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?
>
> 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?
> 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.
> johannes
-derek
--
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 available
On Thu, 2007-08-02 at 14:34 +0200, Johannes Berg wrote:
> On Thu, 2007-08-02 at 15:17 +0300, Winkler, Tomas wrote:
>
> > 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