Having problems connection to hostapd network with HT
j at w1.fi
Thu Dec 1 13:21:19 PST 2016
On Wed, Nov 23, 2016 at 03:28:13PM +0100, Markus Ongyerth wrote:
> We have a problem with hostapd and 80211N.
> We wanted to set up an accesspoint using hostapd.
> When we set the require_ht setting int he hostapd.conf
> our client gets rejected. If we do not set it, we can
> connect, but only get legacy data rates.
That would sound like a client device that either does not support HT or
is behaving in some unexpected manner that makes it disable HT..
> So I did a bit of digging (mainly debug output and
> My test client here is my laptop with an
> "Intel Corporation Wireless 7260 (rev bb)" wifi card.
> I am using an up to date install of archlinux. I have
> done this test with default kernel (4.8) and lts (4.4).
> It should not be relevant though, we had the same
> problems on different devices.
Could you please identify the exact client devices and driver versions
that show this behavior? I have not seen this type of issue with any
mac80211-based driver on the client device.
> I found out that the probe frames are sent with the
> HT-capability info, but the actual assoc (and auth)
> request frames lack these fields.
There is no HT elements in the Authentication frame, but the Association
Request frame needs to have it for HT to get used.
> Looking at the code the code, hostapd checks whether
> the station supports HT when it adds it. This is done
> only when the first association request is sent.
> Which doesn't contain the HT information, which
> explains why we get rejected with require_ht.
The described hostapd behavior here sounds correct, so I'd try to debug
why the station device is not trying to use HT.
> I have attached hexdumps (from wireshark) for the
> mentioned packages and our hostapd.conf
Could you please provide an actual pcap file with all the relevant
frames in that exchange? I'd like to see Beacon frame, Probe Request
frame, Probe Response frame, Authentication frames, Association Request
frame, Association Response frame.
> The relevant parts in the code I found are:
As far as I know, hostapd implementation is correct in this area.
> wpa=1 # WPA2 only
By the way, that comment is not correct. wpa=1 disables WPA2 and only
enables WPA. This would be a bit strange configuration nowadays since
WPA2/RSN was released over ten years ago.. This should really be wpa=2
if you want to enable only WPA2 or wpa=3 if for some reason you still
need backwards compatibility support for WPA (i.e., to support client
devices that are over ten years old).
Jouni Malinen PGP id EFC895FA
More information about the Hostap