WLAN status update

Andy Green andy at openmoko.com
Mon Jan 12 17:00:13 CET 2009

Hash: SHA1

Somebody in the thread at some point said:
| 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
| 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.

Yes only SDIO packets would be triggered by rfkill in this scheme to be
sent to set state in the controlling firmware, not network packets on
the RF.  AIUI if we tell it to go into sleep like mode it won't play
ball as a network device until told to wake up.

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

No, it's a less than happy-making situation there are no updates and no
redistributable Linux firmware update tool.

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

|> 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
| The AP/Authenticator/Supplicant will take care of cleaning up dead

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

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


More information about the devel mailing list