Hello,

I hope that this email isn't offtopic for debian-hams as most of the
list traffic seems to be packaging-related nowadays, but I assume that
AX.25 is so much of a niche topic that asking on another list wouldn't
make much sense.

I'm trying to get a "classic" packet radio (1200 bits/s AFSK) setup
working on Sid and could use some help with debugging a problem with
axcall as the whole world of AX.25 is rather new to me and most of the
existing information on the net is rather outdated.

What I would like to achieve is being able to access a system in AX.25 connected mode (similar to a classic packet BBS). I'm using direwolf
as a virtual KISS-mode TNC to which I connect an AX.25 port with
kissattach (using a pseudo-tty). This works so far that I can use this
AX.25 port in unconnected mode and send packets over it with "beacon"
from the ax25-tools package. Where I am stuck is using connected mode
with axcall. Trying to run axcall always results in the error
"AX25_WINDOW: Invalid argument" and I have no idea what could be going
wrong there. Searching the web unfortunately hasn't brought up any
helpful information, so I'd be very grateful for any hints that you
could provide.

Following is an overview of relevant configuration data and debug
output on my system. In case somebody should wonder about the
"strange" callsigns: I'm trying to use AX.25 over CB radio (which is
permitted in Germany on certain channels), therefore the callsigns
follow the usual conventions on CB radio which are different from the
callsign structure used in ham radio. To make sure that the problem
isn't in the callsign format, I have run some tests with "proper" ham
radio callsigns (of course without connecting a radio to the computer)
and it doesn't change the behaviour.

cat /etc/ax25/axports
=====================
# /etc/ax25/axports
#
# The format of this file is:
#
# name callsign speed paclen window description
#
#
#1 OH2BNS-1 1200 255 2 144.675 MHz (1200 bps)
#2 OH2BNS-9 38400 255 7 TNOS/Linux (38400 bps)
cb 13CB99-1 1200 255 2 CBPR (1200bps)

grep ^MYCALL /etc/direwolf.conf
===============================
MYCALL 13CB99

direwolf log
============
Dire Wolf version 1.6
Includes optional support for: gpsd hamlib cm108-ptt

Reading config file /etc/direwolf.conf
Audio device for both receive and transmit: default (channel 0)
Channel 0: 1200 baud, AFSK 1200 & 2200 Hz, E+, 44100 sample rate.
Note: PTT not configured for channel 0. (Ignore this if using VOX.)
Ready to accept AGW client application 0 on port 8000 ...
Ready to accept KISS TCP client application 0 on port 8001 ...
Virtual KISS TNC is available on /dev/pts/11
Created symlink /tmp/kisstnc -> /dev/pts/11

kissattach
==========
# kissattach /dev/pts/11 cb
AX.25 port cb bound to device ax0
# ifconfig ax0
ax0: flags=67<UP,BROADCAST,RUNNING> mtu 255
ax25 13CB99-1 txqueuelen 10 (AMPR AX.25)
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

Test unconnected mode
=====================
$ /usr/sbin/beacon -s -d 13CB42 cb "test message"

axlisten -t -a -c

cb: fm 13CB99-1 to 13CB42 ctl UI^ pid=F0(Text) len 12
0000 test message

direwolf log

Invalid transmit channel 2 from KISS client app.
Are you using AX.25 for Linux? It might be trying to use a modified
version of KISS which uses the port (channel) field differently than the original KISS protocol specification. The solution might be to use
a command like "kissparms -c 1 -p radio" to set CRC none mode.
Another way of doing this is pre-loading the "kiss" kernel module with CRC disabled:
sudo /sbin/modprobe -q mkiss crc_force=1

Set CRC none mode
=================
# kissparms -c 1 -p cb

Test unconnected mode
=====================
$ /usr/sbin/beacon -s -d 13CB42 cb "second test message"

axlisten -t -a -c

cb: fm 13CB99-1 to 13CB42 ctl UI^ pid=F0(Text) len 19
0000 second test message

direwolf log

[0L] 13CB99-1>13CB42:second test message

Test connected mode
===================
$ LANG=en axcall cb 13CB42
GW4PTS AX.25 Connect v1.11
AX25_WINDOW: Invalid argument
$ LANG=en axcall cb 13CB42-1
GW4PTS AX.25 Connect v1.11
AX25_WINDOW: Invalid argument

Regards,
Karsten
--
Hiermit widerspreche ich ausdrücklich der Nutzung sowie der Weitergabe
meiner personenbezogenen Daten für Zwecke der Werbung sowie der Markt-
oder Meinungsforschung.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hello Karsten,

Test connected mode
===================
$ LANG=en axcall cb 13CB42
GW4PTS AX.25 Connect v1.11
AX25_WINDOW: Invalid argument
$ LANG=en axcall cb 13CB42-1
GW4PTS AX.25 Connect v1.11
AX25_WINDOW: Invalid argument

I never used axcall but by reading the code I think that you should
use the -w argument, valid values are 1..63 or 1..7 depending on the
value of -m that can be either s or e


This is because there is only one place where the "AX25_WINDOW" error
message is printed:

if (setsockopt
(fd, SOL_AX25, AX25_WINDOW, &window,
sizeof(window)) == -1) {
perror("AX25_WINDOW");
close(fd);
fd = -1;
return -1;
}

https://salsa.debian.org/debian-hamradio-team/ax25-apps/-/blob/master/call/call.c#L677

and man setsockopt says:
EINVAL optlen invalid in setsockopt(). In some cases this error can
also occur for an invalid value in optval

and optval gets the value of the varaible window is zero by default
--
73 de IU5HKX Daniele

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Re: Karsten Merker

This is because there is only one place where the "AX25_WINDOW" error message is printed:

if (setsockopt
(fd, SOL_AX25, AX25_WINDOW, &window,
sizeof(window)) == -1) {

Do you perhaps have an idea what else could be the source of the problem?

Does the kernel still support ax25? I remember talk of dropping that.

Christoph

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu, Jan 13, 2022 at 12:32:28AM +0100 Daniele Forsi wrote:

Hello Karsten,

Test connected mode
===================
$ LANG=en axcall cb 13CB42
GW4PTS AX.25 Connect v1.11
AX25_WINDOW: Invalid argument
$ LANG=en axcall cb 13CB42-1
GW4PTS AX.25 Connect v1.11
AX25_WINDOW: Invalid argument

I never used axcall but by reading the code I think that you should
use the -w argument, valid values are 1..63 or 1..7 depending on the
value of -m that can be either s or e

This is because there is only one place where the "AX25_WINDOW" error
message is printed:

if (setsockopt
(fd, SOL_AX25, AX25_WINDOW, &window,
sizeof(window)) == -1) {
perror("AX25_WINDOW");
close(fd);
fd = -1;
return -1;
}

https://salsa.debian.org/debian-hamradio-team/ax25-apps/-/blob/master/call/call.c#L677

Hello Daniele,

many thanks for your help. I've tried passing all values from 1 to 7 with
'-w' in both modes (i.e. with '-m s' and with '-m e'), but axcall still
always gives the same error message. Examples:

$ LANG=en axcall -m s -w 3 cb 13CB42
GW4PTS AX.25 Connect v1.11
AX25_WINDOW: Invalid argument
$ LANG=en axcall -m e -w 7 cb 13CB42
GW4PTS AX.25 Connect v1.11
AX25_WINDOW: Invalid argument

Do you perhaps have an idea what else could be the source of the problem?

Regards,
Karsten
--
Hiermit widerspreche ich ausdrücklich der Nutzung sowie der Weitergabe
meiner personenbezogenen Daten für Zwecke der Werbung sowie der Markt-
oder Meinungsforschung.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu, Jan 13, 2022 at 12:24:08PM +0100 wrote Christoph Berg:

Re: Karsten Merker

This is because there is only one place where the "AX25_WINDOW" error message is printed:

if (setsockopt
(fd, SOL_AX25, AX25_WINDOW, &window,
sizeof(window)) == -1) {

Do you perhaps have an idea what else could be the source of the problem?

Does the kernel still support ax25? I remember talk of dropping that.

Hello,

AFAICS there should be working AX.25 support in the kernel:

lsmod output
============
Module Size Used by
mkiss 24576 1
ax25 77824 1 mkiss

dmesg output
============
NET: Registered PF_AX25 protocol family

ifconfig output
===============
ax0: flags=67<UP,BROADCAST,RUNNING> mtu 255
ax25 13CB99-1 txqueuelen 10 (AMPR AX.25)

Regards,
Karsten
--
Hiermit widerspreche ich ausdrücklich der Nutzung sowie der Weitergabe
meiner personenbezogenen Daten für Zwecke der Werbung sowie der Markt-
oder Meinungsforschung.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

This is a multi-part message in MIME format.
Hello Christoph,

Please don't allow the Debian powers at be to disable those various KISS
/ AX.25 / NETROM / ROSE features. Many people use those features from
the true Debian releases! There are some known kernel bugs in there
that various people are trying to resolve but the code is still very
much functional.

--David
KI6ZHD


On 01/13/2022 03:24 AM, Christoph Berg wrote:

Re: Karsten Merker

This is because there is only one place where the "AX25_WINDOW" error
message is printed:

if (setsockopt
(fd, SOL_AX25, AX25_WINDOW, &window,
sizeof(window)) == -1) {

Do you perhaps have an idea what else could be the source of the problem?

Does the kernel still support ax25? I remember talk of dropping that.

Christoph

<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<font size="-1">Hello Christoph,<br>
<br>
Please don't allow the Debian powers at be to disable those
various KISS / AX.25 / NETROM / ROSE features.� Many people use
those features from the true Debian releases!� There are some
known kernel bugs in there that various people are trying to
resolve but the code is still very much functional.<br>
<br>
--David<br>
KI6ZHD<br>
<br>
<br>
</font>
<div class="moz-cite-prefix">On 01/13/2022 03:24 AM, Christoph Berg
wrote:<br>
</div>
<blockquote cite="mid:[email protected]" type="cite">
<pre wrap="">Re: Karsten Merker
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">This is because there is only one place where the "AX25_WINDOW" error
message is printed:

if (setsockopt
(fd, SOL_AX25, AX25_WINDOW, &amp;window,
sizeof(window)) == -1) {
</pre>
</blockquote>
</blockquote>
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">Do you perhaps have an idea what else could be the source of the problem?
</pre>
</blockquote>
<pre wrap="">
Does the kernel still support ax25? I remember talk of dropping that.

Christoph
</pre>
</blockquote>
<br>
</body>
</html>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

This is a multi-part message in MIME format.
Hello Daniele,

$ LANG=en axcall cb 13CB42
GW4PTS AX.25 Connect v1.11
AX25_WINDOW: Invalid argument

Please post your /etc/ax25/axports file as I imagine there is an error
in there. That configuration file is known to be sensitive to extra characters, CR/LF, etc. Here is a working example where those are TABS creating the space between columns:
--
#portname callsign speed paclen window description
d710 KI6ZHD 9600 255 4 built-in D710
TNC at 1200baud
--

Also.. it should be noted that your given destination callsign is NOT a
valid amateur radio callsign. As such, some software (not necessarily
AX.25 code) might break is unexpected ways.

I never used axcall but by reading the code I think that you should
use the -w argument, valid values are 1..63 or 1..7 depending on the
value of -m that can be either s or e

Where are you getting your axcall binary? Is it from the Debian repos?
If so, that code is rather OLD and this is due to the primary maintainer
not marking new releases on his Git repo. What I recommend to do is to
compile a new version and use that over the Debian repo versions. There
are generally TWO versions you can consider and I explain all of that here:

http://www.trinityos.com/HAM/CentosDigitalModes/RPi/rpi4-setup.html#18.install-ax25

--David
KI6ZHD

<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
Hello Daniele,<br>
<br>
<blockquote cite="mid:CAFetEgw1MLYCoCZ-pgTp_u3bL-RoL+aa7DY7Qz2vvmqrsDS37Q@mail.gmail.com"
type="cite">
<blockquote type="cite">
<pre wrap="">$ LANG=en axcall cb 13CB42
GW4PTS AX.25 Connect v1.11
AX25_WINDOW: Invalid argument
</pre>
</blockquote>
</blockquote>
<br>
Please post your /etc/ax25/axports file as I imagine there is an
error in there.  That configuration file is known to be sensitive to
extra characters, CR/LF, etc.  Here is a working example where those
are TABS creating the space between columns:<br>
--<br>
#portname       callsign        speed   paclen  window  description<br>
d710            KI6ZHD          9600    255     4       built-in
D710 TNC at 1200baud<br>
--<br>
<br>
Also.. it should be noted that your given destination callsign is
NOT a valid amateur radio callsign.  As such, some software (not
necessarily AX.25 code) might break is unexpected ways.<br>
<br>
<pre wrap="">
</pre>
<blockquote cite="mid:CAFetEgw1MLYCoCZ-pgTp_u3bL-RoL+aa7DY7Qz2vvmqrsDS37Q@mail.gmail.com"
type="cite">
<pre wrap="">I never used axcall but by reading the code I think that you should
use the -w argument, valid values are 1..63 or 1..7 depending on the
value of -m that can be either s or e</pre>
</blockquote>
<br>
Where are you getting your axcall binary?  Is it from the Debian
repos?  If so, that code is rather OLD and this is due to the
primary maintainer not marking new releases on his Git repo.  What I
recommend to do is to compile a new version and use that over the
Debian repo versions.  There are generally TWO versions you can
consider and I explain all of that here:<br>
<br>
  
<a class="moz-txt-link-freetext" href="http://www.trinityos.com/HAM/CentosDigitalModes/RPi/rpi4-setup.html#18.install-ax25">http://www.trinityos.com/HAM/CentosDigitalModes/RPi/rpi4-setup.html#18.install-ax25</a><br>
<br>
--David<br>
KI6ZHD<br>
</body>
</html>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu, Jan 13, 2022 at 07:45:34AM -0800 David Ranch wrote:

$ LANG=en axcall cb 13CB42
GW4PTS AX.25 Connect v1.11
AX25_WINDOW: Invalid argument

Please post your /etc/ax25/axports file as I imagine there is an error in there. That configuration file is known to be sensitive to extra
characters, CR/LF, etc. Here is a working example where those are TABS creating the space between columns:
--
#portname callsign speed paclen window description
d710 KI6ZHD 9600 255 4 built-in D710 TNC at 1200baud

Hello,

many thanks for your help. I have attached my /etc/ax25/axports
file to this mail.

Also.. it should be noted that your given destination callsign
is NOT a valid amateur radio callsign.

Indeed, but that is unavoidable when operating AX.25 on CB radio
instead of on the ham bands.

As such, some software (not necessarily AX.25 code) might break
is unexpected ways.

Yes, that could of course happen. To make sure that the source
of the problem at hand isn't using callsigns that do not strictly
comply with the ITU-mandated format for ham callsigns while still
fulfilling the requirements of the AX.25 spec (up to 6
characters, either uppercase ASCII letters or numbers), I had
already run a bunch of tests with structurally valid ham radio
callsigns (both for the local AX.25 port as well as for the
destination). The behaviour of axcall was exactly the same with
the CB and with the ham callsigns.

Where are you getting your axcall binary? Is it from the Debian repos?

Yes, from Debian/sid.

If so, that code is rather OLD and this is due to the primary
maintainer not marking new releases on his Git repo. What I
recommend to do is to compile a new version and use that over
the Debian repo versions. There are generally TWO versions you
can consider and I explain all of that here:

http://www.trinityos.com/HAM/CentosDigitalModes/RPi/rpi4-setup.html#18.install-ax25

I have uninstalled the Debian ax25-apps, ax25-tools, libax25 and
libax25-dev packages and built the software from https://github.com/ve7fet/linuxax25.git as described in your link
above. Unfortunately, with those binaries the behavior is
exactly the same as with the Debian-packaged ones.

For testing the newly-built binaries I have again used
structurally valid (although currently unassigned) ham callsigns
to exclude the callsign format as a possible problem source.

$ cat /etc/ax25/axports
# /etc/ax25/axports
#
# The format of this file is:
#
# name callsign speed paclen window description
#
#
#1 OH2BNS-1 1200 255 2 144.675 MHz (1200 bps)
#2 OH2BNS-9 38400 255 7 TNOS/Linux (38400 bps)
cb DL1ABG-1 1200 255 2 CBPR (1200bps)

$ grep ^MYCALL /etc/direwolf.conf
MYCALL DL1ABG

# /usr/local/stow/ax25/sbin/kissattach /dev/pts/6 cb
AX.25 port cb bound to device ax0
root@aletheia:~# ifconfig
ax0: flags=67<UP,BROADCAST,RUNNING> mtu 255
ax25 DL1ABG-1 txqueuelen 10 (AMPR AX.25)
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

$ LANG=en /usr/local/stow/ax25/bin/call cb DL1ABD
GW4PTS AX.25 Connect 2.0.1
AX25_WINDOW: Invalid argument

$ ldd /usr/local/stow/ax25/bin/call
linux-vdso.so.1 (0x00007ffc68b6d000)
libncursesw.so.6 => /lib/x86_64-linux-gnu/libncursesw.so.6 (0x00007ff0e0b0c000)
libtinfo.so.6 => /lib/x86_64-linux-gnu/libtinfo.so.6 (0x00007ff0e0adb000)
libax25.so.1 => /usr/local/lib/libax25.so.1 (0x00007ff0e0acf000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007ff0e0906000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007ff0e08ff000)
/lib64/ld-linux-x86-64.so.2 (0x00007ff0e0ba4000)

Regards,
Karsten
--
Hiermit widerspreche ich ausdrücklich der Nutzung sowie der Weitergabe
meiner personenbezogenen Daten für Zwecke der Werbung sowie der Markt-
oder Meinungsforschung.

# /etc/ax25/axports
#
# The format of this file is:
#
# name callsign speed paclen window description
#
#
#1 OH2BNS-1 1200 255 2 144.675 MHz (1200 bps)
#2 OH2BNS-9 38400 255 7 TNOS/Linux (38400 bps)
cb 13CB99-1 1200 255 2 CBPR (1200bps)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

This is a multi-part message in MIME format.
Everything you've setup looks correct. What version of Debian and which
kernel version are you running? When running your axcall command,
maybe you can run it via "strace -f" to see more details of where this
is failing?

Ps. You can look how I start up my AX25 stack here ( http://www.trinityos.com/HAM/CentosDigitalModes/RPi/etc/ax25/ax25-up.new
) but once your stack is running, try running these echo statements and
see if anything looks wrong:
--
echo "Displaying current system kissparms"
echo "Displaying current system kissparms" >> $LOG
echo "--"
echo "--" >> $LOG
echo "AX25 protocol mode (0=Norm* 1=Extd) : `cat /proc/sys/net/ax25/$AXINT/ax25_default_mode`"
echo "AX25 protocol mode (0=Norm* 1=Extd) : `cat /proc/sys/net/ax25/$AXINT/ax25_default_mode`" >> $LOG
echo "AX25 backoff type (0=Linear 1=Expon*) : `cat /proc/sys/net/ax25/$AXINT/backoff_type`"
echo "AX25 backoff type (0=Linear 1=Expon*) : `cat /proc/sys/net/ax25/$AXINT/backoff_type`" >> $LOG
echo "AX25 connect mode (0=none 1=network 2=all*) : `cat /proc/sys/net/ax25/$AXINT/connect_mode`"
echo "AX25 connect mode (0=none 1=network 2=all*) : `cat /proc/sys/net/ax25/$AXINT/connect_mode`" >> $LOG
echo "AX25 Extd window size (num of unacked packets 32*) : `cat /proc/sys/net/ax25/$AXINT/extended_window_size`"
echo "AX25 Extd window size (num of unacked packets 32*) : `cat /proc/sys/net/ax25/$AXINT/extended_window_size`" >> $LOG
echo "AX25 idle timeout (idle session timeout in M 20*) : `cat /proc/sys/net/ax25/$AXINT/idle_timeout`"
echo "AX25 idle timeout (idle session timeout in M 20*) : `cat /proc/sys/net/ax25/$AXINT/idle_timeout`" >> $LOG
echo "AX25 AXIP mode (0=Datagram* 1=VirtConnection) : `cat /proc/sys/net/ax25/$AXINT/ip_default_mode`"
echo "AX25 AXIP mode (0=Datagram* 1=VirtConnection) : `cat /proc/sys/net/ax25/$AXINT/ip_default_mode`" >> $LOG
echo "AX25 max packet size (256*) : `cat /proc/sys/net/ax25/$AXINT/maximum_packet_length`"
echo "AX25 max packet size (256*) : `cat /proc/sys/net/ax25/$AXINT/maximum_packet_length`" >> $LOG
echo "AX25 max packet retry count (10*) : `cat /proc/sys/net/ax25/$AXINT/maximum_retry_count`"
echo "AX25 max packet retry count (10*) : `cat /proc/sys/net/ax25/$AXINT/maximum_retry_count`" >> $LOG
echo "AX25 protcol version (DAMA Slave) : `cat /proc/sys/net/ax25/$AXINT/protocol`"
echo "AX25 protcol version (DAMA Slave) : `cat /proc/sys/net/ax25/$AXINT/protocol`" >> $LOG
echo "AX25 STD window size (num of unacked packets 2* ) : `cat /proc/sys/net/ax25/$AXINT/standard_window_size`"
echo "AX25 STD window size (num of unACKed packets 2*) : `cat /proc/sys/net/ax25/$AXINT/standard_window_size`" >> $LOG
echo "AX25 T1 timer (unacked packet retry 10000mS*) : `cat /proc/sys/net/ax25/$AXINT/t1_timeout`"
echo "AX25 T1 timer (unacked packet retry 10000mS*) : `cat /proc/sys/net/ax25/$AXINT/t1_timeout`" >> $LOG
echo "AX25 T2 timer (wait for 2nd RX packet 3000mS*) : `cat /proc/sys/net/ax25/$AXINT/t2_timeout`"
echo "AX25 T2 timer (wait for 2nd RX packet 3000mS*) : `cat /proc/sys/net/ax25/$AXINT/t2_timeout`" >> $LOG
echo "AX25 T3 timer (link still up check 300000mS*) : `cat /proc/sys/net/ax25/$AXINT/t3_timeout`"
echo "AX25 T3 timer (link still up check 300000mS*) : `cat /proc/sys/net/ax25/$AXINT/t3_timeout`" >> $LOG
--


--David
KI6ZHD


On 01/13/2022 12:32 PM, Karsten Merker wrote:

On Thu, Jan 13, 2022 at 07:45:34AM -0800 David Ranch wrote:

$ LANG=en axcall cb 13CB42
GW4PTS AX.25 Connect v1.11
AX25_WINDOW: Invalid argument

Please post your /etc/ax25/axports file as I imagine there is an error in
there. That configuration file is known to be sensitive to extra
characters, CR/LF, etc. Here is a working example where those are TABS
creating the space between columns:
--
#portname callsign speed paclen window description
d710 KI6ZHD 9600 255 4 built-in D710 TNC at >> 1200baud

Hello,

many thanks for your help. I have attached my /etc/ax25/axports
file to this mail.

Also.. it should be noted that your given destination callsign
is NOT a valid amateur radio callsign.

Indeed, but that is unavoidable when operating AX.25 on CB radio
instead of on the ham bands.

As such, some software (not necessarily AX.25 code) might break
is unexpected ways.

Yes, that could of course happen. To make sure that the source
of the problem at hand isn't using callsigns that do not strictly
comply with the ITU-mandated format for ham callsigns while still
fulfilling the requirements of the AX.25 spec (up to 6
characters, either uppercase ASCII letters or numbers), I had
already run a bunch of tests with structurally valid ham radio
callsigns (both for the local AX.25 port as well as for the
destination). The behaviour of axcall was exactly the same with
the CB and with the ham callsigns.

Where are you getting your axcall binary? Is it from the Debian repos?

Yes, from Debian/sid.

If so, that code is rather OLD and this is due to the primary
maintainer not marking new releases on his Git repo. What I
recommend to do is to compile a new version and use that over
the Debian repo versions. There are generally TWO versions you
can consider and I explain all of that here:

http://www.trinityos.com/HAM/CentosDigitalModes/RPi/rpi4-setup.html#18.install-ax25

I have uninstalled the Debian ax25-apps, ax25-tools, libax25 and
libax25-dev packages and built the software from https://github.com/ve7fet/linuxax25.git as described in your link
above. Unfortunately, with those binaries the behavior is
exactly the same as with the Debian-packaged ones.

For testing the newly-built binaries I have again used
structurally valid (although currently unassigned) ham callsigns
to exclude the callsign format as a possible problem source.

$ cat /etc/ax25/axports
# /etc/ax25/axports
#
# The format of this file is:
#
# name callsign speed paclen window description
#
#
#1 OH2BNS-1 1200 255 2 144.675 MHz (1200 bps)
#2 OH2BNS-9 38400 255 7 TNOS/Linux (38400 bps)
cb DL1ABG-1 1200 255 2 CBPR (1200bps)

$ grep ^MYCALL /etc/direwolf.conf
MYCALL DL1ABG

# /usr/local/stow/ax25/sbin/kissattach /dev/pts/6 cb
AX.25 port cb bound to device ax0
root@aletheia:~# ifconfig
ax0: flags=67<UP,BROADCAST,RUNNING> mtu 255
ax25 DL1ABG-1 txqueuelen 10 (AMPR AX.25)
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

$ LANG=en /usr/local/stow/ax25/bin/call cb DL1ABD
GW4PTS AX.25 Connect 2.0.1
AX25_WINDOW: Invalid argument

$ ldd /usr/local/stow/ax25/bin/call
linux-vdso.so.1 (0x00007ffc68b6d000)
libncursesw.so.6 => /lib/x86_64-linux-gnu/libncursesw.so.6 (0x00007ff0e0b0c000)
libtinfo.so.6 => /lib/x86_64-linux-gnu/libtinfo.so.6 (0x00007ff0e0adb000)
libax25.so.1 => /usr/local/lib/libax25.so.1 (0x00007ff0e0acf000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007ff0e0906000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007ff0e08ff000)
/lib64/ld-linux-x86-64.so.2 (0x00007ff0e0ba4000)

Regards,
Karsten

<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
Everything you've setup looks correct.  What version of Debian and
which kernel version are you running?   When running your axcall
command, maybe you can run it via "strace -f" to see more details of
where this is failing?<br>
<br>
Ps.  You can look how I start up my AX25 stack here (
<a class="moz-txt-link-freetext" href="http://www.trinityos.com/HAM/CentosDigitalModes/RPi/etc/ax25/ax25-up.new">http://www.trinityos.com/HAM/CentosDigitalModes/RPi/etc/ax25/ax25-up.new</a>
) but once your stack is running, try running these echo statements
and see if anything looks wrong:<br>
--<br>
<tt>   echo "Displaying current system kissparms"</tt><tt><br>
</tt><tt>   echo "Displaying current system kissparms" &gt;&gt; $LOG</tt><tt><br>
</tt><tt>   echo "--"</tt><tt><br>
</tt><tt>   echo "--" &gt;&gt; $LOG</tt><tt><br>
</tt><tt>   echo "AX25 protocol mode (0=Norm* 1=Extd)               
: `cat /proc/sys/net/ax25/$AXINT/ax25_default_mode`"</tt><tt><br>
</tt><tt>   echo "AX25 protocol mode (0=Norm* 1=Extd)               
: `cat /proc/sys/net/ax25/$AXINT/ax25_default_mode`" &gt;&gt; $LOG</tt><tt><br>
</tt><tt>   echo "AX25 backoff type (0=Linear 1=Expon*)             
: `cat /proc/sys/net/ax25/$AXINT/backoff_type`"</tt><tt><br>
</tt><tt>   echo "AX25 backoff type (0=Linear 1=Expon*)             
: `cat /proc/sys/net/ax25/$AXINT/backoff_type`" &gt;&gt; $LOG</tt><tt><br>
</tt><tt>   echo "AX25 connect mode (0=none 1=network 2=all*)       
: `cat /proc/sys/net/ax25/$AXINT/connect_mode`"</tt><tt><br>
</tt><tt>   echo "AX25 connect mode (0=none 1=network 2=all*)       
: `cat /proc/sys/net/ax25/$AXINT/connect_mode`" &gt;&gt; $LOG</tt><tt><br>
</tt><tt>   echo "AX25 Extd window size (num of unacked packets 32*)
: `cat /proc/sys/net/ax25/$AXINT/extended_window_size`"</tt><tt><br>
</tt><tt>   echo "AX25 Extd window size (num of unacked packets 32*)
: `cat /proc/sys/net/ax25/$AXINT/extended_window_size`" &gt;&gt;
$LOG</tt><tt><br>
</tt><tt>   echo "AX25 idle timeout (idle session timeout in M 20*) 
: `cat /proc/sys/net/ax25/$AXINT/idle_timeout`"</tt><tt><br>
</tt><tt>   echo "AX25 idle timeout (idle session timeout in M 20*) 
: `cat /proc/sys/net/ax25/$AXINT/idle_timeout`" &gt;&gt; $LOG</tt><tt><br>
</tt><tt>   echo "AX25 AXIP mode (0=Datagram* 1=VirtConnection)     
: `cat /proc/sys/net/ax25/$AXINT/ip_default_mode`"</tt><tt><br>
</tt><tt>   echo "AX25 AXIP mode (0=Datagram* 1=VirtConnection)     
: `cat /proc/sys/net/ax25/$AXINT/ip_default_mode`" &gt;&gt; $LOG</tt><tt><br>
</tt><tt>   echo "AX25 max packet size (256*)                       
: `cat /proc/sys/net/ax25/$AXINT/maximum_packet_length`"</tt><tt><br>
</tt><tt>   echo "AX25 max packet size (256*)                       
: `cat /proc/sys/net/ax25/$AXINT/maximum_packet_length`" &gt;&gt;
$LOG</tt><tt><br>
</tt><tt>   echo "AX25 max packet retry count (10*)                 
: `cat /proc/sys/net/ax25/$AXINT/maximum_retry_count`"</tt><tt><br>
</tt><tt>   echo "AX25 max packet retry count (10*)                 
: `cat /proc/sys/net/ax25/$AXINT/maximum_retry_count`" &gt;&gt;
$LOG</tt><tt><br>
</tt><tt>   echo "AX25 protcol version (DAMA Slave)                 
: `cat /proc/sys/net/ax25/$AXINT/protocol`"</tt><tt><br>
</tt><tt>   echo "AX25 protcol version  (DAMA Slave)                
: `cat /proc/sys/net/ax25/$AXINT/protocol`" &gt;&gt; $LOG</tt><tt><br>
</tt><tt>   echo "AX25 STD window size (num of unacked packets 2* ) 
: `cat /proc/sys/net/ax25/$AXINT/standard_window_size`"</tt><tt><br>
</tt><tt>   echo "AX25 STD window size (num of unACKed packets 2*)  
: `cat /proc/sys/net/ax25/$AXINT/standard_window_size`" &gt;&gt;
$LOG</tt><tt><br>
</tt><tt>   echo "AX25 T1 timer (unacked packet retry 10000mS*)     
: `cat /proc/sys/net/ax25/$AXINT/t1_timeout`"</tt><tt><br>
</tt><tt>   echo "AX25 T1 timer (unacked packet retry 10000mS*)     
: `cat /proc/sys/net/ax25/$AXINT/t1_timeout`" &gt;&gt; $LOG</tt><tt><br>
</tt><tt>   echo "AX25 T2 timer (wait for 2nd RX packet 3000mS*)    
: `cat /proc/sys/net/ax25/$AXINT/t2_timeout`"</tt><tt><br>
</tt><tt>   echo "AX25 T2 timer (wait for 2nd RX packet 3000mS*)    
: `cat /proc/sys/net/ax25/$AXINT/t2_timeout`" &gt;&gt; $LOG</tt><tt><br>
</tt><tt>   echo "AX25 T3 timer (link still up check 300000mS*)     
: `cat /proc/sys/net/ax25/$AXINT/t3_timeout`"</tt><tt><br>
</tt><tt>   echo "AX25 T3 timer (link still up check 300000mS*)     
: `cat /proc/sys/net/ax25/$AXINT/t3_timeout`" &gt;&gt; $LOG</tt><br>
--<br>
<br>
<br>
--David<br>
KI6ZHD<br>
<br>
<br>
<div class="moz-cite-prefix">On 01/13/2022 12:32 PM, Karsten Merker
wrote:<br>
</div>
<blockquote cite="mid:[email protected]"
type="cite">
<pre wrap="">On Thu, Jan 13, 2022 at 07:45:34AM -0800 David Ranch wrote:

</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">$ LANG=en axcall cb 13CB42
GW4PTS AX.25 Connect v1.11
AX25_WINDOW: Invalid argument
</pre>
</blockquote>
</blockquote>
<pre wrap="">
Please post your /etc/ax25/axports file as I imagine there is an error in there. That configuration file is known to be sensitive to extra
characters, CR/LF, etc. Here is a working example where those are TABS creating the space between columns:
--
#portname callsign speed paclen window description
d710 KI6ZHD 9600 255 4 built-in D710 TNC at 1200baud
</pre>
</blockquote>
<pre wrap="">
Hello,

many thanks for your help. I have attached my /etc/ax25/axports
file to this mail.

</pre>
<blockquote type="cite">
<pre wrap="">Also.. it should be noted that your given destination callsign
is NOT a valid amateur radio callsign.
</pre>
</blockquote>
<pre wrap="">
Indeed, but that is unavoidable when operating AX.25 on CB radio
instead of on the ham bands.

</pre>
<blockquote type="cite">
<pre wrap="">As such, some software (not necessarily AX.25 code) might break
is unexpected ways.
</pre>
</blockquote>
<pre wrap="">
Yes, that could of course happen. To make sure that the source
of the problem at hand isn't using callsigns that do not strictly
comply with the ITU-mandated format for ham callsigns while still
fulfilling the requirements of the AX.25 spec (up to 6
characters, either uppercase ASCII letters or numbers), I had
already run a bunch of tests with structurally valid ham radio
callsigns (both for the local AX.25 port as well as for the
destination). The behaviour of axcall was exactly the same with
the CB and with the ham callsigns.

</pre>
<blockquote type="cite">
<pre wrap="">Where are you getting your axcall binary? Is it from the Debian repos?
</pre>
</blockquote>
<pre wrap="">
Yes, from Debian/sid.

</pre>
<blockquote type="cite">
<pre wrap="">If so, that code is rather OLD and this is due to the primary
maintainer not marking new releases on his Git repo. What I
recommend to do is to compile a new version and use that over
the Debian repo versions. There are generally TWO versions you
can consider and I explain all of that here:

<a class="moz-txt-link-freetext" href="http://www.trinityos.com/HAM/CentosDigitalModes/RPi/rpi4-setup.html#18.install-ax25">http://www.trinityos.com/HAM/CentosDigitalModes/RPi/rpi4-setup.html#18.install-ax25</a>
</pre>
</blockquote>
<pre wrap="">
I have uninstalled the Debian ax25-apps, ax25-tools, libax25 and
libax25-dev packages and built the software from
<a class="moz-txt-link-freetext" href="https://github.com/ve7fet/linuxax25.git">https://github.com/ve7fet/linuxax25.git</a> as described in your link
above. Unfortunately, with those binaries the behavior is
exactly the same as with the Debian-packaged ones.

For testing the newly-built binaries I have again used
structurally valid (although currently unassigned) ham callsigns
to exclude the callsign format as a possible problem source.

$ cat /etc/ax25/axports
# /etc/ax25/axports
#
# The format of this file is:
#
# name callsign speed paclen window description
#
#
#1 OH2BNS-1 1200 255 2 144.675 MHz (1200 bps)
#2 OH2BNS-9 38400 255 7 TNOS/Linux (38400 bps)
cb DL1ABG-1 1200 255 2 CBPR (1200bps)

$ grep ^MYCALL /etc/direwolf.conf
MYCALL DL1ABG

# /usr/local/stow/ax25/sbin/kissattach /dev/pts/6 cb
AX.25 port cb bound to device ax0
root@aletheia:~# ifconfig
ax0: flags=67&lt;UP,BROADCAST,RUNNING&gt; mtu 255
ax25 DL1ABG-1 txqueuelen 10 (AMPR AX.25)
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

$ LANG=en /usr/local/stow/ax25/bin/call cb DL1ABD
GW4PTS AX.25 Connect 2.0.1
AX25_WINDOW: Invalid argument

$ ldd /usr/local/stow/ax25/bin/call
linux-vdso.so.1 (0x00007ffc68b6d000)
libncursesw.so.6 =&gt; /lib/x86_64-linux-gnu/libncursesw.so.6 (0x00007ff0e0b0c000)
libtinfo.so.6 =&gt; /lib/x86_64-linux-gnu/libtinfo.so.6 (0x00007ff0e0adb000)
libax25.so.1 =&gt; /usr/local/lib/libax25.so.1 (0x00007ff0e0acf000)
libc.so.6 =&gt; /lib/x86_64-linux-gnu/libc.so.6 (0x00007ff0e0906000)
libdl.so.2 =&gt; /lib/x86_64-linux-gnu/libdl.so.2 (0x00007ff0e08ff000)
/lib64/ld-linux-x86-64.so.2 (0x00007ff0e0ba4000)

Regards,
Karsten
</pre>
</blockquote>
<br>
</body>
</html>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Re: David Ranch

Hello Christoph,

Please don't allow the Debian powers at be to disable those various KISS / AX.25 / NETROM / ROSE features. Many people use those features from the
true Debian releases! There are some known kernel bugs in there that
various people are trying to resolve but the code is still very much functional.

Hi David,

I didn't mean to imply that, that was just a question.

There are few ax25 users nowadays, so it's somewhat hard for the
non-users like me to maintain those packages. It would be interesting
to know which bits need fixing to get them on track again.

Christoph DF7CB

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hello,

David, thank you for your Mail.

My questions is:
which kernel versioon is affected, and at which cpu architecture? And what's the debian release?

The described problem seems to me a kernel issue (-> not a problem of libax25 or call).

The setsockopt call fails.

And we remember the exterrnal kernel patch in kernel 5.9x that arrived in 2020, that broke exactly the setsockopt function in 64bit systems.

This is the point where would start to search.

Sinice debian comes with many installable kernels, I think it's worth too test with downgrading the kernel to below 5.9x.
I've not searched which kernel version has integrated the fix for the setsockopt bug.

See appendix below.

Am 14.01.2022 um 16:58 schrieb David Ranch <[email protected]>:

Hello Ralf, Thomas,

It's looking like one of these recent untested Linux kernel commits, accepted by random non-packet developers, has made part of the Linux AX.25 stack toxic. Work is going on to bisect which kernel started the issue but I wanted to forward this

directly on since I don't know if any of you are on the debian-hams list:

https://lists.debian.org/debian-hams/2022/01/msg00106.html

and it seems this user has also posted the issue in the Fedora tracker as well:

https://bugzilla.redhat.com/show_bug.cgi?id=2039199

Is it possible that one of you can give this a look? I'm still hoping that there is a way to get some level of unit tests put into some form of a Linux kernel CI process but I still haven't heard of any solution available.

--David
KI6ZHD

vy 73,
- Thomas dl9sau


Appendix: kernel fix for the setsockopt stuff.

Von: Ralf Baechle <[email protected]>
Betreff: [PATCH v2 1/2] ax25: Fix use of copy_from_sockptr() in ax25_setsockopt()
Datum: 12. Oktober 2021 um 22:05:29 MESZ
An: [email protected]
Kopie: "David S. Miller" <[email protected]>, Jakub Kicinski <[email protected]>, Christoph Hellwig <[email protected]>, Thomas Osterried <[email protected]>, [email protected]
Message-Id: <2dea23e9208d008e74faddf92acf4ef557f97a85.1634069168.git.ralf@linux-mips.org>

The destination pointer passed to copy_from_sockptr() is an unsigned long * but the source in userspace is an unsigned int.

This happens to work on 32 bit but breaks 64-bit where bytes 4..7 will not
be initialized. By luck it may work on little endian but on big endian
where the userspace data is copied to the upper 32 bit of the destination it's most likely going to break.

Signed-off-by: Ralf Baechle <[email protected]>
Reviewed-by: Christoph Hellwig <[email protected]>
Fixes: a7b75c5a8c41 ("net: pass a sockptr_t into ->setsockopt")
---
net/ax25/af_ax25.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/net/ax25/af_ax25.c b/net/ax25/af_ax25.c
index 2631efc6e359..5e7ab76f7f9b 100644
--- a/net/ax25/af_ax25.c
+++ b/net/ax25/af_ax25.c
@@ -534,7 +534,7 @@ static int ax25_setsockopt(struct socket *sock, int level, int optname,
ax25_cb *ax25;
struct net_device *dev;
char devname[IFNAMSIZ];
- unsigned long opt;
+ unsigned int opt;
int res = 0;

if (level != SOL_AX25)
@@ -566,7 +566,7 @@ static int ax25_setsockopt(struct socket *sock, int level, int optname,
break;

case AX25_T1:
- if (opt < 1 || opt > ULONG_MAX / HZ) {
+ if (opt < 1 || opt > UINT_MAX / HZ) {
res = -EINVAL;
break;
}
@@ -575,7 +575,7 @@ static int ax25_setsockopt(struct socket *sock, int level, int optname,
break;

case AX25_T2:
- if (opt < 1 || opt > ULONG_MAX / HZ) {
+ if (opt < 1 || opt > UINT_MAX / HZ) {
res = -EINVAL;
break;
}
@@ -591,7 +591,7 @@ static int ax25_setsockopt(struct socket *sock, int level, int optname,
break;

case AX25_T3:
- if (opt < 1 || opt > ULONG_MAX / HZ) {
+ if (opt < 1 || opt > UINT_MAX / HZ) {
res = -EINVAL;
break;
}
@@ -599,7 +599,7 @@ static int ax25_setsockopt(struct socket *sock, int level, int optname,
break;

case AX25_IDLE:
- if (opt > ULONG_MAX / (60 * HZ)) {
+ if (opt > UINT_MAX / (60 * HZ)) {
res = -EINVAL;
break;
}
--
2.31.1

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am Sun, Jan 16, 2022 at 07:44:00PM +0100 schrieb Thomas Osterried:

Am 14.01.2022 um 16:58 schrieb David Ranch <[email protected]>:

[...]

It's looking like one of these recent untested Linux kernel commits, accepted by random non-packet developers, has made part of the Linux
AX.25 stack toxic. Work is going on to bisect which kernel started the issue but I wanted to forward this directly on since I don't know if any
of you are on the debian-hams list:

https://lists.debian.org/debian-hams/2022/01/msg00106.html

and it seems this user has also posted the issue in the Fedora tracker as well:

https://bugzilla.redhat.com/show_bug.cgi?id=2039199

Is it possible that one of you can give this a look? I'm still hoping
that there is a way to get some level of unit tests put into some form
of a Linux kernel CI process but I still haven't heard of any solution available.

David, thank you for your Mail.

My questions is: which kernel versioon is affected, and at
which cpu architecture? And what's the debian release?

Hello,

I'm the person who originally posted to the debian-hams list
about the problem with axcall. I'm running Debian/sid a.k.a.
"unstable", i.e. Debian's development branch.

$ uname -v
#1 SMP Debian 5.15.5-2 (2021-12-18)

$ uname -m
x86_64

The described problem seems to me a kernel issue (-> not a
problem of libax25 or call).

The setsockopt call fails.

And we remember the exterrnal kernel patch in kernel 5.9x that
arrived in 2020, that broke exactly the setsockopt function in
64bit systems.

This is the point where would start to search.

Sinice debian comes with many installable kernels, I think it's
worth too test with downgrading the kernel to below 5.9x.

I've now built kernel 5.8.9 for testing purposes and indeed with
kernel 5.8.9 axcall doesn't show the error.

I've not searched which kernel version has integrated the fix
for the setsockopt bug.

Appendix: kernel fix for the setsockopt stuff.

AFAICS it this fix is not yet contained in any official kernel
release, but a functionally equivalent patch seems to be queued
up for 5.17:

https://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queue.git/commit/?id=9371937092d5fd502032c1bb4475b36b39b1f1b3

I'll try building 5.16.1 with the patch applied and will then
report back. That might take a bit, though - this box is old
and slow :-).

Kind regards and many thanks for everybody's help,
Karsten

Von: Ralf Baechle <[email protected]>
Betreff: [PATCH v2 1/2] ax25: Fix use of copy_from_sockptr() in ax25_setsockopt()
Datum: 12. Oktober 2021 um 22:05:29 MESZ
An: [email protected]
Kopie: "David S. Miller" <[email protected]>, Jakub Kicinski <[email protected]>, Christoph Hellwig <[email protected]>, Thomas Osterried <[email protected]>, [email protected]
Message-Id: <2dea23e9208d008e74faddf92acf4ef557f97a85.1634069168.git.ralf@linux-mips.org>

The destination pointer passed to copy_from_sockptr() is an unsigned long * but the source in userspace is an unsigned int.

This happens to work on 32 bit but breaks 64-bit where bytes 4..7 will not be initialized. By luck it may work on little endian but on big endian where the userspace data is copied to the upper 32 bit of the destination it's most likely going to break.

Signed-off-by: Ralf Baechle <[email protected]>
Reviewed-by: Christoph Hellwig <[email protected]>
Fixes: a7b75c5a8c41 ("net: pass a sockptr_t into ->setsockopt")
---
net/ax25/af_ax25.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/net/ax25/af_ax25.c b/net/ax25/af_ax25.c
index 2631efc6e359..5e7ab76f7f9b 100644
--- a/net/ax25/af_ax25.c
+++ b/net/ax25/af_ax25.c
@@ -534,7 +534,7 @@ static int ax25_setsockopt(struct socket *sock, int level, int optname,
ax25_cb *ax25;
struct net_device *dev;
char devname[IFNAMSIZ];
- unsigned long opt;
+ unsigned int opt;
int res = 0;

if (level != SOL_AX25)
@@ -566,7 +566,7 @@ static int ax25_setsockopt(struct socket *sock, int level, int optname,
break;

case AX25_T1:
- if (opt < 1 || opt > ULONG_MAX / HZ) {
+ if (opt < 1 || opt > UINT_MAX / HZ) {
res = -EINVAL;
break;
}
@@ -575,7 +575,7 @@ static int ax25_setsockopt(struct socket *sock, int level, int optname,
break;

case AX25_T2:
- if (opt < 1 || opt > ULONG_MAX / HZ) {
+ if (opt < 1 || opt > UINT_MAX / HZ) {
res = -EINVAL;
break;
}
@@ -591,7 +591,7 @@ static int ax25_setsockopt(struct socket *sock, int level, int optname,
break;

case AX25_T3:
- if (opt < 1 || opt > ULONG_MAX / HZ) {
+ if (opt < 1 || opt > UINT_MAX / HZ) {
res = -EINVAL;
break;
}
@@ -599,7 +599,7 @@ static int ax25_setsockopt(struct socket *sock, int level, int optname,
break;

case AX25_IDLE:
- if (opt > ULONG_MAX / (60 * HZ)) {
+ if (opt > UINT_MAX / (60 * HZ)) {
res = -EINVAL;
break;
}
--
2.31.1

--
Hiermit widerspreche ich ausdrücklich der Nutzung sowie der Weitergabe
meiner personenbezogenen Daten für Zwecke der Werbung sowie der Markt-
oder Meinungsforschung.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am Mon, Jan 17, 2022 at 10:19:05PM +0100 schrieb Karsten Merker:

Am Sun, Jan 16, 2022 at 07:44:00PM +0100 schrieb Thomas Osterried:

[...]

I've now built kernel 5.8.9 for testing purposes and indeed with
kernel 5.8.9 axcall doesn't show the error.

I've not searched which kernel version has integrated the fix
for the setsockopt bug.

Appendix: kernel fix for the setsockopt stuff.

AFAICS it this fix is not yet contained in any official kernel
release, but a functionally equivalent patch seems to be queued
up for 5.17:

https://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queue.git/commit/?id=9371937092d5fd502032c1bb4475b36b39b1f1b3

I'll try building 5.16.1 with the patch applied and will then
report back.

Hello,

the build is ready and I can report that the problem doesn't
occur anymore with the patch above applied on top of kernel 5.16.1.

Regards,
Karsten
--
Hiermit widerspreche ich ausdrücklich der Nutzung sowie der Weitergabe
meiner personenbezogenen Daten für Zwecke der Werbung sowie der Markt-
oder Meinungsforschung.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hello,

thank you for your efforts.

Let's summarize:
The ioctl issue is fixed and expected to come with the next kernel 5.17.
Kernel up to 5.8.9 are not affected (testet); probably until 5.8.18 (latest in 5.8 tree).
32bit architectures are not affected.

For the kernels in >5.9 up to 5.16.x, users have to apply the patch.

Long term kernels: "Only important bugfixes are applied to such kernels and they don't usually see very frequent releases".
(https://www.kernel.org/category/releases.html)

Kernel 5.15 is a longterm kernel (planned EOL Oct 2023).
Kernel 5.10 is a longterm kernel (planned EOL Dec 2026).

Kernel 5.4 and some of the 4.x are also longterm kernels, but should not have been affected by the problem.

I see the need, that the patch is regarded as "important patch", for reaching longterm kernels 5.10 and 5.15.

vy 73,
- Thomas dl9sau

Am 18.01.2022 um 08:18 schrieb Karsten Merker <[email protected]>:

Am Mon, Jan 17, 2022 at 10:19:05PM +0100 schrieb Karsten Merker:

Am Sun, Jan 16, 2022 at 07:44:00PM +0100 schrieb Thomas Osterried:

[...]

I've now built kernel 5.8.9 for testing purposes and indeed with
kernel 5.8.9 axcall doesn't show the error.

I've not searched which kernel version has integrated the fix
for the setsockopt bug.

Appendix: kernel fix for the setsockopt stuff.

AFAICS it this fix is not yet contained in any official kernel
release, but a functionally equivalent patch seems to be queued
up for 5.17:

https://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queue.git/commit/?id=9371937092d5fd502032c1bb4475b36b39b1f1b3

I'll try building 5.16.1 with the patch applied and will then
report back.

Hello,

the build is ready and I can report that the problem doesn't
occur anymore with the patch above applied on top of kernel 5.16.1.

Regards,
Karsten
--
Hiermit widerspreche ich ausdrücklich der Nutzung sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der Werbung sowie der Markt-
oder Meinungsforschung.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 18.01.22 at 18:38 wrote Thomas Osterried:

I see the need, that the patch is regarded as "important patch", for reaching longterm kernels 5.10 and 5.15.

This is interesting. I am running kernel 5.10.70 (debian) on a raspi 4
and a kernel 5.13.0 (ubuntu) on x64 and do not experience the problem,
i.e. axcall works for me.

73 oe1rsa

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am Tue, Jan 18, 2022 at 07:13:49PM +0100 schrieb Roland OE1RSA:

On 18.01.22 at 18:38 wrote Thomas Osterried:

I see the need, that the patch is regarded as "important patch", for

reaching longterm kernels 5.10 and 5.15.

This is interesting. I am running kernel 5.10.70 (debian) on a raspi 4 and a kernel 5.13.0 (ubuntu) on x64 and do not experience the problem, i.e. axcall works for me.

That's indeed interesting. I'll try building 5.10.70 and 5.13.0 on my box and see whether things work with those or not.

One thing that might be relevant regarding the Raspi 4: are you
running an armhf or an arm64 userland on the Raspi? I ask
because although the Raspi4 has an arm64 CPU, it is rather common
to run an armhf userland on it and if I understand the situation
correctly, the kernel bug wouldn't manifest itself on a 32bit
userland.

Regards,
Karsten
--
Hiermit widerspreche ich ausdrücklich der Nutzung sowie der Weitergabe
meiner personenbezogenen Daten für Zwecke der Werbung sowie der Markt-
oder Meinungsforschung.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Karsten,

Am 19.01.22 um 12:55 schrieb Karsten Merker:

That's indeed interesting. I'll try building 5.10.70 and 5.13.0 on my box and see whether things work with those or not.

One thing that might be relevant regarding the Raspi 4: are you
running an armhf or an arm64 userland on the Raspi?

I started with an image I downloaded from:
https://raspi.debian.net

and then compiled a custom kernel.

My lscpu reads:

Architecture: aarch64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
CPU(s): 4
On-line CPU(s) list: 0-3
Thread(s) per core: 1
Core(s) per socket: 4
Socket(s): 1
NUMA node(s): 1
Vendor ID: ARM
Model: 3
Model name: Cortex-A72
Stepping: r0p3
CPU max MHz: 1500,0000
CPU min MHz: 600,0000
BogoMIPS: 108.00
NUMA node0 CPU(s): 0-3
Vulnerability Itlb multihit: Not affected
Vulnerability L1tf: Not affected
Vulnerability Mds: Not affected
Vulnerability Meltdown: Not affected
Vulnerability Spec store bypass: Vulnerable
Vulnerability Spectre v1: Mitigation; __user pointer sanitization Vulnerability Spectre v2: Vulnerable
Vulnerability Srbds: Not affected
Vulnerability Tsx async abort: Not affected
Flags: fp asimd evtstrm crc32 cpuid

From this I would conclude that I am running 64 bit? Yes?

73oe1rsa

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Re: Roland OE1RSA

I started with an image I downloaded from:
https://raspi.debian.net

and then compiled a custom kernel.

My lscpu reads:

Architecture: aarch64
CPU op-mode(s): 32-bit, 64-bit

Afaik the userland can still be either.

dpkg --print-architecture

Christoph

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am 20.01.22 um 22:21 schrieb Christoph Berg:

Afaik the userland can still be either.

dpkg --print-architecture

dpkg --print-architecture
arm64

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In case this is of interest, on my raspi 4:

#include <iostream>

int main(int argc, char* argv[]) {
std::cout << "Hello World!" << std::endl;
std::cout << "sizeof(int)=" << sizeof(int) << std::endl;
std::cout << "sizeof(long int)=" << sizeof(long int) << std::endl;
std::cout << "sizeof(long long int)=" << sizeof(long long int) << std::endl;
return 0;
}

g++ hello.cpp -o hello
./hello

Hello World!
sizeof(int)=4
sizeof(long int)=8
sizeof(long long int)=8

Btw.: Result is same on amd64

73oe1rsa

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, Jan 21, 2022 at 08:35:56AM +0100, Roland OE1RSA wrote:

In case this is of interest, on my raspi 4:

#include <iostream>

int main(int argc, char* argv[]) {
std::cout << "Hello World!" << std::endl;
std::cout << "sizeof(int)=" << sizeof(int) << std::endl;
std::cout << "sizeof(long int)=" << sizeof(long int) << std::endl;
std::cout << "sizeof(long long int)=" << sizeof(long long int) << std::endl;
return 0;
}

g++ hello.cpp -o hello
./hello

Hello World!
sizeof(int)=4
sizeof(long int)=8
sizeof(long long int)=8

Btw.: Result is same on amd64

Another question is the endianess (big endian vs. little endian),
because it may affect the unitinalized part of the variable used for the
ioctl. -- But: as far as I know, both systems are little endian.

Still can't say, why armhf behaves better in this bug case.

vy 73,
- Thomas dl9sau

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)