netplan type wifis needs a device option

That's not quite the device, but a driver value though. I wonder if it wouldn't be best to either always set -Dnl80211 on wireless (and -Dwired for 802.1x on ethernet...), or to make it possible to use an alternative value if matching by driver.

For example:

wifis:
  wlan1:
    match:
      driver: wext
      name: wlan1
    access-points:
       [...]
    dhcp4: yes

Triaged; we will need some input from Steve though to figure out how to addess this in the netplan schema.

It's Triaged High as it actually does potentially impact many devices. There are sadly still lots of devices that either don't do wext, or don't do nl80211, and maybe it wouldn't hurt to be explicit when enabling 802.1x on wired.

What is the range of possible values for this -D option, and why would you ever want to specify it in the netplan yaml instead of inferring it?

Re range of possible values for -D option:

From man wpa_supplicant:

AVAILABLE DRIVERS
       A summary of available driver backends is below. Support for each of the driver backends is
       chosen at wpa_supplicant compile time. For a list of supported driver backends that may be used
       with the -D option on your system, refer to the help output of wpa_supplicant (wpa_supplicant -h).

       wext Linux wireless extensions (generic).

       wired wpa_supplicant wired Ethernet driver

       roboswitch
              wpa_supplicant Broadcom switch driver

       bsd BSD 802.11 support (Atheros, etc.).

       ndis Windows NDIS driver.

from wpa_supplicant --help on my system:

drivers:
  nl80211 = Linux nl80211/cfg80211
  wext = Linux wireless extensions (generic)
  wired = Wired Ethernet driver
  none = no driver (RADIUS server/WPS ER)

I'm afraid I still don't understand from this why one would specify a -D option by hand

Here's one (e.g. my) case:

Asus AC1200 USB-AC53 Nano wifi adapter. No linux driver available from the manufacturer. But there are open-source drivers available that work well, but that require the -D parameter in order to be able to use wpa_supplicant.

Quoting https://github.com/jeremyb31/rtl8822bu/blob/master/README.md

NOTES
This driver allows use of wpa_supplicant by using the nl80211 driver wpa_supplicant -Dnl80211

This bug affects me too: to be able to use my RTL-8188EUS on Ubuntu Server 18.04.4 I have to pass -Dwext as parameter to wpa_supplicant. My workaround up to now has been to create a wrapper script named wpa_supplicant renaming the original executable.

This also affects me: the wireless dongle I am using needs wext driver but by default netplan is trying to use the nl80211 driver. If I specify -Dwext as seen in this paste I can get a connection:

https://paste.ubuntu.com/p/gxDb7PcFnP/

I have this problem too, I think netplan is garbage, because it has no config for some networkd config(such as mdns and ipv6 prefix delegation), it only have is a basic network config, I don't know why bother use netplan but it's integrated in ubuntu as essential(ubuntu-minimal and cloud-init all depends on it). I don't know why this isn't an option to to user, and they have many ancient bug that are still open.

Same here. Also using rtl8188 chipset which only works with wext.

This bug affects me
tested on two different adaptors
/sbin/wpa_supplicant -c /run/netplan/wpa-wlxd037453da72a.conf -iwlxd037453da72a -Dwext
will work for me
lsusb reports 0bda:8179 Realtek Semiconductor Corp. RTL8188EUS 802.11n Wireless Network Adapter
however running
/sbin/wpa_supplicant -c /run/netplan/wpa-wlxd037453da72a.conf -iwlxd037453da72a -Dnl80211
will not work
same with
/sbin/wpa_supplicant -c /run/netplan/wpa-wlxd037453da72a.conf -iwlxd037453da72a
which appears to corrospond with how netplan is attempting to initialise the usb adapter
this option works for one adaptor that does not use nl80211 drivers

my other device will work regardless
/sbin/wpa_supplicant -c /run/netplan/wpa-wlx00198611c22e.conf -iwlx00198611c22e
/sbin/wpa_supplicant -c /run/netplan/wpa-wlx00198611c22e.conf -iwlx00198611c22e -Dnl80211
/sbin/wpa_supplicant -c /run/netplan/wpa-wlx00198611c22e.conf -iwlx00198611c22e -Dwext
lsusb reports
0bda:818b Realtek Semiconductor Corp. RTL8192EU 802.11b/g/n WLAN Adapter

