Hi,

I have a few i386 boxes running OpenBSD hostapd, each with 2 rum devices
(mix of manufacturers, revisions, with/without USB cables).  Most of
them panic, crash hard, or one/both rum interfaces stop transmitting
every few hours/days.

So far I seem to think there are numerous, separate issues in OpenBSD's
if_rum.c making it unstable right now, but I'm trying to take time to
work on this:

Issue 1:  beacons didn't work (fixed in CVS HEAD, rev 1.99 -- thanks)

Issue 2:  physically pulling a rum device that is 'up' and busy (sending
lots of broadcast pings, hostapd not running) can trigger a panic (about
1 time in 10);  I think I'm close to having a patch for this;

Issue 3:  occasional 'rum0: device timeout' during operation;  after
this, flag IFF_OACTIVE stays set, no more packets go out, and if PF/cbq
is enabled, the queue fills right up;

Issue 4:  after a timeout, 'ifconfig rum0 stop' or a reboot will then
crash the box hard, so far I've seen a panic message on the serial port,
and with ddb.panic=0 it fails to automatically restart;

Issue 5:  a 'silent' tx lockup of the device;  with no mention of any
'device timeout', and IFF_OACTIVE not set, I noticed a device stop
responding to Association Requests;  with hostapd still running, I did
"ifconfig rum1 down ; ifconfig rum1 up" and got 'rum1: failed to queue
raw tx frame' 4 times before the box crashed hard.

Issue 6:  deauthentication frames are constantly sent out to devices
that haven't been in range for hours, to the same BSSIDs over and over;
 as if it is about to purge them from the node cache, but actually
doesn't;  I think these frames are what triggered the 'failed to queue
raw tx frame' mentioned for Issue 5 above while the interface was going
down.

Thanks for any help or suggestions.  I'll continue to share any more
successes/failures I have with this.

Regards,
-- 
Steven Chamberlain
[email protected]

Reply via email to