Question: eth0 vs enp1s0

[Hans]

Hi folks,

just a question about network names, which I do not understand.

I have two different computers, both are installed with the same versions of
debian packages. But one of it has enp1s0 as network interface name( my EEEPC
1005HGO) , the other one the old eth0 scheme (my Aspire 7520G).

Both got 70-persistent-net-rules configured.

Now I can not understand, why one of them is using enp1s0. Who is deciding the
name? I read the documentations and the blogs, but I did not understand, why
both machines are different.

As I am not happy (at the moment) with the new naming, I added the if.names=0
to the grub commandline.

Would be nice, if someone could help me to understand.

Best regards and a happy new year.

Hans

[Felix Miata]

Hans composed on 2015-12-29 19:34 (UTC+0100):

> just a question about network names, which I do not understand.

> I have two different computers, both are installed with the same versions of
> debian packages. But one of it has enp1s0 as network interface name( my EEEPC
> 1005HGO) , the other one the old eth0 scheme (my Aspire 7520G).

Was exactly the same installation method/techique employed on both, or was
one say done via DVD and the other say via netboot?

> Both got 70-persistent-net-rules configured.

> Now I can not understand, why one of them is using enp1s0. Who is deciding the
> name? I read the documentations and the blogs, but I did not understand, why
> both machines are different.

> As I am not happy (at the moment) with the new naming, I added the if.names=0
> to the grub commandline.

> Would be nice, if someone could help me to understand.

Under the "modern" scheme, enp1s0 is the preferred or default, used if none
of the avoidance techniques listed at the bottom of
http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/
has been employed at installation/configuration time.
--
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)

Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata *** http://fm.no-ip.com/

[Brian]

On Tue 29 Dec 2015 at 19:34:43 +0100, Hans wrote:

> just a question about network names, which I do not understand.
>
> I have two different computers, both are installed with the same versions of
> debian packages. But one of it has enp1s0 as network interface name( my EEEPC
> 1005HGO) , the other one the old eth0 scheme (my Aspire 7520G).
>
> Both got 70-persistent-net-rules configured.
>
> Now I can not understand, why one of them is using enp1s0. Who is deciding the
> name? I read the documentations and the blogs, but I did not understand, why
> both machines are different.

Persistant name generation is enabled by default since udev 220-7 and
will be used on new installations or with new hardware. Existing
installations and hardware which get upgraded to udev 220-7 are covered
by the old 75-persistent-net-generator.rules and will keep their
interface names

[Charlie Kravetz]

It is supposed to simplify the naming scheme. It confuses me at this
time. An explanation of why they decided it needed changing is:
http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/

As to why two systems will have different names, as they get the bugs
ironed out, they add the changes to the installer.


