3 Sep
2017
3 Sep
'17
11:59 a.m.
Hello Everyone,
I'm currently working Thomas Osterried and Ralf Baechle on this below
issue but I thought I'd email this out to the list just in case you hit
it. Both Thomas and Ralf have confirmed it and the root issue is the
length of the Ethernet interface name which is due to Stretch's new
default of using predictable network interface names. Below mentions how
to revert back to the classic "eth0" interface naming convention which
will get things working again.
--David
KI6ZHD
While running Linpac on the console (not over SSH) on Raspbian Stretch,
I would still see errors like "SIOCGIFHWADDR: No such device" but the
program wouldn't crash. If I would run Linpac over an SSH terminal, it
would crash. I then was comparing straces of linpac running on the
console run linpac vs. the ssh run linpac and was gravitating towards
various locale issues and trying different environment variables like
LANG, LANGUAGE, TERM, etc but nothing was getting me the consistency of
*not* crashing when using an SSH terminal. I was then noticing that in
the SSH-based sessions of running Linpac, it was constantly coming back
to the Raspbery Pi 3's Ethernet interface which is named
"enxb827eb5f053b" in Stretch but it's "eth0" in Jessie.
--
root@rpi3:/etc/ax25# ifconfig
ax0: flags=67<UP,BROADCAST,RUNNING> mtu 253
ax25 KI6ZHD-6 txqueuelen 10 (AMPR AX.25)
RX packets 68 bytes 5306 (5.1 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 5 bytes 20 (20.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
enxb827eb5f053b: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.0.24 netmask 255.255.255.0 broadcast 192.168.0.255
ether b8:27:eb:5f:05:3b txqueuelen 1000 (Ethernet)
RX packets 735 bytes 55331 (54.0 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 559 bytes 109673 (107.1 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
loop txqueuelen 1 (Local Loopback)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
wlan0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
ether b8:27:eb:0a:50:6e txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
--
I've never personally been a fan of the new predictable network
interface names but I've dealt with them. On a lark, I disabled the
predictable naming convention and brought back the classic eth0 name per
making the following change in the /boot/cmdline.txt file:
https://serverfault.com/questions/741210/disabling-predictable-network-inte…
With that in place.. No more crashes! Man.. that's VERY surprising to
me but now that I'm paying very close attention, I'm seeing the same
issues in the standard AX.25 programs! When I start the "axbeacon"
program with no interface specified (that means it will listen on all
AX25 interfaces), I'm seeing:
strace -f /usr/bin/listen -artc 2> /tmp/beacon.strace
root@rpi3:/etc/ax25# echo $?
22
I've attached that strace as well and it also has signs of persistent
Ethernet naming issues (notice below that the full interface name is
missing the "3b" at the end of the Ethernet interface name"):
--
ioctl(3, SIOCGIFHWADDR, {ifr_name="enxb827eb5f05"}) = -1 ENODEV (No such
device)
dup(2) = 5
fcntl64(5, F_GETFL) = 0x20001 (flags
O_WRONLY|O_LARGEFILE)
close(5) = 0
write(2, "SIOCGIFHWADDR: No such device\n", 30SIOCGIFHWADDR: No such device
--
I have confirmed this happens with both the 3rd party VE7FET's AX.25
sources ( https://github.com/ve7fet/linuxax25 ) and the standard .deb
packages repos supporting Raspbian Stretch. It seems there is an even
bigger issue for the Debian .debs as it's axlisten wasn't properly
compiled with Ncurses support as it gives the addition error:
--
Could not initialize color support.
--
At least the beacon program doesn't crash like LInpac but all this
confirms there is something wrong here that something just with Linpac.
--David
KI6ZHD