Fwd: Re: Linpac and other AX.25 binaries failing to run on Debian Stretch
-------- Forwarded Message --------
Subject: Re: Linpac and other AX.25 binaries failing to run on Debian
Stretch
Date: Sun, 3 Sep 2017 12:21:02 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: David Ranch <dranch@trinnet.net>
CC: Colin Tuckley <colint@debian.org>, Thomas Osterried
<thomas@osterried.de>, Bernard, f6bvp <f6bvp@free.fr>, Basil Gunn -
N7NIX <basil@pacabunga.com>
On Sat, Sep 02, 2017 at 11:05:17PM -0700, David Ranch wrote:
> 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
enxb827eb5f053b is 15 character long, even 16 when counting the terminating
\0 character. The symbol IFNAMSIZ defines the permissable maximum which
on Linux is 16.
> 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)
And enxb827eb5f05 is truncated to just 13 characters. Of course it
won't be found.
Recently I've audited a number of ax25-* programs for how they handle
interface names from the commandline, each and every was broken!
> 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.
I leave curses to Thomas.
> 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?
Fixing the code :-)
As for why this is happening, I've taken a look at what listen does:
struct sockaddr sa;
socklen_t asize = sizeof(sa);
[...]
sock = socket(PF_PACKET, SOCK_PACKET, htons(proto));
[...]
size = recvfrom(sock, buffer, sizeof(buffer), 0, &sa, &asize);
[...]
strcpy(ifr.ifr_name, sa.sa_data);
if (ioctl(sock, SIOCGIFHWADDR, &ifr) == -1)
splat();
And guess what, struct sockaddr's sa_data is only 14 bytes:
/* Structure describing a generic socket address. */
struct sockaddr
{
__SOCKADDR_COMMON (sa_); /* Common data: address family and
length. */
char sa_data[14]; /* Address data. */
};
Now, that's a bit an ugly system limitation and entirely unrelated to
AX.25!
We probably need to pass something like sockaddr_storage or even our
own self-defined type instead of struct sockaddr.
Ralf
Reply to: