FLSU/FTM protocol + 188-110A Serial: example of 3G/2G switching

post has been moved here:
http://i56578-swl.blogspot.it/2017/02/stanag-4538-circuit-mode-3g-2g-switching.html

R&S proprietary ARQ-protocol RSX.25 over GM-2100 HF modem

transmission received on 06450.0 KHz on USB at 0753 UTC. The ending part in MIL 188-141A, which terminates the link, reveals that the user is the Italian "Guardia di Finanza - GdF", ALE addresses are CAGLIARI (Coastal Naval Station in Cagliari, the sender) and the patrol boat OLTRAMONTI (the receive peer). 

Data are sent using the HF waveform "Signal Format", a so-called Rohde & Schwarz proprietary advanced waveform originated by the HF modem GM2x00, in combination with the proprietary ARQ-protocol RSX.25. LAN/WAN interconnections are most likely managed by the "Message Handling System PostMan" running at upper layer.

RSX.25 literally stands for R&S adaptation of wired X.25 protocol to the HF radio channel, it derives from the packet protocol X.25 and cannot be used togheter with STANAG and MIL-STD HF waveforms such as S-4039, S-4285 and 199-110A; for these waveforms, radio protocols such as STANAG 5066 are available (quoting from R&S data sheets [1]).

The GM2x00 waveform "Signal Format" exhibits the usual 1800Hz carrier with PSK-8 modulation at 2400 symbols/sec (Fig. 1)

Fig.1

Figs. 2a and 2b show the frame structure. The preamble consisting of a fixed 192 symbol sequence enables the receive station to synchronize with correct timing and phase. The following data block consists of 64-symbols frames each composed of 48 unknown (data) symbols + 16 known symbols (probe). The postamble, terminating the data block, has a structure which is basically the same as that of the data frames but it contains a stop-code sequence instead of information data.

Fig.2a

Fig. 2b (from a different recording)

Most likely the patterns of the test sequences generate the 133.33msec ACF spikes, i.e. five data blocks which make 960 bit or 320 symbols period (Fig.3).
 

Fig.3

The RSX.25 protocol permits all types of digital data to be transmitted, eg for a printer, digital camera, camcorder or fax unit. RSX.25 organizes the data to be transmitted in packets, which are successively transferred to the data modem. The packets contain a variable number of frames, the number per packet depending on radio-link quality and being adapted at regular intervals.
The data transmitted in a packet are distributed among the frames. The length of the frame data is variable and also depends on radio-link quality. In channels of very good quality, a frame contains 250 data bytes, in strongly disturbed channels 4 bytes. The length of the transmitted data is continually adapted to link quality. 
RSX.25 has a typical period of 8-bit period with recognizable patterns and is visible once removed the overhead due the Signal Format waveform (Fig. 4).

Fig.4

https://www.rohde-schwarz.com/fi/file/n160_email.pdf
https://www.rohde-schwarz.com/file/n155_shortwave.pdf

https://yadi.sk/d/L8ccg2Nnyq5Su

cars, chameleons, networks, and other stories (update)

6231 net (6231.0 KHz)
I recently spotted the frequency 6231.0 KHz on USB where stations connect following the same procedure as of AB-net and use STANAG-5066 HMTP protocol which is transported by a STANAG-4285 modem configured for 1200 bps and short interleaver (Figs. 1,2).  As in the 5054-net, the message transfer is not preceded by ALE or selcall phase and this supports the idea of scheduled tansmissions. 
The post related to AB-net and 5054-net (HRV MORH-u) can be read here.

Fig.1 - the HF waveform (Stanag-4285)

Fig.2 - 1776 bit period (Stanag-5066)

While the transmissions in the AB-net are scheduled on tuesday and thursady from 0830 UTC (0730, daylight savings time), transmissions on this frequency start  at 0800 UTC on monday and wednesday (most likely 0700, daylight savings time)[1]. These are the heard callsigns,  listed in the call-order: 
GHU3 (net-control station)
ONI6
ZIO4
OLI7
NIK2
ULI6
VEL8
CIK5
ZIL7
Stations are contacted a first time by GHU3 for a radio-check then, in case of messages, the stations shall be contacted a second time and in the same order. Unless the initial 188-141 2G-ALE phase, the message transfer follows the schema seen here, used in the AB-net.

The HMTP headers in Fig. 4 prove that this net belongs to the HRV MORH-u network as the previous AB-net and 5054-net: same OS (Linux Open-SUSE), same STANAG-5066 application ("CroS 5066", developed by CROZ) and same attachment filename.

Fig. 4

