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

2011-04-01 Thread Ruan Chunping
The following reply was made to PR usb/156000; it has been noted by GNATS.

From: Ruan Chunping r...@mipang.com
To: PseudoCylon moonlightak...@yahoo.ca
Cc: bug-follo...@freebsd.org
Subject: Re: usb/156000: rum(4) Fatal trap 18: integer divide fault while in
 kernel mode
Date: Fri, 1 Apr 2011 15:31:29 +0800

 Thanks for your suggestion
 
 I will do more test.
 
 On Fri, Apr 1, 2011 at 15:14, PseudoCylon moonlightak...@yahoo.ca wrote:
 
  From: Ruan Chunping r...@mipang.com
  To: PseudoCylon moonlightak...@yahoo.ca
  Cc: bug-follo...@freebsd.org; Hans Petter Selasky hsela...@c2i.net
  Sent: Tue, March 29, 2011 7:42:54 AM
  Subject: Re: usb/156000: rum(4) Fatal trap 18: integer divide fault whil=
 e in
  kernel mode
  
  Thanks a lot!
  
  
  Maybe rum(4) has anthor ARP-Reply problem too.
  
 
  No.
 
  The driver shouldn't panic just because it's received an odd packet, and =
 need to
  be fixed. Other than that, based on your tcpdump output, the driver is be=
 having
  fine.
 
  When the driver is not receiving any arp packet, it isn't sending any, so
  android phone doesn't work. No driver sends out a packet spontaneously.
  When the driver receives an arp packet, it sends out, so nokia phone work=
 s.
  There is nothing wrong from driver's point of view.
 
  It seems routing table hasn't properly been configured, so arp reply pack=
 ets are
  sent to default gateway (most likely to em0).
 
  Once the routing table is set up, every thing should work fine.
  http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/network-routing=
 .html
 
  You can set up an AP without bridge. Since you are making subnet, rather =
 not to.
  But, if you need to use bridge, you need to add 2 or more NICs as I menti=
 oned in
  previous thread. That's what bridge is for.
 
  bridge0: flags=3D8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 m=
 tu 1500
   =C2=A0 =C2=A0 =C2=A0 =C2=A0ether 72:5f:7d:8a:55:34
   =C2=A0 =C2=A0 =C2=A0 =C2=A0inet 192.168.77.1 netmask 0xff00 broadca=
 st 192.168.77.255
   =C2=A0 =C2=A0 =C2=A0 =C2=A0id 00:00:00:00:00:00 priority 32768 hellotim=
 e 2 fwddelay 15
   =C2=A0 =C2=A0 =C2=A0 =C2=A0maxage 20 holdcnt 6 proto rstp maxaddr 100 t=
 imeout 1200
   =C2=A0 =C2=A0 =C2=A0 =C2=A0root id 00:00:00:00:00:00 priority 32768 ifc=
 ost 0 port 0
   =C2=A0 =C2=A0 =C2=A0 =C2=A0member: wlan0 flags=3D143LEARNING,DISCOVER,=
 AUTOEDGE,AUTOPTP
   =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ifmaxaddr 0 port=
  10 priority 128 path cost 370370
   =C2=A0 member: em0 .  you need this
 
 
  AK
 
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org


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

2011-03-29 Thread PseudoCylon
The following reply was made to PR usb/156000; it has been noted by GNATS.

From: PseudoCylon moonlightak...@yahoo.ca
To: bug-follo...@freebsd.org, r...@mipang.com
Cc: Hans Petter Selasky hsela...@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
 
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org


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

2011-03-29 Thread Ruan Chunping
The following reply was made to PR usb/156000; it has been noted by GNATS.

From: Ruan Chunping r...@mipang.com
To: PseudoCylon moonlightak...@yahoo.ca
Cc: bug-follo...@freebsd.org, Hans Petter Selasky hsela...@c2i.net
Subject: Re: usb/156000: rum(4) Fatal trap 18: integer divide fault while in
 kernel mode
