On Sat, Apr 08, 2017 at 09:43:29AM -0500, Jordon wrote: > > > On Apr 8, 2017, at 3:38 AM, Stefan Sperling <s...@stsp.name> wrote: > > > > On Fri, Apr 07, 2017 at 05:06:22PM -0500, Jordon wrote: > >> My new wifi adapter finally arrived today (AR9271) so I want to give > >> hostap a > >> try with its new 802.11n support. > > > >> Am I on the right track? > > > > No. AR9271 is a USB device, and unfortunately there are bugs in the > > driver that prevent hostap from working properly with USB devices. > > > > At least in my testing, the device sends no beacons. I have not yet > > found a way to fix it and am not currently investing more time into it. > > Perhaps it will get fixed some day. > > > > > Dang. Although, IIRC, beacons are what announce the presence of the access > point. I definitely saw it on the client machine, so I think that part was > working. But, yeah, anything beyond that is unsupported so I guess I’ll have > to get a PCIe one. > >
My USB athn(4) AP responds to probe requests but does not send beacons. A client can connect if you set the SSID and do a "directed scan" for this AP. The AP will respond with a probe response directed at the client. A beacon is a probe response sent to the broadcast address periodically. Beacons are required for proper operation for several reasons. Off the top of my head, two of those are: - Clients read configuration settings from beacons (such as frame protection rules for proper interop with 11a/b/g clients on the same channel). These settings can change over time. Using stale settings is bad for clients but won't actually cause severe problems in most situations. - Some clients monitor beacons to find out if they've gone out of range. They will re-connect over and over if they don't see any beacon.
