From: Jouni Malinen (jkmaline_at_cc.hut.fi)
Date: 2002-08-31 08:22:12 UTC
On Wed, Aug 28, 2002 at 06:08:05PM +0200, Ricardo Galli wrote:
> Just plain iwconfig (with no arguments, as root at least, running it several
> times) or wavemon, which hangs the machine in few seconds.
There were couple of bugs that could have caused double-kfree()s and plenty of possibilities for race condition with cmd_queue entries. I fixed the double-kfree() cases and added reference counts to cmd_queue entries to get rid of the other problem. All fixed are in CVS.
It looks like the current version removed host crashes at least from my test cases. I am unable to crash a laptop bridging packets between wired and wireless net (and using WEP with host encrypt and decrypt)--no matter how I flood it (TCP/UDP/ping from wired->wireless or wireless->wired) and while running iwconfig in busy loop. The card does not end up in any odd state and do not require resets.
On another test setup I use SMP host and Compaq WL200 with old firmware. With this, there is one case (TCP flood from wired to wireless) that seems to put the card in confused state that requires card resetting (which the driver is able to do). However, the host system did not crash anymore with the latest driver version.
I'm not fully sure whether the problems with confusing the card are due to the driver or hardware/firmware problems. There might still be some locking issues at least with SMP hosts. Anyway, if I do not get any new reports about host site crashes with the current CVS snapshot, I will probably make a new release and continue debugging this later.
> My test is a ping from a machine in the _ethernet_ (100 mbps) side [*] to
> another machine in the wireless, using 104 WEP encryption, kernel 2.4.19 and
> bridging enabled.
The problems I have so far fixed seem to be totally independent of WEP and bridge functionality, but apparently these result in suitable timing for some operations to fail. Current implementation of RX event handler uses quite a bit of time in hardware interrupt handler which is not very nice behavior since it could cause too much latency for other interrupts. I will probably do something to this later (e.g., only copy the received packet payload in the hardware interrupt handler and process this data after freeing the host system to handle new interrupts).
-- Jouni Malinen PGP id EFC895FA