--
Charlie Kravetz
Linux Registered User Number 425914
[http://linuxcounter.net/user/425914.html]
Never let anyone steal your DREAM. [http://keepingdreams.com]

[Hans]

Hi Brian, Felix and Charlie,

> Persistant name generation is enabled by default since udev 220-7 and
> will be used on new installations or with new hardware. Existing
> installations and hardware which get upgraded to udev 220-7 are covered
> by the old 75-persistent-net-generator.rules and will keep their
> interface names

thanks for the fast response. However, it does not explain, why both machines
are different.

Both machines were installed by DVD and both got the same settings and package
versions. Both machines were installed by the same DVD and then of course
upgraded by the internet. And both are running debian/testing.

The only thing, which IMO would explain it, that the EEEPC is newer than the
other one. But then the hardware must talk to the operation system and give
more information to udev or systemd. Does this do such things? There was
something mentioned in the doku, but I did not quite understand, what the doku
meant.

And if enps10 is the "new" kind of naming network devices, is it then
recommended to edit all configurations and change the entries from eth0 to
enp1s0?

This would also mean, I guess, either 70-persistent-net-rules must also be
edited or should be deleted.

But all this makes not clear to me, what makes the decision, when enp1s0 or
when eth0 is going to be created on a system at boot.

Thanks for reading.

Best

Hans

[Brian]

On Tue 29 Dec 2015 at 20:55:45 +0100, Hans wrote:

> Hi Brian, Felix and Charlie,
> > Persistant name generation is enabled by default since udev 220-7 and
> > will be used on new installations or with new hardware. Existing
> > installations and hardware which get upgraded to udev 220-7 are covered
> > by the old 75-persistent-net-generator.rules and will keep their
> > interface names
> thanks for the fast response. However, it does not explain, why both machines
> are different.
>
> Both machines were installed by DVD and both got the same settings and package
> versions. Both machines were installed by the same DVD and then of course
> upgraded by the internet. And both are running debian/testing.

Both machines started life with Jessie. Both were upgraded to Stretchh
My understanding is that on package upgrade *both* systems should have
kept the interface name they had under Jessie. One machine doesn't; I
have no explanation for that.

> The only thing, which IMO would explain it, that the EEEPC is newer than the
> other one. But then the hardware must talk to the operation system and give
> more information to udev or systemd. Does this do such things? There was
> something mentioned in the doku, but I did not quite understand, what the doku
> meant.

There is a README.Debian for udev which explains how the persistant name
generator works. It might help to track down the cause.

[Felix Miata]

Hans composed on 2015-12-29 20:55 (UTC+0100):

> and both got the same settings

What makes you sure of this?

...

> The only thing, which IMO would explain it, that the EEEPC is newer than the
> other one. But then the hardware must talk to the operation system and give
> more information to udev or systemd. Does this do such things?

Kernel and drivers probe, so, yes, information is given them. An important
point is that racing goes on, and hardware varies, so only 100% identical
equipment can produce 100% identical results, and only when the procedure is
invariant. What drivers and kernels do will vary with versions. Given the
same installation DVD, driver and kernel probably is not a factor in your
case, but hardware probably is given the different age of the machines.

> There was
> something mentioned in the doku, but I did not quite understand, what the doku
> meant.

I suggest you read it again, and if it doesn't become clear, ask specific
question(s) about what remains unclear.

> And if enps10 is the "new" kind of naming network devices, is it then
> recommended to edit all configurations and change the entries from eth0 to
> enp1s0?

What is recommended is that if you care about what device names are assigned
that you take an active role in the assignment process. Otherwise, let them
be whatever kernel and driver choose for them to be, and don't waste time
trying to figure out *why* they do what they do.

> This would also mean, I guess, either 70-persistent-net-rules must also be
> edited or should be deleted.

Again, it depends on your interest. It sounds like you care enough that you
should take an active role.

> But all this makes not clear to me, what makes the decision, when enp1s0 or
> when eth0 is going to be created on a system at boot.

I don't think it can ever be totally clear to anyone who deals with
non-identical hardware.

All my installations are created with net.ifnames=0 on installation kernel
cmdline, with fixed IP info on installation kernel cmdline, with the result
that eth0 is used for the wired ethernet interface. Post-installation I add
/etc/udev/rules.d/80-net-setup-link.rules to help ensure it stays as
initially configured through subsequent update and upgrade processes.

[Jörg-Volker Peetz]

Did you take a look at dmesg on both systems? Something like

grep -E '(enp|eth)' /var/log/dmesg

Could you show the content of both 70-persistent-net-rules files?

Regards,
jvp.

[Hans]

Am Mittwoch, 30. Dezember 2015, 12:58:23 schrieb Jörg-Volker Peetz:

Hi Jörg-Volker

> Did you take a look at dmesg on both systems? Something like

>

> grep -E '(enp|eth)' /var/log/dmesg

This showed no useful information. The only output is from my EEEPC below, the Aspire showed no output at all.

 

root@protheus7:/home/ullhan63# grep -E '(enp|eth)' /var/log/dmesg
[    8.480990] eeepc_laptop: Get control methods supported: 0xe301713
[   64.534486] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready

 

>

> Could you show the content of both 70-persistent-net-rules files?

 

Yes, this is Aspire with eth0:

# This file was automatically generated by the /lib/udev/write_net_rules
# program run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single line.

# PCI device 0x168c:0x001c (ath5k_pci)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",ATTR{address}=="00:1d:XX:XX:XX:XX", ATTR{type}=="1", KERNEL=="wlan*", NAME="wlan0"

# PCI device 0x10de:0x054c (forcedeth)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="1c:75:YY:YY:YY:YY", ATTR{type}=="1
", KERNEL=="eth*", NAME="eth0"

# Firewire device /sys/devices/pci0000:00/0000:00:08.0/0000:01:04.0/fw-host0/00023f0aba40084e (nod
emgr)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:02:3f:ZZ:ZZ:ZZ:ZZ", ATTR{dev
_id}=="0x0", ATTR{type}=="24", KERNEL=="eth*", NAME="eth1"

