Netplan replug function is incompatible with ath9k_htc module
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Snappy |
Fix Released
|
Undecided
|
Unassigned | ||
netplan |
Fix Released
|
High
|
Mathieu Trudel-Lapierre | ||
nplan (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned | ||
Xenial |
Fix Released
|
Undecided
|
Unassigned | ||
Yakkety |
Fix Released
|
Undecided
|
Unassigned | ||
Zesty |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
[Impact]
Replugging ath9k_htc may confuse the driver and cause connection issues.
[Test case]
- Run nplan integration tests on the release
- Validate that netplan generate && netplan apply alone, without config, behave as expected (no result)
- Validate that netplan generate && netplan apply with minimal config writes /run/NetworkMan
- Validate that netplan generate && netplan apply works with any existing configuation.
- Run 'netplan apply' with a valid config for an ath9k_htc device, validate the device is not replugged.
[Regression potential]
Existing configurations that do not rely on ath9k, brcmfmac or mwifiex (for example) should continue to replug the devices where appropriate to ensure the interface renaming is correctly applied. Configurations for the affected devices should not fail to apply supported configuration.
---
We hit the following problem about the interaction between netplan and the ath9k_htc module, controlling the chip Atheros AR9271.
If you run the following command
netplan --debug apply
or you use console-conf for setting the network interfaces we get the following messages :
** (generate:2261): DEBUG: Processing input file //etc/netplan/
** (generate:2261): DEBUG: eth0: setting default backend to 1
** (generate:2261): DEBUG: Generating output files..
** (generate:2261): DEBUG: NetworkManager: definition eth0 is not for us (backend 1)
DEBUG:netplan generated networkd configuration exists, restarting networkd
DEBUG:no netplan generated NM configuration exists
DEBUG:device lo operstate is unknown, not replugging
DEBUG:device eth0 operstate is up, not replugging
DEBUG:replug wlan0: unbinding 4-1:1.0 from /sys/bus/
DEBUG:replug wlan0: rebinding 4-1:1.0 to /sys/bus/
The last two row show two consecutive actions, one soon after the other: unbind and bind the usb device on usb hub.
The module ath9k_htc doesn't work fine in this situation: the wireless interface disappears.
Our problem can be fixed by using the same approach used for mac80211_hwsim e mwifiex_pcie modules.
The attached patch file fix the issue following the same pattern adopted for the following modules:
mwifiex_
description: | updated |
description: | updated |
tags: |
added: verification-done-xenial removed: verification-done |
In Progress/High. I'm preparing a new release, so I'll include this.
I'm a little concerned about the trend of half-broken kernel drivers requiring this kind of exceptions though. Have you also filed a bug against 'linux' for the driver to get fixed?
There will also be the question on whether we can do better than replugging the devices like this, but for now we will do with an exception.