chaning mode only when interface down?

chaning mode only when interface down?

[dragoran]

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?

Re: chaning mode only when interface down?

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 633 bytes --]

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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]

Re: chaning mode only when interface down?

[dragoran]

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?

Re: chaning mode only when interface down?

[Andy Green]

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

Re: chaning mode only when interface down?

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 469 bytes --]

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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]

RE: [ipw3945-devel] chaning mode only when interface down?

[Winkler, Tomas]

>-----Original Message-----
>From: ipw3945-devel-bounces@lists.sourceforge.net
[mailto:ipw3945-devel-
>bounces@lists.sourceforge.net] On Behalf Of dragoran
>Sent: Thursday, August 02, 2007 12:17 PM
>To: Johannes Berg
>Cc: Dan Williams; linux-wireless@vger.kernel.org; network manager;
ipw3945-
>devel@lists.sourceforge.net
>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
>Ipw3945-devel@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/ipw3945-devel

RE: [ipw3945-devel] chaning mode only when interface down?

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 446 bytes --]

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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]

RE: [ipw3945-devel] chaning mode only when interface down?

[Winkler, Tomas]

>-----Original Message-----
>From: Johannes Berg [mailto:johannes@sipsolutions.net]
>Sent: Thursday, August 02, 2007 3:34 PM
>To: Winkler, Tomas
>Cc: dragoran; Dan Williams; linux-wireless@vger.kernel.org; network
>manager; ipw3945-devel@lists.sourceforge.net
>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

RE: [ipw3945-devel] chaning mode only when interface down?

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 512 bytes --]

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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]

Re: [ipw3945-devel] chaning mode only when interface down?

[dragoran]

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?

Re: [ipw3945-devel] chaning mode only when interface down?

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 584 bytes --]

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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]

Re: [ipw3945-devel] chaning mode only when interface down?

[Tomas Winkler]

On 8/2/07, Johannes Berg <johannes@sipsolutions.net> 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
> Ipw3945-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/ipw3945-devel
>
>
>

Re: [ipw3945-devel] chaning mode only when interface down?

[Derek Atkins]

dragoran <drago01@gmail.com> writes:

> On 8/2/07, Johannes Berg <johannes@sipsolutions.net> 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?
>    
>     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

-- 
       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
       warlord@MIT.EDU                        PGP key available

Re: chaning mode only when interface down?

[Dan Williams]

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

RE: [ipw3945-devel] chaning mode only when interface down?

[Dan Williams]

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

Re: [ipw3945-devel] chaning mode only when interface down?

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 660 bytes --]

On Thu, 2007-08-02 at 11:52 -0400, Derek Atkins wrote:

> 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?

> 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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]

RE: [ipw3945-devel] chaning mode only when interface down?

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 1005 bytes --]

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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]

RE: [ipw3945-devel] chaning mode only when interface down?

[Dan Williams]

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

Re: [ipw3945-devel] chaning mode only when interface down?

[Derek Atkins]

Johannes Berg <johannes@sipsolutions.net> 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
       warlord@MIT.EDU                        PGP key available

Re: [ipw3945-devel] chaning mode only when interface down?

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 740 bytes --]

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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]

Re: [ipw3945-devel] chaning mode only when interface down?

[John W. Linville]

On Fri, Aug 03, 2007 at 10:33:07AM -0400, Derek Atkins wrote:
> Johannes Berg <johannes@sipsolutions.net> 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
linville@tuxdriver.com

Re: [ipw3945-devel] chaning mode only when interface down?

[Derek Atkins]

"John W. Linville" <linville@tuxdriver.com> writes:

> On Fri, Aug 03, 2007 at 10:33:07AM -0400, Derek Atkins wrote:
>> Johannes Berg <johannes@sipsolutions.net> 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
       warlord@MIT.EDU                        PGP key available

blocking in dev->open (was: [ipw3945-devel] chaning mode only when interface down?)

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 1791 bytes --]

[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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]