Re: New nomeclature of ethernet devices
On Tue 25 Jun 2019 at 19:51:53 (-0400), The Wanderer wrote:
> On 2019-06-25 at 09:28, Michael Stone wrote:
> > On Tue, Jun 25, 2019 at 08:46:28AM -0400, The Wanderer wrote:
> >> On 2019-06-25 at 08:11, Michael Stone wrote:
>
> >>> It isn't because: 1) the new names are predictable but not
> >>> constant, so you can't configure a single default across all
> >>> systems
> >>
> >> Which seems reasonable to describe as "unpredictable".
> >
> > They're perfectly predictable for a given system.
>
> And reasonably unpredictable between systems.
I think you should understand that "predictable" means capable of
being predicted. It doesn't mean you necessarily have the information
at hand to make that prediction. Someone who works on PC buses would
be in a better position.
My zodiac sign is predictable, depending only on my birthday. But
you can't tell me which.
> Just reiterating the case where they *are* predictable misses my point
> so badly that it almost seems as if it must be intentional.
>
> > The old names also weren't constant, but people didn't seem to care
> > as much about the nuances because "that's the way it's always been".
> > (Sometimes it was an eth, sometimes it was a wlan, etc.) Why were
> > those differences ok but these differences aren't? Familiarity.
>
> No, not just familiarity.
>
> To the best of my awareness, the old names were 100% constant, as long
> as you had no more than one interface *of a given type*.
By "type" I take it you mean ethernet or whatever. Well, no, if you
added a faster card, or one in a more "privileged slot", it would
grab eth0 at the next boot, and your old one would become eth1.
That's in the distant past.
In more recent times, the new one would become eth(N+1). But here the
problem was that each new card you added would itself become eth(N+2),
eth(N+3) etc, even if you were removing the old ones. That's because
udev was busy populating /etc/udev/rules.d/70-persistent-net.rules
with all the MACs it had ever caught sight of.
> And because you have to deal differently with interfaces of different
> types (wireless interfaces need different userspace software from what
> you need for wired ones), naming them differently - but still
> predictably, in the same sense as before wireless interfaces ever
> existed - was useful, because it let you easily distinguish which ones
> needed which type of handling.
That's just not true. Here's a PC with a ethernet and wireless
interfaces running jessie:
2: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 00:0e:35:3f:68:7c brd ff:ff:ff:ff:ff:ff
inet 192.168.1.10/24 brd 192.168.1.255 scope global eth1
valid_lft forever preferred_lft forever
inet6 fe80::20e:35ff:fe3f:687c/64 scope link
valid_lft forever preferred_lft forever
3: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000
link/ether 00:c0:9f:44:15:b5 brd ff:ff:ff:ff:ff:ff
> With the new names, the fact that two interfaces get different name
> prefixes (etc.) tells you basically nothing useful about how to handle
> them; it just exposes underlying hardware details of some kind, which
> you don't actually need to know in order to make effective use of those
> interfaces.
Eh? Here's the same PC running stretch's netboot installer:
3: wlp2s4: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:0e:35:3f:68:7c brd ff:ff:ff:ff:ff:ff
4: enp2s2: <BROADCAST,MULTICAST> mtu 1500 qdisc mq qlen 1000
link/ether 00:c0:9f:44:15:b5 brd ff:ff:ff:ff:ff:ff
I'm guessing it's the p2s4 stuff that offends you. But the point is
that to know what the interface is called, you should ask the system,
not just make it up in some "traditional" manner.
> >> On a single computer with any number of interfaces of any type, the
> >> new names are 100% predictable from one boot to the next. (At least
> >> assuming you don't change which slot a given network device is
> >> connected to; IIRC that can change the assigned name, in at least
> >> some cases.)
> >
> > That does change the name, that's the entire point.
>
> With no real benefit as far as I can tell, but yes.
Well, the obvious one is that you can label the slots at the back if
you have several cables to plug in. Not something many of us do, but
now it's possible for those that want it, as opposed to impossible
(or very risky).
> It's also rare even on servers, much less on end-user systems (which
> tend to have the network device hardwired into the motherboard, as often
> as not). I only included that line for completism's sake - and
> apparently it even misses a few cases where things can change even
> without doing that, at least one of which I hadn't even considered.
I'm still running one PC with just a NIC (Seattle 2 mobo). I'm sure
I'm not alone. That's one of the virtues of linux: prolonging the
useful life of aging hardware.
> >> Computers with multiple interfaces of the same type are, AFAIK
> >> always have been, and IMO are likely to always be, much less common
> >> than computers with at most one interface of a given type.
> >
> > They're also the only computers where the name actually matters. In
> > the simple case it's set at install time and doesn't change, so it
> > could be completely random and it wouldn't make a difference.
>
> It matters if you're giving someone directions, with the computer sight
> unseen.
>
> Before, you could write directions - or even a script - which just
> referenced 'eth0' and/or 'wlan0', and hand the result out Internet-wide,
> with assurance that it would work reliably for the large majority of people.
And when it didn't: confusion and the back-and-forth so often seen on
this list.
> Now, you have to do something to detect the interface(s) and choose the
> right one.
Yes, ip a. Difficult, eh?
> >>> They are tremendously helpful if you build servers with multiple
> >>> interfaces, or you ever have to swap out a broken nic. If you
> >>> have a simple system it gets set once at install time, so who
> >>> cares?
> >>
> >> Among possibly other things: anyone who has to work with multiple
> >> systems with different hardware configurations, which have at most
> >> one interface of each type.
> >>
> >> Imagine carrying around a live-CD type of environment, for
> >> rescue-boot or maintenance-boot purposes, to use on end-user
> >> computers. I work in exactly that situation, and adapting - both
> >> scripts, and tech habits / expectations / etc. - to the way network
> >> interface names now vary between machines has been quite a pain.
> >
> > ifquery --list | grep -v lo
>
> And what about when you only want the wired interface, or only the
> wireless one, but the machine might have one of each type?
See the example above.
> (Plus, I'm pretty sure the environment I work with doesn't have ifquery;
> it has ifconfig, but not necessarily much beyond that. The older
> versions didn't even have a DHCP client more sophisticated than dhcpcd.
> I can add tools to it, but that becomes a pain to maintain, for the same
> reasons as adding 'net.ifnames=0' to the kernel command line would be.)
You're unlikely to have ifconfig and not ip. (And ifconfig has the
well-known gotcha: you need to type its path.)
> > If there's more than one result, it was going to be hard "the old
> > way" also. More portably, something like
>
> Why?
>
> Just using 'eth0' blindly wasn't hard at all, and since we're dealing
> with single-user workstations which will never have more than one wired
> and one wireless interface, it was a safe assumption to rely on.
See the example above. Again.
> > ip -o l | awk '{sub(/:/, "", $2); if ($2 != "lo") print $2}'
> >
> > or
> >
> > ip -o l | awk '{sub(/:/, "", $2); if ($2 != "lo") {print $2; exit 0}}'
> >
> > if you just want the first interface
>
> I want the first (only) *wired* interface. Do the new names even
> distinguish between the types? (I haven't paid them enough close
> attention to have the necessary awareness of what names result in order
> to be able to answer that question with any confidence.)
Wait a minute—you haven't paid attention to the new names yet you're
already arguing here that they shouldn't be the default?
Cheers,
David.
Reply to: