27 September 2016

STANAG-4285 & HMTP-66 (HF Mail Transport Protocol) example


Other than (H)BFTP and CFTP, e-mails can be sent over HF using the protocol HMTP (HF Mail Transport Protocol) defined in STANAG-5066 Annex F and  MIL 188-141B Appendix E.  The HMTP protocol is used by a mail client to submit a mail-object to a mail server using the allowed HF transport waveforms, or alternatively, it may be used as the protocol to transfer a mail object over the HF subnetwork from one mail server to another. The HMTP protocol is NOT used to send and receive Formal or High Grade Military Messages but rather for informal interpersonal e-mail only.

The transmission has been heard on 5054.0 KHz/USB at 0804 UTC on 26 September, the used HF waveform is STANAG-4285: ACF and frame structure are shown in fig. 1. The user/organization is still un-identified: likely I went on the signal after the ALE session, anyway no link-closure message followed the end of the S-4285 transmission so it could even be a BRASS/MRL circuit.

fig. 1 - ACF and frame structure of the head signal (STANAG-4285)
A 1776 bit period, often met in STANAG-5066, pops up after removal the STANAG-4285 overhead (fig. 2)
 
fig. 2 - 1776 bit period
The "payload" (email message) is visible in figure 3 once removed the STANAG-5066 headers:

fig. 3 - HMTP mail message
Back to HMTP, "two HF Mail Transfer Protocols have been proposed and both called HMTP. Both are variants of SMTP that reduce the number of link turnarounds thanks to the Pipelining Command. STANAG 5066 Annex F describes a protocol here denoted HMTP-66. The protocol specified in MIL-STD-188-141B Appendix E is here denoted HMTP-141
As said, thanks to Pipelining Command both the HMTP variants allow varying degrees of grouping of the commands and responses to reduce the number of link turnarounds but HMTP-66 goes a step further in respect to HTMP-141: it buffers all responses for all mail messages, sending them in a batch in response to a QUIT command just before ending the connection" (quoting from : E-MAIL STANDARDS FOR HF RADIO - Eric E. Johnson, Science Applications International Corp.). 
Comparison of email transport protocols is shown in figure 4.

fig. 4 - Mail Transfer Protocols comparison

Since the data link protocol used in this transmission is STANAG-5066 we expect HMTP-66 sequences, and this is pecisely what you get (fig. 5):

fig. 5
Note that the sequences in-air are "splitted" in PDUs so we see sequences in seven files that will be re-assembled at S-5066 receive peer.

User, as said above, is unid. From the HMTP-66 sequences in fig. 5 we can grab email addresses and the OS running in the server as well as the 5066 IP Addresses of the peers: destination 006.008.003.036 and source (the sender) 006.008.004.165.

 

25 September 2016

MIL 188-110C App.D: BW6 KHz, SR4800 Bd, Walsh


yet another 188-110C App.D signal (WBHF,  Wide Band High Frequency) spotted around 1850 UTC on 5407.0 KHz/USB by my friend Karapuz: it worth noting the bandwidth of the signal, 6000Hz, and consequently the sampling frequency adopted for the recording, 24000 Hz, which allows a good signal resolution and accommodation. Since the presence of an annoying fading and the signal strength,  the block #2 is the most suitable for a good analysis.
The basic parameter of the waveform are shown in figs 2,3

fig. 2 - baudrate line
fig. 3 - PSK-8 constellation
The cited value of 5407.0 KHz is the tuning frequency used to mantain the signal at the center of the band and thus it isn't the real dial frequency: indeed, you may note that the carrier frequency is almost the double of the expected 3300Hz.

preamble section
From the 188-110C App.D documentation, the orthogonal Walsh modulation is used in the Synchronization Section of the preamble and the length of each super-frame is 18 channel-symbols, ie:
9 (fixed) + 4 (downcount symbols) + 5 (waveform identification symbols) 
Since in 6KHz bandwidth waveforms the preamble channel-symbol is 64 symbol length, the length of each repeated superframe is: 18 (channel-symbols) x 64 (length of one channel-symbol) = 3456 bit. 

fig. 4 - repeated superframes in the Sync Section of the preamble
The lenght of the Sync Section superframes generates the 3456 bit period which is apparent in the bitstream of the preamble after its demodulation (fig. 5).

fig. 5 - 3456 bit period in the preamble due to the superframes length
data section
The data section exhibits ~426ms ACF spikes (fig. 6) that make a 6144-bit length period(!), corresponding to 2048 tribit symbols. The period does not have the Known/Unknown data structure, so mini-probes are not sent but rather the data symbols are sent continuously after the initial preamble: this means that the block #2 is the wavfeorm Id 0 and Walsh Orthogonal Modulation is used.

fig. 6 - ACF value measured in the data section
from D.5.1.2.3  (MIL 188-110C Appendix D):
Waveform ID 0 utilizes a different modulation technique, Walsh Orthogonal Modulation. For each pair of coded and interleaved data bits, the method produces a 32 symbol repeated Walsh sequence. The Walsh Orthogonal Modulation is accomplished by taking each pair of bits, or di-bit, and selecting a corresponding Walsh Sequence. The selected four element Walsh sequence is repeated 8 times to yield a 32 element Walsh sequence. For example, if the di-bit is 01, the sequence 0404 is repeated to generate the 32 symbol sequence:
0, 4, 0, 4, 0, 4, 0, 4, 0, 4, 0, 4, 0, 4, 0, 4, 0, 4, 0, 4, 0, 4, 0, 4, 0, 4, 0, 4, 0, 4, 0, 4

Processing the bitstream of the data section, we get a value of 6144 bit (fig. 7) that matches the ACF value obtained in fig 6:

fig. 7 - 6144 bit period of the data section
Why this 6144 bit? 
For the Walsh Orthogonal Modes (waveform id 0) the data scrambling implementation generates 256 x 8 = 2048 values and the scrambling sequences are continuously wrapped around the 2048 symbol boundary: ie just 2048 x 3 = 6144 bit and then the ACF of the data section is due to the scrambler lenght.
Athough data are modulated using Walsh ortogonal modulation, they are scrambled to appear on-air as the PSK-8 constellation seen in fig. 3.

22 September 2016

PACTOR-IV ("Dragon" modem) BPSK/QPSK


PacTOR-IV transmission using BPSK and QPSK modulation and speed of 1800 symbols/sec (in both the cases), without the characteristic PacTOR-IV spreading factor used at lower data rates. The presence of the spreading can be detected running the 'AM detector' module of SA and looking at the phase vector of the signal: in fig. 2 the AM detector exhibits a single baudrate line (so no spread factor) and the phase vector has a normal trend.

fig. 2
Instead, the AM detector in fig.3 exhibits multiple baudrate lines and the phase vector assumes the characteristic sawtooth ramp. Note that the base speed is about 112.5 Baud (the lower baudrate line and the frequency in the phase vector) while the speed detected by tha analyzer is 1800 Baud: this is a spread-16 since 112.5Bd * 16 just results 1800Bd.

fig. 3
Modulation vary according to the channel condition (PACTOR-IV is an adaptive mode) and the resulting constellations are visible in fig. 4, the related phase vectors are shown in fig. 5

fig. 4 - constellations
fig.5 - phase vectors for BPSK and QPSK blocks
A distinguishing characteristic, other than the 3300ms block length, is the 239 symbols lenght of the BPSK and QPSK frame structures:
239 symbols = 239 bit for BPSK (two modulation symbols, 1 binary digit)
239 symbols = 478 bits for QPSK (four modulation symbols, 2 binary digits)
Bitstreams after demodulations and frame structures are shown in figs 6,7. It may happen that the bistreams have the period length which  is the double of the expected one: most likely this is due to the  un-initialized state of the (generic) psk demodulator of SA.

fig. 6 - PACTOR-IV BPSK frame structure
fig. 7 - PACTOR-IV QPSK frame structure

20 September 2016

logs



