Tx timed out! Resetting card (with OpenAP)

[earl]

earl wrote:

> I've only tried this so far in the case of
> wds_type=2 and *not* the case of doing the volatile firmware update with
> wds_type=4.  (I don't understand whether a card-reset will cause the volatile
> firmware update to be lost, causing the card to revert to its permanent firmware
> --- anyone know what to expect?)

After experimenting with this, i've found that an automatic card reset which would
have been tolerated in the first case (wds_type=2, without volatile firmware update)
will kill the link in the second case (wds_type=4, with volatile firmware update).
I'm not going to investigate further right now but it looks like the card reset
causes a volatile firmware update to be lost.  After the reset, if i set wds_type to
2, then the link will work again, so presumably it's gone back to the permanent
firmware which can't handle wds_type=4.

Regarding my previous message (about recoverable and not-recoverable card-reset
events), i notice that when the link is truly dead the output of iwconfig for that
interface is missing the two lines that look something like this:
          Bit Rate:1Mb/s   Tx-Power:1 dBm   Sensitivity=1/3
          Retry min limit:8   RTS thr:off   Fragment thr:off
Since a dead wlan0 is fatal for this particular system (its only purpose is to be an
AP), i have a dumb background script that checks iwconfig's output for that
condition (iwconfig wlan0 | grep Rate) every once in a while, and if wlan0 is dead
will reboot the system as a last resort.  Yes it's crude, but it's better than
letting an AP languish in that useless state.  I'd prefer to just unload-reload the
modules but that doesn't seem to be working.

earl