disable/enable WiFi on devices with read-only rootfs, the wifi network name will auto plus 1

Bug #1435687 reported by You-Sheng Yang on 2015-03-24
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
systemd
Fix Released
Unknown
ubuntu-settings (Ubuntu)
Undecided
Unassigned

Bug Description

On devices with read-only rootfs, e.g. mobile phones, nic device number (wlan<N>) may increase every time disabled and re-enabled. To be more precisely, this happens only on devices when disabling a NIC removes the corresponding driver.

"/lib/udev/rules.d/75-persistent-net-generator.rules" checks whether NAME attribute has been assigned to wlan<N> device: if yes, skip all the followed steps, or, call to "/lib/udev/write_net_rules" to generate a persistent device name rule file. That persistent file should be created under "/etc/udev/rules.d" and named "70-persistent-net.rules", so it guarantees NAME attribute should be assigned if available before being read. However, when rootfs was previously mounted as read-only, a file "/run/udev/tmp-rules--70-persistent-net.rules" is created instead. This temporary file is supposed to be moved back into "/etc/udev/rules.d" by a systemd service udev-finish right after the system finishes start-up chaos. Again, if rootfs is still mounted as read-only, this move will certainly fail. One last important thing, /run/udev is _NOT_ included in udev rules inclusion paths, so any rules written here will not be taken into account when processing uevents.

So, when wlan0 is probed for the first time on a device with read-only rootfs, udev creates "/run/udev/tmp-ruiles--70-persistent-net.rules" and inserts one rule for it. When wlan0 is disabled and re-enabled, since "/run/udev/tmp-rules--70-persistent-net.rules" is not taken into account, its NAME attribute will not be set, and udev recognize it as a new nic and tries to write another rule for it again. However, in this time, "wlan0" has been taken in the previously written temporary rules file, so "wlan1" is chosen instead, and an exactly the same matching rule (except for NAME= part) is appended to "/run/udev/tmp-rules--70-persistent-net.rules". When the device is again disabled and re-enabled, "wlan2" will be assigned. And so on ....

This is a cloned bug from Debian bug 780705 (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=780705), which affects Ubuntu Phone.

Related branches

You-Sheng Yang (vicamo) wrote :
You-Sheng Yang (vicamo) wrote :

The attached patch Avoid-duplicated-udev-match-rules.patch was also submitted to Debian upstream, but as Debian is switching to systemd and systemd has come with a feature to consolidate device names in a more generic way, this patch is probably not going further. However, since some Ubuntu Phones have not yet fully switch to systemd, a quick patch for this might be valuable.

This patch tries to reuse device names that is already written in tmp rules and has exactly the same match expr with the one that is going to be written out.

Didier Roche (didrocks) wrote :

Thanks for reporting this patch and help to make ubuntu better.

It's mostly the same people working on implementing systemd in debian and ubuntu (and we push most of our patches to debian experimental for non RC bugs, and then sync in ubuntu), so let's continue the discussion on the debian bug report, shall we?

I let this one opened to ensure Martin has a look as he's way more udev savy than I am :)

You-Sheng Yang (vicamo) wrote :

Sorry, I don't know that. Just want to have a backup here so that we may still have a chance to pick it up once it's ditched by Debian.

Didier Roche (didrocks) wrote :

Sure, let's wait for Michael and Martin to comment on this, they are more up to date on the network side of systemd than I am (Martin will be back at the end of week FYI). Thanks for your patch!

The attachment "Avoid duplicated udev match rules" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

tags: added: patch
Changed in systemd:
status: Unknown → Fix Released
Martin Pitt (pitti) wrote :

I think this overcomplicates things a lot. I see three options here:

 1) My impression is that we don't actually care about persistant interface names on the phone. Therefore, phone image builds could just create/ship an empty /etc/udev/rules.d/75-persistent-net-generator.rules which will disable the one in /lib/udev/rules.d/ and therefore disable the generator completely.

 2) If we actually do want persistant names across reboots, then /etc/udev/rules.d/ needs to become writable. It does not make sense to support a phone specific path for this if we could just make the above writable.

 3) As you already said, we could also enable net.ifnames=1 on the kernel command line to use "proper" interface names, which will also disable 75-persistent-net-generator.rules.

affects: systemd (Ubuntu) → ubuntu-settings (Ubuntu)

(replied inline)

2015-03-26 20:46 GMT+08:00 Martin Pitt <email address hidden>:

> I think this overcomplicates things a lot. I see three options here:
>
> 1) My impression is that we don't actually care about persistant
> interface names on the phone. Therefore, phone image builds could just
> create/ship an empty /etc/udev/rules.d/75-persistent-net-generator.rules
> which will disable the one in /lib/udev/rules.d/ and therefore disable
> the generator completely.
>

This is doable to me.

 2) If we actually do want persistant names across reboots, then
> /etc/udev/rules.d/ needs to become writable. It does not make sense to
> support a phone specific path for this if we could just make the above
> writable.
>

It's not about persistent names across reboots, the interface name will not
be consistent if driver reload happens, and that's what's happening on
embedded devices. Whenever driver reload happens, there will be an ADD
uevent which triggers 75-persistent-net-generator.rules.

> 3) As you already said, we could also enable net.ifnames=1 on the
> kernel command line to use "proper" interface names, which will also
> disable 75-persistent-net-generator.rules.
>

net.ifnames depends on systemd, and Ubuntu Phone is not yet upgrade to use
systemd by default.

> ** Package changed: systemd (Ubuntu) => ubuntu-settings (Ubuntu)

Vicamo

Martin Pitt (pitti) wrote :

> > create/ship an empty /etc/udev/rules.d/75-persistent-net-generator.rules
> This is doable to me.

OK, that might be the quickest/safest way for now?

> net.ifnames depends on systemd

No, that's udev only. It should work just fine under upstart too. As that's the long-term goal, doing that on touch for vivid+1 could be the the best option, but it's certainly too intrusive for RTM/vivid for now, I figure?

You-Sheng Yang (vicamo) wrote :

2015-03-26 21:34 GMT+08:00 Martin Pitt <email address hidden>:

> > > create/ship an empty
> /etc/udev/rules.d/75-persistent-net-generator.rules
> > This is doable to me.
>
> OK, that might be the quickest/safest way for now?
>

That follows someone has to cherry-pick the same karg change to each device
affected, which means all because rootfs is always mounted read-only except
for those in very early development stage. So quickest? I'm not so sure. As
for safest, I don't think leaving a obvious defect open counts. It's just
one of the many possible solutions.

We may also choose to ignore this bug and wait until all the devices switch
to systemd and Debian drops
"Make-net.ifnames-opt-in-instead-of-opt-out.patch". So far there is no
fatal symptom reported yet, but a changing device name can certainly affect
automation tools.

Martin Pitt (pitti) wrote :

For the record, we are going to switch to net.ifnames soon in wily and Debian. See bug 1454254 and https://lists.ubuntu.com/archives/ubuntu-devel/2015-May/038761.html

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

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