04015.0 ---: Unid (poss. Croatian) 0617 USB STANAG-4285 modified waveform (17Sep16) (AAI)
04055.2 DHJ58/3: German Navy, D 0516 USB STANAG-4285 600bps/L continuous bcast (06Sep16) (AAI)
04225.7 IDR: Italian Navy S.Rosa, I 0532 USB STANAG-4285 600bps/L CARBs "IDR02I(0)/IDR23 /IDR22 /IDR03I(0)/IDR04I(0)/IDR21 /"
04250.5 HEB: Global link Berne, SUI 0649 PacTOR/cw marker "CQ DE HEB" (17Sep16) (AAI)
04254.0 DHJ59/3: German Navy, D 0450 USB STANAG-4285 600bps/L continuous bcast (06Sep16) (AAI)
04259.2 ---: Unid 0528 USB STANAG-4285 600bps/L continuous bcast (06Sep16) (AAI)
04277.2 EBA: Spanish Navy, E 0525 USB STANAG-4285 600bps/L continuous bcast (06Sep16) (AAI)
04288.6 FUG: French Navy commcen La Regine, F 0500 USB STANAG-4285 1200bps/L continuous bcast (06Sep16) (AAI)
04295.0 FUE: French Navy Brest, F 0445 USB STANAG-4285 600bps/L test strings "ALL DE FUE" (06Sep16) (AAI)
04325.0 FUE: French Navy commcen Brest, F 0505 USB STANAG-4285 600bps/L continuous bcast (06Sep16) (AAI)
04338.0 FUE: French Navy commcen Brest, F 0510 USB STANAG-4285 600bps/L continuous bcast (06Sep16) (AAI)
04422.6 DHJ58: German Navy Gluecksburg, D 0542 USB STANAG-4285 600bps/L continuous bcast (06Sep16) (AAI)
04618.0 BPLEZS: 0547 USB  MIL 188-141 2G-ALE handshake BP24 flwd by R&S GM2100 HF modem "signal format" (14Sep16) (AAI)
04643.0 FUO: French Navy, F 0602 USB STANAG-4285 1200bps/L continuous bcast (06Sep16) (AAI)
04743.5 ---: Unid 0552 USB STANAG-4197 ANDVT modem (17Sep16) (AAI)
04921.5 DUM: Polish Mil, POL 0555 MIL 188-141 2G-ALE calling OSI (14Sep16) (AAI)
05068.5 ---: Unid 0730 USB Thales Systeme-3000 Skymaster ALE flwd by Thales TRC-177x PSK-8 2400Bd, S-4285 modified waveform (10Sep16) (AAI)
05215.6 FUO: French Navy, F 0608 USB STANAG-4285 1200bps/L continuous bcast (06Sep16) (AAI)
05246.2 SXV: Greek Navy, GRC 0611 USB STANAG-4285 1200bps/L continuous bcast (06Sep16) (AAI)
05270.0 IDR: Italian Navy S.Rosa Rome, I 0625 USB/J3E radio check with Bussola, Orale and Filone (06Sep16) (AAI)
05297.5 ---: Unid 0631 USB Thales Systeme-3000 Skymaster ALE (06Sep16) (AAI)
05316.0 K1U: Slovakian Mil, SVK 0602 USB MIL 188-141 2G-ALE calling Z1V (14Sep16) (AAI)
05316.0 K51: Slovakian Mil, SVK 0615 USB MIL 188-141 2G-ALE sounding (14Sep16) (AAI)
05316.0 Z1V: Slovakian Mil, SVK 0602 USB MIL 188-141 2G-ALE calling S1S (14Sep16) (AAI)
05441.0 ---: Unid 0620 USB STANAG-4285 1200bps/L continuous bcast (06Sep16) (AAI)
05687.0 ---: Germany Air Force 0624 USB/J3E wkg 406 (06Sep16) (AAI)
05747.0 SD4: Slovakian Mil, SVK 0556 USB MIL 188-141 2G-ALE VY5 handshake (08Sep16) (AAI)
05747.0 VY5: Slovakian Mil, SVK 0608 USB MIL 188-141 2G-ALE HK6 handshake (08Sep16) (AAI)
05747.0 VY5: Slovakian Mil, SVK 0622 USB MIL 188-141 2G-ALE calling SD4 (06Sep16) (AAI)
05798.0 JNR: USAF Salinas Puerto Rico, PTR 0623 USB MIL 188-141 2G-ALE sounding (16Sep16) (AAI)
05837.5 ---: Unid 0630 USB Thales Systeme-3000 Skymaster ALE (06Sep16) (AAI)
05838.0 ABC7: Unid 0732 USB MIL 188-141 2G-ALE ABD1 handshake, voice radio-check (08Sep16) (AAI)
05838.0 ABC7: Unid 0734 USB MIL 188-141 2G-ALE ABS5 handshake, auth id then STANAG-5066 HMTP over STANAG-4285 1200bps/S (06Sep16) (AAI)
05838.0 ABC7: Unid 0735 USB MIL 188-141 2G-ALE calling ABH3 (no reply) (06Sep16) (AAI)
05838.0 ABC7: Unid 0738 USB MIL 188-141 2G-ALE ABD1 handshake, auth id then STANAG-5066 HMTP over STANAG-4285 1200bps/S (06Sep16) (AAI)
05838.0 ABC7: Unid 0740 USB MIL 188-141 2G-ALE ABF2 handshake, voice radio-check (08Sep16) (AAI)
05838.0 ABC7: Unid 0741 USB MIL 188-141 2G-ALE ABS5 handshake, voice radio-check (08Sep16) (AAI)
05838.0 ABC7: Unid 0743 USB MIL 188-141 2G-ALE ABH3 handshake, voice radio-check (08Sep16) (AAI)
05838.0 ABC7: Unid 0746 USB MIL 188-141 2G-ALE ABK4 handshake, voice radio-check (08Sep16) (AAI)
05838.0 ABC7: Unid 0747 USB MIL 188-141 2G-ALE ABG6 handshake, auth id then STANAG-5066 HMTP over STANAG-4285 1200bps/S (06Sep16) (AAI)
05838.0 ABC7: Unid 0748 USB MIL 188-141 2G-ALE ABD1 handshake, voice radio-check (08Sep16) (AAI)
05838.0 ABC7: Unid 0804 USB MIL 188-141 2G-ALE ABF2 handshake, voice radio-check, auth id then STANAG-5066 HMTP over STANAG-4285 1200bps/S (08Sep16) (AAI)
05838.0 ABC7: Unid 0818 USB MIL 188-141 2G-ALE ABk4 handshake, auth id then STANAG-5066 HMTP over STANAG-4285 1200bps/S (06Sep16) (AAI)
05838.0 ABC7: Unid 0756 USB MIL 188-141 2G-ALE handshake ABG6, exchange auth id flwd by STANAG-5066 over STANG-4285 (20Sep16) (AAI)
05838.0 ABC7: Unid 0803 USB MIL 188-141 2G-ALE calling ABG6 (13Sep16) (AAI)
05838.0 ABC7: Unid 0804 USB MIL 188-141 2G-ALE handshake ABF2, radio check (13Sep16) (AAI)
05838.0 ABC7: Unid 0805 USB MIL 188-141 2G-ALE handshake ABS5, radio check (13Sep16) (AAI)
05838.0 ABC7: Unid 0806 USB MIL 188-141 2G-ALE handshake ABH3, radio check (13Sep16) (AAI)
05838.0 ABC7: Unid 0806 USB MIL 188-141 2G-ALE handshake ABK4, radio check (13Sep16) (AAI)
05838.0 ABC7: Unid 0807 USB MIL 188-141 2G-ALE handshake ABD1, radio check flwd by STANAG-5066 over STANG-4285 1200bps/S (13Sep16) (AAI)
05838.0 ABC7: Unid 0823 USB MIL 188-141 2G-ALE handshake ABH3 flwd by STANAG-5066 over STANG-4285 (20Sep16) (AAI)
05838.0 ABC7: Unid 0834 USB MIL 188-141 2G-ALE handshake ABK4,exchange auth id flwd by STANAG-5066 over STANG-4285 (20Sep16) (AAI)
05884.0 FUO01D: French Navy Toulon, F 0750 USB MIL 188-141 2G-ALE handshake CDG01D Carrier "Charles de Gaulle" flwd by STANAG-4285 300bps/S KG84 encrypted messages (16Sep16) (AAI)
05884.0 LYR01D: French Navy ship (M648 Lyre?),F 1020 USB MIL 188-141 2G-ALE handshake FUO01D Toulon flwd by STANAG-4285 300bps/S KG84 encrypted messages (16Sep16) (AAI)
06130.0 T3O: Slovakian Mil, SVK 0843  USB  MIL 188-141 2G-ALE handshake R2k, voice comm (too weak to read) (13Sep16) (AAI)
06218.2 NSS: US Navy (relay from S.Rosa Rome, I ?) 0925 USB STANAG-4285 CARB bcast "NSS3I(0)/NSS4I(0)/" (10Sep16) (AAI)
06250.0 IDR: Italian Navy, S.Rosa-Rome, I 0840 radio check with IHMT flwd by STANAG-4285 600bps/L with KG-84 encryption (13Sep16) (AAI)
06329.0 OSY: Sailmail Brugge, BE 0650 USB (cf + 1500Hz) PacTOR-III (18Sep16) (AAI)
06604.0 WSY-70: New York Volmet 0515 USB/J3E "This is New York Radio" (19Sep16) (AAI)
06902.6 KWA37: US Dept of State station 1318 USB MIL 188-141 2G-ALE calling KWT93 (01Sep16) (AAI)
06930.0 B10: Ukrainian net, UKR 0506 USB MIL 188-141 2G-ALE sounding (19Sep16) (AAI)
07610.0 VY5: Slovakian Mil, SVK 0546 USB MIL 188-141 2G-ALE calling SD4 (12Sep16) (AAI)
08010.5 ---: Unid 0555 (cf) FSK-2 100Bd/500 revs (16Sep16) (AAI)
08070.0 ---: Algerian Mil, ALG 0510 USB J3e/USB voice comm flwd by MIL 188-110 ST 2400/4800bps (20ms ACF) (26Aug16) (AAI)
08151.7 ---: Unid 0600 USB STANAG-4285 600bps/L KG-84 encrypted messages (16Sep16) (AAI)
08348.0 ---: Unid 0457 USB STANAG-4197 ANDVT modem (26Aug16) (AAI)
10116.0 ---: Russian Navy, RUS 0732 (cf) CIS Navy "Akula" FSK 500Bd/1000 (05Sep16) (AAI)
11120.0 CM1:  Algerian AF Blida, ALG 0958 USB MIL 188-141 2G-ALE calling 761 (04Sep16) (AAI)
12153.0 ---: Russian Intel, RUS 0738 (cf) MFSK-68 (34+34) + QPSK 2400Bd 10KHz wide-band inserts (05Sep16) (AAI)
12155.0 ---: Russian Intel, RUS 0734 USB CIS FTM-4, MFSK-4 150Bd (effective 37.5Bd) 4000Hz modem (tones at: -6, -2, +2, +6 KHz) (05Sep16) (AAI)
12176.2 DHJ58: German Navy, D 0746 USB STANAG-4285 600bps/L 17-secs KG-84C encrypted msg (05Sep16) (AAI)
12198.6 ---: Unid 0817 (cf) Siemens CHX200 F1-modem (CHP-200), FSK 249 & 250 Bd 170 Hz (05Sep16) (AAI)
12370.1 ---: Unid NATO bcst 0552 USB STANAG-4285 600bps/Long with KG-84C encrypted msgs (01Sep16) (AAI)
12394.0 ---: Unid 0809 USB Arcotel MAHRS-2400 ALE bursts, 2400Bd PSK-8 (05Sep16) (AAI)
12704.6 CTA: Portoguese Navy, POR 0734 LSB STANAG-4285 600bps/L CARBs "//CTA02I/CTA08I/CTA12I/CTA14I/CTA16I//" (17Sep16) (AAI)
13215.0 MCC: HFGCS McClellan CA, USA 0552  USB MIL 188-141 2G-ALE sounding (23Aug16) (AAI)
13390.1 ---: Unid 1300 FSK 50Bd/520 revs (29Aug16) (AAI)
13423.5 XPZ: UK DHFCS (mobile station?), G 0811 USB MIL 188-141 2G-ALE calling XSS (18Aug16) (AAI)
13500.0 ---: Unid (prob. Ukrainian net) 0520 USB 2 of 6x100Bd/120Hz VFT system (12Sep16) (AAI)
13503.6 KWT93: US Dept of State station 0724 USB MIL 188-141 2G-ALE calling KWT (25Aug16) (AAI)
13554.0 CENTR3: MFA Bucarest, ROU 0807 USB MIL 188-141 2G-ALE handshaking BLJ (18Aug16) (AAI)
14489.5 ---: Unid (prob. Ukrainian net) 0620 (cf) FSK 100Bd/2000, T-207 encryption (12Sep16) (AAI)
14489.5 ---: Unid (prob. Ukrainian net) 0653 (cf) FSK 100Bd/2000, T-207 encryption (29Aug16) (AAI)
14570.0 ---: Unid (prob. Ukrainian net) 0522 USB 1 of 6x100Bd/120Hz VFT system (12Sep16) (AAI)
14581.5 ---: Russian Navy, RUS 1531 FSK 50Bd/40, 7-bit code 4/3 (four 1 + three 0) (01Sep16) (AAI)
14617.3 ---: Unid NATO bcst 0728 USB STANAG-4285 600bps/Long with KG-84C encryption transmissions (23Aug16) (AAI)
14631.1 CTA: Portoguese Navy, POR 0725 LSB STANAG-4285 600bps/L CARBs "//CTA02I/CTA08I/CTA12I/CTA14I/CTA16I//" (17Sep16) (AAI)
14801.2 ---: Russian Intel, RUS 0916 USB CIS-3000 PSK-8 3000Bd serial flwd by MFSK-68 (34+34) (20Sep16) (AAI)
14969.5 ---: Unid (prob. Ukrainian net) 0615 (cf) FSK 100Bd/2000, T-207 encryption (12Sep16) (AAI)


