Date: Sun, 16 Oct 2011 17:28:26 +0100 From: Steven Chamberlain <steven@pyro.eu.org> To: Adrian Chadd <adrian@freebsd.org> Cc: freebsd-net@freebsd.org Subject: Re: kern/149643: [rum] device not sending proper beacon frames in ap mode Message-ID: <4E9B062A.9050408@pyro.eu.org> In-Reply-To: <4E9A5FB6.7040904@pyro.eu.org> References: <201110152200.p9FM0QUO044812@freefall.freebsd.org> <CAJ-VmomdNhZd7fEv9CHTBrMaQabO1Xks4Y-gjTMKEe3KNSNPAQ@mail.gmail.com> <4E9A5FB6.7040904@pyro.eu.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Hello again, I've made another observation regarding this bug. It is possible to also trigger it in 11b mode if the ESSID is large enough -- up to 11 chars is okay: > # ifconfig rum0 media DS1 mode 11b mediaopt hostap nwid 0xcccccccccccccccccccccc > 15:51:43.053446 00:19:5b:d3:00:56 > ff:ff:ff:ff:ff:ff, bssid 00:19:5b:d3:00:56: 802.11: beacon, ssid 0xcccccccccccccccccccccc, rates, ds, tim > 0000: 8000 0000 ffff ffff ffff 0019 5bd3 0056 ....������..[�.V > 0010: 0019 5bd3 0056 1000 1602 0000 0000 0000 ..[�.V.......... > 0020: 6400 2100 000b cccc cccc cccc cccc cccc d.!...��������� > 0030: cc01 0482 840b 1603 010d 0504 0001 0000 �............... But with 12 chars or more we see the bug again. This results in a beacon frame pkthdr.len > 88 bytes, plus a 24-byte tx descriptor. The first byte of the frame was 0x80 (beacon subtype) but is now overwritten with 0x00 (turning beacons into association requests). A stray 0xff has also been appended: > # ifconfig rum0 media DS1 mode 11b mediaopt hostap nwid 0xcccccccccccccccccccccccc > 15:51:42.944718 00:19:5b:d3:00:56 > ff:ff:ff:ff:ff:ff, bssid 00:19:5b:d3:00:56: 802.11: association request > 0000: 0000 0000 ffff ffff ffff 0019 5bd3 0056 ....������..[�.V > 0010: 0019 5bd3 0056 200b 7e9c 1401 0000 0000 ..[�.V .~....... > 0020: 6400 2100 000c cccc cccc cccc cccc cccc d.!...��������� > 0030: cccc 0104 8284 0b16 0301 0d05 0400 0100 ��.............. > 0040: ff � Making the ESSID a full 32 bytes long gets even more interesting -- clearly the end of the beacon frame has 'wrapped around' on itself. The first 21 bytes here (ending 0x0504 00010000) are what should be in place of the last 21 bytes of the frame: > 16:03:58.575748 0b:16:03:01:0d:05 > cc:cc:01:04:82:84, bssid 04:00:01:00:00:56: 802.11: type#12 > 0000: cc84 cccc cccc 0104 8284 0b16 0301 0d05 �.����.......... > 0010: 0400 0100 0056 9000 7a81 0c00 0000 0000 .....V..z....... > 0020: 6400 2100 0020 cccc cccc cccc cccc cccc d.!.. ��������� > 0030: cccc cccc cccc cccc cccc cccc cccc cccc ��������������� > 0040: ff86 f702 57b8 e9b6 f1e7 9941 43f5 08a7 �.�.W�����.AC�.� > 0050: d442 5429 d8 �BT) In 11g mode, the longer list of supported rates means that the beacon frame is always at least 90 bytes long even with an empty ESSID, which is why the bug is always noticed there. I am waaay out of my depth now but I feel so close to figuring this out. The beacon frame is read from an MBUF; does this work something like a ring buffer internally? The kernel manual doesn't actually use that word. mtod() is called without m_pullup() so maybe the data in it isn't in a contiguous block? Regards, -- Steven Chamberlain steven@pyro.eu.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4E9B062A.9050408>