QSO One is much more stable now. Still looking for more beta testers to get all the edge cases

Third-Party Apps
,
1

A bit of a progress update on QSO One, the cross-platform AllStarLink client I've been building.

If you would like to join the beta, let me know. Or search QSO One on google.

When this started, the goal was simple: a proper Windows AllStar client, since IAXRpt had been abandoned since 2019 and there wasn't much else. It's grown into a full Flutter app running on Windows and Android, with the IAX2 protocol reverse-engineered frame by frame from scratch.

The last few months have been mostly about hardening it against the real world. A lot of the early pain was protocol-level: VNAK handling, ACK races, sequence number wraps, the kind of bugs you only find with Wireshark open and a lot of coffee. More recently I tracked down a whole class of "cannot connect" failures that turned out to be an authority/context issue in how the NEW frame was built. Nodes that were completely unreachable before now connect on the first try.

Where it stands now: node mode and WT mode for AllStarLink are solid, with cellular and CGNAT handling that actually deals with carrier networks instead of just failing. EchoLink and IAXRpt are in there as full modes too, and there's an experimental M17 mode with Codec 2 that I'm pretty happy with. Connection recovery, network transition handling, Bluetooth PTT, in-app updates, the unglamorous stuff that makes something usable day to day, all working.

It's at the point where it's mostly stable and the remaining work is edge cases, which is exactly where more testers help. Different hardware, different networks, different node setups all surface things I'd never hit on my own. If you run AllStar and want to kick the tires on Windows or Android, I'd genuinely value the feedback.

73, KD8JKK

2

@kd8jkk Frank, this project matters more than most people here probably realize, and the CGNAT handling is a big reason why.

I work in the WISP industry. IPv4 exhaustion is not some future problem. It is already here. CGNAT is where a lot of ISPs have landed because they do not have many good options left. Mobile carriers have been doing it for years. Fixed wireless providers are moving that way. Starlink uses it. Some fiber providers are starting to do it too as their address pools dry up.

That means a growing number of hams are sitting behind CGNAT right now. They cannot just forward UDP 4569 and call it done. In many cases they do not control the upstream router, the carrier network, or the CPE. Traditional IAX clients either fail, fail silently, or require workarounds the user may not even be able to do. That is not user error. That is the reality of modern networking.

QSO One actually handles that reality.

I have been running it on Windows and Android as a beta tester, and the difference is real. On Windows, IAXRpt has not been touched since 2019. QSO One is the only modern maintained replacement I know of for that use case. On Android, DVSwitch Mobile works, and I respect what it can do, but it is still more of a configuration project than an app for normal users. It assumes you already understand the moving parts: IAX, node numbers, credentials, ports, audio routing, NAT behavior, and how AllStar behaves under the hood.

QSO One feels like something you can hand to a ham and say, "try this."

The bigger thing is that this is not just an AllStar app. It is starting to look like a modern ham radio network client. AllStarLink, EchoLink, IAX Direct, and experimental M17 in one interface is a big deal. Most of us are used to one app per network, one set of quirks per app, and a lot of old software that technically works but feels abandoned. Having one maintained client that can move between these networks matters.

The hard parts are not the shiny parts. The hard parts are Node Mode and WT Mode behaving correctly, IAX2 actually surviving real networks, cellular and CGNAT handling, connection recovery, network changes, Bluetooth PTT, EchoLink support, audio device handling, and now M17 with Codec 2. The protocol-level fixes matter too. VNAK handling, ACK races, sequence number issues, and the NEW frame authority/context problem are exactly the kind of ugly details that decide whether an app works in the real world or only on the developer's desk.

That is why more beta testers matter. Different routers, different NAT types, hotel Wi-Fi, Starlink, LTE hotspots, fixed wireless, campus networks, Bluetooth headsets, USB mics, oddball audio drivers, HamVOIP nodes, ASL3 nodes, public nodes, private nodes, EchoLink stations, and M17 reflectors. Those are the edge cases that make or break this kind of app.

I also want to say that it is good to see someone pushing this part of the ecosystem forward. The old answer of "just configure Asterisk and edit iax.conf" works for people who already know what they are doing, but it is not much of a welcome mat for everyone else.

Frank is building the welcome mat.

If you are on Windows or Android and want to help, get in the beta. Especially if you are on cellular, Starlink, fixed wireless, hotel Wi-Fi, campus Wi-Fi, or anything weird behind CGNAT. Also test EchoLink, IAX Direct, M17, Bluetooth audio, USB audio, weird headsets, and whatever strange network setup you have. The ask is low, and the payoff for the ham radio community is real.

3

No application alone solves the problem of Carrier-Grade NAT nor is "traditional IAX" clients the problem. This is not a commentary on QSOone or any other app; I am merely stating this for accuracy and so people understand some of the issues being raised.

The core issue with AllStarLink specifically is that the registration/access protocol hails from the pre-CGNAT (and even pre-NAT) era of the Internet. WebTransceiver or "WT" is a tottering series of hacks that itself is obsolete and not suited for the modern Internet.

There is a Vendor collaboration channel in Slack where this has already been discussed that "WT" as it exists today is going to be replaced. It will work similar to how it does today but not exactly like it does today. The current WT protocol is insecure and is scraping a website which is not reliable. There will be an upcoming roadmap published later this summer on some targeted dates for the new, highly-available API model to be available, when "WT" will be deprecated, and when when "WT" will be retired. It will be a reasonable amount of time for each phase.

Similarly, the underlying "node mode" (which is misnomer created only to call normal AllStarLink that isn't the WT stuff) will be changing to use a set of public/private keypairs that is "state aware" for clients. This will remove CGNAT challenges for most clients and then only repeaters, hub nodes, and other constructs that expect to be "connected to" will need to have a publicly-accessible UDP port (i.e. UDP/4569). More about this will be published later this summer as well. Support for IPv6, which is being finalized now is essential to this plan and will appear first.

However all of this takes time and will be a disruptive change. AllStarLink is trying to be thoughtful, careful, and not unnecessarily break nodes and clients in an ecosystem where people are very slow to upgrade.

4

I am absolutely looking forward to this change!

5

I appreciate the support! Indeed, the more testing environments we encounter, the better the experience will be for everyone involved.

6

KD8JKK, Good afternoon and how may I help with beta testing? 73 Craig KD9UQE

7

Basically just using the program in the way you would want to use it! The more use it gets, the more edge cases we find. You can email me at support@qso1.net and I can get you set up on it.