7 November 2018

IP over HF via STANAG-5066 RCOP, MIL 188-110A as HF waveform

Interesting transmissions spotted on 9105.0 KHz/usb at 1240z, user/locations are unid, maybe form US-Mil stations? The transfer concerns IP-over-HF (IPoHF) via STANAG-5066 RCOP protocol [1]: 1380 bytes IP packets are exchanged in directions 192.168.2.48 -> 192.168.12.48 and 192.168.1.48 -> 192.168.14.48 , ESP (IPSec) secure protocol is used.  MIL-STD 188-110A Serial is used as the HF waveform. STANAG-5066 Addresses (001.003.003.103 001.001.001.101) belong to US-DoD. Similar transmissions was heard on 8th October on 13378.0 KHz/usb using 188-110A and S4539 QAM-64 as HF bearers (discussed here) maybe the user is the same.
The sequence of the figures illustrates the various steps that have been performed in the analysis of the signal.

Fig. 1 - 188-110A on-air symbols
Fig. 2 - STANAG-5066 bitstream after the removal of 188-110A overhead
Fig. 3 - hex-dump after the removal of STANAG-5066

The hex-dump file resulting after the removal of STANAG-5066 PDUs encapsulations has been processed using "wireshark" software: IPv4 addresses and headers as well as IPSec encapsulation are clearly visible.

Fig. 4 -


https://yadi.sk/d/wuBIWQ_HSwVRMA
https://yadi.sk/i/6p-izzJatalVwg
https://yadi.sk/i/ulK473q0E2rCNw

[1] https://www.isode.com/whitepapers/ip-over-stanag-5066.html

https://yadi.sk/i/6p-izzJatalVwg

3 November 2018

two interesting FSK catches: 74.5Bd /250 and 75Bd/200

1) FSK 74.5Bd/250
Some FSK 74.5Bd/250 short transmissions (Fig. 1) have been heard on 11018.0 KHz (CF) sending the same seven bits pattern in postive and in negative polarity (Fig. 2). Since the short transmission time I coould not DF the transmission site.

Fig. 1
Fig. 2
 FSK 74.5Bd/250

2) FSK 75Bd/200
The FSK 75Bd/200 (Fig. 3) is a continuous transmission that can be heard on 8408.0 KHz (CF), most likely an encrypted broadcast (shore-to-ship ?). Several TDoA runs point to the West Mediterranean sea area: the Tx location could be Algeria or Balearic Islands (Fig. 4).

Fig. 3
Fig. 4

The demodulated bitstream does not exhibit ACF spikes (ACF = 0) after normal and differential decoding and can be descrambled using the polynomial x^8+x^6+x+1 but without appreciable results.
A similar transmission (FSK 75Bd/200) was heard on 11 Jan 2018 on 4540.0 KHz. In that case, after differential decoding, the stream showed up a clear 365-bit period (Fig. 5) which is due to the sequence of the scrambler polynomial x^7+x^6+1. The descrambled stream is shown in Figure 6 (thanks to cryptomaster).

Fig. 5
Fig. 6

1 November 2018

(some) October logs


06205.0: ELETTRA11: Italian Ny, I 0822 USB/J3E radio-check with IBIS11 (11Oct18) (AAI)
06690.0: BD9: Unid (Moroccan-Pol ?) 0632 USB 188-141 2G-ALE calling T4N (24Oct18) (AAI)
06733.0: 6628: Ascott-6628 RAF USB 1007 J3E/USB requesting wx reports to TASCOMM for LFLL, LFMN, LICJ, LMML (20Oct18) (AAI)
06922.0: ---: Unid 0824 USB 3G-HF 2-way FLSU handshake / LDL96 transfer,83 bytes 'Citadel' encrypted file (11Oct18) (AAI)
06931.0: ---: Unid (prob from Croatia) 0828 USB STANAG-4285 600bps/S, 2 stations exchanging 128-bit MI encrypted msgs (11Oct18) (AAI)
07559.0: ---: Unid 0715 USB 3G-HF FLSU handshake / HDL24 transfer (24Oct18) (AAI)
07606.0: ---: Unid 0910 USB NILE/Link-22, STANAG-4539 TDMA Waveform #2 (09Oct18) (AAI)
07625.0: ---: Unid 2150 ISB Link-11 CLEW (30Oct18) (AAI)
07856.0: SE3: Polish-Mil, POL 1034 USB MIL 188-141 2G-ALE calling EM4 (31Oct18) (AAI)
07961.0: 32X: Unid 0748 USB 188-141 2G-ALE calling DRX (22Oct18) (AAI)
07961.0: 32X: Unid 0749 USB 188-141 2G-ALE calling DRY (22Oct18) (AAI)
07961.0: FAY: Unid 0638 USB 188-141 2G-ALE calling DRX (24Oct18) (AAI)
08086.0: NX10: Algerian-Mil, ALG 0900 USB 188-141 2G-ALE handshake KB23 / MIL 188-110A Serial (20Oct18) (AAI)
08132.0: BP25: Bundes Polizei patrol vessel "Bayreuth", D 0835 USB 188-141 2G-ALE handshake BPLEZSEE HQ / GM2X00 HF modem serial waveform, updating GPS position (23Oct18) (AAI)
08162.0: 093: Hungarian Defense Forces, HNG 0755 USB 188-141 2G-ALE calling 035 (22Oct18) (AAI)
08190.0: --- : Unid 0645 USB 3G-HF HDL+ transfer (18Oct18) (AAI)
08190.0: CAPPELLETTI: GdF Patrol Boat Cappeletti G094, I 1005 USB 188-141A 2G-ALE handshake ROMA, sending email using R&S PostMan II and X.25 over GM2100 modem (11Oct18) (AAI)
08218.0: ---: Unid 1720 USB 3G-HF 2-way FLSU handshake / HDL+ transfer (03Oct18) (AAI)
08677.0: ---: Unid, prob. KNL Networks CNHF (Cognitive Networked HF) 0725 USB PSK-2 48000Bd waveform, 576-bit period (16Oct18) (AAI)
08684.5: ---: Unid, prob. KNL Networks CNHF (Cognitive Networked HF) 0742 USB BPSK/QPSK 2400Bd waveform (11Oct18) (AAI)
08722.0: AB1: Maltese Navy, MLT 1745 USB 188-141A 2G-ALE calling EB7 (03Oct18) (AAI)
09120.o: PP7: Polish-Mil, POL 1152 USB 188-141 2G-ALE calling ML2 (23Oct18) (AAI)
09162.0: ---: Unid 1204 USB 3G-HF FLSU handshake / LDL448 transfer, 859 bytes 'Citadel' encrypted file (23Oct18) (AAI)
10185.0: MIRADOR2: Unid 1417 USB 188-141A 2G-ALE sounding (06Oct18) (AAI)
11118.0: ---: Unid 0607 USB (offset + 1500Hz) Siemens CHX200 F1-modem (CHP-200) FSK 249Bd & 250Bd/170Hz, selcall mode (10Oct18) (AAI)
12194.0: CM6: Commandement de la 6e Région Militaire Tamanrasset, ALG 0638 USB 188-141 2G-ALE calling TIN (18Oct18) (AAI)
12457.0: ---: Unid, prob. KNL Networks CNHF (Cognitive Networked HF) 1340 USB 6KHz WideBand PSK-2 4800bps waveform (14Oct18) (AAI)
12780.0: ---: Unid, prob. KNL Networks CNHF (Cognitive Networked HF) 0810 USB 18KHz WideBand PSK-2 19200bps waveform (14Oct18) (AAI)
13378.0: ---: Unid 0848 USB MIL 110A & STANAG-4539, STANAG-5066 IP-over-HF sessions (01Oct18) (AAI)
17398.2: ---: DHFCS Cyprus Is. Overseas Stn 1120 USB STANAG-4285/1200bps 1536-bit TDM protocol (prob. DRS GA-205 multiplexer) (28Oct18) (AAI)

