Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #186136 > unrolled thread

Inconsistent predictable interface names

Back to article view | Back to linux.debian.user

Contents

  Inconsistent predictable interface names Henning Follmann <hfollmann@itcfollmann.com> - 2017-08-29 17:10 +0200
    Re: Inconsistent predictable interface names Reco <recoverym4n@gmail.com> - 2017-08-29 18:50 +0200
      Re: Inconsistent predictable interface names Henning Follmann <hfollmann@itcfollmann.com> - 2017-08-29 19:10 +0200
        Re: Inconsistent predictable interface names Reco <recoverym4n@gmail.com> - 2017-08-29 19:30 +0200
          Re: Inconsistent predictable interface names Henning Follmann <hfollmann@itcfollmann.com> - 2017-08-30 14:20 +0200
          Re: Inconsistent predictable interface names Cindy-Sue Causey <butterflybytes@gmail.com> - 2017-08-30 14:50 +0200
            Re: Inconsistent predictable interface names Reco <recoverym4n@gmail.com> - 2017-08-30 15:20 +0200
              Re: Inconsistent predictable interface names Henning Follmann <hfollmann@itcfollmann.com> - 2017-08-30 17:10 +0200
                Re: Inconsistent predictable interface names David Wright <deblis@lionunicorn.co.uk> - 2017-08-30 18:50 +0200

#186136 — Inconsistent predictable interface names

Hello,
I am experiencing an odd issue with a new install of Stretch.
I do get the new predictable interface name for my ethernet (enp3s0).
However I still have the old name for the wireless network card (wlan0).
So I checked /etc/systemd/network if there is any .link file, there isn't.
Also grub is configured correctly ("quiet" being the only kernel
parameter).
Where else might I have to check and which program might be overwriting
this?

I disabled NM on this machine and systemd is managing all my network
configuration. However I doubt it has to do with systemd.

BTW it is an old macbook pro, but that also should make any difference.

-H 


-- 
Henning Follmann           | hfollmann@itcfollmann.com

[toc] | [next] | [standalone]

#186142

	Hi.

On Tue, Aug 29, 2017 at 11:01:35AM -0400, Henning Follmann wrote:
> Hello,
> I am experiencing an odd issue with a new install of Stretch.
> I do get the new predictable interface name for my ethernet (enp3s0).
> However I still have the old name for the wireless network card (wlan0).
> So I checked /etc/systemd/network if there is any .link file, there isn't.
> Also grub is configured correctly ("quiet" being the only kernel
> parameter).
> Where else might I have to check and which program might be overwriting
> this?

Please post the output of this (root is needed):

udevadm test /sys/class/net/wlan0

Reco

[toc] | [prev] | [next] | [standalone]

#186143

On Tue, Aug 29, 2017 at 07:45:41PM +0300, Reco wrote:
> 	Hi.
> 
> On Tue, Aug 29, 2017 at 11:01:35AM -0400, Henning Follmann wrote:
> > Hello,
> > I am experiencing an odd issue with a new install of Stretch.
> > I do get the new predictable interface name for my ethernet (enp3s0).
> > However I still have the old name for the wireless network card (wlan0).
> > So I checked /etc/systemd/network if there is any .link file, there isn't.
> > Also grub is configured correctly ("quiet" being the only kernel
> > parameter).
> > Where else might I have to check and which program might be overwriting
> > this?
> 
> Please post the output of this (root is needed):
> 
> udevadm test /sys/class/net/wlan0
> 
> Reco
> 


========================================================
This program is for debugging only, it does not run any program
specified by a RUN key. It may show incorrect results, because
some values may be different, or not available at a simulation run.

