]> git.ipfire.org Git - thirdparty/hostap.git/commit
Multi-AP: Don't reject backhaul STA on fronthaul BSS
authorArnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Tue, 12 Feb 2019 14:35:23 +0000 (15:35 +0100)
committerJouni Malinen <j@w1.fi>
Mon, 18 Feb 2019 18:21:01 +0000 (20:21 +0200)
commitbfcdac1c8bb7189310d0797b9bdf19d92d0414f3
treec51c87829f96b217c52125fa1ff681ed305d2d4c
parenta1debd33848ee92af71d1f6d06738f7022e563d0
Multi-AP: Don't reject backhaul STA on fronthaul BSS

The Multi-AP specification only specifies that information elements have
to be added to the Association Request and Association Response frame;
it doesn't specify anything about what should be done in case they are
missing. Previously, we rejected non-backhaul associations on a
backhaul-only BSS, and non-fronthaul associations on a fronthaul-only
BSS.

However, this makes WPS fail when fronthaul and backhaul are separate
SSIDs. Indeed, WPS for the backhaul link is performed on the *fronthaul*
SSID. Thus, the Association Request frmae used for WPS *will* contain
the Multi-AP IE indicating a backhaul STA. Rejecting that association
makes WPS fail.

Therefore, accept a multi-AP backhaul STA Association Request frame on a
fronthaul-only BSS. Still issue a warning about it, but only at level
DEBUG intead of INFO. Also change the condition checking to make it
clearer.

While we're at it, also fix the handling of unexpected bits in the
Multi-AP IE. 4 bits are reserved in the specification, so these
certainly have to be ignored. The specification also doesn't say that
setting one of the other bits is not allowed. Therefore, only report
unexpected values in the Multi-AP IE, don't reject because of it. Note
that a malformed IE (containing more than one byte) still triggers a
rejection.

Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
src/ap/ieee802_11.c