UDP datagrams sent via STANAG-5066 over async MS-110A (IP over HF)

23 December 2025

UDP datagrams sent via STANAG-5066 over async MS-110A (IP over HF)

This is a casual catch while I was exploring the 14 MHz band (14963.5 KHz/USB to be precise): the data transmission occurred after the usual MS-141A 3-way handshake between the ALE nodes 101 (caller) and 102 (called). Recording thanks to linkz KiwiSDR [1]. The used HF waveform is MS-110A in 300bps/Long mode (Figure 1).

Fig. 1 - MS-110A 300bps/L waveform

The resulting bitstream after MS-110A decoding uses 8N1 asynchronous framing (1 start bit, 1 stop bit) as shown in Figure 2.

Fig. 2 - 8N1 framing in demodulated bitstream

Examining the 8-bit bitstream after removing the start/stop bits, it must be noted the presence of the 16-bit Maury-Styles synchronization sequence 0xEB90 (LSB transmitted first) which identifies the STANAG-5066 Data Transfer Protocol Data Units (D_PDUs) frames (1).

Fig. 3 - STANAG-5066 sync sequences

I then decided to process the 8-bit bitstream using the STANAG-5066 dissector tool [2] obtaining interesting results which I comment below. The STANAG-5066 transfer consists of two frames which are basically a repetition (2): Figure 4 shows the first D_UDP frame.

Fig. 4 - first frame of the STANAG-5066 transfer

a) The D_PDU is type: 7 NON-ARQ DATA, ie Non-ARQ data transfer. Indeed, as Figure 1 shows, the data transmission is not followed by feedback ACK bursts. The "Delivery confirmation = none" flag is an additional confirmation of the NON-ARQ data transfer mode.

b) STANAG-5066 Addresses are
Source node address: 011.020.100.101
Destination node address: 011.020.100.102
Note that the last 3 digits of the addresses (101 and 102) correspond to the respective MS-141A ALE addresses used during link management.
If 11.20.y.z are actual STANAG-5066 addresses (not fake or dummy addresses), the nodes belong to an Armenian political or organizational network (STANAG-5066 Table N-9 — Middle East National Addressing Schema). Also note that in STANAG 5066, addresses are logical identifiers that reflect political or organizational belonging, not physical location.

c) The used "Source and Destination Service Access Point" is 9 (1001 binary): this identifies an IP-type Client/Application, according to STANAG-5066 #F.1.2 Standardized Assignment of Service Access Point Identifiers. Thus, this is a real-world example of IP over HF.

d) The "Client Application ID" field serves to identify the application (i.e., higher-level protocol) using the connection.

For further analysis of the IP packet we need to extract and edit a "reassembled" C_PDU, provided by the dissector tool, and then save it as an HEX dump file. We have to remove the first 6 bytes, ie the headers of C (Channel Access Sublayer) and S (Subnetwork Interface Sublayer) Protocol Data Units:
00 00 99 40 6D 9F
where:
00 C_PDU type (0 = data)
00 S_PDU type (0 = data)
99 S_PDU source & destination SAP IDs (1001 & 1001)
40 6D 9F S_PDU control and TDD fields
After removing these first 6 bytes you can copy and paste the hexadecimal data and save it to a .txt file, as for example "hex_dump.txt" (Figure 5).

Fig. 5

The HEX dump file can be now analyzed by using the well-known "wireshark" tool [3]: first click "File" -> "Import from Hex Dump", select the file to be imported, set offsets to "none" and Encapsulation Type to "Raw IP" then click Import. The result of the IP packet analysis is shown in Figure 6.

Fig. 6 - IP packet analysis

a) The first interesting thing to note are the values of the source/destination IP addresseses: 192.168.101.15 and 192.168.102.15, here too we see a repetition of the "digits" 101 and 102. Sumarizing:
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

b) As expecetd, since the Non-ARQ type D_PDU, the IP packet transports an User Datagram Protocol (UDP, a connectionless communication protocol) datagram with destination port 2753.
According to the official IANA service registry [4], the UDP port 2753 is registered as "de-spot". This means that if an application declares it uses UDP 2753, it’s conventionally associated with a service called de-spot, but that name doesn’t correspond to any widely known mainstream protocol like DNS or DHCP. It’s a registered but obscure / application-specific designation, port 2753 seems to be utilized by specific monitoring tools without a universal standard service name.

c) The UDP datagram transports the 16 bytes payload [0x]:
00 10 00 03 06 00 72 c6 c0 a8 65 0f 00 00 0c c3
I asked ChatGPT to try to break down the payload byte by byte, it's something like "mission impossible" I know, but some results are worth attention.

1. 00 10 → Possibly a message type or some identifier (2 bytes). Hex 0x0010 = 16 decimal (just the length of the message!)
2. 00 03 → Another 2-byte field, could be message type or command. Hex 0x0003 = 3 decimal.
3. 06 00 → Could represent a flags field, version, or sub-type. Hex 0x0600 = 1536 decimal.
4. 72 C6 → Often a transaction ID, session ID, or another 2-byte value. Hex 0x72C6 = 29318 decimal.
5. C0 A8 65 0F → This looks exactly like an IPv4 address in hex: C0 A8 65 0F → 192.168.101.15 (just the IP address of the sender!)
6. 00 00 → Possibly padding, reserved, or a 2-byte zero field.
7. 0C C3 → Could be a port, checksum, or some other 2-byte value. Hex 0x0CC3 = 3267 decimal.

The exact meaning depends on what application protocol is encapsulated inside the UDP packet. As seen, the IP address in UDP payload matches the source address in IP header: by itself, UDP doesn’t care about IP addresses, payload fields just contain whatever the application protocol puts there (data/metadata).
I do not know why the source IP address is repeated in the UDP paylod, maybe it's due to protocol design, NAT traversal, or validation (heartbeat/keepalive message?): I think that a network specialist could clarify the question and the used application protocol.

As is usual in SIGINT analysis, I followed a bottom-up approach, that is, I started from the HF bitstream and worked my way up to the application layer protocol. Top-down flow of the data is shown in Figure 7.

Fig. 7 - data flow during transmission

Every now and then I stop for a few hours to monitor the channel (14963.5 KHz) but up until the time of writing I have not had the luckiness of listening such transmissions, neither simple MS-141A exchanges.

https://disk.yandex.com/d/qUCfb7EBQyIKxg

(1) As per STANAG-5066 "C.3.2 Generic detailed D_PDU structure": All D_PDUs, regardless of type, shall begin with the same 16-bit synchronisation (SYNC) sequence. The 16-bit sequence shall (5) be the 16-bit Maury-Styles (0xEB90) sequence shown below, with the least significant bit (LSB) transmitted first: (MSB) 1 1 1 0 1 0 1 1 1 0 0 1 0 0 0 0 (LSB).

(2) most likely the D_PDU frame is repeated to provide some increased probability of receipt and reliability.