I changed the MAC cause of security purposes in this mail.

 

 

Same for EEEPC:

 

# This file was automatically generated by the /lib/udev/write_net_rules
# program, run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single
# line, and change only the value of the NAME= key.

# PCI device 0x1969:0x1062 (atl1c)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="90:e6:XX:XX:XX:XX", ATTR{dev_id}==
"0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

# PCI device 0x168c:0x002b (ath9k)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:25:YY:YY:YY:YY", ATTR{dev_id}==
"0x0", ATTR{type}=="1", KERNEL=="wlan*", NAME="wlan0"

Changed MAC, too, but you can of course still see the vendors (first two bytes).

> Regards,

> jvp.

 

 

Hope this helps a little bit. My solution at the moment is the well known addition "if.netnames=0" in grub commandline.

 

So I can easyly change from eth* to enp* when this is recommended.

 

Best regards

 

Hans

--

 

 

 

[Chris Bannister]

On Wed, Dec 30, 2015 at 03:32:04PM +0100, Hans wrote:
> Am Mittwoch, 30. Dezember 2015, 12:58:23 schrieb Jörg-Volker Peetz:
> Hi Jörg-Volker
> > Did you take a look at dmesg on both systems? Something like
> >
> > grep -E '(enp|eth)' /var/log/dmesg
> This showed no useful information. The only output is from my EEEPC
> below, the Aspire showed no output at all.
>
> root@protheus7:/home/ullhan63# grep -E '(enp|eth)' /var/log/dmesg
>
>
> >

> > Could you show the content of both 70-persistent-net-rules files?
>
> Yes, this is Aspire with eth0:
> # This file was automatically generated by the /lib/udev/write_net_rules
>

> I changed the MAC cause of security purposes in this mail.
>
>
> Same for EEEPC:
>
> # This file was automatically generated by the /lib/udev/write_net_rules
>

> Changed MAC, too, but you can of course still see the vendors (first two
> bytes).
>
> > Regards,
> > jvp.

Weird, nothing came through this end. You sure you pasted them?


--
"If you're not careful, the newspapers will have you hating the people
who are being oppressed, and loving the people who are doing the
oppressing." --- Malcolm X

[Hans]

My fault. I sent in HTML, but should be ascii.

> Weird, nothing came through this end. You sure you pasted them?

I sent the mail again, now in ASCII.
Please tell me, if it is not ok the second time.

Thank you

Hans

[Hans]

Am Mittwoch, 30. Dezember 2015, 12:58:23 schrieb Jörg-Volker Peetz:
Hi Jörg-Volker

> Did you take a look at dmesg on both systems? Something like
>
> grep -E '(enp|eth)' /var/log/dmesg

This showed no useful information. The only output is from my EEEPC below, the
Aspire showed no output at all.

