axlisten -t -a -ccb: fm 13CB99-1 to 13CB42 ctl UI^ pid=F0(Text) len 12
direwolf logInvalid transmit channel 2 from KISS client app.
axlisten -t -a -ccb: fm 13CB99-1 to 13CB42 ctl UI^ pid=F0(Text) len 19
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
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?
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
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.
Re: Karsten Merker
Does the kernel still support ax25? I remember talk of dropping that.This is because there is only one place where the "AX25_WINDOW" errorDo you perhaps have an idea what else could be the source of the problem?
message is printed:
if (setsockopt
(fd, SOL_AX25, AX25_WINDOW, &window,
sizeof(window)) == -1) {
Christoph
$ LANG=en axcall cb 13CB42
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
$ 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.
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
On Thu, Jan 13, 2022 at 07:45:34AM -0800 David Ranch wrote:
Hello,Please post your /etc/ax25/axports file as I imagine there is an error in$ LANG=en axcall cb 13CB42
GW4PTS AX.25 Connect v1.11
AX25_WINDOW: Invalid argument
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
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 callsignIndeed, but that is unavoidable when operating AX.25 on CB radio
is NOT a valid amateur radio callsign.
instead of on the ham bands.
As such, some software (not necessarily AX.25 code) might breakYes, that could of course happen. To make sure that the source
is unexpected ways.
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 primaryI have uninstalled the Debian ax25-apps, ax25-tools, libax25 and
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
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
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.
This is the point where would start to search.
Am 14.01.2022 um 16:58 schrieb David Ranch <dranch@trinnet.net>:
Hello Ralf, Thomas,directly on since I don't know if any of you are on the debian-hams list:
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
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
Von: Ralf Baechle <ralf@linux-mips.org>
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: netdev@vger.kernel.org
Kopie: "David S. Miller" <davem@davemloft.net>, Jakub Kicinski <kuba@kernel.org>, Christoph Hellwig <hch@lst.de>, Thomas Osterried <thomas@osterried.de>, linux-hams@vger.kernel.org
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 <ralf@linux-mips.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
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
[...]Am 14.01.2022 um 16:58 schrieb David Ranch <dranch@trinnet.net>:
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?
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.
Appendix: kernel fix for the setsockopt stuff.
Von: Ralf Baechle <ralf@linux-mips.org>
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: netdev@vger.kernel.org
Kopie: "David S. Miller" <davem@davemloft.net>, Jakub Kicinski <kuba@kernel.org>, Christoph Hellwig <hch@lst.de>, Thomas Osterried <thomas@osterried.de>, linux-hams@vger.kernel.org
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 <ralf@linux-mips.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
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
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.
I see the need, that the patch is regarded as "important patch", for reaching longterm kernels 5.10 and 5.15.
Am 18.01.2022 um 08:18 schrieb Karsten Merker <merker@debian.org>:
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.
I see the need, that the patch is regarded as "important patch", for reaching longterm kernels 5.10 and 5.15.
On 18.01.22 at 18:38 wrote Thomas Osterried:
I see the need, that the patch is regarded as "important patch", forreaching 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 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
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
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 301 |
Nodes: | 16 (2 / 14) |
Uptime: | 214:58:40 |
Calls: | 6,744 |
Calls today: | 4 |
Files: | 12,272 |
Messages: | 5,369,111 |