WLAN status update
andy at openmoko.com
Mon Jan 12 17:45:49 CET 2009
-----BEGIN PGP SIGNED MESSAGE-----
Somebody in the thread at some point said:
| 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"
| life-patching mechanism?
| And by "no redistributeable" you mean there exists a tool, but it's NDA'd?
I think at some point we ended up with a copy somehow but it was a
Windows app and not redistributable, personally I never saw it even.
|> | 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? :)
Samuel Oritz worked on AR6001 driver for a while, he may be able to
point to stuff that is already available and doesn't hurt NDA-wise.
|> 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.
No, I'm just saying killing RF TX, just like a killswitch does --> the
device can't talk on the air any more --> then you know it is going to
lose association --> big trashing of upper layers state. So rfkill is
inherently destructive of all kinds of network state (intentionally, and
|> 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
| trashing at least part of the connection.
| So yeah, we should re-load all state (or as you said un-rfkill).
Sounds like everyone has the same idea.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the devel