From nox@jelal.kn-bremen.de  Sat Aug 14 11:22:51 2010
Return-Path: <nox@jelal.kn-bremen.de>
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 688601065693;
	Sat, 14 Aug 2010 11:22:51 +0000 (UTC)
	(envelope-from nox@jelal.kn-bremen.de)
Received: from smtp.kn-bremen.de (gelbbaer.kn-bremen.de [78.46.108.116])
	by mx1.freebsd.org (Postfix) with ESMTP id 2ABB78FC0A;
	Sat, 14 Aug 2010 11:22:51 +0000 (UTC)
Received: by smtp.kn-bremen.de (Postfix, from userid 10)
	id 7E22E1E0016B; Sat, 14 Aug 2010 13:04:04 +0200 (CEST)
Received: from triton8.kn-bremen.de (noident@localhost [127.0.0.1])
	by triton8.kn-bremen.de (8.14.4/8.14.3) with ESMTP id o7EB22wo013545;
	Sat, 14 Aug 2010 13:02:02 +0200 (CEST)
	(envelope-from nox@triton8.kn-bremen.de)
Received: (from nox@localhost)
	by triton8.kn-bremen.de (8.14.4/8.14.3/Submit) id o7EB22Zd013544;
	Sat, 14 Aug 2010 13:02:02 +0200 (CEST)
	(envelope-from nox)
Message-Id: <201008141102.o7EB22Zd013544@triton8.kn-bremen.de>
Date: Sat, 14 Aug 2010 13:02:02 +0200 (CEST)
From: Juergen Lock <nox@jelal.kn-bremen.de>
Reply-To: Juergen Lock <nox@jelal.kn-bremen.de>
To: FreeBSD-gnats-submit@freebsd.org
Cc: Bernhard Schmidt <bschmidt@freebsd.org>, Kevin Lo <kevlo@freebsd.org>
Subject: [rum] device not sending proper beacon frames in ap mode
X-Send-Pr-Version: 3.113
X-GNATS-Notify:

>Number:         149643
>Category:       kern
>Synopsis:       [rum] device not sending proper beacon frames in ap mode
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-net
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sat Aug 14 11:30:01 UTC 2010
>Closed-Date:    
>Last-Modified:  Tue Oct 18 04:20:10 UTC 2011
>Originator:     Juergen Lock
>Release:        FreeBSD 8.1-RC2 amd64
>Organization:
me?  organized??
>Environment:
System: FreeBSD triton8.kn-bremen.de 8.1-RC2 FreeBSD 8.1-RC2 #8: Thu Aug 5 18:52:07 CEST 2010 nox@triton8.kn-bremen.de:/usr/obj/data2v/home/nox/src-r81/src/sys/TRITON8U amd64


>Description:
	I was asked to make this a seperate PR after bschmidt's
	patch in kern/149185 fixed the if_rum panics:

	Instead of beacon frames (Frame control 0x0080, wireshark
	calls this field wlan.fc), the device sends frames with
	Frame control 0x221e, which wireshark says is 802.11
	Unrecognized, Type/Subtype Unknown 0x31.

>How-To-Repeat:
	Try to use hostapd with if_rum, watch clients frequently
	disconnect.

	# ifconfig wlan0 create wlandev rum0 wlanmode ap country DE channel 11:g
	# /etc/rc.d/hostapd onestart

	This particular device comes up as:

	rum0: <Belkin Belkin 54g USB Network Adapter, class 0/0, rev 2.00/0.01, addr 3> on usbus5
	rum0: MAC/BBP RT2573 (rev 0x2573a), RF RT2528
	rum0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps
	rum0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps

>Fix:
	No idea :)
>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: freebsd-bugs->freebsd-net 
Responsible-Changed-By: linimon 
Responsible-Changed-When: Sat Aug 14 13:31:54 UTC 2010 
Responsible-Changed-Why:  
Over to maintainer(s). 

http://www.freebsd.org/cgi/query-pr.cgi?pr=149643 

From: Henry Hu <henry.hu.sh@gmail.com>
To: bug-followup@freebsd.org, nox@jelal.kn-bremen.de
Cc:  
Subject: Re: kern/149643: [rum] device not sending proper beacon frames in ap mode
Date: Sat, 19 Mar 2011 18:17:24 +0800

 I have similar issue. My card:
 
 rum0: <Ralink 802.11 bg WLAN, class 0/0, rev 2.00/0.01, addr 6> on usbus6
 rum0: MAC/BBP RT2573 (rev 0x2573a), RF RT2528
 
 I also see my clients disconnect quickly.
 However, mine one do not send out any beacons.
 I'm also using hostapd, and as I capture the packets in the
 IEEE802_11_RADIO layer from an internal intel 3945 card, I cannot see
 any beacons sent by the card.
 I can see beacons of other access points, and if I plug the Ralink
 card into a WinXP laptop with official driver and software installed,
 I can see beacons from the card.
 So I think that the hardware is capable of sending beacons. It's just
 a problem of the driver.
 
 I found that though there is no beacons, a windows laptop connects
 fairly stable to the network. Maybe it ignores the beacons.
 However, my phone always disconnects from the network. It is an
 android phone, which uses wpa_supplicant to manage wireless
 connection.
 
 I create my wlan device with this:
 # sudo ifconfig wlan0 create wlandev rum0 wlanmode hostap
 My hostapd.conf:
 
 interface=wlan0
 ctrl_interface=/var/run/hostapd
 wpa=1
 wpa_passphrase=xxxxxxxxxx
 ssid=henryhu
 
 By the way, I found that the beacon_int and channel in hostapd.conf is
 useless, is it true?
 
 
 -- 
 Cheers,
 Henry

From: Steven Chamberlain <steven@pyro.eu.org>
To: bug-followup@FreeBSD.org, nox@jelal.kn-bremen.de
Cc: henry.hu.sh@gmail.com
Subject: Re: kern/149643: [rum] device not sending proper beacon frames in
 ap mode
Date: Sat, 15 Oct 2011 22:56:55 +0100

 Hi!
 
 I was just trying to debug the same issue because I experienced it using
 the rum driver on OpenBSD.  With this OpenBSD-specific ifconfig line I
 can force the adapter into 11b-only mode and the beacons (sniffed by
 another device) are then sent correctly:
 
 > # ifconfig rum0 media DS11 mode 11b mediaopt hostap up
 
 > 21:22:39.646991 00:19:5b:d3:00:56 > ff:ff:ff:ff:ff:ff, bssid 00:19:5b:d3:00:56: 802.11: beacon, ssid (TESTTEST), rates, ds, tim
 >   0000: 8000 0000 ffff ffff ffff 0019 5bd3 0056  ....������..[�.V
 >   0010: 0019 5bd3 0056 3001 b622 1c00 0000 0000  ..[�.V0.�"......
 >   0020: 6400 2100 0008 5445 5354 5445 5354 0104  d.!...TESTTEST..
 >   0030: 8284 0b16 0301 0105 0400 0100 00         .............
 
 But after switching to 11g mode, the beacons either stop completely, or
 are sent malformed with wrong destination/subtype:
 
 > # ifconfig rum0 media OFDM54 mode 11g mediaopt hostap up
 
 > 21:21:14.864881 00:19:5b:d3:00:56 > 32:04:30:48:60:6c, bssid 00:19:5b:d3:00:56, DS >: 802.11: association request
 >   0000: 0022 0100 3204 3048 606c 0019 5bd3 0056  ."..2.0H`l..[�.V
 >   0010: 0019 5bd3 0056 408c ef3c b10d 0000 0000  ..[�.V@.�<�.....
 >   0020: 6400 2104 0008 5445 5354 5445 5354 0108  d.!...TESTTEST..
 >   0030: 8284 8b96 0c12 1824 0301 0105 0400 0100  .......$........
 >   0040: ef86 7703 d7b9 e937 f1e5                 �.w.׹�7�
 
 The first 10 bytes of the beacon frame have been replaced with junk.
 
 Changing the length of the ESSID can affect what type of packet is sent
 instead of a beacon.  The longer the ESSID, the more bytes from the
 destination address are overwritten with junk (should always be
 ff:ff:ff:ff:ff:ff).
 
 
 With ESSID set to "TESTTEST", tshark decoded one of the broken frame
 like this:
 
 > IEEE 802.11 Association Request, Flags: ........
 >     Type/Subtype: Association Request (0x00)
 >     Frame Control: 0x0001 (Normal)
 >         Version: 1
 >         Type: Management frame (0)
 >         Subtype: 0
 >         Flags: 0x0
 
 >     Destination address: 30:48:60:6c:ff:ff (30:48:60:6c:ff:ff)
 >     BSS Id: 00:19:5b:d3:00:56 (00:19:5b:d3:00:56)
 >     Fragment number: 0
 
 > IEEE 802.11 wireless LAN management frame
 >     Fixed parameters (4 bytes)
 >         Capability Information: 0xE5A8
 
 >     Tagged parameters (46 bytes)
 >         SSID parameter set
 >             Tag Number: 0 (SSID parameter set)
 >             Tag length: 0
 >             Tag interpretation: : Broadcast
 >         SSID parameter set
 >             Tag Number: 0 (SSID parameter set)
 >             Tag length: 0
 >         Reserved tag number: Tag 100 Len 0
 >             Tag Number: 100 (Reserved tag number)
 >             Tag length: 0
 >             Tag interpretation: Not interpreted
 >         Power Capability
 >             Tag Number: 33 (Power Capability)
 >             Tag length: 4
 >             Power Capability: Error: Tag length must be exactly 2 bytes long
 >             Minimum Transmit Power: 0x00
 >             Maximum Transmit Power: 0x08
 >         Reserved tag number
 >             Tag Number: 83 (Reserved tag number)
 >             Tag length: 84
 
 There are 8 stray bytes (0x0000000064002104) that should not be here,
 that have been decoded as information elements.  Other wireless devices
 see the first SSID tag and interpret it as meaning 'no SSID'.
 
 The SSID tag should instead look like 0x00 = ESSID, 0x08 = length, then
 0x54455354... = "TESTTEST", which you can above appeared in a broken
 'Power Capability' tag (although 0x5354 became 0x8384).
 
 
 My absolute guess is that an OFDM rate is being chosen for mgmtrate.
 Maybe this happens if the channel type is wrongly detected as a
 5GHz/802.11a one.  rum_setup_tx_desc would generate a different result
 if it is thought to be an OFDM frame:
 
 > if_rum.c:1012 if (ieee80211_rate2phytype(ic->ic_rt, rate) == IEEE80211_T_OFDM) {
 
 The result would then probably not be what rum_prepare_beacon expects here:
 
 > if_rum.c:2139 rum_setup_tx_desc(sc, &desc, RT2573_TX_TIMESTAMP, RT2573_TX_HWSEQ,
 > if_rum.c:2140     m0->m_pkthdr.len, tp->mgmtrate);
 
 > if_rum.c:2142 /* copy the first 24 bytes of Tx descriptor into NIC memory */
 > if_rum.c:2143 rum_write_multi(sc, RT2573_HW_BEACON_BASE0, (uint8_t *)&desc, 24);
 
 
 I will have to find some faster hardware to rebuild the driver and test
 my idea.  Or hopefully I've given enough detail that someone else may
 realise the problem now.
 
 Thanks!
 Regards,
 -- 
 Steven Chamberlain
 steven@pyro.eu.org

From: Steven Chamberlain <steven@pyro.eu.org>
To: Adrian Chadd <adrian@freebsd.org>
Cc: freebsd-net@freebsd.org, bug-followup@FreeBSD.org
Subject: Re: kern/149643: [rum] device not sending proper beacon frames in
 ap mode
Date: Tue, 18 Oct 2011 04:36:33 +0100

 Hi Adrian,
 
 I see that revision 226467 by bz already fixed the compiler warnings.
 I've now built and tested this on freebsd-8 amd64.
 
 The same bugfix has been working throughout the day on a couple of
 openbsd i386 boxes with rum hardware too.
 
 I guess the PR number you asked me for yesterday is just kern/149643 ?
 
 Many thanks for getting this into -HEAD.
 Regards,
 -- 
 Steven Chamberlain
 steven@pyro.eu.org

From: Adrian Chadd <adrian@freebsd.org>
To: Steven Chamberlain <steven@pyro.eu.org>
Cc: freebsd-net@freebsd.org, bug-followup@freebsd.org
Subject: Re: kern/149643: [rum] device not sending proper beacon frames in ap mode
Date: Tue, 18 Oct 2011 11:44:59 +0800

 On 18 October 2011 11:36, Steven Chamberlain <steven@pyro.eu.org> wrote:
 > Hi Adrian,
 >
 > I see that revision 226467 by bz already fixed the compiler warnings.
 > I've now built and tested this on freebsd-8 amd64.
 
 Sweet. I'll just assume at this point that it'll work on FreeBSD-9 and
 aim to get it into the tree in the next few days.
 
 > The same bugfix has been working throughout the day on a couple of
 > openbsd i386 boxes with rum hardware too.
 
 Great news :) I'm sure the OpenBSD guys will appreciate being sent a
 bugfix as well.
 Just make sure you mention it came from FreeBSD. :)
 
 > I guess the PR number you asked me for yesterday is just kern/149643 ?
 
 I'll check it out, thanks! :)
 
 
 Adrian
>Unformatted:
