Date: Sun, 16 Oct 2011 20:32:42 +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: <4E9B315A.6030607@pyro.eu.org> In-Reply-To: <CAJ-Vmonvs=HaoAGvpLw43S4ATmZUi2vaG8JYFhRZAZhfvwcWbQ@mail.gmail.com> References: <201110152200.p9FM0QUO044812@freefall.freebsd.org> <CAJ-VmomdNhZd7fEv9CHTBrMaQabO1Xks4Y-gjTMKEe3KNSNPAQ@mail.gmail.com> <4E9A5FB6.7040904@pyro.eu.org> <4E9B062A.9050408@pyro.eu.org> <CAJ-Vmonvs=HaoAGvpLw43S4ATmZUi2vaG8JYFhRZAZhfvwcWbQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 16/10/11 17:46, Adrian Chadd wrote: > I don't think it's the mbuf. It looks like the mbuf allocation is fine. > The linux code in compat-wireless... Hi Adrian! Thanks for your suggestions. Happily I've got it working, and it wasn't nearly that complicated. I'm only using i386 architecture. I looked further into the magic 88-byte threshold after which the bug occurs. It turns out that figure included the 24-byte tx_desc, and up to 64 bytes of beacon frame (header+data). rum_write_multi doesn't seem happy with writing >64 bytes at a time to the MAC register. If I break it up into separate calls (e.g. bytes 0-63, then bytes 64-65, written at the appropriate offset) I see the proper beacon frames being transmitted now. It's working for any length of ESSID from 0-32 bytes so padding, alignment or guard bytes don't appear to be necessary for the beacon frame. (For tx_data, though, there is code to handle that). I'll neaten this up, produce a patch and test some more. 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?4E9B315A.6030607>