email over HF using STANAG-5066 DTS: a more interesting example

This recording is another example of sending compressed e-mail file using STANAG-5066 DTS and the MS188-110A serial waveform as "carrier" at physical layer: while the previous recording was relative to Polish Military, the present one concerns a BFTP transfer over HF link between two peers of Romanian MAECT - Minister of Foreign Affairs (...which surely use Harris hardware/software equipments). The transfer was heard on 10315.0 KHz/USB on 18 Apr, starting from 0756 UTC.

STANAG 5066 (Profile for HF Radio Data Communication) is a NATO protocol stack definition operated over HF modem/radio equipment. S5066 provides standard clients over SIS (Subnetwork Interface Sublayer) and an IP mapping/adaptation in order to make use of conventional IP applications over HF radio band in a transparent way. There exist three editions of S5066 specification. Edition 1, and Edition 2 radios do not attempt to transmit when it is known that another radio is transmitting. It means that the data exchange is node to node and no more than two peers may communicate at the same time. With the release of S5066 Edition 3, this problem was resolved by using CSMA and HFTRP methods. The DTS (Data Transfer Sublayer) are same for Edition 1 and 2, the  CSMA and HFTRP new features was added to DTS layer of Edition 3 maintaing backward compatibility with the 1,2 editions. 

I used k500 decoder to demodulate the heard transmissions and then passed to the analysis of the obtained bitstream, once removed the 188-110 overhead.

188-110 over-the-air symbols

 Since S5066 is a "protocol stack", it has up to eight different Packet Data Units (PDUs) available and then analyzing a S-5066 transfer we could face different packet lenghts as in a wireshark capture example in pic. 1
 

Pic. 1 - some S5066_DTS PDU types

Although the DATA_ONLY PDU (222 byte, or 1776 bit period) is the more often met, this sample is interesting since exhibits pronounced 29 byte (or 232 bit) period mostly due to the EXP_NON_ARQ_DATA PDUs in the last two 2400bps/L 188-110 messages (pic. 2).  The DATA_ONLY (1776 bit) is clearly visible analyzing the PDU in the first 1200bps/short 188-110 message (pic. 3).
 

Pic. 2 - 29 byte = 232 bit period mostly due to  PDU type 8: EXP_NON_ARQ_DATA

Pic. 3 - 222 byte = DTS PDU type 0: DATA_ONLY

 It's interesting to note in pic. 4 that all the four S5066 PDUs have the same pattern:

Pic. 4

I just focused on the first 1200bps/S 188-110 message since it's the one that just contains a valid DATA_ONLY PDU.
The presence of the file HBFTP--1.gz  into the bitstream after S5066 PDU-0 removal (pic. 5), reveals that the data transfer is performed using a compressed file and Basic File Transfer Protocol (BFTP): in this case the used protocol is HBFTP that stands for Harris BFTP.

Pic. 5 - the compressed file HBFTP--1

The Basic File Transfer Protocol (BFTP) is a very simple protocol (based on the ZMODEM protocol) and is not designed to be especially robust. It's used in conjunction with CFTP (and obviously S5066) to forward e-mails over HF links. Messages produced by an e-mail application are  compressed in CFTP, segmented in the S5066 Basic File Transfer Protocol (BFTP), and passed to the S5066 DTS. At the receiving node, this process is reversed, and the uncompressed e-mail message is delivered to the receiving e-mail application for delivery or forwarding (pic. 6)

Pic. 6 - S5066 as a "connecting link" between wired and HF networks

It's worth noting that S5066 may use two top protocols named RCOP (Reliable Connection Oriented Protocol) and UDOP (Unreliable Datagram-Oriented Protocol) which are the HF equivalents of the well-known TCP and UDP protocols used in wired (inter)networks. In a few words, S5066 is a sort of "Middle-Earth" between wired and HF network... but that's another story.

Back to the received BFTP file, once decompressed we get the original e-mail message (pic 7,8): it's a simple and nice test message that in my opinion can be safely shown because it's a not a "suepr secret" message  but just a simple e-mail "chat" between operators (I only obscured part of the involved addresses): they know what are doing when send clear text.

Pic. 7

 

For nosey people, it's also possible to understand that "HARRIS2" uses HP computer (look at "...Received: from hp3254104...").