On Mar 1, 2021, at 8:04 PM, Carl Makin <carl@...> wrote:

?Hi Mike,

On 2 Mar 2021, at 2:13 am, Mike Allred <mike@...> wrote:

If I could have both APRS and Winlink using the native AX.25 stack then it would all be seamless in theory.

There are a couple of solutions, one is rxecho,??that routes ax25 packets between ports, or there is kissnetd??that echos kiss frames between multiple ptys.

net2kiss might also be useful as yaac can connect to a network TNC (I do that here with a moxa ip-serial port box), perhaps in conjunction with kissnetd.

Carl.

(vk1kcm)

No, YAAC does not at the present time support access to the Linux native AX.25 protocol stack.

Part of the problem is that YAAC is a Java application and the native AX.25 stack is not accessible through standard Java APIs (the Java runtime only supports Internet Protocol V4 and V6), so it would require a platform-specific native library (using the Java Native Interface API to implement it) to be able to create sockets of address family (protocol) AF_AX25, and then dynamically select the appropriate platform-specific native code variant at runtime (as the JSSC library does to access serial ports). Note that "platform-specific" means not only being Linux, but Linux on a particular hardware architecture (32-bit versus 64-bit Intel CPU, ARM CPU, etc.). It's a solveable problem (JSSC has already solved it), but not sure if it's worth the effort because....

Secondly, a given radio port operates on only one frequency (not switchable by AX.25 stack client applications), and different frequencies are used for connected-mode packet (PBBS) versus APRS non-connected mode. So the user would have to properly select the appropriate AX.25 native port (by callsign-SSID), where YAAC would not be able to help the user in determining which was the correct one.

As such, there hasn't been enough demand to create a Linux-only YAAC plugin to support access to the native AX.25 stack when there are plenty of other ways to connect YAAC to TNCs. Most APRS-only packet users don't use the native stack because it just adds overhead and complexity, and doesn't support features like New-N paradigm digipeater aliases. All the regular APRS applications support direct (exclusive) control over a hardware or software TNC port at user mode, which is reasonable since APRS and non-APRS traffic shouldn't be sharing an RF channel anyway, so there's typically no need to add the native stack overhead to multiplex multiple simultaneous applications to a single TNC port. And, if you do need that, some of the software TNCs do allow multiple applications to connect to a single TNC port (although their behavior for received unconnected packets is not consistent on which of the multiple applications would receive said packets).

Having said all this, is there an interest in having such native AX.25 kernel stack access anyway?

Andrew, KA2DDO
author of YAAC
________________________________________
From: [email protected] <[email protected]> on behalf of Mike Allred
Sent: Sunday, February 28, 2021 3:10 PM
Subject: [yaac-users] Linux AX.25

Hello,

I'm now to the group, so apologies if this has been mentioned recently. A Google search let me to a post on this subject from early last year and made me aware of this group.

Does YAAC support the native AX.25 stack in linux yet? (via kissattach, etc...)


Thanks,
Mike
AE4G

Whoops. Missed the point you were making.

Note that W0NED-10 is not necessarily the fastest I-gate in the area, so it is possible that the later I-gate actually got your packets to the Internet more quickly than W0NED-10 did (if W0NED-10 submitted them to APRS-IS at all). Hence, aprs.fi would not see any report of W0NED-10 that they had heard your station because it was duplicate-discarded.

It's been said hundreds of times before by dozens of people, but I'm going to say it again:

You CANNOT use aprs.fi (or the APRS-IS backbone in general) for propagation analysis, because it only keeps the first network-received copy of any transmitted packet, not all of the later copies injected by other I-gates, such that you cannot see all RF paths a packet took to get to the APRS-IS.

Andrew, KA2DDO
author of YAAC

________________________________________
From: [email protected] <[email protected]> on behalf of Matt Reynolds <nedheadd@...>
Sent: Wednesday, February 24, 2021 11:38 AM
To: [email protected]
Subject: [yaac-users] Question regarding 'Stations heard directly by'

I transmitted an aprs position packet from my aprsdroid unit.

After doing so, my aprsdroid unit (KD0PYK-7) was properly positioned on the APRS.fi map.

Looking at the 'Last path' for my aprsdroid packet, it shows KD0PYK-7>APDR16 via W)NED-10....

This is appropriate.

[cid:part1.F8302B06.6399C956@...]

-------------------------------------------------------------------------------------------------------------------------------------------------------------------

However, when I look at the info display for W0NED-10, I don't see KD0PYK-7 under 'Stations heard directly by W0NED-10'.

Why not ?

-------------------------------------------------------------------------------------------------------------------------------------------------------------------

[cid:part2.DAB4ED3E.E7DFF310@...]


________________________________
[AVG logo] <>

This email has been checked for viruses by AVG antivirus software.
www.avg.com<>