WLAN status update

[Andy Green]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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"
through the
| 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
it's fine).

|> 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).

Sounds like everyone has the same idea.

- -Andy

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAklrc70ACgkQOjLpvpq7dMp/6wCfQgkyGC0ScB4gDV9heUnOcYfZ
16YAnRMrWIPwzerQN8klFnz3CYlQi3Cf
=mrZO
-----END PGP SIGNATURE-----