ACTION=add
DEVPATH=/devices/pci0000:00/0000:00:15.0/0000:02:00.0/ssb0:0/net/wlan0
DEVTYPE=wlan
ID_BUS=pci
ID_MM_CANDIDATE=1
ID_MODEL_FROM_DATABASE=BCM4322 802.11a/b/g/n Wireless LAN Controller (AirPort Extreme)
ID_MODEL_ID=0x432b
ID_NET_DRIVER=b43
ID_NET_LINK_FILE=/lib/systemd/network/99-default.link
ID_NET_NAME_MAC=wlxd8a25e8dabb1
ID_OUI_FROM_DATABASE=Apple, Inc.
ID_PATH=pci-0000:02:00.0
ID_PATH_TAG=pci-0000_02_00_0
ID_PCI_CLASS_FROM_DATABASE=Network controller
ID_PCI_SUBCLASS_FROM_DATABASE=Network controller
ID_VENDOR_FROM_DATABASE=Broadcom Limited
ID_VENDOR_ID=0x14e4
IFINDEX=3
INTERFACE=wlan0
SUBSYSTEM=net
SYSTEMD_ALIAS=/sys/subsystem/net/devices/wlan0
TAGS=:systemd:
USEC_INITIALIZED=16526604
run: 'ifupdown-hotplug'
run: '/lib/systemd/systemd-sysctl --prefix=/net/ipv4/conf/wlan0 --prefix=/net/ipv4/neigh/wlan0 --prefix=/net/ipv6/conf/wlan0 --prefix=/net/ipv6/neigh/wlan0'




-- 
Henning Follmann           | hfollmann@itcfollmann.com

[toc] | [prev] | [next] | [standalone]

#186145

	Hi.

On Tue, Aug 29, 2017 at 01:04:06PM -0400, Henning Follmann wrote:
> On Tue, Aug 29, 2017 at 07:45:41PM +0300, Reco wrote:
> > 	Hi.
> > 
> > On Tue, Aug 29, 2017 at 11:01:35AM -0400, Henning Follmann wrote:
> > > Hello,
> > > I am experiencing an odd issue with a new install of Stretch.
> > > I do get the new predictable interface name for my ethernet (enp3s0).
> > > However I still have the old name for the wireless network card (wlan0).
> > > So I checked /etc/systemd/network if there is any .link file, there isn't.
> > > Also grub is configured correctly ("quiet" being the only kernel
> > > parameter).
> > > Where else might I have to check and which program might be overwriting
> > > this?
> > 
> > Please post the output of this (root is needed):
> > 
> > udevadm test /sys/class/net/wlan0
> 
> ========================================================
> This program is for debugging only, it does not run any program
> specified by a RUN key. It may show incorrect results, because
> some values may be different, or not available at a simulation run.
> 
> ACTION=add
> DEVPATH=/devices/pci0000:00/0000:00:15.0/0000:02:00.0/ssb0:0/net/wlan0
> DEVTYPE=wlan
> ID_BUS=pci
> ID_MM_CANDIDATE=1
> ID_MODEL_FROM_DATABASE=BCM4322 802.11a/b/g/n Wireless LAN Controller (AirPort Extreme)
> ID_MODEL_ID=0x432b
> ID_NET_DRIVER=b43
> ID_NET_LINK_FILE=/lib/systemd/network/99-default.link
> ID_NET_NAME_MAC=wlxd8a25e8dabb1
> ID_OUI_FROM_DATABASE=Apple, Inc.
> ID_PATH=pci-0000:02:00.0
> ID_PATH_TAG=pci-0000_02_00_0
> ID_PCI_CLASS_FROM_DATABASE=Network controller
> ID_PCI_SUBCLASS_FROM_DATABASE=Network controller
> ID_VENDOR_FROM_DATABASE=Broadcom Limited
> ID_VENDOR_ID=0x14e4
> IFINDEX=3
> INTERFACE=wlan0
> SUBSYSTEM=net
> SYSTEMD_ALIAS=/sys/subsystem/net/devices/wlan0
> TAGS=:systemd:
> USEC_INITIALIZED=16526604
> run: 'ifupdown-hotplug'
> run: '/lib/systemd/systemd-sysctl --prefix=/net/ipv4/conf/wlan0 --prefix=/net/ipv4/neigh/wlan0 --prefix=/net/ipv6/conf/wlan0 --prefix=/net/ipv6/neigh/wlan0'

Hm. This particular output seems to lack 'trie on-disk' blurb that shows
exact udev configuration files that could influence its decision, but
that's pure cosmetic.
The main difference from the hardware I have access to is the lack of
ID_NET_NAME and ID_NET_NAME_PATH attributes.

Presumably that's because this particular class of PCI devices is not
recognised by net_id and net_setup_link udev builtins as a valid NIC.
It could be fixed in newer udev, or not.

Long story short - you've found a udev bug.

A good thing is - it has as easy workaround as creating a .link file
like this:

[Match]
MACAddress=d8:a2:5e:8d:ab:b1
[Link]
Name=enp2s0

Or whatever 'predictable' name you prefer. I believe that in your
conditions 'wlan0' is predictable enough ☺.

Reco

[toc] | [prev] | [next] | [standalone]

#186175

On Tue, Aug 29, 2017 at 08:29:05PM +0300, Reco wrote:



[...] 
> Long story short - you've found a udev bug.
> 

So should I file a bugreport?
Against the debian package or upstream?

> A good thing is - it has as easy workaround as creating a .link file
> like this:
> 
> [Match]
> MACAddress=d8:a2:5e:8d:ab:b1
> [Link]
> Name=enp2s0
> 
> Or whatever 'predictable' name you prefer. I believe that in your
> conditions 'wlan0' is predictable enough ☺.
> 

You are absolutely right. I wasn't too concerned to begin with I just
noticed the inconsistency.

I appreciate your help, thanks.

-H

-- 
Henning Follmann           | hfollmann@itcfollmann.com

[toc] | [prev] | [next] | [standalone]

#186179

On 8/29/17, Reco <recoverym4n@gmail.com> wrote:
>
> On Tue, Aug 29, 2017 at 01:04:06PM -0400, Henning Follmann wrote:
>> On Tue, Aug 29, 2017 at 07:45:41PM +0300, Reco wrote:
>> >
>> > On Tue, Aug 29, 2017 at 11:01:35AM -0400, Henning Follmann wrote:
>> > > Hello,
>> > > I am experiencing an odd issue with a new install of Stretch.
>> > > I do get the new predictable interface name for my ethernet (enp3s0).
>> > > However I still have the old name for the wireless network card
>> > > (wlan0).
>> > > So I checked /etc/systemd/network if there is any .link file, there
>> > > isn't.
>> > > Also grub is configured correctly ("quiet" being the only kernel
>> > > parameter).
>> > > Where else might I have to check and which program might be
>> > > overwriting
>> > > this?
>> >
>> > Please post the output of this (root is needed):
>> >
>> > udevadm test /sys/class/net/wlan0
>>
>> ========================================================
>> This program is for debugging only, it does not run any program
>> specified by a RUN key. It may show incorrect results, because
>> some values may be different, or not available at a simulation run.
>>
>> ACTION=add
>> DEVPATH=/devices/pci0000:00/0000:00:15.0/0000:02:00.0/ssb0:0/net/wlan0
>> DEVTYPE=wlan
>> ID_BUS=pci
>> ID_MM_CANDIDATE=1
>> ID_MODEL_FROM_DATABASE=BCM4322 802.11a/b/g/n Wireless LAN Controller
>> (AirPort Extreme)
>> ID_MODEL_ID=0x432b
>> ID_NET_DRIVER=b43
>> ID_NET_LINK_FILE=/lib/systemd/network/99-default.link
>> ID_NET_NAME_MAC=wlxd8a25e8dabb1
>> ID_OUI_FROM_DATABASE=Apple, Inc.
>> ID_PATH=pci-0000:02:00.0
>> ID_PATH_TAG=pci-0000_02_00_0
>> ID_PCI_CLASS_FROM_DATABASE=Network controller
>> ID_PCI_SUBCLASS_FROM_DATABASE=Network controller
>> ID_VENDOR_FROM_DATABASE=Broadcom Limited
>> ID_VENDOR_ID=0x14e4
>> IFINDEX=3
>> INTERFACE=wlan0
>> SUBSYSTEM=net
>> SYSTEMD_ALIAS=/sys/subsystem/net/devices/wlan0
>> TAGS=:systemd:
>> USEC_INITIALIZED=16526604
>> run: 'ifupdown-hotplug'
>> run: '/lib/systemd/systemd-sysctl --prefix=/net/ipv4/conf/wlan0
>> --prefix=/net/ipv4/neigh/wlan0 --prefix=/net/ipv6/conf/wlan0
>> --prefix=/net/ipv6/neigh/wlan0'
>
> Hm. This particular output seems to lack 'trie on-disk' blurb that shows
> exact udev configuration files that could influence its decision, but
> that's pure cosmetic.
> The main difference from the hardware I have access to is the lack of
> ID_NET_NAME and ID_NET_NAME_PATH attributes.
>
> Presumably that's because this particular class of PCI devices is not
> recognised by net_id and net_setup_link udev builtins as a valid NIC.
> It could be fixed in newer udev, or not.
>
> Long story short - you've found a udev bug.
>
> A good thing is - it has as easy workaround as creating a .link file
> like this:
>
> [Match]
> MACAddress=d8:a2:5e:8d:ab:b1
> [Link]
> Name=enp2s0
>
> Or whatever 'predictable' name you prefer. I believe that in your
> conditions 'wlan0' is predictable enough ☺.


I left everything in there in case somehow it already says "yes or
no". Is it possible that's previously declared somewhere, possibly
maybe in user configuration files that would carry over from upgrade
to upgrade? Maybe like something manually altered via a network
manager at some point... or something....? :)

Just thinking out loud... :)

Cindy :)
-- 
Cindy-Sue Causey
Talking Rock, Pickens County, Georgia, USA

* runs with duct tape *

[toc] | [prev] | [next] | [standalone]

#186181

	Hi.

On Wed, Aug 30, 2017 at 08:39:44AM -0400, Cindy-Sue Causey wrote:
> On 8/29/17, Reco <recoverym4n@gmail.com> wrote:
> >
> > On Tue, Aug 29, 2017 at 01:04:06PM -0400, Henning Follmann wrote:
> >> On Tue, Aug 29, 2017 at 07:45:41PM +0300, Reco wrote:
> >> >
> >> > On Tue, Aug 29, 2017 at 11:01:35AM -0400, Henning Follmann wrote:
> >> > > Hello,
> >> > > I am experiencing an odd issue with a new install of Stretch.
> >> > > I do get the new predictable interface name for my ethernet (enp3s0).
> >> > > However I still have the old name for the wireless network card
> >> > > (wlan0).
> >> > > So I checked /etc/systemd/network if there is any .link file, there
> >> > > isn't.
> >> > > Also grub is configured correctly ("quiet" being the only kernel
> >> > > parameter).
> >> > > Where else might I have to check and which program might be
> >> > > overwriting
> >> > > this?
> >> >
> >> > Please post the output of this (root is needed):
> >> >
> >> > udevadm test /sys/class/net/wlan0
> >>
> >> ========================================================
> >> This program is for debugging only, it does not run any program
> >> specified by a RUN key. It may show incorrect results, because
> >> some values may be different, or not available at a simulation run.
> >>
> >> ACTION=add
> >> DEVPATH=/devices/pci0000:00/0000:00:15.0/0000:02:00.0/ssb0:0/net/wlan0
> >> DEVTYPE=wlan
> >> ID_BUS=pci
> >> ID_MM_CANDIDATE=1
> >> ID_MODEL_FROM_DATABASE=BCM4322 802.11a/b/g/n Wireless LAN Controller
> >> (AirPort Extreme)
> >> ID_MODEL_ID=0x432b
> >> ID_NET_DRIVER=b43
> >> ID_NET_LINK_FILE=/lib/systemd/network/99-default.link
> >> ID_NET_NAME_MAC=wlxd8a25e8dabb1
> >> ID_OUI_FROM_DATABASE=Apple, Inc.
> >> ID_PATH=pci-0000:02:00.0
> >> ID_PATH_TAG=pci-0000_02_00_0
> >> ID_PCI_CLASS_FROM_DATABASE=Network controller
> >> ID_PCI_SUBCLASS_FROM_DATABASE=Network controller
> >> ID_VENDOR_FROM_DATABASE=Broadcom Limited
> >> ID_VENDOR_ID=0x14e4
> >> IFINDEX=3
> >> INTERFACE=wlan0
> >> SUBSYSTEM=net
> >> SYSTEMD_ALIAS=/sys/subsystem/net/devices/wlan0
> >> TAGS=:systemd:
> >> USEC_INITIALIZED=16526604
> >> run: 'ifupdown-hotplug'
> >> run: '/lib/systemd/systemd-sysctl --prefix=/net/ipv4/conf/wlan0
> >> --prefix=/net/ipv4/neigh/wlan0 --prefix=/net/ipv6/conf/wlan0
> >> --prefix=/net/ipv6/neigh/wlan0'
> >
> > Hm. This particular output seems to lack 'trie on-disk' blurb that shows
> > exact udev configuration files that could influence its decision, but
> > that's pure cosmetic.
> > The main difference from the hardware I have access to is the lack of
> > ID_NET_NAME and ID_NET_NAME_PATH attributes.
> >
> > Presumably that's because this particular class of PCI devices is not
> > recognised by net_id and net_setup_link udev builtins as a valid NIC.
> > It could be fixed in newer udev, or not.
> >
> > Long story short - you've found a udev bug.
> >
> > A good thing is - it has as easy workaround as creating a .link file
> > like this:
> >
> > [Match]
> > MACAddress=d8:a2:5e:8d:ab:b1
> > [Link]
> > Name=enp2s0
> >
> > Or whatever 'predictable' name you prefer. I believe that in your
> > conditions 'wlan0' is predictable enough ☺.
> 
> 
> I left everything in there in case somehow it already says "yes or
> no". Is it possible that's previously declared somewhere, possibly
> maybe in user configuration files that would carry over from upgrade
> to upgrade?

