Disclaimer: The following analysis is based on empirical reflection of HF traffic and does not represent an authoritative specification. The recognition of protocol messages and roles is simply a method hypothesis intended for investigation purposes.
This post examines what appears to be a customized HF adaptation of the WireGuard VPN protocol [1], a streamlined UDP-native protocol designed for high-performance safe tunneling. While the examined protocol shares characteristics with both MESH and VPN architectures, I have opted for the second definition. This is due to the fact that an HF implementation of a mesh protocol is better suited for tactical (field-deployed) theaters alternatively than the consolidated, fixed-site network observed in this case.
I have utilized the word "WireGuard-like" in the title due to the fact that the observed packet structures diverge from standard specifications; nevertheless, protocol-specific signatures propose a proprietary implementation tailored for transmission over HF links. For convenience, the word "WireGuard" (WG) will be utilized hereafter to mention to this circumstantial implementation, its framing characteristics, and the field designations identified here.This analysis besides serves as a continuation of the work initiated in [2] [3]; readers are encouraged to mention to those erstwhile posts for background on the operational scenario.
As established in the aforementioned posts, the bulk of the erstwhile captures consists of intermittent 2G-ALE (MS-141A) handshakes between Node 101 (caller) and Node 102 (called). Sometimes handshakes are followed by short MS-110A bursts, carrying encapsulated STANAG-5066 UDP payloads of 16 and 32 bytes. However, a fewer days ago (February 19), while occasionally monitoring 20779.5 kHz (1), sustained async MS-110A transmissions were recorded, characterized by prolonged data exchanges specifically between nodes 101 and 102 (Figure 1). Unlike the sporadic heartbeats/pings observed earlier, these emissions propose the transfer of larger, continuous data blocks. My friend Kosmod kindly shared his recordings with me.
 |
| Fig. 1: Waterfall display showing continuous MS-110A bursts on 20779.5 kHz, indicating an active data session between ALE nodes 101 and 102 |
1. Bitstream Analysis
The MS-110A demodulated bitstreams exhibit the expected 8N1 asynchronous framing format, an example is shown in Figure 2. This format ensures that even if the radio link drops or fades momentarily, the serial framing allows the hardware to re-sync at the very next byte, alternatively than losing an full synchronous frame.
 |
| Fig. 2: MS-110A 8N1 asynchronous pattern |
After stripping the asynchronous start/stop bits, the underlying STANAG-5066 frames are identified via their 0x90EB sync sequence. These frames encapsulate IP traffic within U_PDUs (Unreliable/Unacknowledged PDUs), facilitating data exchange between nodes 011.020.100.101 and 011.020.100.102 (Figure 3a). The U_PDU payloads were subsequently extracted and reassembled, revealing IP/UDP datagrams routed between 192.168.101.15 and 192.168.102.15. Analysis of the reassembled UDP payloads identified a consistent 0x04 first value, corresponding to WireGuard kind 4 Transport Data packets (2). This protocol recognition was further validated by the Wireshark dissector (Figure 3b).
 |
| Fig. 3: Example of protocol decapsulation utilizing STANAG-5066 (3a) and Wireshark dissectors (3b) |
Figures 3a/3b highlights any interesting elements:
1. Cross-Layer Addressing: source and destination IP addresses are correlated with the ALE and STANAG-5066 node IDs. This mapping confirms a consistent logical-to-physical addressing scheme, verifying the identity of the transceiving stations across the radio link:ALE address: 101 -> STANAG-5066 address: 011.020.100.101 -> LAN IP address: 192.168.101.15
ALE address: 102 -> STANAG-5066 address: 011.020.100.102 -> LAN IP address: 192.168.102.15
2. Transport Layer Optimization: the capture reveals the implementation of UDP (User Datagram Protocol). This choice is mirrored at the data-link layer by the usage of STANAG-5066 Non-ARQ data transfer.
3. Encapsulated Tunneling: further dissection of the UDP payload identifies the usage of an HF implementation of WireGuard VPN Protocol, indicating that the session employs a modern, high-performance encryption to safe the traffic.
2. Proposed Protocol Analysis
(All field designations are my own and are utilized for convenience of presentation)
The following section provides the UDP payloads analysis of the data transfer session illustrated in Figure 4.
The following section provides the UDP payloads analysis of the data transfer session illustrated in Figure 4.
 |
| Fig. 4: spectral time-frequency analysis |
For reference, the following workflow was utilized for signal processing and analysis:
- MS-110A demodulation and asynchronous start/stop bit stripping
- STANAG-5066 protocol dissection
- Extraction and reassembly of segmented U_PDUs (Unreliable Data Protocol Units)
- Wireshark IP packet dissection
- Hexadecimal forensic analysis of the extracted UDP payloads
The session commences with the standard MS-141A 2G-ALE handshake between Node 101 (caller) and Node 102 (called) which are followed by 3 WG bursts.
WG1 burst:
Internet Protocol Version 4, Src: 192.168.101.15, Dst: 192.168.102.15
User Datagram Protocol, Src Port: 55504, Dst Port: 2753
UDP payload (32 bytes): 002000020003cbf6c0a8650f00000def699713f500010000c0a8660f0000064d
This 32-byte pyload is the first packet of a fresh session, it serves as the "Announcement" or "Master Synchronization" Type 2 Message . In a high-latency, low-bandwidth environment like HF, you cannot afford the back-and-forth of a standard TCP-style or WireGuard handshake. Instead, the sender "pushes" the full connection state in this single 32-byte burst.
WG2 burst:
Internet Protocol Version 4, Src: 192.168.102.15, Dst: 192.168.101.15
User Datagram Protocol, Src Port: 54107, Dst Port: 2754
UDP payload (28 bytes): 001c00010600a36dc0a8660f0001000ec0a8650f00000def00010002
Internet Protocol Version 4, Src: 192.168.102.15, Dst: 192.168.101.15
User Datagram Protocol, Src Port: 54107, Dst Port: 2754
UDP payload (28 bytes): 001c00010600a36dc0a8660f0001000ec0a8650f00000def00010002
This 28-byte payload serves as the Synchronized Acknowledgement (ACK) Type 1 Message. It confirms that the receiver has accepted the session parameters (Session ID and Clock) proposed in the first 32-byte WG1 burst.
WG3 burst: The WG3 burst consists of 2 parts:
WG3_1 part:
WG3_1 part:
Internet Protocol Version 4, Src: 192.168.101.15, Dst: 192.168.102.15
User Datagram Protocol, Src Port: 55504, Dst Port: 2753
User Datagram Protocol, Src Port: 55504, Dst Port: 2753
UDP payload (32 bytes): 002000020003cbf6c0a8650f00000def699713f500010000c0a8660f0000064d
In this capture, the 3rd payload seems to complete the MS-141A ALE Three-Way Handshake paradigm, transitioning the link from the "Linking" state to the "Data Traffic" state. Interestingly, the hex for this 3rd packet is identical to the 1st packet. In HF protocols, this usually indicates a re-transmission or a State Enforcement frame to guarantee the receiver definitely has the Master Context before the data burst begins.
WG3_2 part:
Internet Protocol Version 4, Src: 192.168.101.15, Dst: 192.168.102.15
User Datagram Protocol, Src Port: 55504, Dst Port: 2753
WireGuard Protocol
Type: Transport Data (4)
Reserved: 000000
Receiver: 0x9ee70200
Counter: 17225424150020335808
Encrypted Packet
User Datagram Protocol, Src Port: 55504, Dst Port: 2753
WireGuard Protocol
Type: Transport Data (4)
Reserved: 000000
Receiver: 0x9ee70200
Counter: 17225424150020335808
Encrypted Packet
Examination of the UDP payload hexdump reveals a consistent 0x04000000 first series , i.e., a fingerprint of standard-WireGuard Transport Data Type 4 Message.
 |
| Fig. 5: hexdump of WG3_2 UDP payload |
The structural composition of the header is detailed below:
The 16-byte Authentication Tag is always the last 16 bytes appended at the end of the encrypted payload. This tag is the consequence of the Poly1305 algorithm ChaCha20-Poly1305 for Authenticated Encryption with Associated Data (AEAD).
Note that while the Receiver Index is stored in Little-Endian (WireGuard standard), the Embedded IP (C0 A8...) is stored in Big-Endian (Network Byte Order). This "hybrid" endianness is an indicator of a customized wrapper being utilized to bridge standard networking with the WireGuard protocol.
Note that while the Receiver Index is stored in Little-Endian (WireGuard standard), the Embedded IP (C0 A8...) is stored in Big-Endian (Network Byte Order). This "hybrid" endianness is an indicator of a customized wrapper being utilized to bridge standard networking with the WireGuard protocol.
In a standard WireGuard implementation, the Nonce (bytes 08-15) is usually just a monotonic counter starting from zero.
However, this circumstantial capture shows interesting points:
1. Identity Injection: by placing 192.168.101.15 (the sender's interior IP) straight into the first 4 bytes of the Nonce, the receiver can verify the origin of the packet at the cryptographic layer before even attempting to decrypt the interior payload.
2. Timestamp Alignment: the following 4 bytes (00 00 0d ef) guarantee the packet is unique and in sequence.
3. The "Double Match": notice this is an exact match to the 32-byte Master Sync packet analyzed in WG_1 burst. This confirms that the first data packet in a session "inherits" the series number and identity utilized during the handshake to prevent any startup hold on the HF link.
Below the complete packet flow summary.
In this HF-optimized environment, the 32-byte Master Sync (WG1 burst) functions as a "state-push" mechanism, forcefully synchronizing the absolute Unix Epoch and session identity to satisfy WireGuard's anti-replay requirements in a single burst. The subsequent 28-byte ACK (WG2 burst) confirms bidirectional reachability and IP binding, while the final 32-byte State Lock (WG3_1 part) ensures the receiver is full primed despite possible HF fading or ALE tuning delays. This robust "handshake-less" initiation minimizes airtime while establishing the essential cryptographic context for the immediate transmission of WireGuard kind 4 Data packets.
Another crucial capture reveals the existence of a 16-byte Type 3 Message, which in this context likely functions as a Status/Keep-Alive announcement. announcement that this kind 3 control message is transmitted immediately following the 2G-ALE (MS-141A) handshake, without an instant follow-up data burst, thereby marking the transition from link establishment to tunnel maintenance. Figure 6 displays the transition between the physical (2G-ALE) and logical (WG message)
layers.
 |
| Fig. 6 : transition between the physical (2G-ALE) and logical (Type 3 Message) layers |
The following table provides the proposed structure of the kind 3 message:
Internet Protocol Version 4, Src: 192.168.101.15, Dst: 192.168.102.15
User Datagram Protocol, Src Port: 56503, Dst Port: 2753
UDP payload (16 bytes): 0010000306001056c0a8650f0000059d
Internet Protocol Version 4, Src: 192.168.101.15, Dst: 192.168.102.15
User Datagram Protocol, Src Port: 56503, Dst Port: 2753
UDP payload (16 bytes): 0010000306001056c0a8650f0000059d
While kind 1 & 2 messages handle acknowledgments between peers, shorter 16-byte kind 3 messages likely service as heartbeat signals, periodically announcing the presence of the 192.168.101.15 node to the network.
The immediate transmission of the kind 3 message after the 2G-ALE handshake serves as a bridge between the physical layer (radio synchronization) and the logical layer (tunnel persistence). This ensures that the UDP session is active before the bulk transport of kind 4 encrypted data begins. As seen in erstwhile sequences, the ALE → WG transition is the "acid test" confirming that the strategy utilizes ALE simply as a pathfinder before immediately handing over control to the tunneling protocol.
The immediate transmission of the kind 3 message after the 2G-ALE handshake serves as a bridge between the physical layer (radio synchronization) and the logical layer (tunnel persistence). This ensures that the UDP session is active before the bulk transport of kind 4 encrypted data begins. As seen in erstwhile sequences, the ALE → WG transition is the "acid test" confirming that the strategy utilizes ALE simply as a pathfinder before immediately handing over control to the tunneling protocol.
2.1. Functional Parallelism with MS-141A Sounding
Critical reflection of the traffic patterns reveals Sub-Type 2 Messages 2.1 (02 01) and 2.2 (02 02) appearing either in isolation (Figure 7) or as a three-message exchange (Figure 8), both notably occurring without an immediate follow-up data burst. These behaviors exhibit a functional parallelism with 2G-ALE (MS-141A) sounding transmissions, where unilateral or short-handshake bursts are utilized to keep channel state and verify way viability independently of active traffic.
 |
| Fig. 7 : isolated/probe kind 02 Message without an immediate follow-up handshake or data burst |
Hex: 0020020200030b03c0a8650f00000de76996f7d300010000c0a8660f00000646
Figure 8 sows a three-message exchange between nodes 101 and 102 without an immediate follow-up data burst.
 |
| Fig. 8: three-message exchange without an immediate follow-up data burst |
Analisys of the UDP payloads, IP/UDP encapsulations are omitted.
WG1 Burst UDP Payload: first Sounding (Node 101)
Hex: 0020020200030b03c0a8650f00000de76996f7d300010000c0a8660f00000646
Hex: 0020020200030b03c0a8650f00000de76996f7d300010000c0a8660f00000646
WG2 Burs UDP Payload: consequence (Node 102)
Hex: 001c0201060019fdc0a8660f0001000ec0a8650f00000de700010002
Hex: 001c0201060019fdc0a8660f0001000ec0a8650f00000de700010002
WG2 payload is 28 bytes and contains the reflected "Echo" of WG1 payload.
WG3 Burst UDP Payoad: Final Confirmation (Node 101)
Hex: 0020020200030b03c0a8650f00000de76996f7d300010000c0a8660f00000646
Hex: 0020020200030b03c0a8650f00000de76996f7d300010000c0a8660f00000646
Sumarizing:
WG1 (The Sound): Node 101 announces itself and sets the Sync ID to 0x0de7.
WG2 (The Call/Response): Node 102 confirms it heard the sound by reflecting the IP .101.15 and the ID 0x0de7 back to the sender.
WG3 (The Conclusion): Node 101 re-transmits its state to guarantee the link is locked. This redundancy is the core of the ALE-logic parallelism, ensuring connectivity even if the first packet had jitter.
WG2 (The Call/Response): Node 102 confirms it heard the sound by reflecting the IP .101.15 and the ID 0x0de7 back to the sender.
WG3 (The Conclusion): Node 101 re-transmits its state to guarantee the link is locked. This redundancy is the core of the ALE-logic parallelism, ensuring connectivity even if the first packet had jitter.
This confirms that the nodes are handshaking on a state, not just passing data.
Observed sequences besides show the presence of Sub-Type 1 Messages 1.2 (01 02), appearing either as isolated/probe burst (Figure 9):
 |
| Fig. 9: isolated/probe WG burst |
UDP Payload (IP/UDP encapsulation is omitted)
Hex: 00200102000323aac0a8650f00000df1699706f600010000c0a8660f0000064b
UDP Payload WG1 (IP/UDP encapsulation is omitted)
Hex: 00200102000323aac0a8650f00000df1699706f600010000c0a8660f0000064b
Hex: 00200102000323aac0a8650f00000df1699706f600010000c0a8660f0000064b
or occurring immediately before a kind 2 Message inside the same kind 4 data exchange burst. Notably, no ACK is issued by the destination peer (typically Node 102) in this circumstantial sequence.
 |
| Fig. 10 |
UDP Payload WG1 (IP/UDP encapsulation is omitted)
Hex: 00200102000323aac0a8650f00000df1699706f600010000c0a8660f0000064b
Hex: 002000020003a325c0a8650f00000dea699713f300010000c0a8660f0000064e
Payload A Epoch: 69 97 06 f6 ≈ 07:40:06 UTC
Payload B Epoch: 69 97 13 f3 ≈ 08:35:01 UTC
Delta: 3325 seconds (approx. 55 minutes and 25 seconds).
The fact that kind 04 (Data) follows Payload B immediately, could likely mean that the 55-minute jump in the epoch was a session sesynchronization.
The circumstantial function of Sub-Type 1.2 remains unclear and deserves further investigation.
2.2. Protocol kind Messages
Based on the observed sequences, this WireGuard-like protocol follows a deterministic four-stage lifecycle for link management and data transfer identified by the kind Message IDs:
- Link Initiatior (Type 2 Message): the session originates with an Initiator message utilized to request channel allocation or to "wake up" the distant peer within the STANAG-5066 stack.
- Receiver ACK (Type 1 Message): the responding node returns a Receiver ACK message. This exchange validates link-layer synchronization and confirms that both modems are aligned.
- Link Maintenance/Persistence (Type 3 Message): during periods of data inactivity, the link is sustained via Heartbeat messages. These 16-byte frames likely prevent STANAG-5066 session timeouts and supply the network controller with continuous node reachability status.
- Transport Data (Type 4 Message): erstwhile the control plane is stabilized, the Transport Data packets carry the encrypted payload. The persistence of the Receiver Index across distinct captures confirms a long-term safety association managed by this customized signaling layer.
Notice the similarity between the 2 ACK Types 0001 and 0201.
Interestingly, the protocol utilizes a non-sequential kind Message assignment that deviates from standard handshake conventions. kind 02 functions as the Initiator, signaling the intent to establish a link, while kind 01 serves as the Receiver ACK. This inversion suggests a priority-based numbering strategy or a derivation from a legacy STANAG-5066 signaling framework, where kind 01 is traditionally reserved for link-layer acknowledgments.
3. any techical observations
3.1. STANAG-5066 addresses
The addresses utilized in STANAG-5066 (Source: 011.020.100.101; Destination: 011.020.100.102) are formally assigned to an Armenian political or organizational network (STANAG-5066 Table N-9 mediate East National Addressing Schema); however, they are likely dummy/fictitious addresses intended to avoid interference with authoritative NATO-standard communications. Regardless, they do not aid in geolocation since these represent logical identifiers that reflect organizational affiliation alternatively than physical geographical location. They identify "who" is communicating within the network, but they bear no relation to "where" the transmitter is physically located.
The addresses utilized in STANAG-5066 (Source: 011.020.100.101; Destination: 011.020.100.102) are formally assigned to an Armenian political or organizational network (STANAG-5066 Table N-9 mediate East National Addressing Schema); however, they are likely dummy/fictitious addresses intended to avoid interference with authoritative NATO-standard communications. Regardless, they do not aid in geolocation since these represent logical identifiers that reflect organizational affiliation alternatively than physical geographical location. They identify "who" is communicating within the network, but they bear no relation to "where" the transmitter is physically located.
3.2.
Cross-Mapped UDP Architecture (port asimettry)
In a typical net deployment, WireGuard is symmetric (e.g., Peer A:51820 ↔ Peer B:51820), nevertheless analysis of the UDP datagrams reveals a consistent asymmetric pattern:
Node 101 TX Path: Local Port 55504 → Node 102 distant Port 2753
Node 102 TX Path: Local Port 54107 → Node 101 distant Port 2754
Looking at erstwhile captures, the local port does not always have the same value but changes (55504,54107,56503,60510,...) while distant ports 2753/2754 stay fixed:
Node 101 TX Path: Local Port (variable) → Node 102 distant Port 2753
Node 102 TX Path: Local Port (variable) → Node 101 distant Port 2754
The transition from symmetric to asymmetric UDP ports confirms that this is simply a Radio-Aware implementation. The cross-mapping of ports 2753 and 2754 serves as a synchronization bridge between the synchronous nature of the WireGuard protocol and the asynchronous, half-duplex constraints of HF.
In a typical net deployment, WireGuard is symmetric (e.g., Peer A:51820 ↔ Peer B:51820), nevertheless analysis of the UDP datagrams reveals a consistent asymmetric pattern:
Node 101 TX Path: Local Port 55504 → Node 102 distant Port 2753
Node 102 TX Path: Local Port 54107 → Node 101 distant Port 2754
Looking at erstwhile captures, the local port does not always have the same value but changes (55504,54107,56503,60510,...) while distant ports 2753/2754 stay fixed:
Node 101 TX Path: Local Port (variable) → Node 102 distant Port 2753
Node 102 TX Path: Local Port (variable) → Node 101 distant Port 2754
The transition from symmetric to asymmetric UDP ports confirms that this is simply a Radio-Aware implementation. The cross-mapping of ports 2753 and 2754 serves as a synchronization bridge between the synchronous nature of the WireGuard protocol and the asynchronous, half-duplex constraints of HF.
By separating the RX/TX paths into different ports the software knows that anything arriving on ports 2753/2754 is exclusively incoming traffic from the distant peer, eliminating any hazard of processing its own transmitted signals. In essence, the port asymmetry transforms a standard peer-to-peer VPN tunnel into a dual-channel "Virtual Circuit" optimized for the unique HF channel.
Although a search of the IANA port registry yields no authoritative assignments for UDP ports 2753 or 2754, the consistency of their appearance suggests they are de facto service-dedicated ports for this circumstantial protocol.
3.3. End-user recognition and Attribution
Regarding the end-user, it can be confirmed with certainty that the entity is an Italian diplomatic/military body, as erstwhile signal captures have intercepted op-chats conducted in Italian language. Furthermore, multiple UDXF logs support this attribution, identifying the ALE exchanges between nodes 101 and 102 as part of an Italian Military Attaché network.
Regarding the end-user, it can be confirmed with certainty that the entity is an Italian diplomatic/military body, as erstwhile signal captures have intercepted op-chats conducted in Italian language. Furthermore, multiple UDXF logs support this attribution, identifying the ALE exchanges between nodes 101 and 102 as part of an Italian Military Attaché network.
3.4. Node Roles and Network Topology
The circumstantial roles of ALE nodes 101 and 102 stay hard to define, specifically regarding which functions as the HQ node and which as the distant node. However, it is established that node 101 consistently initiates both the link negotiation and the VPN tunnel, while besides managing subsequent data forwarding. Based on standard network architecture, this behaviour suggests that node 101 likely operates as the distant station (initiating a "call home" procedure), while node 102 functions as the central gateway or HQ.
The circumstantial roles of ALE nodes 101 and 102 stay hard to define, specifically regarding which functions as the HQ node and which as the distant node. However, it is established that node 101 consistently initiates both the link negotiation and the VPN tunnel, while besides managing subsequent data forwarding. Based on standard network architecture, this behaviour suggests that node 101 likely operates as the distant station (initiating a "call home" procedure), while node 102 functions as the central gateway or HQ.
Based on the presumption of an Italian Military Attaché entity, it is highly plausible that the distant station (Node 101) transmits periodic diplomatic/military situation reports (SITREPs) to the central office in Rome (Node 102), likely Ministry of abroad Affairs or Ministry of Defense.
3.5. Geolocation and method Constraints
Similar uncertainties apply to the geolocation of the 2 transmitters. The TDoA (Time Difference of Arrival) method employed for Direction uncovering (DF) requires a minimum dwell time of 30 seconds from a single transmitting origin and at least 3 receivers synchronized to the monitoring frequency.
These conditions are hard to meet due to the unpredictable nature of the transmissions (they seem to happen only erstwhile a "report" is ready) and the handshake mechanics employed, which involves 2 distinct transmitting sources alternating rapidly. This fast switching between the initiator (Node 101) and the responder (Node 102) prevents the TDoA strategy from maintaining a unchangeable lock long adequate for a precise fix.
Similar uncertainties apply to the geolocation of the 2 transmitters. The TDoA (Time Difference of Arrival) method employed for Direction uncovering (DF) requires a minimum dwell time of 30 seconds from a single transmitting origin and at least 3 receivers synchronized to the monitoring frequency.
These conditions are hard to meet due to the unpredictable nature of the transmissions (they seem to happen only erstwhile a "report" is ready) and the handshake mechanics employed, which involves 2 distinct transmitting sources alternating rapidly. This fast switching between the initiator (Node 101) and the responder (Node 102) prevents the TDoA strategy from maintaining a unchangeable lock long adequate for a precise fix.
3.6. Protocol's timing logic
Examining respective captures, crucial temporal differences were observed between the WireGuard handshake timestamps in the initiator packets and their actual reception; an example is shown in Figure 11.
Examining respective captures, crucial temporal differences were observed between the WireGuard handshake timestamps in the initiator packets and their actual reception; an example is shown in Figure 11.
 |
| Fig. 11: temporal difference |
All data points in the following table were recorded on the same day (2026/02/19), highlighting the intra-day volatility of the protocol's timing logic.
While the synchronization between the packets is evident, the multi-hour gaps between the interior Timestamp and the Actual Reception time (specifically in Captures C through F) present an unresolved anomaly. At this phase of the analysis, no definitive explanation can be provided for these crucial offsets. respective hypotheses stay under consideration: session-based epochs, strategy clock misalignment (Node 101), or a "store-and-forward" mechanism.
The negative deltas (specifically in Captures A and B) suggest that the interior timestamp functions as an expiration marker, i.e., a Session Validity Deadlines (Time-to-Live): this hypotheses besides remains under consideration.
Negative deltas and multi-hour gaps item a complex session management logic that requires further data acquisition to be full decoded and interpreted.
By the way, all the 2024/11/28 captures show akin negative deltas.
Conclusions
In conclusion, the captured traffic likely represents an HF-customized VPN protocol. Although it deviates from the standard WireGuard specifications, its alignment with observed message structures suggests its specialized HF implementation. This adaptation transcends the capabilities of standard Wireshark dissectors, which are designed for "Vanilla" protocols and may not natively support these physical-layer modifications. This analysis remains a work in progress; further captures will be essential to confirm these findings and refine the protocol details.
(1) Transmissions do not appear to follow a fixed schedule. According to UDXF logs, there are multiple frequencies to monitor, making simultaneous tracking hard unless a polling strategy utilizing ALE software with a scanning receiver or a "staring" monitoring approach is implemented across various distant web-based SDRs:
07780.50, 10220.50, 12110.50, 14963.50, 15906.50
17411.50, 18325.50, 19516.50, 20776.50, 20779.50
(all KHz/USB)
07780.50, 10220.50, 12110.50, 14963.50, 15906.50
17411.50, 18325.50, 19516.50, 20776.50, 20779.50
(all KHz/USB)
[2] http://i56578-swl.blogspot.com/2025/12/udp-datagrams-sent-via-stanag-5066-over.html
[3] http://i56578-swl.blogspot.com/2026/01/udp-datagrams-sent-via-stanag-5066-2.html
[3] http://i56578-swl.blogspot.com/2026/01/udp-datagrams-sent-via-stanag-5066-2.html
