Persistent interface names


#1

As a follow-on to another discussion, I’ve noticed that many times I power up my raspberry pi from a cold state (with a second wifi dongle connected). The assignments of wlan0, wlan1, …etc switch around (between the dongle and the built-in adapter). This is causing me a lot of coding to account for the potential of this changing.

Is there a way, in resin.io to for these to always come up the same?


#2

Udev might be an option for you… I’m using it (via the Python module) for detecting attached USB-TTY devices, then I interrogate them to figure out exactly what’s on the other end.


#3

Thanks, I have already worked out code to help detect what’s happened after boot. However, I’m trying to avoid that long term and was hoping for a way to persist the interface assignments on the host (so that a particular nic is always wlan0, …etc). Right now it’s semi-random. Sometimes after boot the onboard nic is wlan0 and the dongle is wlan1. Other times, that’s reversed.


#4

There’s a way to do that in more recent Linux distributions, not sure how this would work in the context of Resin… https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/
This is honestly the first time I’ve even considered that …ah, feature… of systemd to be useful. But then again, you’ll have different interface names across devices. But they’ll be consistently different across reboots, so that’s something :slight_smile:


#5

Yeah, it’s fine if they’re different across devices - just so long as they’re consistent between boots.

Now-a-days, this is actually almost a universal feature in most full-bodied linux distros (accomplishing it through one of several ways). It just usually goes unnoticed (as your typical linux system has a single network interface, or a lan link + wifi at most). Having a career in networking, I definitely notice :slight_smile: (having spend a good amount of time with systems running many interfaces).


Raspberry Pi 3 and additional network dongle
#6

I was a network dude in a past life, and I miss some of the more interesting (routing for survivability) challenges. I could have really benefitted from the systemd interface naming back then. Especially dealing with homegrown NIDS and SAN boxen. But now my day job has me dealing pretty much exclusively with single-interface cloud workloads. And not having an eth0 in that sort of environment is a real headache, especially in the rare case when I need to manage firewall rules for multiple interfaces.

I’m really interested to know if systemd works for your use case. You may have to mount in the dbus socket in order to do what you need to from inside the container.

Good luck!


#7

Fun stuff for sure! :slight_smile:

Yeah, no luck with dbus means of forcing persistence. I think the right (eventual) approach here will be to have this as part of the host. Probably just allowing the udev/rules 70-persist style setup on the host would take care of it. I’ll see if there’s a place I can make a feature request for this.


#8

if you can install lshw, then you can do:

INTERFACE="$(lshw -class network | awk ‘BEGIN {RS = “*”; FS="logical name: " } ; /usb/ { print $2 }’ | grep wlan)"
echo “Setting up interface $INTERFACE”