netplan set fails silently with wifi access points

Bug #1981071 reported by Dave Jones
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
netplan.io (Ubuntu)
Triaged
High
Unassigned
Jammy
New
Undecided
Unassigned
Kinetic
Won't Fix
High
Unassigned

Bug Description

The netplan set command fails to add new access-points to a wifi definition. Furthermore, it appears to be overly aggressive in pruning "default" settings with the result that definitions for open access points are stripped from the resulting configuration.

My reproduction case is on a Pi, but I would assume this probably isn't Pi specific:

* Boot a freshly flashed kinetic (or jammy) server image
* Edit /etc/netplan/50-cloud-init.yaml to contain a valid wifi definition for a PSK network, along with an empty definition for an open network (such as one might find in a hotel). For example:

  network:
    version: 2
    ethernets:
      eth0:
        dhcp4: true
        optional: true
    wifis:
      wlan0:
        access-points:
          elmers-ap:
            password: VewyVewySecwet
          hotel-ap: {}
        dhcp4: true
        optional: true

* Use "netplan apply" to apply the configuration and check wpa-supplicant has been configured appropriately:

  $ sudo netplan apply
  $ sudo wpa_cli -i wlan0 list_networks
  network id / ssid / bssid / flags
  0 elmers-ap any
  1 hotel-ap any

* Use "netplan set" to define a new AP with a PSK and check the resulting configuration:

  $ sudo netplan set "wifis.wlan0.access-points.bugs-ap={password:Albuquerque}"
  $ cat /etc/netplan/50-cloud-init.yaml
  network:
    ethernets:
      eth0:
        dhcp4: true
        optional: true
    version: 2
    wifis:
      wlan0:
        access-points:
          elmers-ap:
            password: VewyVewySecwet
        dhcp4: true
        optional: true

Note firstly that the new access point ("bugs-ap") is not present, and secondly that the empty definition for the open access point ("hotel-ap") has been removed. Furthermore, the exit code is 0 so presumably netplan thinks everything went okay.

I've attempted defining the new network by setting the entire access-points sub-tree, but this doesn't work either. Changing the password of existing AP definition with "netplan set" *does* work so I'm assuming this isn't a case of missing functionality, but the addition of new APs does appear broken, and the pruning of open-network definitions is certainly a problem.

Dave Jones (waveform)
tags: added: rls-jj-incoming rls-kk-incoming
Revision history for this message
Lukas Märdian (slyon) wrote :

Thanks for tagging this rls-*-incoming.

One observation I made is that if the hotel-ap is explicitly defined as an open AP it does not go away, so there seems to be some issue with the "NULL" handling of parsing an empty "{}" stanza.

        "hotel-ap":
          auth:
            key-management: "none"

I think we need to implement some special handling of connections/interfaces vs APs, as each AP definition basically expands to be it's own connection and this is a special case in the netplan code.

Also, I think there is a similar/related issue with deleting single AP connections from a given wifi interface via libnetplan, which we might be able to fix in the same way.

Changed in netplan.io (Ubuntu):
status: New → Triaged
importance: Undecided → High
Lukas Märdian (slyon)
tags: removed: rls-jj-incoming rls-kk-incoming
tags: added: fr-2546
Benjamin Drung (bdrung)
Changed in netplan.io (Ubuntu Jammy):
status: New → Fix Committed
Changed in netplan.io (Ubuntu Kinetic):
status: Triaged → Fix Committed
status: Fix Committed → Triaged
Changed in netplan.io (Ubuntu Jammy):
status: Fix Committed → New
Revision history for this message
Utkarsh Gupta (utkarsh) wrote :

Ubuntu 22.10 (Kinetic Kudu) has reached end of life, so this bug will not be fixed for that specific release.

Changed in netplan.io (Ubuntu Kinetic):
status: Triaged → Won't Fix
Lukas Märdian (slyon)
tags: added: foundations-todo
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.