OP's e-mail says to this:

> > I am experiencing an odd issue with a new install of Stretch.

My e-mails assumed that there was no upgrade.
'udevadm info' should've shown such stray configuration files BTW, hence
'trie on-disk' remark.


> Maybe like something manually altered via a network
> manager at some point... or something....? :)

That's possible. Network Manager's ability to change MAC address of WLAN
(for AP scanning), or, say, machanger intervention can lead to funny
results if "Predictable" NIC Names are enabled. I haven't seen it
manifested in NIC renaming though.

It should not be possible in this case (all NICs are PCI devices) since
"Predictable" NIC Names should set by udev from initrd long before root
filesystem is mounted and things like Network Manager have a chance to
interfere.

Reco

[toc] | [prev] | [next] | [standalone]

#186191

On Wed, Aug 30, 2017 at 04:12:16PM +0300, Reco wrote:
> 	Hi.
> 
> On Wed, Aug 30, 2017 at 08:39:44AM -0400, Cindy-Sue Causey wrote:
> > On 8/29/17, Reco <recoverym4n@gmail.com> wrote:
> > 
> > 
[...]
> > I left everything in there in case somehow it already says "yes or
> > no". Is it possible that's previously declared somewhere, possibly
> > maybe in user configuration files that would carry over from upgrade
> > to upgrade?
> 
> OP's e-mail says to this:
> 
> > > I am experiencing an odd issue with a new install of Stretch.
> 
> My e-mails assumed that there was no upgrade.
> 'udevadm info' should've shown such stray configuration files BTW, hence
> 'trie on-disk' remark.
> 

Yep, this was a new install. Even though I tend to reuse old configurations
from previous installs, this very much happend with an untouched new
install (only deviation from a "default" was xfce instead of gnome).
I disabled the NM but at that time the names were already like they are
right now. 

BTW. all those "try on disk" were sent to stderr and I piped only the
stdout into my previous mail, that's why they were missing.


> 
> > Maybe like something manually altered via a network
> > manager at some point... or something....? :)
> 
> That's possible. Network Manager's ability to change MAC address of WLAN
> (for AP scanning), or, say, machanger intervention can lead to funny
> results if "Predictable" NIC Names are enabled. I haven't seen it
> manifested in NIC renaming though.
> 

