WLAN status update

[Michael Buesch]

On Monday 12 January 2009 10:09:56 Andy Green wrote:
> | - in the discussion on linux-wireless, Michael Buesch also mentioned
> |   that rfkill is expected to act "immediately".
> 
> Yeah I take it to mean when you return from the rfkill action, the
> stopping of RF TX is done already.  That sounds doable?

Well, that would be ideal.
I think it wouldn't be that much of a problem if it takes another 10ms however.
My main idea just was that rfkill should _not_ trigger _sending_ of the pending
packets in the queue. Instead it should just drop the queue.
So rfkill should not trigger any packets to get sent. So that's what I meant
by "immediately". Don't flush the queues. Just drop them.
If possible, of course. If the firmware does not support this, we're forced to
implement it in another way, of course.

Btw, as we're talking about firmware, I'm wondering if there's some binary firmware
(update?) blob available for download somewhere. Or if it's possible to read the
firmware code from the PROM.
It seems possible to read the device RAM in the boot stage and that also seems to work
fine. But I didn't see a way to read the PROM. I didn't even find a way to write the PROM
actually. Except this runtime patching thing. So I was wondering if that runtime patching
stuff can be used to read the ROM step by step (into RAM).
Does somebody have some information on the CPU and/or instruction set used in the wireless device?

> Well killing TX kills association, kills any connectivity lying around,
> etc.  It inherently affects everything on top of the network interface.
> ~ I think maybe we can just do it and the sky won't fall?

rfkill is expected to kill the radio without terminating any MAC functions.
The AP/Authenticator/Supplicant will take care of cleaning up dead connections.

-- 
Greetings, Michael.