WLAN status update

[Michael Buesch]

On Monday 12 January 2009 17:00:13 Andy Green wrote:
> No, it's a less than happy-making situation there are no updates and no
> redistributable Linux firmware update tool.

Ok, but the firmware _is_ flashable? Or is it just "updateable" through the
life-patching mechanism?
And by "no redistributeable" you mean there exists a tool, but it's NDA'd?

> | 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?
> 
> I don't have anything.

Ok thanks anyway.
I'm interested in any available information about the firmware. Somebody else? :)

> Right, but I mean the direct implication of (only) killing TX is that
> association state and the other network layer states change too.  So I

Are you talking about IFF_* from linux/if.h?
I think we usually don't change them much at all on wireless devices, as most of
them don't make sense for wireless.
I don't know about any device changing these flags on rfkill.

> don't think we need to sweat possibility of rfkill changing state like
> essid when it has definitely trashed the association and all that will
> need to be set up again from scratch.  If it does turn out to be
> objectionable, we can reload old essid from just before we rfkilled it
> when we un-rfkill it.

I think rfkill should be considered to trash all MAC states.
Even if in reality the time rfkill is triggered matters. But I think no
Authenticator will support a killed radio for more than a few seconds without
trashing at least part of the connection.
So yeah, we should re-load all state (or as you said un-rfkill).

-- 
Greetings, Michael.