Date: Wed, 21 Mar 2012 10:28:23 -0700 From: Adrian Chadd <adrian@freebsd.org> To: freebsd-wireless@freebsd.org, Bernhard Schmidt <bschmidt@freebsd.org> Subject: Re: [net80211] PR kern/166286: force a channel change upon a HT info change Message-ID: <CAJ-VmonnJwazDRHLtVH5TeWeKMZv2aAAZOvO7vDDRhRciLmixw@mail.gmail.com> In-Reply-To: <CAJ-Vmonr7y4f23L_gNfcOjiQHVs5xK-NQC72VH%2B6b%2B-9zorRSw@mail.gmail.com> References: <CAJ-Vmonr7y4f23L_gNfcOjiQHVs5xK-NQC72VH%2B6b%2B-9zorRSw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 20 March 2012 20:24, Adrian Chadd <adrian@freebsd.org> wrote: > Hi, > > This patch forces a channel change - sta_recv_mgmt() doesn't set the > channel width early enough to catch it after the ASSOC -> RUN state > change. So there's a transition to HT20 upon association, but it > doesn't transition to HT40 via ic_chan_set(). Thus the hardware is in > HT20 mode, but HT40 frames are sent to the hardware .They obviously > fail. Bernhard and I had a chat on IRC. The main problem with this approach is that any other devices (eg iwn) don't do anything in their ic_chan_set() method. I also thought about it a bit more and can see how the gap between the htinfo update and notifying the driver could be quite annoying. That said, there _are_ plenty of races in net80211 at the moment as things go poking through the ic/vap state without holding locks. SMP and preemption makes this all quite scary. Adrian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-VmonnJwazDRHLtVH5TeWeKMZv2aAAZOvO7vDDRhRciLmixw>