lp:~indicator-network-developers/wpasupplicant/trunk

Branch merges

Related source package recipes

1 recipe using this branch. (?)

Create packaging recipe

Related snap packages

Related bugs

Related blueprints

14163. By Lior David <email address hidden> on 2019-02-21

Fix cipher suite selector default value in RSNE for DMG

According to IEEE Std 802.11-2016, 9.4.2.25 when fields of an RSNE are
not included, the default values are used. The cipher suite defaults
were hardcoded to CCMP in the previous implementation, but the default
is actually different for DMG: GCMP (per 9.4.2.25.2).

It is not possible to find out from the RSNE if the network is non-DMG
or DMG, so callers of wpa_parse_wpa_ie_rsn() need to handle this case
based on context, which can be different for each caller.

In order to fix this issue, add flags to the wpa_ie_data indicating
whether pairwise/group ciphers were included in the RSNE. Callers can
check these flags and fill in the appropriate ciphers. The
wpa_parse_wpa_ie_rsn() function still initializes the ciphers to CCMP by
default so existing callers will not break. This change also fixes some
callers which need to handle the DMG network case.

Signed-off-by: Lior David <email address hidden>

14162. By Jiani Liu <email address hidden> on 2019-02-21

Add new QCA vendor attributes for coex configuration

Signed-off-by: Jiani Liu <email address hidden>

14161. By Arun Kumar Khandavalli <email address hidden> on 2019-02-21

Add a vendor attribute for specifying ethernet protocol type

This new QCA vendor attribute adds provision to specify the
ethernet protocol id from userspace to the packets which are
offloaded to the driver/firmware (e.g., IPv4, IPv6).

Signed-off-by: Arun Kumar Khandavalli <email address hidden>

14160. By Arnout Vandecappelle (Essensium/Mind) <email address hidden> on 2019-02-18

tests: Multi-AP WPS provisioning

Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <email address hidden>

14159. By Arnout Vandecappelle (Essensium/Mind) <email address hidden> on 2019-02-18

hostapd: Add README-MULTI-AP

Document what hostapd and wpa_supplicant do for Multi-AP.

This is only included in hostapd, since a Multi-AP device is always an
access point so it should have hostapd.

Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <email address hidden>

14158. By Davina Lu <email address hidden> on 2019-02-18

hostapd: Support Multi-AP backhaul STA onboarding with WPS

The Wi-Fi Alliance Multi-AP Specification v1.0 allows onboarding of a
backhaul STA through WPS. To enable this, the WPS Registrar offers a
different set of credentials (backhaul credentials instead of fronthaul
credentials) when the Multi-AP subelement is present in the WFA vendor
extension element of the WSC M1 message.

Add new configuration options to specify the backhaul credentials for
the hostapd internal registrar: multi_ap_backhaul_ssid,
multi_ap_backhaul_wpa_psk, multi_ap_backhaul_wpa_passphrase. These are
only relevant for a fronthaul SSID, i.e., where multi_ap is set to 2 or
3. When these options are set, pass the backhaul credentials instead of
the normal credentials when the Multi-AP subelement is present.

Ignore the Multi-AP subelement if the backhaul config options are not
set. Note that for an SSID which is fronthaul and backhaul at the same
time (i.e., multi_ap == 3), this results in the correct credentials
being sent anyway.

The security to be used for the backaul BSS is fixed to WPA2PSK. The
Multi-AP Specification only allows Open and WPA2PSK networks to be
configured. Although not stated explicitly, the backhaul link is
intended to be always encrypted, hence WPA2PSK.

To build the credentials, the credential-building code is essentially
copied and simplified. Indeed, the backhaul credentials are always
WPA2PSK and never use per-device PSK. All the options set for the
fronthaul BSS WPS are simply ignored.

Signed-off-by: Davina Lu <email address hidden>
Signed-off-by: Igor Mitsyanko <email address hidden>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <email address hidden>
Cc: Marianna Carrera <email address hidden>

14157. By Davina Lu <email address hidden> on 2019-02-18

wpa_supplicant: Support Multi-AP backhaul STA onboarding with WPS

The Wi-Fi Alliance Multi-AP Specification v1.0 allows onboarding of a
backhaul STA through WPS. To enable this, the backhaul STA needs to add
a Multi-AP IE to the WFA vendor extension element in the WSC M1 message
that indicates it supports the Multi-AP backhaul STA role. The Registrar
(if it support Multi-AP onboarding) will respond to that with a WSC M8
message that also contains the Multi-AP IE, and that contains the
credentials for the backhaul SSID (which may be different from the SSID
on which WPS is performed).

Introduce a new parameter to wpas_wps_start_pbc() and allow it to be
set via control interface's new multi_ap=1 parameter of WPS_PBC call.
multi_ap_backhaul_sta is set to 1 in the automatically created SSID.
Thus, if the AP does not support Multi-AP, association will fail and
WPS will be terminated.

Only wps_pbc is supported.

This commit adds the multi_ap argument only to the control socket
interface, not to the D-Bus interface.

Since WPS associates with the fronthaul BSS instead of the backhaul BSS,
we should not drop association if the AP announces fronthaul-only BSS.
Still, we should only do that in the specific case of WPS. Therefore,
add a check to multi_ap_process_assoc_resp() to allow association with a
fronthaul-only BSS if and only if key_mgmt contains WPS.

Signed-off-by: Davina Lu <email address hidden>
Signed-off-by: Igor Mitsyanko <email address hidden>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <email address hidden>
Signed-off-by: Daniel Golle <email address hidden>
Cc: Marianna Carrera <email address hidden>

14156. By Arnout Vandecappelle (Essensium/Mind) <email address hidden> on 2019-02-18

WPS: Add multi_ap_subelem to wps_build_wfa_ext()

The Multi-AP specification adds a new subelement to the WFA extension
element in the WPS exchange. Add an additional parameter to
wps_build_wfa_ext() to add this subelement. The subelement is only added
if the parameter is nonzero. Note that we don't reuse the existing
MULTI_AP_SUB_ELEM_TYPE definition here, but rather define a new
WFA_ELEM_MULTI_AP, to make sure the enum of WFA subelement types for WPS
vendor extension remains complete.

For now, all callers set the multi_ap_subelem parameter to 0.

Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <email address hidden>

14155. By Arnout Vandecappelle (Essensium/Mind) <email address hidden> on 2019-02-18

tests: Update multi_ap_fronthaul_on_ap to match implementation

Now that the backhaul STA Multi-AP association is not rejected anymore
by the AP, update the test case to expect disconnection to be triggered
by the STA.

Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <email address hidden>

14154. By Arnout Vandecappelle (Essensium/Mind) <email address hidden> on 2019-02-18

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) <email address hidden>