The examination of the headers of the Data PDUs (D_PDU) gives the chance to get the STANAG-5066 addresses of the nodes in the play. 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, begin with that same sync (it's just this sequence that causes the 1776-bit ACF of Figure 2).

Fig.5 - D_PDU headers

The S-5066 addresses obtained from the recordings belong to the 006.008.003.zzz subnet, then 5054.0 and 6321.0 KHz  are just two channels of the same subnet.
Below the updated S-5066 Addresses Table and the Network Map. 

AB-net 5838.0 KHz (...)
ALE  S-5066 Add.       E-mail Add. 
ABC7 006.008.001.039   user1@asdf.123 (ncs)
ABD1 006.008.004.166   user1@sdfg.123
ABG6 006.008.004.165   user1@dfgh.123
ABF2 006.008.006.226   user1@fghj.123
ABS5 006.008.008.215   user1@ghjk.123
ABK4 006.008.002.144   user1@jklp.123
ABH3 006.008.002.055          ?

5054/6231-net 5054.0 KHz, 6231.0 KHz
CALL S-5066 Add.       E-mail Add.

GHU3 006.008.004.165   user1@aysxd.111 (ncs)
ZIO4 006.008.003.032   user1@oli93.111
     006.008.003.033   user1@lost62.111
NIK2 006.008.003.036   user1@dres32.111
ULI6 006.008.003.037   user1@fejk8.111
CIK5 006.008.003.039   user1@huba9.111
ONI6
OLI7
VEL8
ZIL7

Anyway, these are tactical callsigns and rotate likely on a monthly base: e.g. in January 16 2017  the station user1@huba9.111 has been heard with callsign CHP3 (was CIK5) and obviously with same S-50966 Address (006.008.003.039).

[1] further recordings are needed

STANAG-4538 3G-HF, HDL complete session

3G-HF HDL transfer heard on 10627.0 KHz/USB at 1258 UTC
The High-throughput Data Link protocol (HDL), defined in STANAG-4538, is a selective repeat ARQ protocol which can only be run in a point-to-point data packet connection. HDL is most efficient when large volumes of data are to be transmitted and the channel conditions are moderately good, while LDL is best suited for small data volumes and in poor quality channel
"Data transfer by HDL begins after the stations have already established the data link connection in the traffic setup phase (using FLSU BW5 waveform). In an HDL data transfer, the sending station and the receiving station alternate transmissions in the manner depicted in figure 1; the sending station transmitting HDL_DATA PDUs containing payload data packets, and the receiving station transmitting HDL_ACK PDUs containing acknowledgments of the data packets received without errors in the preceding HDL_DATA PDU. The end of a data transfer is reached when the sending station has transmitted HDL_DATA PDUs containing all of the payload data in the delivered datagram, and the receiving station has received these data without errors and has acknowledged their successful delivery. When the sending station receives an HDL_ACK PDU indicating that the entire contents of the datagram have been delivered successfully, it sends an HDL_EOM PDU repeated as many times as possible within the duration of an HDL_DATA PDU, starting at the time at which it would have otherwise transmitted the next HDL_DATA PDU." [1]

fig. 1a

Fig. 1b

 
As in STANAG-4538 Table 13-1, HDL protocol use the burst waveforms BW2 for data forward and BW1 for ACK and EOM/Term signal, all the burst waveforms use the basic PSK-8 modulation at 2400 baud centered at 1800hz also used in the MIL-STD 188-110A serial tone modem waveform (fig. 2) and can be identified by measuring their duration (fig. 3)

fig. 2

fig. 3

BW2 consists of 100 msec TLC section and a short (26,67 msec) preamble followed by a number of fixed-size data packets (3, 6, 12, or 24): the number of packets is negotiated before the HDL protocol starts and remains unchanged until the end of the data transfer. Each packet consists of 20 frames, each of which contains 32 unknown symbols (data) followed by 16 known symbols acting as probe (fig. 5). 
HDL protocol is packet-oriented, in contrast with LDL protocol which is byte-oriented, and it can be designated by a number as HDL<n> where n - as said above - is the negotiated  number of packets which are transmitted in one forward frame: for example, in the recorderd transfer we see HDL3-type frames.

fig. 5

Burst waveform 1 (BW1) is a general-purpose waveform used to carry short messages for many of the 3G protocols: traffic management, link maintenance, and data acknowledgments for the HDL protocol. It consists of 576 PSK-8 symbols preamble followed by 2304 PSK-8 symbols of data which are coded using 16-ary Walsh seqences (fig. 6).

fig. 6

It's worth noting that all the six burst waveforms specified by STANAG-4538 begin with a TLC/AGC guard sequence, why? Existing HF radios were generally not designed with burst waveforms in mind. For example, MIL-STD-188-141 military radios are allowed 25 ms to reach full transmit power after keying. While the transmitter radio frequency stages are ramping up, the input audio signal level is adjusted by a transmit level control (TLC) loop so that it fully modulates the transmit power. At the receiver, an automatic gain control (AGC) loop must also adjust to a new receive signal. To accommodate these characteristics of existing radios, the 3G burst waveforms just begin with a TLC section of “throwaway” 8-ary PSK symbols that are passed through the system while the transmitter’s and receiver’s level control loops stabilize.

[1] from: "Third-Generation and Wideband HF Radio Communications" 
 

https://yadi.sk/d/kwnmIEE_y3xNb

BPSK 2400Bd 3Khz, QPSK 4800Bd 6 KHz (Maritime Band)

These are unidentified signals heard by me and my friend KarapuZ in the Maritime Band segments, mainly 8 and 12 MHz, during daylight. Transmissions are a mix of 3 KHz and 6 KHz wide channels and use PSK modulation, symbols rate is dependent on the bandwidth:

3 KHz BW: 2400 symbols/sec, BPSK modulation (fig. 1)
6 KHz BW: 4800 symbols/sec, BPSK and QPSK modulation (figs. 2, 3)

fig. 1

fig. 2

fig. 3

a (possible) 3G-HF multicast transfer with MDLN protocol

This burst-trasmision has been heard on 13505.0 KHz/USB at 1120 UTC (27 Oct). All of the burst waveforms use an 8-ary PSK serial tone modulation of an 1800 Hz carrier at 2400 symbols per second (fig. 1)

fig. 1

The analysis of the bursts say that they belong to the HF burst waveforms described in STANAG-4538 3G-HF, specifically: after the initial BW5 FLSU burst, there are four BW3 tansmissions which transport 4 x 512 bytes of data and two zero-filled BW3 transmissions which transpot 2 x 51 bytes of data. The transfer ends with a single BW4 burst. BW3 and BW4 waveforms are used by LDL protocol, as defined in STANAG-4538.

fig. 2 - BW3 burst

fig. 3 - BW4 burst

In a normal  LDL data transfer, the sending station and the receiving station alternate transmissions in the manner of figure 4: the sending station transmits LDL_DATA PDUs containing payload data  packets,  and  the  receiving  station  transmits  LDL_ACK  PDUs  each  containing  an acknowledgement  of  whether  or  not  the  data  packet  in  the  preceding  LDL_DATA  PDU  was received without error. The LDL_EOM PDU is transmitted using  the  BW4  waveform indicating that the entire user  datagram  has  been  delivered  to  the  receiving  station  without  errors ( LDL_EOM  PDUs  are  distinguished  from  LDL_ACK PDUs by context: any PDU sent using BW4 in the forward direction is an LDL_EOM PDU, while any PDU sent using BW4 in the reverse direction is an LDL_ACK PDU).

fig. 4 - 3G-HF LDL protocol transfer session

Conversely, in this recording there are no BW4 ACK bursts returned by the receiver station but only a final BW4 burst... unless the BW4 ACKs were transmitted and I did not receive them (Fig. 5):

fig. 5 - the heard 3G-HF session

The supposed lack of ACKs in figure 5 leads to think to a non-ARQ multicast transmission or a trasmission for recipients which are in EMCON (Emission Control): anyway STANAG-4538 does not provide the non-ARQ modality and the HDL/LDL protocols are for point-to-point applications only.

A possible scenario could be the use of the MDL-NACK protocol, Multicast Data Link with NAKs or MDLN. MDLN is a 3G multicast protocol with embedded retransmissions, it's added alongside the point-to-point 3G data link protocols HDL, HDL+ and LDL and shares many of the characteristics of the other 3G data link protocols (fig. 6).

fig. 6 - extended 3G-HF

In MDLN each forward transmission is followed by a pause during which receivers that were not able to decode that transmission emit a very robust pseudonoise (PN) PSK symbol sequence to request retransmission (fig. 7). All receivers share the NAK slot. (Detection of the PN NAK sequence is sufficiently robust to allow any number of NAKs to overlap during the slot.) When the sender detects a NAK, it sends additional redundancy bits. Thus MDLN, like the point-to-point ARQ protocols, sends only enough redundancy to convey the message error-free. 

In our case, the data transfer is performed using MDL-512, a robust mode that uses a stream of 512-byte BW3 bursts. All recipients have decoded the entire transmission so we do not see NACKs.

fig. 7 - MDL-NACK opeation

MDL-MDLN protocol has been introduced in "Third Generation and Wideband HF Radio Communications" and in "Military Communications Conference, 2005" by E. Koski - Harris Corporation. The presence of the Citadel pattern (fig. 8) in the decoded bistream is a strong clue and would just confirm the use of Harris equipment. The transfer contains only one encrypted datagram. Obviously, the encryption is off-line.

fig. 8 - Citadel encryption

https://yadi.sk/d/7sMqo4-OxnJEm 

Logs

03806.5 OE3XEC: Amsstetten AUT, 0754 WinLink traffic (23Oct16) (AAI)
05115.0 ---: Turkish Mil, TUR 0549 (cf) FSK 300Bd/400, KG-84C encrypted (24Oct16) (AAI)
05140.0 ---: Russian Mil (prob. AF) 0602 J3E/USB female voice comms (24Oct16) (AAI)
05182.0 ---: Unid 0722 R&S ALIS 228.65Bd/200 calling address 2190 (25Oct16) (AAI)
05210.0 BU4: Roumenian Police Bucuresti, ROU 0602 USB MIL 188-141 2G-ALE handshake TUL flwd by MIL 188-110A (19Oct16) (AAI)
05211.5 6GW0: Italian Mil, I 0647 J3E/USB radio-check with FB4T, 0WPF, Q77V, 3X0N, Q67Z (25Oct16) (AAI)
05258.0 J62: Moroccan Mil, MRC USB MIL 188-141 2G-ALE sounding (19 Oct16) (AAI)
05316.0 K1U: Slovakian AF, SVK 0637 USB MIL 188-141 2G-ALE calling Z1V (25Oct16) (AAI)
05316.0 P1O: Slovakian AF Prezov, SVK 0637 USB MIL 188-141 2G-ALE calling Z1V (25Oct16) (AAI)
05316.0 S1L: Slovakian AF, SVK 0637 USB MIL 188-141 2G-ALE calling Z1V (25Oct16) (AAI)
05316.0 Z1V: Slovakian AF Zvolen, SVK 0637 USB MIL 188-141 2G-ALE calling S1S (25Oct16) (AAI)
05340.0 LY01: Algerian Mil, ALG 0549 USB MIL 188-141 2G-ALE calling PY01 (26Oct16) (AAI)
05352.5 HG7BHB: propagation beacon, HUN  0545 CW "VVV DE HG7BHB  QTH JN97LE 34SF PWR 50W" (24Oct16) (AAI)
05371.5 9A3WD1P: Global ALE HFnet 0630 USB MIL 188-141 2G-ALE sounding (22Oct16) (AAI)
05400.0 DG501D: French Navy, F 0737 USB 188-141 2G-ALE handshake DG401D flwd by STANAG-4285, KG-84C encrypted (20Oct16) (AAI)
05405.0 YK01: Algerian Mil, ALG 0551 USB MIL 188-141 2G-ALE calling PY01 (26Oct16) (AAI)
05410.0 3127: Sonatrach, ALG 0647 USB MIL 188-141 2G-ALE sounding (24Oct16) (AAI)
05415.5 ---: Russian Mil (prob. AF) 0710 J3E/USB female voice comms (24Oct16) (AAI)
05420.0 IU01: Algerian Mil, ALG 0634 USB MIL 188-141 2G-ALE calling JP01 (27Oct16) (AAI)
05424.0 5B: Bosnia Herzegovina Defense 5th Infantry Brigade Tuzla, BIH 0722 USB MIL 188-141 2G-ALE handshake 2PB flwd MIL 188-110A (24Oct16) (AAI)
05453.0 FP: prob.Italian Guardia Costiera, I 0645 J3E/USB stations: WW, EA, EB, EF, radio-checks, coded msgs as ADA,ASA,ASB,ATA,ANA,ATB using NATO phonetic, prob voice-net parallel to data-net (20Oct16) (AAI)
05455.0 RD21: Algerian Mil, ALG 0557 USB MIL 188-141 2G-ALE handshake PY20 flwd by 188-110A (25Oct16) (AAI)
05500.0 5555: Unid net 0610 USB MIL 188-141 2G-ALE calling 4444 [CMD AMD][/>A2001  ] (20Oct16) (AAI)
05792.0 2212: Unid net 0614 USB MIL 188-141 2G-ALE sounding (20Oct16) (AAI)
05813.5 DO7: Polish Mil, POL 0619 USB MIL 188-141 2G-ALE calling RA2 (26Oct16) (AAI)
05813.5 DO7: Polish Mil, POL 0621 USB MIL 188-141 2G-ALE calling PT1 (26Oct16) (AAI)
05813.5 WI5: Polish Mil, POL 0619 USB MIL 188-141 2G-ALE sounding (26Oct16) (AAI)
05850.0 BU4: Roumenian Police, ROU 0633 USB MIL 188-141 2G-ALE handshake TUL flwd by 188-110A transporting STANAG-5066 HBFTP msgs (24Oct16) (AAI)
05903.0 DO7: Polish Mil, POL 0621 USB MIL 188-141 2G-ALE handshake WI5 (26Oct16) (AAI)
05903.0 DO7: Polish Mil, POL 0627 USB MIL 188-141 2G-ALE calling TE6 (26Oct16) (AAI)
06450.0 ZOCCOLA: Guardia di Finanza, I 0720 USB MIL 188-141 2G-ALE handshake CAGLIARI, voice comms using callsigns ROSTRO549 (ALE ZOCCOLA) and SIRIO60 (ALE CAGLIARI): position, heading and speed of ROSTRO549 (27Oct16) (AAI)
06510.0 Z1V: Slovackian AF Zvolen, SVK 0633 USB 188-141 2G-ALE handshake P1O Prezov flwd by 188-110A transporting Stanag-5066 HBFTP msgs (20Oct16) (AAI)
06779.0 ---: Unid 0705 USB RFSM-8000 modem with data-masking (21Oct16) (AAI)
06806.0 ---: Unid 0845 USB MIL 188-141 2G-ALE using App.B Linking Protection (27Oct16) (AAI)
06905.0 BX02: Algerian Mil, ALG 0757 USB MIL 188-141 2G-ALE calling PY01 (22Oct16) (AAI)
06905.0 HN02: Unid (Algerian Military?) 0824 USB MIL 188-141 2G-ALE handshake BZ01, no traffic (27Oct16) (AAI)
06931.0 ---: Unid 0628 USB modified STANAG-4285 waveform (21Oct16) (AAI)
07316.0 ---: Russian Nvay, RUS 0615 (cf) CIS Navy "Akula" FSK 500Bd/1000 (25Oct16) (AAI)
07535.0 CP01: Algerian Mil, ALG 0541 USB MIL 188-141 2G-ALE calling PY01 (25Oct16) (AAI)
07656.0 ---: Russian Intel, RUS 0710 USB CIS FTM-4, MFSK-4 150Bd (effective 37.5Bd) 4000Hz modem (tones at: -6, -2, +2, +6 KHz) (26Oct16) (AAI)
07745.0 TBB: Turkish Navy Ankara, TUR 0520 USB STANAG-4285 600bps/L CARBs//TBB040I(0)/TBB041I(0)/TBB043I(0)/TBB045I(0)/TBB049I(0)/TBB050I(0)// (25Oct16) (AAI)
08950.0 83401: Turkish Emergency Net, TUR 2037 USB MIL 188-141 2G-ALE sounding (22Oct16) (AAI)
09095.0 ---: Unid (prob. Ukrainian net) 0522 USB 3 of 6x100Bd/120Hz VFT system (26Oct16) (AAI)
10168.0 ---: Unide 1229 USB Arcotel MAHRS-2400 ALE bursts (25Oct16) (AAI)
11155.0 RIT: Rus Navy HQ Severomorsk, RUS 0846 CW "RAL65 DE RIT QSA?" (23Oct16) (AAI)
11155.0 RIT: Rus Navy HQ Severomorsk, RUS 0857 CW "RKN64 DE RIT RIT QSA 2 QRV K" (23Oct16) (AAI)
11429.0 ---: Russian Intel, RUS 1045 (cf) MFSK-68 (34+34) + QPSK 2400Bd 10KHz wide-band inserts (25Oct16) (AAI)
11470.0 ---: Unid (prob. Russian Navy) 1315 FSK 50Bd/500, no traffic (25Oct16) (AAI)
13215.0 201067: USAF unid asset 1113 USB MIL 188-141 2G-ALE sounding (27Oct16) (AAI)
13220.0 ---: no call 1323 USB MIL 188-141 2G-ALE calling CHARLY46 Italian AF (46th Air Brigade) (27Oct16) (AAI)
13499.0 11021: Moroccan Civil Defence, MRC 1122 USB MIL 188-141 2G-ALE sounding (27Oct16) (AAI)
13499.0 2215: Moroccan Civil Defence, MRC 1108 USB MIL 188-141 2G-ALE sounding (27Oct16) (AAI)
13499.0 2415: Moroccan Civil Defence, MRC 1109 USB MIL 188-141 2G-ALE sounding (27Oct16) (AAI)
13505.0 ---: Unid 1120 USB STANAG-4538 LSU + LDL, Harris Citadel encryption (27Oct16) (AAI)
13538.0 ---: Russian Mil, RUS 1213 USB CIS-45 OFDM HDR modem v2 BPSK 40Bd 62.5Hz (23Oct16) (AAI)
13554.0 CENTR3: MAECT Bucarest Centrala3, ROU 1047 USB MIL 188-141 2G-ALE handshake BLJ Telaviv Embassy, flwd by 188-110A transporting STANAG-5066 messages (27Oct16) (AAI)
14493.0 RGG: Russian Mil, RUS 1134 CW "RGP RGP RGP DE RGG RGG QSY 14653 QSY 14653" (21Oct16) (AAI)
14581.5 ---: Russian Navy, RUS 1330 FSK 50Bd/40, 7-bit code 4/3 (four 1 + three 0) (23Oct16) (AAI)
14968.0 XSS: DHFCS Forest Moor, G 1337 USB MIL 188-141 2G-ALE calling XDV (22Oct16) (AAI)
16000.0 6207: Unid 1213 USB MIL 188-141 2G-ALE calling 6202 (26Oct16) (AAI)
16103.0 Russian Mil, RUS 1244 USB CIS-112 OFDM modem 22.22Bd BPSK (24Oct16) (AAI)

Turkish Mil, FSK 300Bd/400Hz KG-84C

Weak signal heard on 5115.5 KHz, central frequency, at 0549 UTC. Analysis with SA reveals an FSK signal running at 300Bd and 400 Hz shift.

fig. 1

fig. 2

Once demodulated, the presence of the KG-84C 64-bit sync pattern (fig. 3)  leads to think about a NATO partner Nation: looking at precedent posts,  most likely the signal belongs to the Turkish  FSK waveforms.

 

fig. 3

https://yadi.sk/d/QXv7FXiYxdbjH

Unid BPSK 1500Bd (prob. Chinese modem)

Unid modem (prob. Chinese origin) using BPSK modulation at 1500 Baud and 1500 Hz sub-carrier. Since the alternation of frames with different strength, this may be a duplex channel.

fig. 1

fig. 2

fig. 3

Once demodulated, the analysis of the bitstream reaveals an interesting 3 bit structure (fig. 4): my friend Karapuz suggested to try a differential (relative) decoding of the signal.

fig. 4

Differential decoding can be obtained directly by running the proper tool of  the bit-editor or by demodulating the signal using the SA demodulator with option "Diff 1" as in fig. 5

fig. 5

Results are similar and in the output bistream, visually more logical, is visible the sync bit and the two data bits (fig. 6).

fig. 6

cars, chameleons, networks, and other stories (part II)

In the first part of this post there were the cars, here are the chameleons: such name is not related to the ALE Addresses but rather to the configuration of the stations. A third part will follow in case of news or updates.
The two following networks, although they exhibit different behaviors, share some aspects which lead to think to the same source/organization or at least to the same Country. As said in the first part, the purpose is only hobbystic; sensitive and confidential messages contents, if any, are anyway not published. I'm interested on the way the "boxes" travel and NOT on their content.

AB net (5838.0 KHz, ...)

Stations and ALE addresses of this network are: ABD1, ABG6, ABF2, ABS5, ABK4, ABH3, and ABC7 that acts as net-control. Transmissions are scheduled on tuesday and thursday from about 0730 UTC and usually follow the schema link-send-terminate. Links are initiates by ABC7 and always in the same order, ie: ABD1 first then, ABG6, ABF2, ABS5, ABK4, and ABH3 as last. Other than 188-141A for ALE, STANAG-5066 is used for messaging and STANAG-4285 as HF waveform (fig. 1), settings are 1200bps and short interleaver. I monitored this net on 5838.0 KHz/USB, that seems to be the main channel, but other frequencies are also used.

fig. 1

In the firts loop, stations are contacted by ABC7 for a radio-check, then  in case the net-control has messages to send, the stations are again contacted and always in the same order. Sometimes the sending phase follows the radio-chek so that the stations are worked one time only, the sending is always preceeded by a voice-exchange of a pair of authentication keys according to the sequence diagram of fig. 2. A common phrasebook for telecommunications, in english, is strictly used.

fig. 2 - sequence diagram

The authentication keys consist of 4 numeric digits for the "my-auth-id" key and 2 numeric digits for the "auth-id" key , eg:

ABC7: alpha bravo x y this is alpha bravo charlie seven, authenticate 79
ABXY: alpha bravo charlie seven, this is alpha bravo x y, my authenticate 6843, authenticate 74
ABC7: this is alpha bravo charlie seven, my authenticate 2895
ABXY: ok send your message

A fter finishing sending the message, the net-control station asks the receiver peer to confirm the message-number then link is terminated and the next station in turn is contacted.

fig. 3 - 188-141A 3-way handshake and Auth keys exchange

The messaging system use the HBFTP protocol to deliver compressed e-mail files, COMSEC devices are not present (unclassified messages?) so, once removed STANAG-4285 and STANAG-5066 overheads, important clues and information can be drawn from an examination of the e-mail headers (fig. 4).

fig- 4

The sender and receiver stations belong to the e-mail domain 123 (point 1) and it's the common domain of all the stations of this network. The message has been received from, and by, the same host whose name is linux.site; "CROZ ESMTP/HMTP Gateway" most likely is the name of the STANAG-5066 application (point 2).  The IP address in the field "Received from" is 127.0.0.1 or localhost (not wired to a LAN ?).
The hostname and the e-mail client fingerprint (point 4) clearly reveal that they use a Linux system, specifically: SUSE Linux 3.1.14. Indeed, the mention of chameleons I adopted  just derives from the official logo of SUSE.

The use of Linux is per se an interesting and peculiar element of this network, but it's not the only one.  The email includes one attached jpeg/image file whose name is "PRILOG 5 - PRILOG ZA SLANJE E-MAILA.jpg". This language suggest a Slavic origin (google-translator), as confirmed by the system timezone at point "3" (+0200), time-zone and especially the language restrict the candidate Countries to two: HIB and HRV. Anyway, the most surprising fact is that the e-mails I decoded have that same attached filename although it refers two images, in other words  they always use the same name for the attachments (fig. 5).

fig. 5 - two e-mails, different ricipients but same attached filename

On my side I can't rebuild the original images from the received S-5066 fragments but I can see at least the upper part of such images: they are always the same (fig. 6), although the image "B" is the most used in the attachments.

fig. 6

The reasons behind such way to comunicate are obscure: test? steganography?.., difficult to state unless speculations. 

In the above fig. 2 we have seen that the net-control stations asks a confirm of the received message-number: this a progressive number and matches the subject of the corresponding e-mail. The message-number is initialized to a new initial value at each day and assigned to the subject of the e-mail sent to the first station in the calling list (ie: ABD1, user1@asdf.123) and then is incremented by one at each step (fig. 7).

fig. 7

The choice of the initial value is apparently odd: fig. 8 is an example
06 Oct: initial value 600
11 Oct: initial value 603 
13 Oct: initial value 508
18 Oct: initial value 610  

fig. 8

5054 net (5054 KHz)

I spotted a QRG, 5054.0 KHz/USB, where stations of this network do not use 188-141A before messages sending and traffic is less frequent, not to say sporadic.  STANAG-5066 HMTP protocol is used instead of HBFTP (fig. 9) and, as for the AB-net, STANAG-4285 is the transporting HF waveform. The lack of the ALE phase is quite odd since the heard transmissions are not bcasts but rather PtP messages: or links are negotiated in other channels/way or receivers are always in listening state. For sure, no 188-141A means no ALE Addresses to collect from this network.

By a quick examination of the e-mails headers (fig. 9) it's easy to see that this network belongs to the same organization/authority of the previous AB-net: same OS (Linux SUSE), same STANAG-5066 application (CROZ ESMTP/HMTP Gateway) and - above all - same attachment filename (PRILOG 5 - PRILOG ZA SLANJE E-MAILA.jpg) can't be a coincidence.

fig.9

Addresses and origin/owner of the networks
I never heard e-mail exchanges between the two nets but only e-mails sent from linux-a5kz to the other stations of AB-net and e-mails sent from linux-2o6y.site to other stations of 5054-net: this leds to think that these are the main stations of their respective networks. It's interesting to pay a look at the e-mail addresses of the two newtorks:

ALE  e-mail address
[AB-net]
ABC7 user1@asdf.123
ABD1 user1@sdfg.123
ABG6 user1@dfgh.123
ABF2 user1@fghj.123
ABS5 user1@ghjk.123
ABK4 user1@jklp.123
ABH3      ?
[5054-net]
  -  user1@aysxd.111
  -  user1@lost62.111
  -  user1@dres32.111
  -  user1@fejk8.111

As expected, the networks belong to two different e-mail domains "123" and "111": behind such choice there is surely a certain logic but unfortunately do not offer any clue for identification.
AB-net seems to use non-sense (?) alphabetical addresses (asdf, sdfg,...) while 5054-net seems to use a sort of "structured" names (lost62, dres,32, fejk8,...).  It's worth noting that the AB-net addresses, if listed in the order of the calling list,  exhibit a left-shift of 3 letters. According to this schema, ABH3 could have the address user1@klpq.123 (m,n,o seem to be not used).

 

A big help in the identification of the source is given by the examination of the collected STANAG-5066 nodes addresses:

ALE  Stanag-5066 address e-mail address
[AB-net]

ABC7 006.008.001.039     user1@asdf.123 (ncs)
ABD1 006.008.004.166     user1@sdfg.123
ABG6 006.008.004.165     user1@dfgh.123
ABF2 006.008.006.226     user1@fghj.123
ABS5 006.008.008.215     user1@ghjk.123
ABK4 006.008.002.144     user1@jklp.123
ABH3 006.008.002.055          ?
[5054-net]
  -  006.008.004.165     user1@aysxd.111 (ncs)
  -  006.008.003.033     user1@lost62.111
  -  006.008.003.036     user1@dres32.111
  -  006.008.003.037     user1@fejk8.111


About the assignments of the STANAG-5066 addresses, the global-regional blocks are defined by the 4 most-significant bits of the full length address (i.e., the first element w of the dotted-decimal form w.x.y.z): from fig. 10, 6.x.y.z is assigned to Europe. 

fig. 10

Within the global-regional blocks, specific 5066 addresses are assigned to individual Nations using the second element “x” of the dotted-decimal address form w.x.y.z.
Now, what european nation matches 6.8.y.z ?
The answer is in Table N-6 "National Address Schema" STANAG-5066 Edition 3 Annex N: 5066 is a NATO unclassified document that may circulated freely and is available on:
http://nso.nato-int/nso/zPublic/stanags/CURRENT/5066Ed03.pdf
Sadly, no part of S-5066 Edition 3 can be published but the mentioned Table N-6 matches the "proposed allocations" which are visible at page 14 (here reported in fig. 11) of  a very interesting pdf file freely downloadable from: http://www.hfindustry.com (note that NC3A, NATO C3 Agency, is now NCIA or NATO Communications and Information Agency).

fig. 11

It's worth noting that the stations dfgh.123 and aysxd.111 exhibit the same S-5066 address 006.008.004.165, i.e. the same node: as far as I know a certain S-5066 address should not be shared by two or more nodes (duplicate address) hence we face the same physical node. Looking at the "Received" headers of one e-mail sent by aysxd.111 (fig. 12) we see that the e-mail is originated (from) and received (by) the same host linux-2o6y.site: this means that the e-mail client and the S-5066 gateway application are running inside that same host. Moreover, the IP address 127.0.0.1 (which refers the sender) is the address of the localhost: this means that the host  linux-2o6y.site, i.e. the 006.008.004.165 S-5066 node, is not wired to a LAN.

fig. 12

Keeping in mind that a node is generally assumed to include the HF modem and radio (and cryptographic) equipment required for communications, a possible explanation could be the configuration in fig. 13, that also clarifies the lack of "cross-messaging" between AB-net and 5054-net: such traffic is handled "inside" the hosts. Unless they assigned the same S-5066 address to two distinct S-5066 nodes or use some other configuration that I do not know.
 

fig. 13

Rockwell-Collins HF Messenger allows a such configuration (fig. 14) in which two clients, belonging to different domains (i.e. two e-mail accounts), share the same S-5066 resource. Anyway, this is not our case since HFM only run on Windows-based pc and we face a Linux based nodes (SUSE Linux 3.1.14).

fig. 14

 

STANAG-5066 gateway application
The S-5066 application running in the Linux gateway nodes add the string "CROZ ESMTP/HMTP gateway" in the received-by header: it's a proprietary application that acts either as Extended SMTP server (on the LAN side) or as HMTP gateway (on the HF network side). Indeed they do not use a Stanag-5066 application from the most "popular" manufacturers, but rather a proprietary product developed by CROZ, an IT Company located in Zagreb and Belgrade, named CroS5066 (fig. 15). The mean features of the product can be read in their pubblication "CRO FYI" of  September 2009. CroS5066 is fully interoperable with other S-5066 systems, positive tests were made during NATO exercises Combined Endeavor 2008 (Lager Aulenbachhere, Germany and Lora Naval Base in Split, Croatia).

 

Fig. 15