WLAN status update
mb at bu3sch.de
Mon Jan 12 18:52:44 CET 2009
On Monday 12 January 2009 18:32:20 Werner Almesberger wrote:
> Needless to day, a soft-MAC would solve a lot of problems for us, even
> if it means that we'd have to write a driver from scratch for it.
Yeah that would solve about all issues left :)
> You mentioned some runtime patching. Do you mean AR6000_XIOCTL_DIAG_WRITE ?
> I'm not aware of anything that uses this interface for "live" updates.
> There is drivers/ar6000/miscdrv/common_drv.c:ar6000_reset_device_skipflash,
> but that only switches between ROM and Flash.
I was talking about BMIrompatchInstall and friends.
The BMIReadMemory interface seems to work (at least it returns some data that looks
like state tables, data structures etc... from RAM), so I guess the rest of the BMI functions would
possibly also work.
> Read access with wmiconfig --dumpchipmem is a bit disappointing: it
> returns that there's plenty of dead beef all over the place in the
> memory regions hard-coded in wmiconfig.
> "wmiconfig --diagaddr=<addr> --diagread" allows some more inspection.
> E.g., there seems to be ROM at 0x1000000 and it can be read.
> drivers/ar6000/include/AR6001_regdump.h suggests that there's a MIPS
> core in there.
Hm, that'd be cool.
> Okay, that's a lot more freedom than the documentation suggests.
> Perhaps we should walk through a few examples with the ESSID,
> because that's a fairly well-understood configuration item.
> Case 1:
> - ESSID is set
> - rfkill disables the transmitter, then re-enables it
> - what states is the ESSID allowed to be in now ?
I think it should be handed to the Supplicant. The Supplicant will try
to re-establish the connection or drop it.
So the real question is, does the firmware implement part of the
Supplicant? I guess so.
Currently, however, most devices that implement rfkill don't drop any state
at all. They simply wait for the Supplicant to notice the connection interruption.
This will happen within a few seconds and the Supplicant will re-establish the connection.
That's not the ideal solution, however, as it introduces a few seconds delay for the supplicant
to notice the interruption.
> Case 2:
> - rfkill disables the transmitter
> - an attempt is made to set the ESSID with SIOCSIWESSID. Does the
> ioctl have to succeed or is it allowed to fail ?
Well, wireless extensions semantics are a little bit crappy. But as far as I
understand the semantics, SIWESSID is supposed to associate to the service (except in a few cornercases).
So IMO it should fail, because without a transmitter, we can't handshake a
> Also, if rfkill affects the ESSID, who is responsible of informing
> user space that the ESSID to be set again, and how is this
> accomplished ? A straightforward way may be to take down the whole
> interface and then bring it up again, but that may be considered a
> little radical.
Yeah, as I said. Current mainline drivers don't mess with state at all. They simply
depend on the upper MAC to detect the situation and re-establish the connection
and states as needed.
More information about the devel