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

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

Question: eth0 vs enp1s0

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

Contents

  Question: eth0 vs enp1s0 Hans <hans.ullrich@loop.de> - 2015-12-29 19:40 +0100
    Re: Question: eth0 vs enp1s0 Felix Miata <mrmazda@earthlink.net> - 2015-12-29 19:50 +0100
    Re: Question: eth0 vs enp1s0 Brian <ad44@cityscape.co.uk> - 2015-12-29 20:20 +0100
      Re: Question: eth0 vs enp1s0 Hans <hans.ullrich@loop.de> - 2015-12-29 21:00 +0100
        Re: Question: eth0 vs enp1s0 Brian <ad44@cityscape.co.uk> - 2015-12-29 22:30 +0100
        Re: Question: eth0 vs enp1s0 Felix Miata <mrmazda@earthlink.net> - 2015-12-29 22:40 +0100
        Re: Question: eth0 vs enp1s0 Jörg-Volker Peetz <jvpeetz@web.de> - 2015-12-30 13:00 +0100
          Re: Question: eth0 vs enp1s0 Hans <hans.ullrich@loop.de> - 2015-12-30 15:40 +0100
            Re: Question: eth0 vs enp1s0 Chris Bannister <cbannister@slingshot.co.nz> - 2015-12-30 16:00 +0100
              Re: Question: eth0 vs enp1s0 Hans <hans.ullrich@loop.de> - 2015-12-30 16:20 +0100
          Re: Question: eth0 vs enp1s0 (second try) Hans <hans.ullrich@loop.de> - 2015-12-30 16:20 +0100
            Re: Question: eth0 vs enp1s0 (second try) Brian <ad44@cityscape.co.uk> - 2015-12-31 16:30 +0100
              Re: Question: eth0 vs enp1s0 (second try) Hans <hans.ullrich@loop.de> - 2015-12-31 19:10 +0100
                Re: Question: eth0 vs enp1s0 (second try) Brian <ad44@cityscape.co.uk> - 2016-01-01 13:10 +0100
                  Re: Question: eth0 vs enp1s0 (second try) Vincent Lefevre <vincent@vinc17.net> - 2016-01-01 17:30 +0100
                    Re: Question: eth0 vs enp1s0 (second try) Brian <ad44@cityscape.co.uk> - 2016-01-02 17:30 +0100
                      Re: Question: eth0 vs enp1s0 (second try) Vincent Lefevre <vincent@vinc17.net> - 2016-01-06 14:00 +0100
                        Re: Question: eth0 vs enp1s0 (second try) Brian <ad44@cityscape.co.uk> - 2016-01-06 15:00 +0100
                          Re: Question: eth0 vs enp1s0 (second try) Vincent Lefevre <vincent@vinc17.net> - 2016-01-07 03:00 +0100
                            Re: Question: eth0 vs enp1s0 (second try) Rick Thomas <rbthomas@pobox.com> - 2016-01-07 07:20 +0100
                              Re: Question: eth0 vs enp1s0 (second try) Vincent Lefevre <vincent@vinc17.net> - 2016-01-07 10:50 +0100
                                Re: Question: eth0 vs enp1s0 (second try) Brian <ad44@cityscape.co.uk> - 2016-01-07 14:20 +0100
                                  Re: Question: eth0 vs enp1s0 (second try) Brian <ad44@cityscape.co.uk> - 2016-01-07 19:50 +0100
                                    Re: Question: eth0 vs enp1s0 (second try) Vincent Lefevre <vincent@vinc17.net> - 2016-01-08 02:40 +0100
                                      Re: Question: eth0 vs enp1s0 (second try) Brian <ad44@cityscape.co.uk> - 2016-01-08 13:10 +0100
            MAC address and security (was: Question: eth0 vs enp1s0 (second try)) Vincent Lefevre <vincent@vinc17.net> - 2015-12-31 16:50 +0100
              Re: MAC address and security Christian Seiler <christian@iwakd.de> - 2015-12-31 23:20 +0100
    Re: Question: eth0 vs enp1s0 Charlie Kravetz <cjk@teamcharliesangels.com> - 2015-12-29 20:20 +0100
    Re: Question: eth0 vs enp1s0 Michael Biebl <biebl@debian.org> - 2015-12-31 22:20 +0100
      Re: Question: eth0 vs enp1s0 Hans <hans.ullrich@loop.de> - 2015-12-31 22:30 +0100
      Re: Question: eth0 vs enp1s0 Brian <ad44@cityscape.co.uk> - 2016-01-02 17:30 +0100

Page 2 of 2 — ← Prev page 1 [2]

#162757 — Re: Question: eth0 vs enp1s0 (second try)

On 2016-01-06 22:09:25 -0800, Rick Thomas wrote:
> On Jan 6, 2016, at 5:49 PM, Vincent Lefevre <vincent@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?

-- 
Vincent Lefèvre <vincent@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)

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

#162765 — Re: Question: eth0 vs enp1s0 (second try)

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 <vincent@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.

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

#162774 — Re: Question: eth0 vs enp1s0 (second try)

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

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

#162780 — Re: Question: eth0 vs enp1s0 (second try)

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.

-- 
Vincent Lefèvre <vincent@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)

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

#162794 — Re: Question: eth0 vs enp1s0 (second try)

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.

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

#162359 — MAC address and security (was: Question: eth0 vs enp1s0 (second try))

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 <vincent@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)

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

#162412 — Re: MAC address and security

[Multipart message — attachments visible in raw view] — view raw

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

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

#162194

On Tue, 29 Dec 2015 19:34:43 +0100
Hans <hans.ullrich@loop.de> wrote:

>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
>

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]

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

#162410

[Multipart message — attachments visible in raw view] — view raw

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?

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

#162411

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

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

#162473

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.

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web