[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Fwd: Linpac and other AX.25 binaries failing to run on Debian Stretch





-------- Forwarded Message --------
Subject: 	Linpac and other AX.25 binaries failing to run on Debian Stretch
Date: 	Sat, 2 Sep 2017 23:05:17 -0700
From: 	David Ranch <dranch@trinnet.net>
To: 	Colin Tuckley <colint@debian.org>, Ralf Baechle
<ralf@linux-mips.org>, Thomas Osterried <thomas@osterried.de>
CC: 	Bernard, f6bvp <f6bvp@free.fr>, Basil Gunn - N7NIX
<basil@pacabunga.com>



+ Basil too!

Hello Colin, Ralf, Bernard, Thomas,

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-interface-names-in-xubuntu-15-10

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:
--
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 that means
there is something wrong here that something just with LInpac.   So,
what do you recommend is the next step here?

--David
KI6ZHD


Reply to: