Date: Sat, 15 Oct 2011 22:00:26 GMT From: Steven Chamberlain <steven@pyro.eu.org> To: freebsd-net@FreeBSD.org Subject: Re: kern/149643: [rum] device not sending proper beacon frames in ap mode Message-ID: <201110152200.p9FM0QUO044812@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/149643; it has been noted by GNATS.
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201110152200.p9FM0QUO044812>