27 October 2018

STANAG-5066 Annex G, the ancestor to US MIL STD 188-110B and STANAG-4539

The other day I was still trying to figure out something from the S4539 8-ary burst transmissions, posted here, using Harris RF-5710A HF modem. Turning between the various operating modes provided I came across what at first glance seemed a strange waveform: i.e. 5066-G. As far as I know, STANAG-5066 is a protocol standard that does not define waveforms, so I went into detail to see what the hell it is.
STANAG-5066 Annex G presents guidelines and requirements for the use of the STANAG 5066 protocol profile with modems and waveforms at rates above 2400bps. Early draft versions of STANAG 5066 Annex G included a detailed specification for high-speed single-tone waveform and convolutional forward-error-correction coding with data rates up to 9600 bps, and this formed the basis for more than one vendor implementation of a commercial product.
Quoting Edition 3 #G.3.0 Implementation Guidance for STANAG 5066 Operation at Higher Rates : "It is clear that higher throughput will be available for the HF long-haul channel in near future (i.e, post 2000). What is not clear is the final form of the waveform standard or standards that will provide these data rates". Notice that the Edition 3 was promulgated on 30 march 2015 and the Annex G is still "information only", ie it is still not mandatory for the purposes of the communication minimum requirements.


Now look at the words "...in near future (i.e, post 2000)": clearly, Annex G has remained unchanged from the first editions of STANAG-5066 (dated before year 2000). Most likely the NATO groups responsible for the standardization preferred a separate STANAG to define the new waveforms since 5066 is a protocol standard, so Annex G is "frozen" and stands like a kind of ancestor to MIL 188-110B and STANAG-4539 (3200 to 12800 bps): these new waveforms used constellations and much of the waveform structure developed for Annex G and added further enhancements. 
Harris developed its implementation of 5066-G, you may find it among the operational modes of their RF-5710A HF modem:


The STANAG-5066 Annex G waveforms provide the highest possible data rates over conventional 3KHz HF channels. A single 1800 Hz sub-carrier is modulated at a constant rate of 2400 symbols per second. the type of modulation varies from QAM-64 to PSK-4 according to the data rate selected. Known data symbols are periodically inserted in the transmitted signal to allow fro adaptive channel equalization at the receiver. Convolutional coding FEC and Viterbi decoding are combine with interleaving to enhance the performance of the receive modem on fading HF channels. Data rates from 3200 bps to 9600 bps are supported together with long, double long, short, and zero interleaving options. An additional 12800 bps uncoded waveform is supported for line-of-sight applications. Automatic detection of the data rate and interleaver setting are provided in the receive mode.

By the way, I tried to demodulate the S4539 8-ary bursts using the 5066-G mode , despite obsolete. Surprisingly, the modem is responsive and distinguishes four different waveforms: 4800L (PSK-8), 8000L bps (QAM-32), 9600L and 12800 bps uncoded (QAM-64), the last two are detected less frequently (Fig. 1). It should be noted that when the same transmission is demodulated using 4539 or 110B you always get the same waveform 12800U.

Fig. 1


Annex G: Use of Waveforms at Data Rates Above 2400 bps (V1.2) 

22 October 2018

BPol vessels tracking using RSX.25 and GM2X00 waveforms (R&S PostMan II)

Quoting R&S PostMan II brochure "[...] another feature is the capability to track mobile stations by using the global positioning system (GPS). If a station is equipped with a GPS receiver, position data can be transmitted in addition to the actual data after analysis of the National Marine Electronics Association (NMEA) 0183 protocol [1]. The current position of and the route covered by each mobile station can thus be tracked from a command center".  The standard package includes an interface with scanned maps as below: in the left side a screenshot from PostMan and in the right side the correspondent map available from the web [2].