root@protheus7:/home/ullhan63# grep -E '(enp|eth)' /var/log/dmesg
[ 8.480990] eeepc_laptop: Get control methods supported: 0xe301713
[ 64.534486] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready


>

> Could you show the content of both 70-persistent-net-rules files?

Yes, this is Aspire with eth0:
# This file was automatically generated by the /lib/udev/write_net_rules

# program run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single line.

# PCI device 0x168c:0x001c (ath5k_pci)
SUBSYSTEM=="net", ACTION=="add",
DRIVERS=="?*",ATTR{address}=="00:1d:XX:XX:XX:XX", ATTR{type}=="1",
KERNEL=="wlan*", NAME="wlan0"

# PCI device 0x10de:0x054c (forcedeth)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
ATTR{address}=="1c:75:YY:YY:YY:YY", ATTR{type}=="1
", KERNEL=="eth*", NAME="eth0"

# Firewire device /sys/devices/pci0000:00/0000:00:08.0/0000:01:04.0/fw-
host0/00023f0aba40084e (nod
emgr)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
ATTR{address}=="00:02:3f:ZZ:ZZ:ZZ:ZZ", ATTR{dev
_id}=="0x0", ATTR{type}=="24", KERNEL=="eth*", NAME="eth1"

I changed the MAC cause of security purposes in this mail.


Same for EEEPC:

# This file was automatically generated by the /lib/udev/write_net_rules

# program, run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single
# line, and change only the value of the NAME= key.

# PCI device 0x1969:0x1062 (atl1c)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
ATTR{address}=="90:e6:XX:XX:XX:XX", ATTR{dev_id}==
"0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

# PCI device 0x168c:0x002b (ath9k)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
ATTR{address}=="00:25:YY:YY:YY:YY", ATTR{dev_id}==
"0x0", ATTR{type}=="1", KERNEL=="wlan*", NAME="wlan0"

Changed MAC, too, but you can of course still see the vendors (first two
bytes).

> Regards,
> jvp.

[Brian]

On Wed 30 Dec 2015 at 16:11:39 +0100, Hans wrote:

> Am Mittwoch, 30. Dezember 2015, 12:58:23 schrieb Jörg-Volker Peetz:
> Hi Jörg-Volker
> > Did you take a look at dmesg on both systems? Something like
> >
> > grep -E '(enp|eth)' /var/log/dmesg
> This showed no useful information. The only output is from my EEEPC below, the
> Aspire showed no output at all.

Is there no sign of any discovered interfaces for the Aspire in the
output of dmesg?

> root@protheus7:/home/ullhan63# grep -E '(enp|eth)' /var/log/dmesg
> [ 8.480990] eeepc_laptop: Get control methods supported: 0xe301713
> [ 64.534486] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready

dmesg or journalctl have no indication that eth0 on the EEEPC is renamed?

[...]

> Hope this helps a little bit. My solution at the moment is the well known
> addition "if.netnames=0" in grub commandline.

I think you mean "net.ifnames=0".

What do 'ls /sys/class/net' and 'ip link' give without this addition?

[Vincent Lefevre]

On 2015-12-30 16:11:39 +0100, Hans wrote:
> I changed the MAC cause of security purposes in this mail.

FYI:

http://security.stackexchange.com/questions/67893/is-it-dangerous-to-post-my-mac-address-publicly

--
Vincent Lefèvre <vin...@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

[Hans]

Hi Brian,

> Is there no sign of any discovered interfaces for the Aspire in the
> output of dmesg?
>

I get this:

dmesg | grep eth0
[ 2.201866] forcedeth 0000:00:0a.0: ifname eth0, PHY OUI 0x732 @ 1, addr
1c:75:08:2c:84:f8
[ 36.198523] forcedeth 0000:00:0a.0 eth0: MSI enabled
[ 36.198795] forcedeth 0000:00:0a.0 eth0: no link during initialization
[ 36.199147] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[ 75.435837] forcedeth 0000:00:0a.0 eth0: link down

> dmesg or journalctl have no indication that eth0 on the EEEPC is renamed?
>
> [...]

> I think you mean "net.ifnames=0".
>

Yey, of course, it was just a typo. :)

> What do 'ls /sys/class/net' and 'ip link' give without this addition?

I get:

ls /sys/class/net/

enp1s0 Io wlan0


Brian, I believe, for now I will stay with the net.ifnames=0 solution. I
checjed, if I want to use enp1s0, I haved to edit a lot of configuration files
from eth0 to enp1s0. This is rather annoying, as any update of a package will
force me to that again and again.

As long the developers won't find a solution, which will fit both options, I
will stay at eth0. When debian changed completely to enp1s0 (and this includes
all the configurations, too), I can easyly remove the net.ifnames option and
return to enp1s0.

I believe, the different outrputs are just becaus the EEEPC is newer and got a
newer hardware and a more talking BIOS.

Thank you for all the help, the explanation is not as easy as I though, but
the solution is.

So let this problem be solved for now.

Thank you (and all the other friends who helped here) very much indeed.

I wish you and your family a very happy new year and much joy of hacking.

Thanks again, and best regards

Hans

[Michael Biebl]

Am 29.12.2015 um 19:34 schrieb Hans:
> Hi folks,
>
> just a question about network names, which I do not understand.
>
> I have two different computers, both are installed with the same versions of
> debian packages. But one of it has enp1s0 as network interface name( my EEEPC
> 1005HGO) , the other one the old eth0 scheme (my Aspire 7520G).
>
> Both got 70-persistent-net-rules configured.

udev is already run in the initramfs.
So for any changes that are made to 70-persistent-net.rules, you need to
rebuild your initramfs.

Maybe your initramfs contains an outdated udev rules file.
If you update the initramfs via update-initramfs -u, does that change
anything?

[Hans]

Am Donnerstag, 31. Dezember 2015, 22:14:49 schrieb Michael Biebl:
> Am 29.12.2015 um 19:34 schrieb Hans:

Hi Michael,

> Maybe your initramfs contains an outdated udev rules file.
> If you update the initramfs via update-initramfs -u, does that change
> anything?

No, I already tried this, but it made no difference.

Thanks for the response.

Best

Hans

[Christian Seiler]

On 12/31/2015 04:42 PM, Vincent Lefevre wrote:
> On 2015-12-30 16:11:39 +0100, Hans wrote:
>> I changed the MAC cause of security purposes in this mail.
>
> FYI:
>
> http://security.stackexchange.com/questions/67893/is-it-dangerous-to-post-my-mac-address-publicly

I disagree here: while I don't think it's the end of the world if a MAC
address is leaked, I do think it's better to not advertise it. For
example, on standard Debian installations the IPv6 privacy extensions
aren't activated, so the host part of the IPv6 address (the lower 64
bits) is built using the MAC address. It's bad enough that computers
can easily be reidentified via this method (even for remote services),
but it becomes worse if the MAC address can easily be associated with a
real name via search engines (when e.g. mailing list postings become
archived), you can then instantly track users at next to no additional
cost. (Sure, without something like Tor there are other ways of doing
the same even when using IPv6 privacy extensions, but they are much
more expensive to do.)

So I do think that it makes sense to keep MAC addresses private when
possible, because while it's possible to obtain it in some other way,
those are more difficult and one doesn't need to make it too easy for
people who want to track oneself.