It appears that there is a problem with the way wpa_supplicant/kernel drivers are detecting hardware, I agree with Steve Langasek in that it is unclear why the -D should be used to resolve this issue
wext is deprecated and is replaced by nl80211

I have this trouble too!!!!!!! Please fix it!

> What is the range of possible values for this -D option, and why would you ever want to specify it in the netplan yaml instead of inferring it?

It would be best if wpa_supplicant selected the correct driver, but it seems it doesn't do a good job with this. It does support fallbacks, though, which seems like a reasonable default behavior for wpa_supplicant ("-Dnl80211,wext"), but sometimes different drivers have different behaviors/abilities, so explicitly choosing one is useful.

I see two issues:
- wpa_supplicant makes no attempt to automatically pick a working driver
- netplan doesn't have a way to choose a driver if wpa_supplicant's default (nl80211) doesn't work

For example, fallback (-Dnl80211,wext) is used for the wpa_supplicant systemd service:

https://salsa.debian.org/debian/wpa/-/blob/debian/unstable/debian/patches/networkd-driver-fallback.patch

But it isn't present in the netplan networkd renderer.

See https://github.com/canonical/netplan/pull/240

A related change to automatically fallback inside wpa_supplicant itself just landed: https://launchpad.net/ubuntu/+source/wpa/2:2.9.0-23

This bug was fixed in the package netplan.io - 0.104-0ubuntu1

---------------
netplan.io (0.104-0ubuntu1) jammy; urgency=medium

  * New upstream release: 0.104
    - Enable 'embedded-switch-mode' setting on SmartNICs
    - Permit multiple patterns for the driver globs in match (LP: #1918421)
    - Improve routing capabilities (LP: #1892272, LP: #1805038)
    - Support additional link offload options for networkd (LP: #1771740)
    - Handle differing 'ip6-privacy' default value for NetworkManager
    - YAML state tracking for DBus API and 'netplan try' (LP: #1943120)
    - Support ConfigureWithoutCarrier ('ignore-carrier') for networkd
    - Cleanup Makefile, install only public headers
    - Netplan 'get' to use the libnetplan parser
    - libnetplan:
      + introduce the notion of NetplanState
      + use an explicit parser context
      + expose coherent generator APIs
      + improve overall error handling
      + consolidation of YAML parsing into the library
    ATTENTION:
    - Restrict the symbol export to a determined public API
      + We dropped some internal symbols from the API that we know have no
        external consumers, see upstream changelog for list of dropped symbols
    Bug fixes:
    - Fix removal of defunct OVS vlan interfaces (LP: #1959147)
    - Make ConfigManager cleanup on destruction (LP: #1959729)
    - Do not write unvalidated YAML from keyfile (LP: #1952967)
    - Disable tmp address generation for real with NetworkManager (LP: #1948027)
    - Ignore empty YAML hints, delete files on 'set network=null' (LP: #1946957)
    - Wait for 'netplan try' to be ready in DBus API (LP: #1949893)
    - Initialize self.state in 'apply' (LP: #1949104)
    - Driver fallback to nl80211 and/or wext for wpa_supplicant (LP: #1814012)
    - Handle missing 'gateway' in keyfile routes, keep 'dns-search' fallback
    - Make it possible to unset a whole devtype subtree (LP: #1942930)
    - Fix memory leaks, dangling pointers & overall cleanup of API data
  * d/t/control: Add explicit wpasupplicant test Depends
  * d/control: Improved glib (v2.70+-) compat
  * d/control: Strict version dependency on libnetplan
  * d/control: Bump standards version to 4.6.0, improve sections
  * Mute false positive lintian warning
  * d/patches/: Drop patches, applied upstream
  * d/p/autopkgtest-fixes: Refresh
  * d/libnetplan0.symbols: Add new symbols for 0.104
  * d/libnetplan0.symbols: Drop (internal) legacy symbols

 -- Lukas Märdian <email address hidden> Thu, 17 Feb 2022 12:46:23 +0100