Present Location: News >> Blog

Blog

> VirtualBox Host-Only Networking
Posted by prox, from Seattle, on August 19, 2017 at 11:39 local (server) time

For about two weeks, I've been trying to troubleshoot some odd host-only networking issues with VirtualBox.  It turned out to be a configuration-related bug in a file marked DO NOT EDIT THIS FILE, which, of course, I ultimately had to edit.

I previously had two VirtualBox VMs, dax (FreeBSD) and adria (Linux) connected together using intnet networking.  The setup worked, but I wanted to convert the adria VM to an LXC instance since I didn't actually need full VM emulation.  I spun up the LXC with the following in its configuration file:

# Networking
lxc.network.type = veth
lxc.network.name = eth0
lxc.network.link = lxcbr0
lxc.network.hwaddr = 00:02:bc:56:cc:99

Then, I put the following in /etc/network/interfaces on the host:

# lxcbr0: bridges vboxnet1/vtnet2 on dax to adria
# This cannot be auto because vboxnet1 does not exist on boot
#auto lxcbr0
iface lxcbr0 inet manual
        bridge_ports vboxnet1
        bridge_fd 0
        bridge_maxwait 0

Since VirtualBox's bridging doesn't play nice directly with LXC veth interfaces (explained here), I decided to convert dax's interface to host-only networking (vboxnet1) and use Linux's native bridging on the host to connect the VM and LXC.  I ended up with the following:

(excalibur:14:09:EDT)% ifconfig vboxnet1
vboxnet1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.57.1  netmask 255.255.255.0  broadcast 192.168.57.255
        ether 0a:00:27:00:00:01  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 13  overruns 0  frame 0
        TX packets 19796  bytes 29052799 (27.7 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

(excalibur:14:09:EDT)% ifconfig vethGEVFJP
vethGEVFJP: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet6 fe80::fca5:45ff:fee5:ecb2  prefixlen 64  scopeid 0x20<link>
        ether fe:a5:45:e5:ec:b2  txqueuelen 1000  (Ethernet)
        RX packets 15215  bytes 1209437 (1.1 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 19678  bytes 29042119 (27.6 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

(excalibur:14:09:EDT)% brctl show         
bridge name	bridge id		STP enabled	interfaces
lxcbr0		8000.0a0027000001	no		vboxnet1
							vethGEVFJP
(excalibur:14:09:EDT)% sudo lxc-ls -f     
NAME  STATE   AUTOSTART GROUPS IPV4       IPV6                               
adria RUNNING 0         -      10.3.7.217 2620:6:2000:12e:202:bcff:fe56:cc99 
(excalibur:14:10:EDT)% 

Looks good, right?  Wrong.  Connectivity worked, but only in one direction, and it seemed to be stopping on vboxnet1.  After lots of tcpdumps, I figured out the following.

LXC ---> VM  (GOOD)
VM  ---> LXC (DROPPED)

More specifically:

LXC -- vethGEVFJP --> lxcbr0 -- vboxnet1   --> VM  (GOOD)
VM  -- vboxnet1   --> lxcbr0 -- vethGEVFJP --> LXC (DROPPED)
     |
     |---- DROPPED HERE

Here are all of the things I tried, but none worked:

It seemed that the problem was on the VirtualBox side between vboxnet1 and the actual VM (vtnet2 on FreeBSD).  This was odd, because I also have vboxnet0 connected to the host and the configuration is identical:

(excalibur:14:18:EDT)% VBoxManage showvminfo dax|grep NIC|head -n3
NIC 1:           MAC: 0002BC56CB39, Attachment: Bridged Interface 'eth0', Cable connected: on,\
Trace: off (file: none), Type: virtio, Reported speed: 0 Mbps,\
Boot priority: 0, Promisc Policy: allow-all, Bandwidth group: none
NIC 2:           MAC: 0002BC56CB99, Attachment: Host-only Interface 'vboxnet0', Cable connected: on,\
Trace: off (file: none), Type: virtio, Reported speed: 0 Mbps,\
Boot priority: 0, Promisc Policy: allow-all, Bandwidth group: none
NIC 3:           MAC: 0002BC56CB29, Attachment: Host-only Interface 'vboxnet1', Cable connected: on,\
 Trace: off (file: none), Type: virtio, Reported speed: 0 Mbps,\
Boot priority: 0, Promisc Policy: allow-all, Bandwidth group: none
(excalibur:14:18:EDT)% 

So, what's the problem, here?  I started looking into configuration files.  Here's what I found in ~/VirtualBox VMs/dax/dax.vbox:

      <Network>
        <Adapter slot="0" enabled="true" MACAddress="0002BC56CB39" cable="true" promiscuousModePolicy="AllowAll" type="virtio">
          <DisabledModes>
            <InternalNetwork name="intnet"/>
            <NATNetwork name="NatNetwork"/>
          </DisabledModes>
          <BridgedInterface name="eth0"/>
        </Adapter>
        <Adapter slot="1" enabled="true" MACAddress="0002BC56CB99" cable="true" promiscuousModePolicy="AllowAll" type="virtio">
          <DisabledModes>
            <InternalNetwork name="intnet"/>
            <NATNetwork name="NatNetwork"/>
          </DisabledModes>
          <HostOnlyInterface name="vboxnet0"/>
        </Adapter>
        <Adapter slot="2" enabled="true" MACAddress="0002BC56CB29" cable="true" promiscuousModePolicy="AllowAll" type="virtio">
          <DisabledModes>
            <BridgedInterface name="tap0"/>
            <InternalNetwork name="intnet"/>
            <NATNetwork name="NatNetwork"/>
          </DisabledModes>
          <HostOnlyInterface name="vboxnet1"/>
        </Adapter>
        <Adapter slot="3" cable="true" type="82540EM"/>
        <Adapter slot="4" cable="true" type="82540EM"/>
        <Adapter slot="5" cable="true" type="82540EM"/>
        <Adapter slot="6" cable="true" type="82540EM"/>
        <Adapter slot="7" cable="true" type="82540EM"/>

The only thing that was different between vboxnet0 and vboxnet1 was the BridgedInterface under the DisabledModes tag.  It must have been added during my original try to get LXC connectivity working and then modified when I used the TAP device during troubleshooting.  It shouldn't matter because it's disabled.  Also, there's a big warning on the top of the file stating:

<!--
** DO NOT EDIT THIS FILE.
** If you make changes to this file while any VirtualBox related application
** is running, your changes will be overwritten later, without taking effect.
** Use VBoxManage or the VirtualBox Manager GUI to make changes.
-->

Well, I made changes to it and removed that one BridgedInterface line, but when the VM was stopped.  Bingo, that fixed it.  I now have bidirectional networking through the Linux bridge between my VM and LXC instance.

This smells like a bug.  VirtualBox must erroneously apply some networking state when it reads through DisabledModes when it really shouldn't.  As a result, I opened ticket 17022.

Comments: 0
> rtl8192cu vs 8192cu on RPi
Posted by prox, from Seattle, on June 22, 2017 at 02:06 local (server) time

From the RPi annoyances department..

I did a kernel upgrade on one of my Raspberry Pis earlier today by installing the latest raspberrypi-kernel from testing (1.20170515-1).  It installed Linux 4.9.28+ and I instantly realized there was something wrong since the Wi-Fi was very latent and would periodically disconnect from any nearby WAPs.  I use the Edimax EW-7811u USB stick since this Raspberry Pi is one of the original model Bs without Wi-Fi.

After debugging a bit and searching the Internet it appeared that I was now using the wrong driver, rtl8192cu instead of 8192cu:

(henry:22:18:PDT)% uname -a
Linux henry 4.9.28+ #998 Mon May 15 16:50:35 BST 2017 armv6l GNU/Linux
(henry:22:19:PDT)% lsmod|grep -i rtl
rtl8192cu              79230  0
rtl_usb                12234  1 rtl8192cu
rtl8192c_common        57894  1 rtl8192cu
rtlwifi                85339  3 rtl_usb,rtl8192c_common,rtl8192cu
mac80211              650547  3 rtl_usb,rtlwifi,rtl8192cu
cfg80211              525710  2 mac80211,rtlwifi

Apparently, before this upgrade the 8192cu driver was being used.  So, I added "blacklist rtl8192cu" to /etc/modprobe.d/raspi-blacklist.conf and rebooted.  Bingo, the right module is now being used:

(henry:23:04:PDT)% lsmod|grep 8192
8192cu                597868  0
cfg80211              525710  1 8192cu

No more Wi-Fi drops!

Comments: 0
> Caribbean Cruise
Posted by prox, from Seattle, on June 11, 2017 at 15:02 local (server) time

It's been awhile since I've posted something here, again.

Devon and I recently completed a Caribbean cruise on the Norwegian Escape.  The ship itself was fairly new (built in 2015) but was packet to the gills.  There were over 4,100 passengers!  As a result, it was difficult to use the elevators from time to time.

Blue Lagoon

We departed out of Miami and visited Nassau, St. Thomas, and Tortola.  I uploaded some random photos.  The image above is from the north side of Blue Lagoon, which was pretty deserted.

Comments: 0
> BIRD Musings
Posted by prox, from Seattle, on February 22, 2017 at 00:09 local (server) time

I started messing with BIRD the other day to work around some IPv6 issues with Quagga.  The configuration is fairly simple, but I ran into a weird issue where it picks the wrong interface IPv4 address from some of my OpenVPN tunnels.  For example, I've got these interfaces:

(storm:0:06:EST)% ip a s tun0
5: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1456 qdisc pfifo_fast state UNKNOWN group default qlen 100
    link/none 
    inet 10.3.254.44 peer 10.3.254.43/32 scope global tun0
       valid_lft forever preferred_lft forever
(storm:0:06:EST)% ip a s tun1
4: tun1: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1456 qdisc pfifo_fast state UNKNOWN group default qlen 100
    link/none 
    inet 10.3.254.81 peer 10.3.254.80/32 scope global tun1
       valid_lft forever preferred_lft forever

Here's what BIRD sees:

bird> show route protocol direct1
10.3.4.64/32       dev lo [direct1 23:53:06] * (240)
10.3.254.43/32     dev tun0 [direct1 23:53:06] * (240)
10.3.254.80/32     dev tun1 [direct1 23:53:06] * (240)
192.168.150.0/24   dev eth0 [direct1 23:53:06] * (240)

The addresses shown are the remote end of the OpenVPN tunnels, not the local end, which I'd expect.

Why?

Update: Well, this should have been obvious:

(storm:0:34:EST)% ip r s p kernel           
10.3.254.43 dev tun0 scope link src 10.3.254.44 
10.3.254.80 dev tun1 scope link src 10.3.254.81 
192.168.150.0/24 dev eth0 scope link src 192.168.150.105

I suppose I'll have to figure out how to get the link source to be visible to BIRD so I can advertise it, which is one of my odd requirements here.

Comments: 0
> apt-get SIGABRT
Posted by prox, from Seattle, on February 05, 2017 at 22:10 local (server) time

As I was doing upgrades on a few of my Raspberry Pi machines (running Raspbian), I ran into a situation where apt-get would SIGABRT on any action.  Depending on the shell, the message to the user is a little different and also overwrites a different amount of APT's status message.  Here's Zsh:

(storm:20:50:EST)% sudo apt-get --purge remove quagga-pimd quagga-isisd quagga-ospfd quagga-ospf6d
zsh: abort      sudo apt-get --purge remove quagga-pimd quagga-isisd quagga-ospfd

Here's Bash:

prox@storm:~$ sudo apt-get --purge remove quagga-pimd 
Aborted package lists... 48%

No matter what the operation (install, upgrade, update, remove), APT would just get a SIGABRT.  There was nothing in the kernel log buffer and the RPi 3 I was on at the time wasn't out of disk space or memory.  Since this RPi had just completed a dist-upgrade and I had rebooted it, everything was more-or-less up-to-date with the "testing" channel of Raspbian.  I searched the web and couldn't find anything related to "abort" or "SIGABRT" on Debian or Raspbian.  There were also no bugs filed against any of the relevant packages.  So, I figured that I had just hit a bug and started downgrading.  I used dpkg-repack on another RPi 3 of the following packages, which I downgraded to:

apt_1.3~rc4_armhf.deb
apt-utils_1.3~rc4_armhf.deb
dpkg_1.18.10_armhf.deb
dpkg-dev_1.18.10_all.deb
libapt-inst2.0_1.3~rc4_armhf.deb
libapt-pkg5.0_1.3~rc4_armhf.deb
libc6_2.23-4_armhf.deb
libc6-dbg_2.23-4_armhf.deb
libc6-dev_2.23-4_armhf.deb
libc-bin_2.23-4_armhf.deb
libc-dev-bin_2.23-4_armhf.deb
libc-l10n_2.23-4_all.deb
libdpkg-perl_1.18.10_all.deb
locales_2.23-4_all.deb
multiarch-support_2.23-4_armhf.deb

On the upgraded RPi, I'd been running APT 1.4~beta4, libc 2.24-9, and dpkg 1.18.18.  Unfortunately, none of the downgrades did the trick.  My next step was to downgrade the kernel, but I started to think something was maybe gummed up with APT itself, possibly in its database since it always received the SIGABRT about 50% of the way through reading package lists.  I ended up looking up the various storage directories and decided to clear out /var/lib/apt/lists.  I did another apt-get upgrade and things started working again:

(storm:21:55:EST)% sudo apt-get update
Get:1 http://archive.raspberrypi.org/debian jessie InRelease [22.9 kB]
Get:2 http://mirrordirector.raspbian.org/raspbian testing InRelease [15.0 kB]
Get:3 http://archive.raspberrypi.org/debian jessie/main armhf Packages [141 kB]                   
Get:4 http://mirrordirector.raspbian.org/raspbian testing/main armhf Packages [11.7 MB]           
Get:5 http://archive.raspberrypi.org/debian jessie/ui armhf Packages [53.6 kB]                
Get:6 http://mirrordirector.raspbian.org/raspbian testing/contrib armhf Packages [56.0 kB]                                                                     
Get:7 http://mirrordirector.raspbian.org/raspbian testing/non-free armhf Packages [95.1 kB]                                                                    
Get:8 http://mirrordirector.raspbian.org/raspbian testing/rpi armhf Packages [1,360 B]                                                                         
Fetched 12.1 MB in 24s (493 kB/s)                                                                                                                              
Reading package lists... Done
(storm:21:59:EST)% sudo apt-get --purge remove quagga-pimd quagga-isisd quagga-ospfd quagga-ospf6d
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following packages were automatically installed and are no longer required:
  libquagga0 quagga-bgpd quagga-core quagga-ripd quagga-ripngd
Use 'sudo apt autoremove' to remove them.
The following packages will be REMOVED:
  quagga* quagga-isisd* quagga-ospf6d* quagga-ospfd* quagga-pimd*
0 upgraded, 0 newly installed, 5 to remove and 8 not upgraded.
After this operation, 957 kB disk space will be freed.
Do you want to continue? [Y/n] 

Apparently something had gotten corrupted in the downloaded package lists and APT didn't handle it properly.  I'd submit a bug for this but I didn't think to backup /var/lib/apt/lists beforehand so I'm not sure how to reproduce this.  Anyway, if you get a SIGABRT when running apt-get, rm /var/lib/apt/lists/* and things will be happy again.

Also, in other news, Lady Gaga's Super Bowl LI performance was pretty decent.  The drones were a nice touch.

Comments: 0
> Updates & C-States Silliness on Linux
Posted by prox, from Seattle, on October 11, 2016 at 02:25 local (server) time

I haven't blogged in awhile.. so here are some updates.

I recently moved dax, which is the FreeBSD-based host that powers this web server, to a VM and away from Internap's Agile service.  dax used to be a dedicated server hosted by Voxel dot net and provided IPv6 connectivity to the rest of my network since September of 2005.  However, things started going downhill when Internap acquired them in 2012.  Technical support turned into a horror story and they recently indicated to me (in an IPv6 support ticket from hell) that the Agile "legacy" services were going to be done away with later in 2016 (not sure if this is true).

I migrated all of my sites off the IPv6 PA /56 I had from Internap and onto my own PI /44.  I moved dax to a VM on excalibur, a dedicated server hosted by Choopa, LLC.  I'm now Internap-free and running everything off of AS395460.

Anyway, excalibur's got an Intel Xeon E3-1240 v2 CPU with 4x cores and should run at 3.40 GHz.  Normally, with servers of mine that run VMs, I instruct cpufreq-set(1) to run all cores with the performance governor, which is supposed to direct all cores to run at their maximum clock rate.  However, with the E3 Xeon CPUs, this doesn't work.  The clock frequencies of each oscillate based on load and cause a considerable latency penalty, which is fairly visible in packet forwarding (causes jitter).  Here's a snapshot:

(excalibur:2:12:EDT)% cat /proc/cpuinfo|grep -i MHz
cpu MHz		: 1714.742
cpu MHz		: 2652.000
cpu MHz		: 3563.492
cpu MHz		: 3799.898
cpu MHz		: 3722.070
cpu MHz		: 2126.195
cpu MHz		: 3800.164
cpu MHz		: 2313.062

Searching on the web indicated I would need to completely disable the C-states in the BIOS, something I wasn't really willing to do and didn't feel like the correct solution.  I then came across another post that indicated I should write "0" to /dev/cpu_dma_latency but keep the file open.  So, I did this:

(excalibur:2:12:EDT)# cat > /dev/cpu_dma_latency
0

.. and didn't hit ^D.  Sure enough:

(excalibur:2:12:EDT)% cat /proc/cpuinfo|grep -i MHz
cpu MHz		: 3599.882
cpu MHz		: 3599.882
cpu MHz		: 3599.882
cpu MHz		: 3599.882
cpu MHz		: 3599.882
cpu MHz		: 3599.882
cpu MHz		: 3599.882
cpu MHz		: 3599.882

Seriously?  There's a whole nice structure in /sys/devices/system/cpu/cpufreq/* that Linux has used for over a decade to control CPU frequency scaling and we've now a one-off /dev character device that controls such things on a modern CPU?

Well, considering the stupidity of systemd that's supposedly accepted by most Linux distributions now, I guess I shouldn't be surprised that this type of hacky interface exists.  At least I've got a way to emulate the behavior of the performance governor without mucking with BIOS settings.  It turns out this also works on my E3 1245 v3 Xeon I've at home in vega, too.

Update: This is a bad idea.  This causes all CPUs to run very hot even when utilization is low, which confuses me:

excalibur burning

Update: The right solution to this problem is to just disable the Intel P-states driver by passing intel_pstate=disable on the kernel command line.  The acpi-cpufreq driver is used instead and operates the way it should.  See comments for more information.

Comments: 10
> Linux VLAN Interface Renaming
Posted by prox, from Seattle, on July 10, 2016 at 01:38 local (server) time

Almost as a continuation of Dead RPis and Interface Naming, I've now encountered some systemd/udev-related problems when creating VLAN interfaces on Linux (Debian) on one of my routers after upgrading to bleeding-edge stuff (Linux 4.6.0 and udev/systemd 230):

Say I have one of the following in /etc/network/interfaces:

auto eth1.35
iface eth1.35 inet static
     address 10.3.7.250
     netmask 255.255.255.252

or..

auto vlan35
iface vlan35 inet static
     address 10.3.7.250
     netmask 255.255.255.252
     vlan-raw-device eth1

I'll get this:

(starfire:22:23:PDT)# ifup vlan35
Set name-type for VLAN subsystem. Should be visible in /proc/net/vlan/config
Added VLAN with VID == 35 to IF -:eth1:-
(starfire:22:24:PDT)# ip link show dev vlan35
Device "vlan35" does not exist.
(starfire:22:24:PDT)# ip link|grep rename
61: rename61@eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
(starfire:22:24:PDT)# 

Obviously, I expected vlan35 to be created, but udev renamed it immediately to rename61.  The only udev rules that are acting on this, from what I can tell, are /etc/udev/rules.d/76-netnames.rules and /lib/udev/rules.d/19-ifrename.rules:

(starfire:22:27:PDT)# cat /lib/udev/rules.d/19-ifrename.rules
# udev rules to properly integrate ifrename.
# Renaming is done using /etc/iftab, with full ifrename functionality.
# Require udev version 107 or later.
# Please double check the path to ifrename, and make sure its available
# when udev runs (i.e. on boot partition).

# Enable this rule to test with udevtest.
#ENV{UDEV_LOG}=="6", SUBSYSTEM=="net", ACTION=="add", IMPORT{program}="/sbin/ifrename -D -V -u -i %k", NAME:="$env{INTERFACE}"

# Main ifrename rule.
# If interface is found in /etc/iftab, subsequent rename rules are bypassed.
# If interface is not found in /etc/iftab, subsequent rename rules applies.
SUBSYSTEM=="net", ACTION=="add", IMPORT{program}="/sbin/ifrename -u -i %k", NAME:="$env{INTERFACE}"
(starfire:22:27:PDT)# cat /etc/udev/rules.d/76-netnames.rules 
# Generated by netnames.sh on Sat Jul  9 19:09:59 PDT 2016
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="00:1b:21:08:2b:0a", NAME="eth0"
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="00:04:23:5f:4c:d9", NAME="eth1"
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="00:1b:21:08:2b:0b", NAME="eth2"
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="00:04:23:5f:4c:d8", NAME="eth3"
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="00:08:74:c5:d4:61", NAME="eth4"
(starfire:22:27:PDT)# 

The former comes with the udev package but the latter was created by me since I needed all of the NICs in my router to have consistent and traditional names.  I'd add these VLAN interfaces to 76-netnames.rules but there's nothing unique I can match since the MAC addresses on the VLAN interfaces are copied from the physical interface.

It's pretty obvious that udev is renaming VLAN interfaces and getting in the way.  I should normally be able to hack around this by a pre-up or up directive in /etc/network/interfaces but the renameXX interfaces are not consistent (but predictable:

(starfire:22:31:PDT)# ip link show |grep rename
(starfire:22:31:PDT)# vconfig add eth1 99      
Added VLAN with VID == 99 to IF -:eth1:-
(starfire:22:31:PDT)# ip link show |grep rename
63: rename63@eth1:  mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
(starfire:22:31:PDT)# vconfig rem rename63     
Removed VLAN -:rename63:-
(starfire:22:31:PDT)# ip link show |grep rename
(starfire:22:31:PDT)# vconfig add eth1 99      
Added VLAN with VID == 99 to IF -:eth1:-
(starfire:22:31:PDT)# ip link show |grep rename
64: rename64@eth1:  mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
(starfire:22:31:PDT)# 

I suspect adding net.ifnames=0 to the kernel command line will fix things again but that's not a long-term solution.  Right now I'm left with no option but to build these interfaces manually after boot.  I'll update this post when I log a bug against one of the Debian packages involved here.

Update 20160710

I managed to get this to work by sticking the following in my /etc/udev/rules.d/76-netnames.rules:

SUBSYSTEM=="net", KERNEL=="eth*.*" ACTION=="add", NAME="$kernel"
SUBSYSTEM=="net", KERNEL=="vlan*" ACTION=="add", NAME="$kernel"

This causes udev to not touch VLAN interfaces using the naming schemes I care about (DEV_PLUS_VID_NO_PAD and VLAN_PLUS_VID_NO_PAD).

Comments: 0
> Dead RPis and Interface Naming
Posted by prox, from Seattle, on May 22, 2016 at 22:18 local (server) time

I recently had a case where a few of my [very] remote Raspberry Pis dropped off the network upon reboot (power failure, etc.).  I run the 'testing' release of Raspbian & Debian on my Linux boxes so I do an apt-get dist-upgrade rather often.  The RPis that dropped off the network had indeed been upgraded recently so I had one shipped back to me for investigation.

It turns out that eth0 and wlan0 had been renamed to enx$MAC and looked like this:

Previously wlan0

(I had the RPi plugged into my TV)

I do know about predictable network interface names, which is supposed to prevent interface names changing when hardware is swapped, among other things.  The enx$MAC naming scheme is used for USB devices.  Up until now I've been content to disable this feature by adding net.ifnames=0 to the kernel command-line.  Indeed, I had this flag in /boot/cmdline.txt on the Pis but it just isn't working anymore.

It turns out that this feature is set to be deprecated in Debian 10, along with the automatically-generated /etc/udev/rules.d/70-persistent-net.rules file, which is appended when a new NIC is added to the system.  This is documented in /usr/share/doc/udev/README.Debian.gz, apparently.

Unfortunately for me, the RPis never had 70-persistent-net.rules written and apparently udev 229-5 already ignores net.ifnames=0.  One of my dist-upgrades bumped udev from 229-4 to 229-5.  This is why none of the interface names that were defined in /etc/network/interfaces were found on boot and the RPis booted up with no enabled interfaces.

/usr/share/doc/udev/README.Debian.gz goes on to say that if custom interface names are needed, use 76-netnames.rules with the following content, which looks similar to what was previously written out in 70-persistent-net.rules automatically:

SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="00:50:56:1a:aa:ab", NAME="eth0"

There's no mention of this method of interface naming being deprecated so I'm going to use it for now.

This is just the latest annoyance, for me, when it comes to Linux's interface naming.  Several years back the right way to setup predictable interface names was to use /etc/iftab and ifrename(8)!

What I haven't figured out is how this is going to impact VMs and virtio.  My own VMs with VirtualBox have static MAC addresses assigned to the vbox file so using 76-netnames.rules will work fine.  However, I'm not sure if EC2 and other Xen-based VPS providers always provide a constant MAC address.  One of my EC2 instances has 53-ec2-network-interfaces.rules, which handles some sort of hotplugging.  I'm not sure if that script will stop working as well after some time and udev upgrades but it would seem the solution is to use some ATTR other than 'addresss'.

Comments: 0

No Previous PageDisplaying page 1 of 119 of 950 results Next Page