Call for opinions: default naming policy for USB network interfaces: MAC/path/kernel?

Fri Apr 8 15:41:09 UTC 2016

On czw, 2016-04-07 at 18:33 +0200, Martin Pitt wrote:
> Hello Steve,
> 
> thanks for your thoughts!
> 
> Steve Langasek [2016-04-06 14:47 -0700]:
> > 
> > Hi Martin,
> > 
> > $.02:
> > 
> > On Wed, Apr 06, 2016 at 12:56:44PM +0200, Martin Pitt wrote:
> > > 
> > > However, as there were some complaints [2][3] about location-
> > > based
> > > names not being appropriate for USB devices, we currently use the
> > > MAC
> > > address for those. I. e. they are named like "enx123456AABBCC".
> > > 
> > > After having seen this in practice for a while, I wonder whether
> > > that
> > > was actually the right decision. There's the stylistic issue of
> > > these
> > > names being very long, but if you configure ifupdown or your
> > > firewall
> > > etc. with those, you only need to copy&paste it exactly once. The
> > > more
> > > important question is whether treating them as "device identity"
> > > as
> > > oppposed to "where do I connect it" is actually the right
> > > default.
> > > 
> > > These are the options with pros (+) and cons (-):
> > > 
> > >  * MAC based (status quo): Emphasize the identity of the device
> > > that
> > >    you connect
> > >    + Works well on PCs/laptops where you want to connect your
> > > phone or
> > >      USB 3G stick on an arbitrary USB slot.
> > > 
> > >    - With boards like the RasPi you usually think in terms of
> > >      location: The left port is for the external USB ethernet
> > > card,
> > >      the right port for something else.
> > > 
> > >    - You can't just take a pre-configured image and install it on
> > > a
> > >      bunch of RasPis, as the configuration depends on the
> > > particular
> > >      USB ethernet dongle that you plug in, so the names will be
> > >      different on every deployed device, you can't keep a r/o
> > >      image, and you need to adjust the configuration everywhere.
> > Well, you can use such a preconfigured image; but we achieve this
> > by having
> > first-boot code that takes the information about the network
> > interface
> > mappings and writes it to the writable config space of the device
> > (via
> > /etc/network/interfaces.d).
> Right, so this assumes having a writable /etc (which is another -,
> and
> we spend some significant efforts on getting r/o images), but you can
> have a first-boot config item indeed. You can also ship some custom
> config to switch to a different policy.
> 
> I. e. the point is not that having this default policy makes it
> impossible to use pre-configured images, just that it takes some
> extra
> effort.
> 
> > 
> > *If* we rule out using either location-based or kernel default
> > names for USB
> > devices, would it make sense to go back to
> > /etc/udev/rules.d/70-persistent-net.rules for this case?
> This would combine the unpredictable (because timing-dependent)
> naming
> with the need for having to have write access to /etc. So, it's
> certainly technically feasible to bring back the generator for this,
> but I don't see much advantage in doing that other than avoiding the
> long names.
> 
> > 
> > (With appropriate fixes to the choice of names to eliminate the
> > previous race conditions)
> Yeah, that part is not a problem, they could be called "enusbN".
> 
> > 
> > If you have to write some per-device config data about the network
> > card, why not have that be a network device name mapping, so that
> > everything higher up the stack can use it consistently - and give
> > us
> > pretty names in the process?
> I'm afraid I don't understand the "if" here. With
> persistent-net-generator we of course do need to write the
> dynamically
> created .rules, and that'd be a network device naming. But I thought
> we were heading into the "read-only"/"reproducible" direction, so
> this
> kind of random network naming doesn't really help there.

Hey

I have a feeling that this is something we could handle with snappy
interfaces. We don't have hook support which could let it enumerate and
manage network interfaces but if we did. Could snappy itself manage
naming of network interfaces?

For some context, we already have code that can create udev rules based
on e.g. slots on the OS snap. We could add a snappy interface type
"network-adapter" and let a hook enumerate (and name) adapters and put
them on the OS snap. The same (I realize this is confusing) snappy
interface would have some code that would create appropriate udev rules
to name it in some way.

I realize this doesn't solve the naming problem but:
 - it would put the whole state handling under snappy
 - it would work out of the box in $some way
   - while letting each gadget snap tweak this for nice experience
 - it would let users rename this (later)

What do you guys think?