Fig. 1
After analyzing some recordings, I think this system is the one used by BPol (Bundespolizei See) for tracking their patrol vessels: positions are transmitted on HF to the ashore command center using RSX.25 protocol over GM-2X00 waveforms as discussed here.
After removing the GM-2X00 waveform and decoding the RSX.25 bitstream, it is possible to see the UUCP commands that are responsible for transferring a Bzipped file from BPOLBP23 (patrol vessel "Bad Düben", now out of service) to BPOLBPLEZSEE_HF (Operations Center HQ Cuxhaven).

Fig. 2 - RSX.25 bitstream

login: UBPOLBPLEZSEE_HF <MPL>2016-11-28 15:49:52+01,BPOLBP23;2016-11- BPOLBPLEZSEE_HF 15:49:52+01,BPOLBP23; 2016-11-28 15:47:45+01,BPOLBP26</MPL> Connected
Shere=BPOLBP23_HF SBPOLBPLEZSEE_HF -pz -vgrade=z -R -N07 ROKN07 Pyie
Uy  ¸ HN = #E D.05PK D.BPOLBP2C05PK uucp -C D.05PK 0666 "" 0x66
rsgpsadd
ƒ!Z)vL@¬“4m˜ßÐ{ f ã BZh91 ...

The UUCP session has been described in detail in this post, here it's more interesting to dwell on the piped commands uucp file | rsgpsadd

D.05PK D.BPOLBP2C05PK uucp -C D.05PK 0666 "" 0x66 
D.05PK = file to send
D.BPOLBP2C05PK = file name on slave (should be D.BPOLBP2505PK)
uucp = application requesting the file transfer
-C = file has been copied to the spool directory
0666 = mode of file on master for outgoing files
0x66 = 102 Bytes file size

 
rsgpsadd 
rsgpsadd = command to be executed after the transfer, most likely stands for "R&S GPS Add". This program  will process the sent file D.05PK, probably unpacking it and store the lines into a database for the further graphic elaboration (map display).

BZh9
here starts the D.05PK file which is sent in Bzip compressed way:
BZ = Signature (0x425A magic number)
h = Bzip2 (h is for Huffman coding)
9 =  increments of 100 kB block-size uncompressed


The compressed file, once unpacked, consists of two lines, each consisting of four values separated by commas "timestamp, vessel, latitude, longitude" as in the transmission heard on August 10 at 0806 in which the vessel Bayreuth (BPOLBP25), comunicates its position at times 0737 and 0757 (CEST):

2017-08-10 07:37:48 +02, BPOLBP25, 54.023927, 10.800935
2017-08-10 07:57:47 +02, BPOLBP25, 54.023125, 10.800987 


Some comments about these files.
GPS Devices can create a file saving the route they are taken and these files are usually stored in a format called NMEA 0183. Now, as can be seen from the mentioned brochure ("... after analysis of the National Marine Electronics Association (NMEA) 0183 protocol") I believe the 0183 format files cannot be read directly by PostMan so they must be converted into a new file format. Well, the format of the files piped to rsgpsadd command looks like the Waypoint file format. In the waypoint format each line contains a triplet of values separated by commas, these values are a text string (optional), a latitude value and a longitude value.  In the rsgpsadd files it seems that each waypoint line, consisting of the triplet "vessel, latitude, longitude", is preceded by a timestamp string that could be a header value added during the 0183-waypoint conversion. By the way, notice that R&S already developed the "GPS Route Converter" program (NMEA 0183 to waypoint files) to be used by the R&S SMU200A Vector Signal Generator [3]: maybe parts and knowledges from that software is used/embedded in this PostMan application, who knows?

Fig. 3

I tried to use some rsgpsadd commands, recordered on 26 August (2017), to trace the patrol vessel BPOL21 by using a .kml file and google Earth application [4]: these rsgpsadd commands update the position with a resolution of 10 minutes

2017-08-26 09:02:08 +02, BPOLBP21, 54.4225, 12.271833
2017-08-26 09:12:09 +02, BPOLBP21, 54.414833, 12.252
2017-08-26 09:22:09 +02, BPOLBP21, 54.4075, 12.2325
2017-08-26 09:32:09 +02, BPOLBP21, 54.4, 12.212833
2017-08-26 09:42:09 +02, BPOLBP21, 54.3925, 12.193167
2017-08-26 09:52:09 +02, BPOLBP21, 54.385, 12.173


below the map I obtained, the vessel was moving from right to left

Fig.4

[1]  https://www.nmea.org/.../nmea_0183_v_410.asp 
[2]  http://fishing-app.gpsnauticalcharts.com
[3]  https://cdn.rohde-schwarz.com/...GPS_route_converter.pdf
[4]  http://www.gpsvisualizer.com/map_input?form=googleearth
 

19 October 2018

use of the radio address format "RSPeer" for direct delivering of messages (R&S PostMan II)

This post can be considered as a continuation of the previous one in which the use of Rohde & Schwarz PostMan was shown: in that post, rsmail sending "classic" email over HF, was analyzed. In order to find other interesting RSX.25 sessions I started to look for my files and old recordings and finally I recovered an interesting transmission of the Italian Coast Guard (Guardia Costiera, say It-GC) on 12270.5 KHz/usb dated January 2016 consisting of the combined RSX.25 and GM-2X00 HF waveform.
 
Fig. 1
I probably went late on that transmission and so I probably lost the initial RSX.25 exchanges but after the demodulation of the signal - although weak - an interesting session came up that uses the Rohde & Schwarz address format "RSPeer" to send a file between two radios. The received signal does not have a good SNR but its interpretation is nevertheless possible, below the file I got after the removal of the GM2X00 HF waveform and RSX.25 demodulation:


...
c„%Ì, TNF8c19f176-c647-11e5-ab22-000c2940a7d1.tmp v˜ xŸ>"©  ' E €  1 1
CP940 RSPEER:CP940,Administrator   N €  à  1 O   € !  +*V    ,ØCµá ªG )@§Ñd€
+ ¤¾£ n Ý T  ROMA RSPEER ROMA,ROMA   0  'ROMA'  0  0   *)  ì  #  &)
...