That was my initial thought.


> It should not be possible in this case (all NICs are PCI devices) since
> "Predictable" NIC Names should set by udev from initrd long before root
> filesystem is mounted and things like Network Manager have a chance to
> interfere.
> 

Yes, and I see that in dmesg happening for eth0. However that does not
happen for the wlan0. I can see the firmware being loaded but no name
changing to predictable pattern.

FWIW

-H


-- 
Henning Follmann           | hfollmann@itcfollmann.com

[toc] | [prev] | [next] | [standalone]

#186196

On Wed 30 Aug 2017 at 11:01:07 (-0400), Henning Follmann wrote:
> On Wed, Aug 30, 2017 at 04:12:16PM +0300, Reco wrote:
> > 	Hi.
> > 
> > On Wed, Aug 30, 2017 at 08:39:44AM -0400, Cindy-Sue Causey wrote:
> > > On 8/29/17, Reco <recoverym4n@gmail.com> wrote:
> > > 
> > > 
> [...]
> > > I left everything in there in case somehow it already says "yes or
> > > no". Is it possible that's previously declared somewhere, possibly
> > > maybe in user configuration files that would carry over from upgrade
> > > to upgrade?
> > 
> > OP's e-mail says to this:
> > 
> > > > I am experiencing an odd issue with a new install of Stretch.
> > 
> > My e-mails assumed that there was no upgrade.
> > 'udevadm info' should've shown such stray configuration files BTW, hence
> > 'trie on-disk' remark.
> > 
> 
> Yep, this was a new install. Even though I tend to reuse old configurations
> from previous installs, this very much happend with an untouched new
> install (only deviation from a "default" was xfce instead of gnome).
> I disabled the NM but at that time the names were already like they are
> right now. 
> 
> BTW. all those "try on disk" were sent to stderr and I piped only the
> stdout into my previous mail, that's why they were missing.
> 
> 
> > 
> > > Maybe like something manually altered via a network
> > > manager at some point... or something....? :)
> > 
> > That's possible. Network Manager's ability to change MAC address of WLAN
> > (for AP scanning), or, say, machanger intervention can lead to funny
> > results if "Predictable" NIC Names are enabled. I haven't seen it
> > manifested in NIC renaming though.
> > 
> 
> That was my initial thought.
> 
> 
> > It should not be possible in this case (all NICs are PCI devices) since
> > "Predictable" NIC Names should set by udev from initrd long before root
> > filesystem is mounted and things like Network Manager have a chance to
> > interfere.
> > 
> 
> Yes, and I see that in dmesg happening for eth0. However that does not
> happen for the wlan0. I can see the firmware being loaded but no name
> changing to predictable pattern.

I see the name changes on these systems (a live stick and an
installation of stretch). What's odd is that the name of the
wireless interface is never reflected when its module is loaded
or reloaded; the first mention is always at the renaming moment.
This contrasts with the wired interface.

[    3.930811] r8169 0000:01:00.0 eth0: RTL8168g/8111g at […]
[    3.942793] r8169 0000:01:00.0 enp1s0: renamed from eth0
[   18.689852] iwlwifi 0000:02:00.0: firmware: direct-loading firmware iwlwifi-7260-17.ucode
[   18.691150] iwlwifi 0000:02:00.0: loaded firmware version 17.352738.0 op_mode iwlmvm
[   19.399207] iwlwifi 0000:02:00.0 wlp2s0: renamed from wlan0

[  111.424281] ipw2200: Intel(R) PRO/Wireless 2200/2915 Network Driver, […]
[  111.439912] tg3 0000:02:02.0 eth0: Tigon3 [partno(BCM95705A50) rev 3003] […]
[  111.443209] tg3 0000:02:02.0 enp2s2: renamed from eth0
[  134.994910] ipw2200 0000:02:04.0 wlp2s4: renamed from eth0

(selected lines only).

Cheers,
David.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web