On Nov 27, 2004, at 8:21 AM, Oli wrote:
>> I did a test this morning on m0n0wall to see if the wifi bug still
>> exists in the hostap mode drivers.  It does.
>>
>> Nov 26 03:11:18 ap2 /kernel: wi1: timeout in wi_seek to 1e3/0; last
>> status 81e3
>> Nov 26 03:11:18 ap2 /kernel: wi1: timeout in wi_seek to 15e/3c; last
>> status 8000
>> Nov 26 03:11:18 ap2 /kernel: wi1: timeout in wi_cmd 0x010b; event
>> status 0x0000
>> Nov 26 03:11:18 ap2 /kernel: wi1: xmit failed
>> Nov 26 03:11:18 ap2 /kernel: wi1: wi_cmd: busy bit won't clear.
>> Nov 26 03:11:18 ap2 /kernel: wi1: xmit failed
>> Nov 26 03:16:24 **********  netcheck: ap2 DOWN!  **********
>>
>> If your connected to m0n0wall using wirelss 802.11b and put your 
>> client
>> wifi card into "power save mode" then the wifi card on m0n0wall will
>> lockup.  The only way I know of to fix this is to have m0n0wall reboot
>> when the error is detected.
>
> I tried to reproduce this behaviour, it's slightly different in my
> setup. When i put my client into powersave mode it also locks up.
>
> Other clients also connected via wireless will still have a link
> to the m0n0wall.
>
> But i don't need to reboot the m0n0 box to fix this. I just turn
> off powersave on the client and the link is back.

Yes, I did find that once powersave mode is turned off then the 
interface returns to normal.  The problem I have is I don't have 
control over the client causing the problem.  It's an unknown client in 
the area.  Might even be a denial of services attack.

> So for me the problem seems to be on the client side.
>
>> This week I'm going to try and figure out a way to get a shell script
>> to run on the box and check for the error message.  When found it will
>> reboot.
>
> Did you try <shellcmd> ?

This is what I'm working on now.  A shellcmd script that will check for 
the error and try to correct it.