file being sent (most likely, see below)
TNF8c19f176-c647-11e5-ab22-000c2940a7d1.tmp

RSPeer address format addresses
CP940, Administrator = patrol vassel "DATTILO" CP-940, callsign IGUB [1]
ROMA, ROMA = Guardia Costiera HQ Roma, callsign ICI [2]

Quoting the paper ADP010679 [3] "The R&S address format RSPeer ensures the direct delivery of the message to the computer of the addressee, i.e. the message is physically available on the hard disk of the recipient, the usual detour to the SMTP server being avoided. This delivery procedure excludes any misuse of and unauthorized access to the mail traffic of a network and ensures that one's own information is secure. This type of addressing also minimizes the data exchange on the frequencies available and so eases the traffic load of the radio network."

Further and more interesting details emerge if the HDLC protocol decoding is used at data-link layer, i.e. just before the RSX.25 demodulation(!): in particular, the strings related to MicroSoft Exchange  are highlighted

(OHDLC-layer.bin)
...
940a7d1.tmp v˜   xŸ>"©      •þÿÿÿþÿû(F°€œøÞÿÿÿ6(F°àš›Þÿÿÿ
ÿ(F¿ 2   Ì, TNF8c19f176-c647-11e5-ab22-000c2940a7d1.tmp v˜  

xŸ>"©    tÑ(F°   ä    è € IPM.Microsoft Mail.Note 1 € €    
PIM 291000A GEN 16 ô €    à 6 (F± ' E €  1 1 CP940 RSPEER:CP940,Administrator
O € ! h›(F² 74F1198C47C6E511AB22000C2940A7D1 ý  þ    ÿ Z µ;ÂÀ,w ¡¼ 
 Úµ(F³ +*V    ,ØCµá ªG )@§Ñd€  Ñd€ + ¤¾£ n%Ý T ROMA RSPEER:ROMA,ROMA 'ROMA'
...

I believe the CP940 user is sending an outlook message in rich text format (RTF) encapsulated into Microsoft "Transport Neutral Encapsulation Format"(TNEF) [4] instead of sending an SMTP (HTML or Plain Text mode) email. The original filename is probably 940a7d1.tmp while the filename TNF8c19f176-c647-11e5-ab22-000c2940a7d1.tmp and the 32-char lenghth string 74F1198C47C6E511AB22000C2940A7D1 are something related to MS-Exchange TNEF encapsulation (I believe the TNF converted file and the key/identifier of the message).
For what concerns PIM 291000A GEN 16, it is probably the time when the message was prepared, expressed in the format: DayHourMinuteAnte(Post)Meridiem Month Year (something like PIM = Product Information Management ???), i.e. 29 January 2016 10.00 AM; indeed it matches the time I recorded the transmission, i.e. 29 Jan 2016 at 10.25 or sent 25 mins after its preparation (Fig. 2).


Fig. 2
That said, PostMan performs an "address gateway" to email networks (SMTP, X.400, MS-Mail) with different address formats (Fig. 3).

Fig.3

So far, I never heard 188-141 ALE messages form It-GC ships and ashore stations but I have a guess about it. Several times I copied on 12270.5 and 8196.5 KHz (frequencies operated by It-GC) R&S-ARQ 228.6Bd/170 "ALIS" selcalls such as:

Called address: 40
Pool size: 8
ALIS 2000: No
Ack: true
Followon type: External modem
ECC: PRP
Spectral diversity: Adaptive
Data rate: Fast
Data encryption: No (clear)
Rephase: false
Sending counter: 1


Assuming that 40 is the ALIS address of CP940, it could be that they use the ALIS selcall instead of the 188-141 mode, but it is only a speculation of mine without any confirmation.


https://yadi.sk/d/Zbdfvc_punPUWw
https://yadi.sk/d/liJWgfG8jZGqXQ (OHDLC-layer.bin)

[1]  http://www.guardiacostiera.gov.it/.../scheda-dati-nave-dattilo-cp-940
[2]  http://www.mediasuk.org/archive/ici.html
[3]  http://www.dtic.mil/dtic/tr/fulltext/u2/p010679.pdf
[4]  http://www.fiction.net/blong/programs/tnef2txt/apptnef.txt 

15 October 2018

email over HF using RSX.25 and GM2X00 waveforms (R&S PostMan II)

I had already met the "combined" Rohde & Schwarz RSX.25 ARQ protocol + GM2X00 waveforms some time ago, in that case UUCP sessions were exchanged between German BPOL patrol boats and the ashore station server in order to transmit and store the positions of the vessels: the analysis is posted here
This time I was lucky to spot transmissions where RSX.25 ARQ protocol and GM2X00 waveforms are used by the R&S message handling system "PostMan II" to send emails between Italian GdF patrol boats and between patrol boats and ashore commands. Such transmissions, along with 188-141 2G-ALE messages exchanges, can be heard by monitoring some known frequencies such as 6450 (noised by close S4285 transmissions), 8190 (sometimes with co-channel interference from Saudi-AF and Israeli-Ny), and 12431 all usb. Unfortunately it could be a long and fruitless monitoring since emails transmissions are not frequent.

R&S PostMan II is a combined hardware and software product, the hardware platform is a communication server running on the Linux operating system and also controlling the connected radios. Notice that PostManII uses the advanced waveforms provided by GM2X00 HF modems since STANAG/MIL-STD waveforms cannot be used together with the RSX.25 protocol; if interoperability is needed the transmission method defined in STANAG-5066 protocol and 110A/4539 HF waveforms can be applied.

Fig. 1 - R&S PostMan II email gateway

Commands and associated files coming from PostMan, who sits at application layer, are segmented and encapsulated into RSX.25 frames which in turn are transported on air by GM2X000 HF waveforms; therefore in order to get the PostMan bitstream you need to demodulate the received signal, extract RSX.25 frames, remove their encapsulation and finally reassembly the segments into a single file (here termed "infoData.tmp"): what I got is shown in Figure 2.

Fig. 2 - infodata.tmp file, PostMan commands togheter with the (Bzip2 compressed) email file
Now let's have a close look to the first bytes of the Hex/ASCII coded infoData.tmp file, i.e. to the PostMan commands (Fig. 3).

Fig.3
"infoData.tmp"

OC0008 pm2mrs -CR D.000t 8 0666 simo@oltramonti.gdf.it 0x3da rs*ail -v2 -f simo@oltramonti.gdf.it simo@cagliari.gdf.it # Ú#º¦BZh94AY&SYèså  ...

R&S PostMan II commands
pm2mrs = PostMan II messenger(?) R&S
-CR  = (?)
rs*ail -v2 -f = rsmail -v2 (version2) -f (?)

email addresses
simo@oltramonti.gdf.it = sender, patrol vessel "Oltramonti"
simo@cagliari.gdf.it = recipient, ashore station Cagliari

Bzip2 4 bytes header
BZ = Signature (0x425A magic number)
h = Bzip2 (h is for Huffman coding)
9 =  increments of 100 kB block-size uncompressed


... compressed email file bytes follow (I did not unpack it!)

Some comments:
1) Since PostMan offers  e-mail, fax and file transfer, I think that the additional command rsmail (most likely R&S mail) that follows the pm2mrs invocation just specifies the email service.
2) In order to reduce the transmission time, both the emails text body and attached files always undergo data compression.
3) For what concerns the email addresses simo@<ALE-address>.gdf.it, it seems that each radio (with its own name, ALE address and PostMan address) belongs to one station so that each station has one unique e-mail domain name where the ALE-address is also the hostname. All the email addresses have the same local-part "simo": I do not know if it's the PostMan default username (just like "user" for Harris RF-6750 mail gateway) or if it's the special GdF entity/role/staff with delegation to the message handling system.
4) The uncoloured strings are not constant in the PostMan sessions I heard, they could be related to the underlying Linux OS layer or to some other parameters (eg, 0x3da could be a file length). Below the strings of another captured (and a bit distorted) PostMan session:
C004 pm2mrs   -CR Dû;004 06D5   simo@cappelletti.gdf.it 0x565 rsmail -v2 -f simo@cappelle tti.gdf.it simo@roma.gdf.it

As said above, PostMan command and files are segmented and encapsulated into RSX.25 frames which in turn are transported on air by GM2X000 HF waveforms. 
The RSX.25 protocol is the R&S adaptation of wired X.25 protocol to the HF radio channel. 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 depending on radio-link quality and being adapted at regular intervals. RSX.25 has a typical 8-bit period (Fig. 4) with recognizable patterns and is visible once removed the overhead due the GM2X00 "advanced" HF serial waveform.

Fig. 4 - typical RSX.25 bitstream
GM2X00 HF waveforms are based on a PSK-8 constellation modulated at a symbol-rate of 2400Bd. The frame structure consists of an initial 192 symbol sequence followed by a data block consisting 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 the one of the data frames but it contains a stop-code sequence instead of information data.

By the way, these are the R&S HF equipments used in the two stations (*):
P.V. 5 "Oltramonti" patrol boat [1]
- XK2500 500W, antenna dipole Whip 8 mt mod. STA80 + tuner FK855C3
- XK2100L 150W, antenna dipole + tuner HX002M1
"Cagliari" Aeronaval Group, Operational Control Room
- XK2900 1 KW, antenna HX002
- XK859C1 1 KW, antenna HX002



(*) these informations are publicly available from the GdF website:
http://www.gdf.gov.it/
 
[1] http://www.naviecapitani.it/.../GDF/G%205%20Oltramonti.htm

10 October 2018

NILE/Link-22 waveform #2 (S4539 Annex D)

STANAG-4539 HF Fixed Frequency TDMA transmission, used by NILE/Link-22, spotted on 7606.0 KHz/usb and followed from 0905z up to 0950z (October, 9). Modem for HFFF TDMA operations are described in Annex D of STANAG-4539.
The 270 symbols of the Media Code Frame in this samples are arranged according to the QPSK Traffic Waveform #2 (WF2) consisting of 8 sections with 18 symbols data blocks and 15/16 symbols mini-probes.

Other NILE/Link-22 waveforms, all characterized by having the same 112.5ms ACF value, are discussed here.

Fig. 1
Fig. 2

As in the table below, there are six sections consisting of 18+16=34 dibit symbols (ie 68 bits) and two sections consisting of 18+15=33 dibit symbols (ie 66 bits). Using the time shift cursor of the tool in Fig. 2 you may get the same order of the sections which is shown in the table.
 

https://yadi.sk/d/SNq_OMzQY7IF-Q

9 October 2018

S5066 data transfer, scaling from 3200bps (QPSK/PSK8 on-air) up to 9600bps (QAM64)

8th October update: using "Wireshark" software to detect IP packets (IP over HF)

