usb/156000: rum(4) Fatal trap 18: integer divide fault while in kernel mode

[PseudoCylon]

The following reply was made to PR usb/156000; it has been noted by GNATS.

From: PseudoCylon <moonlightakkiy at yahoo.ca>
To: bug-followup at freebsd.org, rcp at mipang.com
Cc: Hans Petter Selasky <hselasky at c2i.net>
Subject: Re: usb/156000: rum(4) Fatal trap 18: integer divide fault while in kernel mode
Date: Tue, 29 Mar 2011 03:09:33 -0700 (PDT)

 > sudo arping -i wlan0 -b -S 192.168.77.100 -s 00:21:fe:3e:0a:6b -t 
 >00:1d:0f:07:9b:28 192.168.77.1
 > 
 > * 00:1d:0f:07:9b:28 is the rum0/wlan0 's MAC
 
 Looks like
 1) rum0 was asked to Tx a packet with it's own mac addr as dst addr
 2) find_tx_node() picked Tx node with ni_associd == 0 (node with own mac addr)
     because rum0 runs in HOSTAP mode, IEEE80211_NODE_ASSOCID flag hasn't been 
 set
 3) the packet slip though this test
    http://fxr.watson.org/fxr/source/net80211/ieee80211_output.c#L231
 4) picked up a bogus value at
    http://fxr.watson.org/fxr/source/dev/usb/wlan/if_rum.c#L1221
 5) probably divided by 0 at
    http://fxr.watson.org/fxr/source/dev/usb/wlan/if_rum.c#L1019
 
 [RFC] could add a simple test to the driver, like if (rate != 0), but isn't it 
 nicer to patch in ieee80211_output.c?
 
 workaround
 Also addm em0, and set dhcpd_iface in /etc/re.conf
 http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/network-dhcp.html
 Then, it should work without issuing tricky arping
 
 
 AK