(You shouldn't base authentication on MAC addresses, as was obviously
explained in the posting you linked, but that's separate issue.)

Off topic: I consider the change in RFC 4941 from RFC 3041 to turn the
privacy extensions off by default (which is what Linux does as it
implements the RFC correctly) to be idiotic: sure, having your outgoing
IPv6 address change dynamically might require application programmers
to be a bit more careful if they do in fact rely on the same address,
but even IPv4 addresses can change (e.g. in Germany DSL lines are
forced to reconnect every 24h for non-technical reasons); and most
applications don't require a constant outgoing IP (on non-link-local)
anyway, so when weighing the options of what the default should be, I
just don't get why the IETF disabled it - the privacy advantages far
outweigh the maybe 5 applications that now need to call setsockopt()
to tell the kernel that they do need the permanent address. And this is
not relevant to servers, which have a fixed IP address anyway. </rant>
(I'm of a mind to open a bug that Debian should use privacy extensions
by default anyway, regardless of what the RFC says, which Windows and
Mac OS X already do, btw.)

Regards,
Christian

[Brian]

On Thu 31 Dec 2015 at 19:08:18 +0100, Hans wrote:

> What do 'ls /sys/class/net' and 'ip link' give without this addition?
>
> I get:
>
> ls /sys/class/net/
>
> enp1s0 Io wlan0

Interesting. One interface is renamed; one is not (wlan0).

[Snip]

> I believe, the different outrputs are just becaus the EEEPC is newer and got a
> newer hardware and a more talking BIOS.

My understanding is that the information provided by the BIOS and PCI
slots is used by udev to produce the interface names. I'm not happy with
newness as an explanation.

> Thank you for all the help, the explanation is not as easy as I though, but
> the solution is.
>
> So let this problem be solved for now.

The view might be different if the machine had been remote and using
ifupdown's hardcoded interface names. 70-persistent-net-rules is
intended to ensure renaming doesn't happen. If it has that would be
quite a serious matter.

[Vincent Lefevre]

On 2016-01-01 12:03:32 +0000, Brian wrote:
> On Thu 31 Dec 2015 at 19:08:18 +0100, Hans wrote:
> > What do 'ls /sys/class/net' and 'ip link' give without this addition?
> >
> > I get:
> >
> > ls /sys/class/net/
> >
> > enp1s0 Io wlan0
>
> Interesting. One interface is renamed; one is not (wlan0).

On my laptop (installed from Jessie, then upgraded to unstable),
this is the opposite:

eth0 lo wlp61s0

Quite strange...

[Brian]

On Fri 01 Jan 2016 at 17:22:37 +0100, Vincent Lefevre wrote:

> On 2016-01-01 12:03:32 +0000, Brian wrote:
> > On Thu 31 Dec 2015 at 19:08:18 +0100, Hans wrote:
> > > What do 'ls /sys/class/net' and 'ip link' give without this addition?
> > >
> > > I get:
> > >
> > > ls /sys/class/net/
> > >
> > > enp1s0 Io wlan0
> >
> > Interesting. One interface is renamed; one is not (wlan0).
>
> On my laptop (installed from Jessie, then upgraded to unstable),
> this is the opposite:
>
> eth0 lo wlp61s0
>
> Quite strange...

Move 70-persistent-net.rules somewhere and do

rmmod -v <driver>

followed by

modprobe -v <driver>

Repeat with 70-persistent-net.rules returned to /etc/udev/rules.d. Any
changes in 'ls /sys/class/net/'?

[Brian]

On Thu 31 Dec 2015 at 22:14:49 +0100, Michael Biebl wrote:

> udev is already run in the initramfs.
> So for any changes that are made to 70-persistent-net.rules, you need to
> rebuild your initramfs.
>
> Maybe your initramfs contains an outdated udev rules file.
> If you update the initramfs via update-initramfs -u, does that change
> anything?

I'd suggest that this advice and 'update-initramfs -u' should be
included in the documentation if the user makes changes to
70-persistent-net.rules.

[Vincent Lefevre]

Well, I want to keep eth0 on my laptop because I have things
that depend on it. But what I was wondering is why I have
wlp61s0 instead of wlan0, i.e. why a rule for wlan0 hadn't
been added to 70-persistent-net.rules at that time.

[Brian]

On Wed 06 Jan 2016 at 13:56:57 +0100, Vincent Lefevre wrote:

> On 2016-01-02 16:21:11 +0000, Brian wrote:
> >
> > Move 70-persistent-net.rules somewhere and do
> >
> > rmmod -v <driver>
> >
> > followed by
> >
> > modprobe -v <driver>
> >
> > Repeat with 70-persistent-net.rules returned to /etc/udev/rules.d. Any
> > changes in 'ls /sys/class/net/'?
>
> Well, I want to keep eth0 on my laptop because I have things
> that depend on it. But what I was wondering is why I have
> wlp61s0 instead of wlan0, i.e. why a rule for wlan0 hadn't
> been added to 70-persistent-net.rules at that time.

Did the wireless interface name change using the above procedure?

Custom interface naming can be done with a file in /etc/udev/rules.d.
What is the content of yours? The udev README.Debian advises a prefix
between 75 and 80 for this file.

[Vincent Lefevre]

On 2016-01-06 13:55:45 +0000, Brian wrote:
> On Wed 06 Jan 2016 at 13:56:57 +0100, Vincent Lefevre wrote:
>
> > On 2016-01-02 16:21:11 +0000, Brian wrote:
> > >
> > > Move 70-persistent-net.rules somewhere and do
> > >
> > > rmmod -v <driver>
> > >
> > > followed by
> > >
> > > modprobe -v <driver>
> > >
> > > Repeat with 70-persistent-net.rules returned to /etc/udev/rules.d. Any
> > > changes in 'ls /sys/class/net/'?
> >
> > Well, I want to keep eth0 on my laptop because I have things
> > that depend on it. But what I was wondering is why I have
> > wlp61s0 instead of wlan0, i.e. why a rule for wlan0 hadn't
> > been added to 70-persistent-net.rules at that time.
>
> Did the wireless interface name change using the above procedure?

After moving 70-persistent-net.rules:

# rmmod -v iwlmvm
# rmmod -v iwlwifi
# rmmod -v e1000e
# ls /sys/class/net/
lo
# modprobe -v e1000e
insmod /lib/modules/4.3.0-1-amd64/kernel/drivers/net/ethernet/intel/e1000e/e1000e.ko
# modprobe -v iwlwifi
insmod /lib/modules/4.3.0-1-amd64/kernel/drivers/net/wireless/iwlwifi/iwlwifi.ko
# ls /sys/class/net/
enp0s25 lo wlp61s0

And repeating the procedure with 70-persistent-net.rules:

[...]
# ls /sys/class/net/
eth0 lo wlp61s0

BTW, after doing that, I had to kill the DHCP client manually because when
the eth0 interface became up again, it didn't get an IPv4 address.

> Custom interface naming can be done with a file in /etc/udev/rules.d.
> What is the content of yours? The udev README.Debian advises a prefix
> between 75 and 80 for this file.

70-persistent-net.rules contains:

SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="30:8d:99:25:ad:3f", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

Still the same question: why eth0 only?

[Rick Thomas]

On Jan 6, 2016, at 5:49 PM, Vincent Lefevre <vin...@vinc17.net> wrote:

> 70-persistent-net.rules contains:
>
> SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="30:8d:99:25:ad:3f", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
>
> Still the same question: why eth0 only?

Because the ethernet interface is the only one mentioned in 70-persistent-net.rules. If you want to specify a name for the wifi interface, you have to put something in to do it.

HTH!
Rick

[Vincent Lefevre]

On 2016-01-06 22:09:25 -0800, Rick Thomas wrote:
> On Jan 6, 2016, at 5:49 PM, Vincent Lefevre <vin...@vinc17.net> wrote:
>
> > 70-persistent-net.rules contains:
> >
> > SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="30:8d:99:25:ad:3f", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
> >
> > Still the same question: why eth0 only?
>
> Because the ethernet interface is the only one mentioned in 70-persistent-net.rules.

But my question is: Why is the ethernet interface the only one
mentioned in 70-persistent-net.rules?

[Brian]

On Thu 07 Jan 2016 at 10:45:20 +0100, Vincent Lefevre wrote:

> On 2016-01-06 22:09:25 -0800, Rick Thomas wrote:
> > On Jan 6, 2016, at 5:49 PM, Vincent Lefevre <vin...@vinc17.net> wrote:
> >
> > > 70-persistent-net.rules contains:
> > >
> > > SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="30:8d:99:25:ad:3f", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
> > >
> > > Still the same question: why eth0 only?
> >
> > Because the ethernet interface is the only one mentioned in 70-persistent-net.rules.
>
> But my question is: Why is the ethernet interface the only one
> mentioned in 70-persistent-net.rules?

Pass. 70-persistent-net.rules was generated on Jessie and carried over
to testing. You would need a Jessie install on the same machine to
investigate.

[Brian]

On Thu 07 Jan 2016 at 13:12:59 +0000, Brian wrote:

> Pass. 70-persistent-net.rules was generated on Jessie and carried over
> to testing. You would need a Jessie install on the same machine to
> investigate.

Perhaps not; one theory could be tested on Stretch.

Many WiFi devices require firmware. Some of those devices will not have
an interface registered (they are not initialised) if the firmware is
not present to be loaded into the device. Other devices get an interface
whether the firmware is present or not. If there is no interface there
is nothing for the Jessie udev to put in 70-persistent-net.rules.

Which type do you have?

Move the wireless device's firmware out of /lib/firmware. Then

modprobe -r -v <wireless_module>

ls /sys/class/net

modprobe -v <wireless_module>

ls /sys/class/net

[Vincent Lefevre]

On 2016-01-07 18:47:48 +0000, Brian wrote:
> Many WiFi devices require firmware. Some of those devices will not have
> an interface registered (they are not initialised) if the firmware is
> not present to be loaded into the device. Other devices get an interface
> whether the firmware is present or not.

According to lshw, the firmware is 16.242414.0, which is provided
by /lib/firmware/iwlwifi-3160-16.ucode from the firmware-iwlwifi
package.

> If there is no interface there is nothing for the Jessie udev to put
> in 70-persistent-net.rules.

According to the dpkg logs, udev was upgraded to 220-7 before I
installed firmware-iwlwifi. But according to the udev changelog,
the switch to net.ifnames is just for new installations and for
new hardware. Here the hardware was already there; there was just
no firmware.

[Brian]

On Fri 08 Jan 2016 at 02:36:20 +0100, Vincent Lefevre wrote:

> On 2016-01-07 18:47:48 +0000, Brian wrote:
> > Many WiFi devices require firmware. Some of those devices will not have
> > an interface registered (they are not initialised) if the firmware is
> > not present to be loaded into the device. Other devices get an interface
> > whether the firmware is present or not.
>
> According to lshw, the firmware is 16.242414.0, which is provided
> by /lib/firmware/iwlwifi-3160-16.ucode from the firmware-iwlwifi
> package.
>
> > If there is no interface there is nothing for the Jessie udev to put
> > in 70-persistent-net.rules.
>
> According to the dpkg logs, udev was upgraded to 220-7 before I
> installed firmware-iwlwifi. But according to the udev changelog,
> the switch to net.ifnames is just for new installations and for
> new hardware. Here the hardware was already there; there was just
> no firmware.

The ethernet interface is the only one mentioned in the .rules file
because there was no wlan0 interface due to a lack of firmware on
Jessie. eth0 is not renamed on upgrade to unstable because there is
a rule for it. There is no rule for wlan0 so it gets a predictable
name. You can change to a custom name by devising a rule for the
interface; udev will not generate one for you.

The switch to net.ifnames has honoured what was on the previous
installation.