13378.0 KHz/USB, 0848z: S5066 data transfer using HF waveforms 110A & S4539 which scale from 3200bps (QPSK/PSK-8 on air) up to 9600bps (QAM-64); unid user/location. Notice in Figure 1 that QAM-32 constellation use multiple PSK rings to maintain good peak-to-average ratios, and the QAM-64 constellation is a variation of the standard square QAM constellation, which has been modified to improve the peak-to-average ratio.

Fig. 1 . HF waveforms constellations
The typical 1776 bits structure of S5066 is obtained after the removal of the HF waveforms overhead, in Figure 2 the bitstream is synchronized on the sync sequence 0x90EB. 

Fig. 2 - STANAG-5066 bitstream synched on 0X90EB
Looking at the 16-byte headers of the Data Transfer Protocol Data Units (D_PDU), we see that #0 (Data only)  is the used D_PDU type: this type is used for simplex data transfer of segmented C_PDUs with a Selective Repeat-Request (SRQ) service protocol. The peers in the link have the S5066 addresses: 001.005.005.105 and 001.001.001.101.

0x90EB D_PDU sync sequence
04 D_PDU type

10 50 56 91 01 01 65 source & destination address

90 EB 04 F6 3C E9 10 50 56 91 01 01 65 48 BA 85 ...
90 EB 04 F6 3B E9 10 50 56 91 01 01 65 08 C8 87 ...
90 EB 04 F6 3A E9 10 50 56 91 01 01 65 08 C8 88 ...
90 EB 04 F6 39 E9 10 50 56 91 01 01 65 08 C8 89 ...
90 EB 04 F6 39 E9 10 50 56 91 01 01 65 08 C8 8A ...
90 EB 04 F6 38 E9 10 50 56 91 01 01 65 08 C8 8B ...
90 EB 04 F6 37 E9 10 50 56 91 01 01 65 48 BA 8C ...
90 EB 04 F6 36 E9 10 50 56 91 01 01 65 08 C8 8E ...
90 EB 04 F6 35 E9 10 50 56 91 01 01 65 08 C8 8F ...
90 EB 04 F6 34 E9 10 50 56 91 01 01 65 08 C8 90 ...

The  D_PDUs payloads originate a group of files which have the same 38 bytes length initial structure consisting of a 33-byte pattern followed by a progressive 0xnn number and four 0x00 bytes:

00 07 99 42 EF 44 45 00 05 64 FF FF 40 00 FE 32 E6 B6 C0 A8 01 30 C0 A8 0E 30 00 00 04 89 00 00 00 18 00 00 00 00 4F ...
00 07 99 42 EF 44 45 00 05 64 FF FF 40 00 FE 32 E6 B6 C0 A8 01 30 C0 A8 0E 30 00 00 04 89 00 00 00 19 00 00 00 00 5A ...
00 07 99 42 EF 44 45 00 05 64 FF FF 40 00 FE 32 E6 B6 C0 A8 01 30 C0 A8 0E 30 00 00 04 89 00 00 00 1A 00 00 00 00 CC ...
00 07 99 42 EF 44 45 00 05 64 FF FF 40 00 FE 32 E6 B6 C0 A8 01 30 C0 A8 0E 30 00 00 04 89 00 00 00 1B 00 00 00 00 53  ...
 

In my opinion the first six bytes are the headers of C (Channel Access Sublayer) and S (Subnetwork Interface Sublayer) Protocol Data Units: 

00 07 99 42 EF 44

00 C_PDU type (0 = data) 
07 S_PDU type (0 = data)
99 S_PDU source & destination SAP IDs (1001 & 1001)

42 EF 44 S_PDU control and TDD fields

and the remaining 32 bytes, from 0x45 to 0x4F, could be the headers of the User Protocol data Units (U_PDUs) incoming from the client/application upper layer (Figure 3). Since the presence of a progressive number (0x18, 0x19,0x1A,...) it could be that the client message has been segmented into smaller U_PDUs before the subnet interface, but it's only a my guess.

Fig.3 - sublayers within STANAG-5066

SAP_ID stands for Service Access Point Identifier, it's a number in the range 0-15 and is equivalent to the “port” of the TCP protocol. In this case - according to S5066, the used Service Access Point should be the IP port (1001).

My friend and colleague j. sent me an email with his comments about this signal "I also analysed the last S5066 signal you posted on your page. It finally contains IP data packets (local addresses are 192.168.1.48 ->192.168.14.48) in the direction 1.1.1.101 -> 1.5.5.105. The used protocol is ESP (IPSec). The other direction confirms the data using RCOP"
Well, it's possible to prepare an hex dump file by removing the  C & S headers (0x 00 07 99 42 EF 44) :

00 07 99 42 EF 44 45 00 05 64 FF FF 40 00 FE 32 E6 B6 C0 A8 01 30 C0 A8 0E 30 00 00 04 89 00 00 00 18 00 00 00 00 4F ...

and then process the obtained file using "wireshark" software. The results show the IP packet originally submitted to S5066 and thus to the HF network, i.e. IP over HF [1]


[1] https://www.isode.com/.../ip-over-stanag-5066.html
https://yadi.sk/d/ZFTNRhiPkoT1HQ
 

1 October 2018

logs

05838.0: ABC7: Croatian Mil, HRV 0742 USB 188-141 2G ALE calling ABH3 (20Sep18) (AAI)
05855.0: ---: Unid 0723 USB TADIRAN AutoCall MFSK-4 (20Sep18) (AAI)
05859.0: QS00: Unid 0629 USB 188-141 2G ALE handshake QJ00, no follow-on (20Sep18) (AAI)
05859.0: QS00: Unid 0653 USB 188-141 2G ALE calling QN00 (20Sep18) (AAI)
05859.0: QS00: Unid 0708 USB 188-141 2G ALE handshake QF00 / MIL 188-110 Serial (20Sep18) (AAI)
05916.5: JO2: Polish Mil, POL 0845 USB 188-141 2G ALE calling MA1 / 188-110 Serial (06Sep18) (AAI)
06348.0: FUE: French Ny, Brest FR 0827 USB STANAG-4285 600bps/L async ITA2 "FG DE FUE QSL R 192351Z SEP 18 TIME 0820Z KKKKILO DFF" (20Sep18) (AAI)
06809.0: AQ00: Unid 0716 USB 188-141 2G ALE calling QS00 (07Sep18) (AAI)
06865.0: ---: Unid 0738 USB 3G-HF FLSU Async call (07Sep18) (AAI)
07775.0: ---: Unid 0622 USB 3G-HF FLSU Async call (12Sep18) (AAI)
07830.0: MDN: Algerian Ministry of Defense, ALG 0744 USB 188-141 2G ALE calling AT01 (07Sep18) (AAI)
07898.0: 049112: DRK - German Red Cross, D 0703 USB PACTOR-1, sellcall DEK77 / 188-141 2G ALE, TWS (01Sep18) (AAI)
07937.0: ---: DHFCS Crimond, UK 1830 USB STANAG-4285 1200bps/L, 1536-bit TDM protocol (25Aug18) (AAI)
08010.0: ---: Unid 0728 USB 3G-HF FLSU Async call (21Sep18) (AAI)
08082.5: A16: Dutch Mil, HOL 1535 USB 188-141 2G ALE calling ANCS (prob. Net Control Station A) (11Sep18) (AAI)
08093.5: A16: Dutch Mil, HOL 0635 USB 188-141 2G ALE handshake A15 / 188-110A Serial, FED-1052B 8-bit encrypted file (12Sep18) (AAI)
08145.0: DOMUTOWO79: Unid (Polish-Mil?) 0538 USB 188-141 2G ALE calling INTER24 (19Sep18) (AAI)
08145.0: R01: Unid (Polish-Mil?) 0547 USB 188-141 2G ALE calling R02 (19Sep18) (AAI)
08157.5: BS0601: Unid 1140 USB 188-141 2G ALE calling MP0621 (26Sep18) (AAI)
08218.0: ---: Unid 1032 USB 3G-HF LDL160 transfer, 139-byte 'Citadel' encrypted file (28Sep18) (AAI)
08363.0: ---: Unid, prob. KNL Networks CNHF (Cognitive Networked HF) 0720 USB 6 KHz bandwidth PSK-2 4800Bd burst waveform (18Sep18) (AAI)
08516.8: FUG: French Ny La Régine (Saissac), F 0840 USB (offset + 2KHz) RATT 50Bd/850 naval bcast, 21-bit frames delimited by "1"s and LFSR markers x^7+x^6+1, x^6+x^5+1 (07Sep18) (AAI)
08644.0: ---: Unid, prob. KNL Networks CNHF (Cognitive Networked HF) 0720 USB PSK-2 2400Bd burst waveform (18Sep18) (AAI)
08875.0: MIRADO: (also MIR) Unid (Moroccan Mil?) 0837 USB 188-141 2G ALE calling VX1, heard other calls to E1, RB5, VX1 (14Sep18) (AAI)
09075.0: ---: Unid (likely from Kaliningrad oblast) 0810 (CF) FSK 100Bd/500, T-207 encryption (11Sep18) (AAI)
09309.0: BU4: Roumenian Police (Bucuresti-4 ?), ROU 0824 USB 188-141 2G ALE handshake 1PY / 188-110A Serial, STANAG-5066 encrypted file (13Sep18) (AAI)
10170.0: ---: Russian Mil/Gov, RUS 0720 CIS-VFT/3x100Bd/1440Hz, T207 encryption (20Sep18) (AAI)
11015.0: ---: DHFCS Crimond, UK 1350 USB STANAG-4285 1200bps/L, 1536-bit TDM protocol (27Aug18) (AAI)
11130.0: H1: Unid (Moroccan Mil?) 0851 USB 188-141 2G ALE calling H5 (26Sep18) (AAI)
11520.0: ---: Unid 0735 (cf) FSK 75Bd/250 (26Sep18) (AAI)
12799.0: ---: Unid 0800 USB 1500Hz carrier PSK-2 & QPSK 2400Bd bursts (28Sep18) (AAI)
13720.0: ---: Unid 1320 (cf) FSK 1200Bd/1200, test transmissions (26Sep18) (AAI)
13994.8: ---: Russian AF, RUS 0955 (cf) FSK 100Bd/1000, T-207 encryption (26Sep18) (AAI)
14390.0: ---: DHFCS Ascension Is. - overseas station, ASC 1310 USB STANAG-4285 1200bps/L, 1536-bit TDM protocol (27Aug18) (AAI)
14548.2: ---: DHFCS Cyprus Is. - overseas station, CYP 0930 USB STANAG-4285 1200bps/L, 1536-bit TDM protocol (26Aug18) (AAI)
15810.0: 1001: Moroccan MoI, MRC 0944 USB 188-141 2G ALE calling 1106 (07Sep18) (AAI)
15812.1: ---: DHFCS Cyprus Is.overseas station, CYP 0947 USB STANAG-4285 1200bps/L, 1536-bit TDM protocol (prob. DRS GA-205 multiplexer) (07Sep18) (AAI)
16106.3: ---: DHFCS St. Eval, UK 0930 USB STANAG-4285 1200bps/L, 1536-bit TDM protocol (prob. DRS GA-205 multiplexer) (02Sep18) (AAI)
16287.0: ---: DHFCS Ascension Is. - overseas station, ASC 1320 USB STANAG-4285 1200bps/L, 1536-bit TDM protocol (27Aug18) (AAI)
16398.2: ---: DHFCS Cyprus Is. overseas station, CYP 0925 USB STANAG-4285 1200bps/L, 1536-bit TDM protocol (prob. DRS GA-205 multiplexer) (07Sep18) (AAI)

29 September 2018

HF Industry website (HFIA)

WARNING: some of the recent posts have links to the "meetings & presentations" section of the High Frequency Industry Association (HFIA) website that end up giving the 404 error "page not found". The "404" errors are not due to my errors in the links but to the fact that HFIA has recently changed the layout and the policy  of its website, and in particular the "meetings & presentations" section has been replaced by "resources" and is no longer browsable without an account.

the old layout of HFIA website


28 September 2018

unid FSK 1200Bd/1200 test transmissions

Unid long-run (crtical) FSK 1200Bd/1200 test transmission heard on 13720.0 (cf) around 1320z (26 Sep). The demodulated stream consists of 16-bit frames, each frame consisting of:
*) seven bits coded with ASCII-7  ([A-Z] letters, [0-9] numbers and special chars)
*) 4-bit coded numbers [0-9]
*) 5-bit coded numbers patterns
Notice the sharp filtering at the edge of FSK transitions.





https://yadi.sk/d/7hXxtCYFjmM3bA

26 September 2018

25 September 2018

8-ary constellation bursts at 12800bps data rate (likely UK-MoD)


These transmissions consist of spread band "cluster bursts" which are sent in sequential order on several frequencies, ie the clusters are not sent simultaneously (Figure 1). Each cluster lasts about 5200ms and is composed of three 1600ms bursts separated by 200ms and spaced by 6000Hz (b1-b2) and 9000Hz (b2-b3). My friend KarapuZ spotted other clusters on 3.3, 4.0, and 4.7 MHz and published a youtube clip that shows a complete cycle [1], therefore it seems that "five" is the number of the used clusters, for a total of 3x5 = 15 "burst channels".


Fig. 1 - 5.7 and 7.8 MHz clusters
Probably they use staring SDRs, and in my opinion it could be an implementation of STANAG-4539 Annex H "Technical specifications to ensure interoperability of application communication systems using multiple discrete HF channels serial waveform", also provided in 110C Appendix F.
 
The bursts use the STANAG-4539 2400Bd and a 8-ary like constellation with a data-rate of 12800bps uncoded (!?!), a similar waveform (S-4539 12800bps/U bursts) was heard on 14 June on 7807.2 KHz/usb [2], just the same frequency of burst b1 of the 7.8 MHz cluster!
12800bps, also detected by my Harris RF-5710A, is clearly unlikely since PSK-8 modulation at a symbol rate of 2400Bd makes a gross bit transfer of 2400x3 = 7200 bit/sec, which in turn allows max data rates of 3200bps and 4800bps (if uncoded). So, 12800bps or PSK-8 seems an inconsistent data rate.
Fig. 2 - incosistent data rates
The frame structure of the bursts matches the one specified in S4539 #4.3. An initial
preamble is followed by data frames of alternating data and known symbols. Each data frame consists of a data block (256 data symbols), followed by a mini-probe (31 symbols of known data).  It's worth noting that each burst (consisting of 12 data blocks) curiously ends up with a half (½) data block.
Since the waveforms match, I wonder if they use an alternative/reserved coding that somehow deceives the RF-5710A modem. The only way to shed light on the wrong data rate is look at the received preamble.
Data rate and interleaver settings are explicitly transmitted as a part of the waveform in the second 103 symbols of the initial preamble and are coded as described in S4539 #4.3.1.1 "Synchronisation preamble" page B-11

The tribit symbols D0, D1, and D2 take one of 30 possible sets of values to indicate the data rate and interleaver settings:


The Modulo operations are meant to signify that the data rate and interleaver coded values (D0,D1,D2) are used to shift the phase of the Barker code 0,4,0,4,0,0,4,4,0,0,0,0,0.
Now look at the phase diagram of the received preamble (Fig. 3): data rate setting consists of two equal sequences plus a third one, such a symbols pattern can be originated only by the values "0,0,4", "6,6,2", and "2,2,6" of the Table 4.3.1.1-1 above reported.

Fig. 3 - phase variations of the received preamble
I'm less than a novice GNU-Octave coder so I asked my friend Christoph to write a little script to extract the symbols from the received preambles, results are surprising: quoting his email "the first few symbols of the preamble are not transmitted but the rest fits perfectly D0,D1,D2 = 6,6,2", therefore the 12800bps setting seems to be coded into the received preambles. I edit his script to improve the display of the 39 symbols related to the setting and replicated the tests: results are shown in Figure 4.
Fig. 4 - a) 287 symbols preamble and its sync (red); b) the actual "6,6,2" setting read from the preamble; c) the theoretic "6,6,2" setting
Since the 12800bps settings is correct, the used 8-ary constellation can't be a PSK-8 modulation!

But oddities do not end there.
Assuming that - in some ways - the decoding is correct, what you get is that each single burst carries 1536 bits of data and by aggregating the bursts of a single channel you will end up to see a 1536-bit protocol which looks like the DHFCS multiplexed stream (Figure 5).

Fig. 5 - demodulated streams of the 7.8 MHz cluster
Notice that each burst carries different contents: maybe the source contents are spread on the five clusters (ie on the 15 burst channels)?
I just add that all TDoA runs point to Cornwall, maybe St.Eval? if so, I wonder if Babcock/DHFCS are testing/using a  S4539 burst system in addition to the S4285 based system.
Fig. 9 - result of TDoA

(to be continued)
 
[1] https://youtu.be/iZCq4DnlNxo
[2] http://i56578-swl.blogspot.com/2018/06/stanag-4539-unexpected-data-rate-of.html

https://yadi.sk/d/EhPc_M8G7jC-mg