Date: Tue, 29 Mar 2011 21:42:54 +0800

 --bcaec51b2071e86735049f9f3d93
 Content-Type: text/plain; charset=UTF-8
 
 Thanks a lot!
 
 
 Maybe rum(4) has anthor ARP-Reply problem too.
 
 Last week,i try to setup the rum as my wireless AP.
 I foud that, some device work, and some not.
 
 My Nokia E71(symbian) works good, while anthor two Andriod mobile phones can
 not access any website.
 
 rum0 hostap
 wlan0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500
 ether 00:1d:0f:07:9b:28
 inet 192.168.77.1 netmask 0xff00 broadcast 192.168.77.255
 media: IEEE 802.11 Wireless Ethernet autoselect mode 11g hostap
 status: running
 ssid mptest channel 6 (2437 MHz 11g) bssid 00:1d:0f:07:9b:28
 regdomain ROW country CN authmode WPA2/802.11i privacy MIXED
 deftxkey 3 AES-CCM 2:128-bit AES-CCM 3:128-bit txpower 30 scanvalid
 60
 protmode CTS dtimperiod 1 -dfs
 
 
 Let's see how E17 talking to wlan0 (arp request/reply)
 
 #tcpdump -i wlan0 -e -Nnnn arp
 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
 listening on wlan0, link-type EN10MB (Ethernet), capture size 96 bytes
 20:56:12.234527 00:21:fe:3e:0a:6b  ff:ff:ff:ff:ff:ff, ethertype ARP
 (0x0806), length 42: Request who-has 192.168.77.101 tell 0.0.0.0, length 28
 20:56:12.234561 00:21:fe:3e:0a:6b  ff:ff:ff:ff:ff:ff, ethertype ARP
 (0x0806), length 42: Request who-has 192.168.77.101 tell 0.0.0.0, length 28
 20:56:13.263247 00:21:fe:3e:0a:6b  ff:ff:ff:ff:ff:ff, ethertype ARP
 (0x0806), length 42: Request who-has 192.168.77.1 tell 192.168.77.101,
 length 28
 20:56:13.263389 00:21:fe:3e:0a:6b  ff:ff:ff:ff:ff:ff, ethertype ARP
 (0x0806), length 42: Request who-has 192.168.77.1 tell 192.168.77.101,
 length 28
 20:56:13.263513 00:1d:0f:07:9b:28  00:21:fe:3e:0a:6b, ethertype ARP
 (0x0806), length 42: Reply 192.168.77.1 is-at 00:1d:0f:07:9b:28, length 28
 
 Everything ok.
 
 And,the Andriod phone.
 18:02:06.879851 a4:ed:4e:74:e4:30  ff:ff:ff:ff:ff:ff, ethertype ARP
 (0x0806), length 42: Request who-has 192.168.77.1 tell 192.168.77.100,
 length 28
 18:02:06.879869 a4:ed:4e:74:e4:30  ff:ff:ff:ff:ff:ff, ethertype ARP
 (0x0806), length 42: Request who-has 192.168.77.1 tell 192.168.77.100,
 length 28
 18:02:07.879226 a4:ed:4e:74:e4:30  ff:ff:ff:ff:ff:ff, ethertype ARP
 (0x0806), length 42: Request who-has 192.168.77.1 tell 192.168.77.100,
 length 28
 18:02:07.879244 a4:ed:4e:74:e4:30  ff:ff:ff:ff:ff:ff, ethertype ARP
 (0x0806), length 42: Request who-has 192.168.77.1 tell 192.168.77.100,
 length 28
 18:02:08.877476 a4:ed:4e:74:e4:30  ff:ff:ff:ff:ff:ff, ethertype ARP
 (0x0806), length 42: Request who-has 192.168.77.1 tell 192.168.77.100,
 length 28
 18:02:08.877494 a4:ed:4e:74:e4:30  ff:ff:ff:ff:ff:ff, ethertype ARP
 (0x0806), length 42: Request who-has 192.168.77.1 tell 192.168.77.100,
 length 28
 18:02:15.260227 a4:ed:4e:74:e4:30  ff:ff:ff:ff:ff:ff, ethertype ARP
 (0x0806), length 42: Request who-has 192.168.77.1 tell 192.168.77.100,
 length 28
 18:02:15.260245 a4:ed:4e:74:e4:30  ff:ff:ff:ff:ff:ff, ethertype ARP
 (0x0806), length 42: Request who-has 192.168.77.1 tell 192.168.77.100,
 length 28
 18:02:16.261477 a4:ed:4e:74:e4:30  ff:ff:ff:ff:ff:ff, ethertype ARP
 (0x0806), length 42: Request who-has 192.168.77.1 tell 192.168.77.100,
 length 28
 18:02:16.261495 a4:ed:4e:74:e4:30  ff:ff:ff:ff:ff:ff, ethertype ARP
 (0x0806), length 42: Request who-has 192.168.77.1 tell 192.168.77.100,
 length 28
 ...
 there's no arp answer reply to  andriod's mac a4:ed:4e:74:e4:30
 
 so the andriod phone don't know who-has 192.168.77.1,he can't access any
 website.
 
 # arp -an
 (192.168.77.101) at 00:21:fe:3e:0a:6b on wlan0 expires in 1197 seconds
 [ethernet
 ...
 ( there's no 192.168.77.1 at 00:1d:0f:07:9b:28 on wlan0 ... is it right?)
 
 
 //
 
 Then, i addm wlan0 to an bridge (Another pc, Freebsd8.2-RELEASE amd64)
 
 rum0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 2290
 ether 00:1d:0f:07:9b:28
 media: IEEE 802.11 Wireless Ethernet autoselect mode 11g hostap
 status: running
 wlan0: flags=8943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST metric 0
 mtu 1500
 ether 00:1d:0f:07:9b:28
 media: IEEE 802.11 Wireless Ethernet autoselect mode 11g hostap
 status: running
 ssid mptest channel 6 (2437 MHz 11g) bssid 00:1d:0f:07:9b:28
 regdomain ROW country CN authmode WPA2/802.11i privacy MIXED
 deftxkey 3 AES-CCM 2:128-bit AES-CCM 3:128-bit txpower 30 scanvalid
 60
 protmode CTS dtimperiod 1 -dfs
 bridge0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu
 1500

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

2011-03-28 Thread Chunping Ruan

Number: 156000
Category:   usb
Synopsis:   rum(4) Fatal trap 18: integer divide fault while in kernel mode
Confidential:   no
Severity:   serious
Priority:   high
Responsible:freebsd-usb
State:  open
Quarter:
Keywords:   
Date-Required:
Class:  sw-bug
Submitter-Id:   current-users
Arrival-Date:   Mon Mar 28 16:00:19 UTC 2011
Closed-Date:
Last-Modified:
Originator: Chunping Ruan
Release:8.2-RELEASE i386/amd64
Organization:
Environment:
FreeBSD test.home.com 8.2-RELEASE FreeBSD 8.2-RELEASE #0: Fri Feb 18 02:24:46 
UTC 2011 r...@almeida.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC  i386
Description:
I have a usb wireless NIC (TP-LINK TL-WN321G+ ),
and setup as my hostap

dmesg|grep rum
rum0: Ralink 54M.USB..., class 0/0, rev 1.10/0.01, addr 2 on usbus0
rum0: MAC/BBP RT2573 (rev 0x2573a), RF RT2528

ifconfig
em0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500
options=9bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM
ether 08:00:27:d7:1e:31
inet 192.168.1.220 netmask 0xff00 broadcast 192.168.1.255
media: Ethernet autoselect (1000baseT full-duplex)
status: active
lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST metric 0 mtu 16384
options=3RXCSUM,TXCSUM
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2
inet6 ::1 prefixlen 128
inet 127.0.0.1 netmask 0xff00
nd6 options=3PERFORMNUD,ACCEPT_RTADV
rum0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 2290
ether 00:1d:0f:07:9b:28
media: IEEE 802.11 Wireless Ethernet autoselect mode 11g hostap
status: running
wlan0: flags=8943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST metric 0 mtu 
1500
ether 00:1d:0f:07:9b:28
media: IEEE 802.11 Wireless Ethernet autoselect mode 11g hostap
status: running
ssid mptest channel 6 (2437 MHz 11g) bssid 00:1d:0f:07:9b:28
regdomain ROW country CN authmode WPA2/802.11i privacy MIXED
deftxkey 2 AES-CCM 2:128-bit txpower 30 scanvalid 60 protmode CTS
dtimperiod 1 -dfs
bridge0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500
ether 3e:cc:4a:2e:67:65
inet 192.168.77.1 netmask 0xff00 broadcast 192.168.77.255
id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15
maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200
root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0
member: wlan0 flags=143LEARNING,DISCOVER,AUTOEDGE,AUTOPTP
ifmaxaddr 0 port 4 priority 128 path cost 370370

arp -an

? (192.168.77.100) at 00:21:fe:3e:0a:6b on bridge0 expires in 1199 seconds 
[bridge]
? (192.168.77.1) at 3e:cc:4a:2e:67:65 on bridge0 permanent [bridge]
? (192.168.1.77) at e0:05:c5:22:61:fc on em0 expires in 1199 seconds [ethernet]
? (192.168.1.100) at 00:07:e9:a8:1e:f4 on em0 expires in 1153 seconds [ethernet]
? (192.168.1.220) at 08:00:27:d7:1e:31 on em0 permanent [ethernet]


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

then, system panic and reboot



* why i do such arping ?

it seems that , the bridged wlan0 cant reply ARP reply packets

tcpdump -i wlan0
18:02:08.877494 a4:ed:4e:74:e4:30  ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), 
length 42: Request who-has 192.168.77.1 tell 192.168.77.100, length 28
18:02:15.260227 a4:ed:4e:74:e4:30  ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), 
length 42: Request who-has 192.168.77.1 tell 192.168.77.100, length 28
18:02:15.260245 a4:ed:4e:74:e4:30  ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), 
length 42: Request who-has 192.168.77.1 tell 192.168.77.100, length 28
18:02:16.261477 a4:ed:4e:74:e4:30  ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), 
length 42: Request who-has 192.168.77.1 tell 192.168.77.100, length 28
18:02:16.261495 a4:ed:4e:74:e4:30  ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), 
length 42: Request who-has 192.168.77.1 tell 192.168.77.100, length 28


and, 
tcpdump -i bridge0
18:02:15.260258 a4:ed:4e:74:e4:30  ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), 
length 42: Request who-has 192.168.77.1 tell 192.168.77.100, length 28
18:02:15.260281 72:5f:7d:8a:55:34  a4:ed:4e:74:e4:30, ethertype ARP (0x0806), 
length 42: Reply 192.168.77.1 is-at 72:5f:7d:8a:55:34, length 28
18:02:16.261508 a4:ed:4e:74:e4:30  ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), 
length 42: Request who-has 192.168.77.1 tell 192.168.77.100, length 28
18:02:16.261521 72:5f:7d:8a:55:34  a4:ed:4e:74:e4:30, ethertype ARP (0x0806), 
length 42: Reply 192.168.77.1 is-at 72:5f:7d:8a:55:34, length 28

you see, bridge0 send ARP reply ,but wlan0 not send

the arp request packets are sent by my Android mobile phone,he can't access any 
web site,because he don't know who-has 192.168.77.1
 
so, i use arping to test.





Fatal trap 18: integer divide fault while in kernel mode
cpuid = 0; apic