WLAN status update
mb at bu3sch.de
Mon Jan 12 17:26:11 CET 2009
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
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).
More information about the devel