Merge ~till-kamppeter/network-manager:master into network-manager:master
| Status: | Rejected |
|---|---|
| Rejected by: | Sebastien Bacher |
| Proposed branch: | ~till-kamppeter/network-manager:master |
| Merge into: | network-manager:master |
| Diff against target: |
146 lines (+124/-0) 3 files modified
debian/changelog (+7/-0) debian/patches/WiFi-detect-FT-support-per-interface-and-avoid-enabling-it.patch (+116/-0) debian/patches/series (+1/-0) |
| Related bugs: |
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| Iain Lane | Disapprove | ||
|
Review via email:
|
|||
Commit message
Backport detecting Wi-Fi FT support per interface, release as 1.20.0-1ubuntu2
See https:/
Description of the change
This is a backport of the upstream change to not prefer FT-PSK when it is only supported by supplicant but not by the Wi-Fi interface or driver.
From upstream:
Previously we only cared whether supplicant is build with support for
FT. In that case we would pass FT-PSK to supplicant, like
Config: added 'key_mgmt' value 'WPA-PSK WPA-PSK-SHA256 FT-PSK'
Supplicant would then always try FT with preference, regardless whether
the interface/driver support it. That results in a failure to associate, if
the driver does not support it.
NetworkManage
...
wpa_supplican
wpa_supplican
...
wpa_supplican
...
kernel: ERROR @wl_set_key_mgmt :
kernel: invalid cipher group (1027076)
Since we pass a list of acceptable "key_mgmt" options to supplicant,
FT-PSK should not be used when supplicant knows it's not supported.
That is a supplicant bug.
Regardless, work around it by checking the per-interface capability, and
avoid it if support is apparently not present.
| Sebastien Bacher (seb128) wrote | # |
There was an error fetching revisions from git servers. Please try again in a few minutes. If the problem persists, contact Launchpad support.
just told Till this on IRC: there is a new upstream version containing this fix, which is available in Debian too - we should merge it too I think