15 September 2016

HF networks mapping from on-air signals

The aim of the post is to illustrate an "hand" method to draw HF networks from STANAG-5066 Protocol Data Units (PDUs) that are exchanged over HF radio between peer HF nodes: mainly, the DATA-ONLY type 0 D_PDUs (Simplex data transfer) will be used here.
According to the STANAG-5066 terminology, a node (or HF node), is an implementation of the profile described in the main body and mandatory annexes to the S-5066 profile. The node is generally assumed to include the HF (modem and radio) and cryptographic equipment required for communications. A subnetwork is a collection of nodes. As a whole, a subnetwork provides a reliable networked data-transport service for external users or clients (client applications). 
It may happen that in certain deployments the client applications (clients) reside inside the same physical machine that run the node as well as deployments in which the clients reside in a LAN(s), behind the HF node.

To map a certain STANAG-5066 HF network we need to know the IP adresses of the nodes which belong to that network: it can be done by recording the transmissions from that network and analyzing the S-5066 D_PDUs which compose the bitstream obtained after the removal of the overhead added by the used HF waveform (S4285, MS188-110A/B,...). If the heard transmissions are in plain-text (not encrypted) then source and destination IP addresses will be found in the headers of the D_PDUs (fig. 1). These on-air addresses will be associated to the routing indicators in the HF address table of the 5066 software.

fig. 1
The D_PDU headers can be highlighted by synchronizing the bitstream on the 16-bit Maury-Styles sequence 0xEB90 since all D_PDUs, regardless of type as seen in previous posts in this blog, begin with that same sync. Sometimes, change the polarity may be necessary (fig. 2). The sync sequence 0xEB90 causes a marked 1776 bit ACF, that makes a 222 bytes period, in case of DATA-ONLY type D_PDUs.

fig. 2
As specified in Annex C of S-5066, the Size-of-Address Field  specify the number of bytes in which the source and destination address are encoded. The address field may be from one (1) to seven (7) bytes in length, with the source and destination address of equal length.
Since the D_PDU header must be made up of an integer number of bytes, addresses are available in 4-bit increments of size: 4 bits (or 0.5 bytes), 1 byte, 1.5 bytes, 2 bytes, 2.5 bytes, 3 bytes, and 3.5 bytes.

In the headers of figure 2 the size of address field is the binary 111 or decimal 7, so half of the bits, 3.5 bytes, are assigned to the source and the other half to the destination. By dividing the addresses field we get the 0.0.0.203 as the source IP, and 0.0.0.90 as the destination IP of the peers (figs. 3a,3b).
fig. 3a
fig. 3b

The "Group Address" can be likely found in D_PDU headers: as above, these addresses are obtained by looking at size of address field as in figs 4,5.

fig. 4
fig. 5
Transmissions that exchange data are usually preceeded by MS 188-141A handshakes which allow to build and populate a sort of basic "HF pairings table" [1] for each organization you want monitor, consisting of the ALE calls and their (on-air) IP addresses. With a little luck you can receive HF emails and henance your pairings-tables by adding the e-mail addresses (fig. 6).

fig. 6
Below some simple mappings of little(!) pieces of real HF networks: although the IP addresses come from real-world, some node names are fictional. Countries and  Mil/Gov/Diplo authorities and organizations are intentionally omitted.

As said, we focused on the DATA-ONLY type 0 D_PDUs but source and destination IP addresses are available also from the other D_PDU types (up to 15). By the way, since type 0 D_PDU send segmented C_PDUs, they are used in conjunction with a basic selective automatic repeat request type of protocol such as the ACK-ONLY type 1 D_PDU (fig. 7).
 
fig. 7
What has said above is an hand-method to obtain the addresses, a great help comes from protocol analyzers which can do the work for you.  Anyway, comparisons between results and bitstreams is always a good practice:  exotical IP addresses may come from corrupted frames (fig.8) which are ignored by the parser.


fig.8
As a final note, I want to advise that this post is not an hostile attempt or an encouragement to grab reserved informations since the heard transmissions are in clear-text and a rich documentation of STANAG-5066 D_PDUs is widely known and publicly downloadable from NATO and other web sites.
I have only shown the "boxes"  and not their contents: contents are encrypted and anyway I am not interested in them but only in the technical aspects of such communications. Likely, further posts on this topic will follow.



[1] the so-called "HF Domain Map" and "HF Address Table" as they appear in some 5066 system packages: it's worth noting the similarity with the "HF Pairing table". Thanks to my friend Marco for these screenshots!