Hi all,

Direwolf works great for years now without any hickups. Eventually, there are some "experts" with a little or none awareness that they abuse radio traffic with their so called perfect digipeaters which emmits weather conditions every freakin minute or less, with fixed location, made of some arduinos or so... Been there, not the right path. I want to block specific callsigns from digipeating. Is that possible somehow? They are in the RF range of my digi and I can hear them very well. Suppose that this can be done with filters, but that is much more complicated cause I need to allow ALL OTHER stations (manually) ?

Thanks!

The issue here is *connected* AX.25 session so your Winlink
connections would be impacted. APRS would not be impacted since it's
unconnected traffic and still works fine.

Yes, I know that but your subject line implies that you already know the
problem is in the AX.25 stack and that might/probably not be the case. I
am using native Linux AX.25 stack with Dire Wolf DEVELOPMENT version 1.7
A (Feb 15 2021) on 4 different systems and it is working fine.

The way the Canonical backports fixes into older kernels is
difficult to track and they aren't dating things in the
changelog but I see this

The following is the commit summary from kernel.org for kernel 5.11.4
and ax.25 commits. I looked at each of these commits & none of them
should cause your symptom.

2020-11-20 rose: Fix Null pointer dereference in rose_send_frame() Anmol Karn 1
2020-07-23 AX.25: Prevent integer overflows in connect and sendmsg Dan Carpenter 1
2020-07-22 AX.25: Prevent out-of-bounds read in ax25_sendmsg() Peilin Ye 1
2020-07-22 AX.25: Fix out-of-bounds read in ax25_connect() Peilin Ye 1
2020-07-04 Documentation: networking: ax25: drop doubled word Randy Dunlap 1
2020-05-20 ax25: fix setsockopt(SO_BINDTODEVICE) Eric Dumazet 1
2020-04-28 Docs: networking: convert ax25.txt to ReST Mauro Carvalho Chehab 3
2019-09-24 ax25: enforce CAP_NET_RAW for raw sockets Ori Nimron 1

I suggest swapping some big components in your system including NOT
using the internal D-710 TNC. Once you do that you can test against the
Direwolf user land ax.25 stack & the Linux kernel mode ax.25 stack.

Just did a successful connection test between two ARM machines using
these kernels 5.10.17-v7l+ and 5.4.79-v7l+.

Also there was a massive Linux kernel code merge from the middle of
December 2020 to the first week of Jan 2021 that took the kernel from
version 5.4.83 to 5.10.11 that caused a few problems. Not sure what that
means for Ubuntu.

(posted 2021-02-04)
--
* Focal update: v5.4.55 upstream stable release (LP: #1890343)
- AX.25: Fix out-of-bounds read in ax25_connect()
- AX.25: Prevent out-of-bounds read in ax25_sendmsg()
...
- AX.25: Prevent integer overflows in connect and sendmsg
--
* Focal update: v5.4.44 upstream stable release (LP: #1881927)
- ax25: fix setsockopt(SO_BINDTODEVICE)
--

What TNC device are you using? /Basil N7NIX

On this system, it's a D710 in KISS mode connected to a Lenovo T470
(i7-7600U with 16GB RAM) running 64bit Ubuntu 20.04. I'm 99.9% sure
that if I switched away from a serial attached hardware TNC to a
software-based TNC like Direwolf, I would still see the issue. I've
done more testing with reverting the kernel to older versions but the
ones I've tested so far still fail as well:

5.8.0-44 : BAD
5.8.0-43 : BAD
5.8.0-41 : BAD
..
5.8.0-36 : BAD
..
5.4.0-66 : BAD
..
5.4.0-42 : BAD

It's clear that my mistake is that after Canonical pushes a
new kernel version and I apply it, I should reboot then test
things to KNOW if the AX25 stack has been impacted. I skipped
a few reboot cycles as different kernels were installed so I
really don't know where to start. Even then, I'm thinking this
issue might be more of a libc interface issue or something
else since going way back to 5.4.0-42 dated 2020-07-10 is
seeing the same issue.

root@hampacket3:/var/log/apt# dpkg -l | grep -e libc6 -e linux-libc
ii libc6:amd64 2.31-0ubuntu9.2 amd64 GNU C Library: Shared libraries
ii libc6-dbg:amd64 2.31-0ubuntu9.2 amd64 GNU C Library: detached
debugging symbols ii libc6-dev:amd64 2.31-0ubuntu9.2 amd64 GNU C
Library: Development Libraries and Header Files ii
linux-libc-dev:amd64 5.4.0-66.74 amd64 Linux Kernel Headers for
development

That libc6 was installed on "2021-01-28"

It's frustrating as I have no clue where to start as the machine just locks up and doesn't give any hint of where to start troubleshooting. Could be an 64bit thing. Could be an SMP thing. Dunno,

--David KI6ZHD

Tnx for the reply's.? I will do some testing and post results.
Trip - KT4WO

开云体育

Hello Trip,

Per the 2400-4800-PSK-for-APRS-Packet-Radio.pdf document, the "B" modem is the one you should use.? Neither version of this modem is superior as it's just a difference in starting "phase".? Read the PDF for details. ? Btw, you can run this "2400" modem all they way up to 3600bps using a standard MIC connector and it should work.? Warning: I did test this but not using real radios.. I was just testing two sound cards connected back to back.

As for the 4800 modem, you WILL need a connection to the radio's discriminator (aka the 9600 pin) for this wider mode.

--David
KI6ZHD

开云体育

Hello Basil,

I am NOT seeing your described symptom on various (7) Raspberry Pis running the Linux AX.25 stack with Winlink, APRS & Chattervox at 1200 & 9600 baud. My hardware is mainly RPi 4's and sound cards using direwolf.

The issue here is *connected* AX.25 session so your Winlink connections would be impacted.? APRS would not be impacted since it's unconnected traffic and still works fine.

The two kernels I am using from the Raspberry Pi Foundation (raspbian): Linux test119022321 5.4.79-v7l+ #1373 SMP Mon Nov 23 13:27:40 GMT 2020 armv7l GNU/Linux Linux pi400 5.10.11-v7l+ #1399 SMP Thu Jan 28 12:09:48 GMT 2021 armv7l GNU/Linux

The way the Canonical backports fixes into older kernels is difficult to track and they aren't dating things in the changelog but I see this

???? (posted 2021-02-04)
--
? * Focal update: v5.4.55 upstream stable release (LP: #1890343)
??? - AX.25: Fix out-of-bounds read in ax25_connect()
??? - AX.25: Prevent out-of-bounds read in ax25_sendmsg()
??? ...
??? - AX.25: Prevent integer overflows in connect and sendmsg
--
? * Focal update: v5.4.44 upstream stable release (LP: #1881927)
??? - ax25: fix setsockopt(SO_BINDTODEVICE)
--

What TNC device are you using? /Basil N7NIX

On this system, it's a D710 in KISS mode connected to a Lenovo T470 (i7-7600U with 16GB RAM) running 64bit Ubuntu 20.04.? I'm 99.9% sure that if I switched away from a serial attached hardware TNC to a software-based TNC like Direwolf, I would still see the issue.? I've done more testing with reverting the kernel to older versions but the ones I've tested so far still fail as well:

? 5.8.0-44 : BAD
? 5.8.0-43 : BAD
? 5.8.0-41 : BAD
? ..
? 5.8.0-36 : BAD
? ..
? 5.4.0-66 : BAD
? ..
? 5.4.0-42 : BAD


It's clear that my mistake is that after Canonical pushes a new kernel version and I apply it, I should reboot then test things to KNOW if the AX25 stack has been impacted.? I skipped a few reboot cycles as different kernels were installed so I really don't know where to start.? Even then, I'm thinking this issue might be more of a libc interface issue or something else since going way back to 5.4.0-42 dated 2020-07-10 is seeing the same issue.

?? root@hampacket3:/var/log/apt# dpkg -l | grep -e libc6 -e linux-libc
?? ii? libc6:amd64??????????????????????????????? 2.31-0ubuntu9.2?????????????????????? amd64??????? GNU C Library: Shared libraries
?? ii? libc6-dbg:amd64??????????????????????????? 2.31-0ubuntu9.2?????????????????????? amd64??????? GNU C Library: detached debugging symbols
?? ii? libc6-dev:amd64??????????????????????????? 2.31-0ubuntu9.2?????????????????????? amd64??????? GNU C Library: Development Libraries and Header Files
?? ii? linux-libc-dev:amd64?????????????????????? 5.4.0-66.74?????????????????????????? amd64??????? Linux Kernel Headers for development

That libc6 was installed on "2021-01-28"


It's frustrating as I have no clue where to start as the machine just locks up and doesn't give any hint of where to start troubleshooting.? Could be an 64bit thing.? Could be an SMP thing.? Dunno,

--David
KI6ZHD

On Sun, Mar 7, 2021 at 08:48 AM, kt67 wrote:

And what about the 3600 bit modem?

That should have been 4800 bit modem.

I would like to add a 2nd port (on 440Mhz) at a local mtn. top node--
As I have users that use UZ7HO I would like to be compatible for them.
I see there are (2) 2400 modes--A and B in UZ7HO. From the Direwolf
side of things, which would be better?(line of sight links)
Has anyone tested in real world links?
And what about the 3600 bit modem?
Thoughts?
Oh --also-- the radios I am using DO NOT have the 9600 HS ports
so any mode would need to go thru the MIC connector.
(old public safety radios)

Tnx de Trip - KT4WO

I am NOT seeing your described symptom on various (7) Raspberry Pis running the Linux AX.25 stack with Winlink, APRS & Chattervox at 1200 & 9600 baud. My hardware is mainly RPi 4's and sound cards using direwolf.

I do NOT use Linpac or Gnome3

The two kernels I am using from the Raspberry Pi Foundation (raspbian): Linux test119022321 5.4.79-v7l+ #1373 SMP Mon Nov 23 13:27:40 GMT 2020 armv7l GNU/Linux Linux pi400 5.10.11-v7l+ #1399 SMP Thu Jan 28 12:09:48 GMT 2021 armv7l GNU/Linux

What TNC device are you using? /Basil N7NIX

开云体育

Hello Everyone,

I wanted to check with the larger community to see if others are experiencing system crashes when making connected AX.25 sessions.? I have confirmed that this is NOT an RFI thing and sending unconnected (UI) transmissions (beacons) small or large is fine, and even initiating the beginning of connected session to a non-existent remote station callsign is OK with axcall, linpac, etc.? The issue is that once a valid AX.25 connection is established, I begin to receive data from the remote station and then seemingly when my station is to send an ACK packet, the machine locks hard.? No segmentation failure, no kernel panic, the Gnome3 display stays up but the screen no longer updates , nothing in the logs and even stops pinging from a different machine on the LAN.? The machine is 100% crashed and this is 100% reproducible.

Is anyone else seeing this?

?? $ uname -a
?? Linux hampacket3 5.8.0-44-generic #50~20.04.1-Ubuntu SMP Wed Feb 10 21:07:30 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

--David
KI6ZHD

开云体育

Hello John,

Thank you for the details.? Very interesting and the vapn.org link is an interesting read.

Guess I should chime in since much of the reasoning for WinRPR and TeensyTNC existing is due in part to my plea to SCS to not have Robust Packet die on the vine after the demise of the most excellent Tracker TNC DSP.? Word leaked out after a productive summer 2020 effort from SCS folks with some of us testing their beta releases leading to this post.

Considering that this VAPN web page still mentions that the WinRPR software is essentially a proprietary SCS product (of sorts), I bet that kills any hope to add any support into Direwolf.

The existence of WinRPR gives hope that the modem portion can be segregated in such a way to port into something like DireWolf in time. This would be quite spectacular.

I disagree.? Until SCS releases some form of a specification documents with clear license that's compatible with say GPL, Apache, etc. with releasing any liability to any developer, I doubt any support will ever happen.

Note both WinRPR and TeensyTNC are basically the same thing under the hood to include...

• HF Packet Modem (300 AFSK)
• Robust Packet 300
• Robust Packet 600
• 1200 AFSK
• 9600 FSK
• Full AX.25 stack in the form of the WA8DED "TheFirmware" - really nice to access any TNC command via Escape sequence.

WinRPR adds?graphical displays to the mix.? Teensy is just a virtual serial port to the basic TNC.

This last line is confusing to me.? As I understand say the G8BPQ Teensy TNC project supporting classic packet as well as ARDOP is a *complete* TNC.? That effort in the TNC is not "just a virtual serial port".? Is this WinRPR + Teensy components BOTH required for a working RPR solution?

WinRPR has become quite popular in the small RPR community and provides a free way for third party monitoring a proprietary mode... solving one legal issue.

Is this a receive only solution today or can it also transmit?? I do know of the SCS PMON Raspberry Pi image to do monitoring only for Pactor traffic but it doesn't seem to support RPR:

??

Anyway, that's enough for now, but wanted to explain what is really going on in the RPR world.

Seems very interesting to me as I love everything packet yet I'm surprised I never heard of this WinRPR effort.? Maybe the reason for that is that I don't do Windows anything whenever possible.? I guess I'll need to add myself to the groups.io discussion to see what's really going on but I still don't see why WB2OSZ would want to try adding RPR support into Direwolf when this is still seemingly proprietary and probably patented.

--David
KI6ZHD

开云体育

Please do not hijack email threads for new topics.? Please re-post your email with a new, relevant subject.

--David
KI6ZHD

Hi David and John,

David, sorry for throwing you into cold water with respect to RPR. John, many thanks for the background. It helps a lot in understanding what is going on.
But you are right with respect to the license question. I did not notice that all this development of the modem is still in the hands of SCS. Unfortunately there is no real license information for WinRPR other than the statement that it is only free for amateur use.
Without having it as a kind of open standard it is unlikely to have any implementation apart from WinRPR and the Teensy TNC. But maybe its worth to keep an eye on how the situation evolves.

Thank you for the discussion!
Mario

开云体育

开云体育

Hello Mario,

I had to do some Googling for "Teensy RPR TNC" but it seems this is a good starting point.? Yes?

??
??


I understand Robust Packet available from SCS is proprietary and patented.? The world of reverse engineering can make somethings legal but depends on the country.? Do you have any details there?? Also, do you know if the team doing the reverse engineering is documenting the entire effort?? Without that, it would be very difficult to implement anything without having someone reverse engineer their embedded processor code into something that would run in say Direwolf.

--David
KI6ZHD

With the Teensy RPR TNC shortwave AX25 becomes some more traction again maybe.
Is there any plan to integrate RPR into Direwolf as well? It would probably be some nice feature to monitor RPR APRS with Openwebrx for example.

开云体育

Please see the Direwolf archives for this.? It's a known issue on the Windows side:

?? /g/direwolf/message/4644?p=,,,20,0,0,0::Created,,CM119+PTT,20,2,0,78512914

--David
KI6ZHD

Here's a longer, complete log (with nothing snipped out), showing several connection attempts with different digipeater paths. The radio was turned off, so nothing was received. All connections were from the same client (Outpost PMM); the only difference is the digipeater paths. It seems noteworthy that only one of the three connections resulted in the ominous message.