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