> 
> > 
> > I think you also left off "long and ugly names" as a - for this
> > option.
> Right (I mentioned it above, but not in the list), thanks.
> 
> > 
> > On that point, it occurs to me that we aren't using the MAC address
> > in the interface name because we want to expose the MAC address to
> > the user, but only because we want something predictable and
> > collision-free.  Therefore there's no actual reason that the MAC
> > address has to be represented as a long hex string.  What about a
> > base64 representation?  That would give you 8 characters instead of
> > 12 to represent the MAC address.
> IMHO that's still not significantly smaller enough to be able to
> memorize it, so it's copy&paste in either case. But then you have a
> number/name which doesn't match anything the user can see in NM
> config
> or "ip a", while the MAC address is often even printed on a device
> label. Plus, it'd be a downstream specific patch and introduce yet
> another type of policy, so all around I think it'd be too high
> cost/low benefit.
> 
> > 
> > Or, how good is the support for unicode in interface names? A
> > "base256" encoding using extended Latin characters as its charset
> > would only require 6 characters to represent a MAC address.
> > 
> > But OK, that's unfriendly to anyone who doesn't have access to
> > those
> > characters on their keyboard for input; and very unfriendly to
> > anyone using a non-UTF8 CJK locale.
> I think we'd get some really angry messages from people who have to
> type it on a keyboard which doesn't happen to have keys for ¶, þ,
> non-breaking space or form-feed ☺ (in other words, pretty much
> everyone in the world)
> 
> > 
> > On non-desktop systems (server and IoT), it's more of a problem for
> > the
> > interface name to change, for all the usual reasons.  These devices
> > also
> > tend to have their network interfaces provisioned much more
> > statically,
> > whether or not they're USB.
> Right, definitively for IoT. For the more "classic" server world USB
> network interfaces are fairly rare, and for cloud it's of course not
> an issue at all.
> 
> > 
> > However, while that may be true for any individual device, it's
> > less true
> > that *all* devices are going to have their USB NIC configured with
> > the same
> > topology.  Even within a single class of device, people may
> > individually
> > hook USB NICs up to different ports; but across *all* devices that
> > we would
> > expect to work out of the box with a common rootfs, it's absolutely
> > certain
> > that there's no single location-based interface name that will be
> > correct
> > for all systems.  So it doesn't appear that this option gets us
> > away from
> > the requirement for storing state at first boot.
> Right, that's the core of the question -- do we have more scenarios
> which work better with location or with device identity. So for this
> particular scenario it's a guarantee that device names by identity
> (i.
> e. MAC based) differ between different devices -- while it's merely
> likely that names differ with location-based naming, but
> significantly
> likely to be preferrable.
> 
> But as I said this is the point where there's no objective data any
> more, and also why this keeps coming up..
> 
> > 
> > 
> > > 
> > >  * Keep the kernel name (like eth0) for USB devices
> > >    * I. e. this requires you to manually configure names IF you
> > > need
> > >      to refer to the names in config files (ifupdown, firewall)
> > > AND
> > >      you need multiple USB network devices simultaneously.
> > AIUI this option means users with multiple USB interfaces may see
> > their
> > device names flip back and forth across boots, due to the lack of
> > stable
> > enumeration of USB.
> Correct, as per the "*" point above. I brought it up mostly because
> the common case is to only have (at most) one USB device, and saying
> "if you need multiple devices with known names you have to set them
> up
> yourself according to what *you* need" is at least consistent and
> plausible (but of course not necessarily better than using some
> ifname
> schema).
> 
> > 
> > That seems like it incorporates the downsides of both of the other
> > options.
> > We're definitely not solving the need for on-disk state to make
> > interface
> > names persistent in the general case, so I don't think it's any
> > more elegant
> > than what we have currently *except* that the name is less ugly.
> Yeah, I agree. As you always have the option to name things yourself,
> the location-based names would be a better default. I just wanted to
> be complete in showing and comparing all the options that we have.
> 
> > 
> > And since this option can't be directly coupled with persistent-
> > net.rules
> > (because kernel names vs. races),
> FTR, the kernel name racing is only if you rename them to ethN; so if
> we would bring back the persistent-net-generator for enusbN or usbN
> or
> so, there would be no race.
> 
> > 
> > I think if we *don't* want either location or MAC based rules, we
> > should instead go with some other simple first-come-first-serve
> > naming scheme that doesn't collide with kernel names and which
> > *optionally* uses persistent-net.rules if writable.
> If 70-persistent-net.rules (or any other custom rules exist), this
> will always win anyway, and our default policy doesn't matter. But
> using 70-persistent-net.rules would get us back to a state of
> un-predictability, you merely have stability (plus the added
> necessity
> to keep having to write /etc/udev/rules.d/). So I actually feel this
> is the worst option.
> 
> But you are right in the sense that this should be a fourth option in
> the list.
> 
> Thanks,
> 
> Martin
> -- 
> snappy-devel mailing list
> snappy-devel at lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/l
> istinfo/snappy-devel