dscp46, aka isithran
dscp46, aka isithran
I'm aware that blog is way too quiet, consideting what is done, but I don't I have points relevant enough to share in specific posts.
Here are some notable things that happened during this year:
The rise of GNSS jamming in regional conflicts is a good reminder not to take space-based resources for granted.
On top of that, CISA has recognized timing as a critical function (among others) to support key infrastructure, including telecommunication networks.
While my previous experiments on DCF-77 receivers have been quite successful, reliance on amplitude modulation signals and on transmitters that are 500+ miles away can be challenging with deep indoor receivers.
Despite being more complex to decode, the French legal time signal (162kHz) has interesting features: its phase modulation, and high transmit power (10x higher than DCF77), provides better noise immunity, and... it is closer, as far as I'm concerned.
F5RCT has designed an ALS162 receiver for this signal, however some details rub me the wrong way:
This year, I've begun writing a bit of documentation on how the ALS162 signal works that needs some corrections, now that I have acquired a copy of NF C 90-002.
Additionally, I've begun writing a baseband stub signal generator, to test my receiver's synchronization logic (not publicly available, for now) and metadata decoding.
Finally, I've laid down a few ideas for my receiver in a design document.
Nothing significant has happened on that specific topic:
In the near future, I'd like to add a regional IRC server, and an IRC-to-APRS FMUC bridges, even though this is not in my current priority list.
D-Star's specification covers how data transfer can happen, but no mechanism exists, as of today, to encapsulate AX.25 frames.
I have written a small proof of concept program to expose a D-Star DV radio to packet radio software, as if it was a KISS TNC.
Additionally, I'm currently writing a service gateway that act as a D-Plus reflector, from a D-Star repeater's point of view, but that acts as a AX.25 encapsulation/decapsulation bridge, such that existing packet radio apps (notably Winlink) can be used over existing D-Star DV repeaters.
A presentation on my proceedings is scheduled at Ondexpo 2026, on 2026-03-28, if you're interested.
Prior to this contribution, it was impossible to perform some administrative tasks on a remote system without transmitting your cleartext password over the air (running sudo, for example).
In axspawn, there is an authentication mechanism that relies on a MD5 challenge, we have written a compatible PAM module.
While some of its caracteristics are objectable (use of the obsolete MD5 hash function, a cleartext copy of the password must be kept on the remote system), we're still miles ahead of prior art in terms of security with this one: the Baycom scheme (pick 5 characters in a long secret passphrase) is not clearly specified, some implementations accept non-padded responses or short passphrases, and security warranties are significantly lower than with the MD5 mechanism.
I've written a quick-and-dirty APRS to Nagios/Centreon passive monitoring event translator.
For now, it only supports APRS-IS monitoring, and static frame formats.
On top of that, but not strictly in the packet radio scope, I've written a VE.Direct dumper, to relay MPPT messages over MQTT and on the site's local network over multicast. I'll hopefully publish in 2026.
Reading Isode's whitepaper on providing web services over HF radio was quite an inspiring exercise, which has incited me to design and implement a similar mechanism to transport Web traffic over raw AX.25.
Conceptually, an existing web browser interfaces with a bridge that acts as a SOCKS5 proxy, which forwards queries to a remote service gateway. Said service gateway then sends those queries to the Web server in a store-and-forward manner.
Incidentally, I've sifted though RFCs to find a HTTP header to report when a user agent is connecting though a constrained channel. This would be used to request the server to serve a lightweight version of the content, in zero HTTP round trip. Historically, this would have been relevant when we transitioned from dial-up to DSL/Cable, but nobody had the idea or the APIs to do so. In my memories, the usual strategy was to insert a link to the lightweight version on the top of the pages, but at the cost of one HTTP round trip.
As far as I've searched, there is no such header. I've thus defined X-Constrained-Channel to satisfy that use case. The associated value needs to be set to a non-zero integer, for a lightweight response to be served. Formal specification to come...
In our situation, this header will be inserted by the service gateway, to save a bit of bandwidth over the air, and to avoid tweaking our web browser.
Alternatively, detection of a constrained channel can be performed using Javascript, but I'll need to write a small post to cover this specific matter. That would be useful for bandwidth-impaired clients (e.g. mobile phone on a 2G/3G connection).
I've got a test proxy on the client side, the service gateway is left to be implemented and tested. More to come on next year...
Historically, the Winlink network has been built around Windows boxes. This fact is less and less true, as clients for Android and Linux have appeared in the recent years.
On the network side, building Winlink access points on top of a linux base brings significant benefits, notably in terms of power consumption.
LinBPQ works fine, but it's not designed to work aside other packet applications (especially on higher speed links, because it isn't designed to handle extended AX.25 counters).
Linux RMS Gateway provides a promising base. However, some notable issues were plaguing it:
To cite @ffmpeg CM's piece of wisdom:
Talk is cheap, send patches.
A pull request I've written to migrate away from python 2 has been merged, another one is pending to address the few segfaults, and I'm currently working on the remaining points.
Plans for the future would be to write a RMS Relay implementation to implement hybrid routing, but my initial contact with the Winlink admins didn't yield significant information to begin this.
I've recently ordered and assembled NinoTNC packet modems to operate at 9,600 bps and 19,200 bps.
I've sent a few remarks to the project's mailing list on how to improve the modem connector to handle electrically incompatible squelch signals.
NinoTNC's lack of hardware flow control and limited transmit buffer limits (2100 bytes) falls a bit short to build a long transmit window, notably when operating at 19,200bps. Thus, I'd like to write a small program to emulate a larger transmit buffer, by relying on the backpressure when can get from G8BPQ's extended KISS ACK mode command.
I've enriched my out-of-tree LUA dissector collection:
On top of those, I've reported the following issues:
I have migrated the pre-production instance on my infrastructure, and I've integrated Anubis to block content scrapers.
I need to do the same for the production instance.
~~~~
This list may not exhaustive at the time this article was written, despite my efforts to list them. Please note, if you've skipped the previous section, that aforementioned points may already have covered planned actions.
High priority queue:
Lower priority queue:
AX.25 still faces challenges to address some use cases, especially secure remote management and C2 (Command & Control), since we're unable to ensure authentication and integrity in some streams.
Meanwhile, TCP/IP operate very poorly on low-bandwidth-high-latency channels, and TLS is not adapted to our target, as it can't be retrofit in existing packet radio setups (mostly because the NULL encryption is progressively retired of mainstream implementations).
With this topic, we will inspire from IPSec to specify a security layer:
The axspawn authentication mechanism clearly lacks some necessary characteristics to face the 21st century challenges.
We will implement SCRAM, which fit those, then a public-key authentication scheme.
Additionally, we will elaborate a protocol to provide a MITM-proof secure credential rotation scheme without relying on AXSec.
Write a small blog article on what we've tried with LinBPQ during 2025.
Rhizomatica has published a free software HF modem named Mercury, which is a candidate to compete with VARA HF and Pactor III/IV.
Contribute the necessary files to make that software it package-able for Debian, then schedule field tests to confirm how it behaves over Skywave and specifically over NVIS.
Write a linux-native OpenB2F message router that will fit on our regional Hamnet network, with the option of falling back on V/UHF or HF forwarding.
My initial intent was to provide a linux-native Hybrid RMS, but as evoked above, my few questions to the Winlink admins didn't yield actionable information to understand the routing selection protocol works in the Hybrid network.
On our gateways, the idea would be to add an application to handle a regional a-centered message forwarding system, first with Hamnet as a backbone, then with a hybrid scheme to find connectivity through V/UHF. The groundworks to elect (or to enable the user to manually select) 1~3 message delivery nodes is almost finished, I need now to work on topology discovery, routing algorithm, how to handle efficient neighbor advertisement for the "over the air" segment, routing weight calibration, etc.
That one is a huge bone to chew, don't expect quick results. I'm not even finished digging into prior art (ham and non-ham).
I'm waiting for Authelia to finish their implementation of an OpenID Connect 1.0 provider to phase out my pubtkt-based SSO on my infrastructure.
X-Constrained-Channel header, such that we have one HF browsable site, on top of Isode's demonstrator for HF Radio.That's all folks, I hope that wasn't too boring.
Please don't hesitate to page me on Signal or Discord if you have a few questions or remarks.
