PolAF, UUCP over RSX.25 to exchange HF email messages

I have already encountered the Rohde & Schwarz RSX.25 protocol in some transmissions of the German BPOL and Italian GdF, this time (just a few days ago) I spotted such transmissions from the Polish AirForce (Siły Powietrzne - Ministerstwo Obrony Narodowej, MON) on 6884 KHz/USB where they use R&S GM2100 proprietary waveforms as HF bearer and UUCP over RSX.25 to send PostMan II email messages (Figure 1). Transmission were recorded using a Polish KiwiSDR [1].

Fig. 1

Particularly, one of the transmissions being analyzed refers to the nodes with ALE address WARSZAWA2 and BYDGOSZCZ:

TO WARSZAWA2 TIS BYDGOSZCZ
TO BYDGOSZCZ TIS WARSZAWA2
TO WARSZAWA2 TIS BYDGOSZCZ User Unique Function 00 07 (CMD USER UNIQUE WORD)

The used 2G-ALE protocol is the well-known standard 188-141A: the first thing that catches the eye is the use of a User Unique Function (UUF) [2] with the value 00 07 (14-bit ASCII [nul][bel]) in the third frame of the ALE handshake. User Unique Functions enable the transmission of a manufacturer-specific Unique Index which may be used for controlling the subsequent data transmission protocol; in this case, the value 0007 is most likely the particular "index" that R&S uses to signal UUCP/RSX.25 protocol to the receive node.

Data are sent using the HF waveform "Signal Format", a so-called R&S proprietary advanced waveform provided by their GM2100/GM2200 HF modem. The used waveform is the quite common 2400Bd PSK8 occupying a 3 KHz bandwidth (Figure 2). With 8PSK the net data rate of the serial modem is 5400 bit/s, errors are at first corrected by FEC, which reduces net data rate to 2700 bit/s. 

Fig. 2

The framing consists of a 192-symbol sequence preamble followed by one ore more data blocks each consisting of 64-symbols: 48 unknown symbols (coded data) + 16 known symbols ("test sequences"). The postamble terminates the data blocks and consists of a 64-symbol End Of Message sequence. Except for the presence of an initial TLC section(s), the total length is then a multiple of 64 symbols.

Fig. 3

Figure 4 shows the ACF/period of the GM2100 waveform: since the 2400 Baud, the ACF value of 133.33ms corresponds to a 320-symbol period, ie to five 64-symbol data blocks.

Fig. 4

The length of 320 symbols is due to the fact that the 16-symbol test sequences are actually "segments" of a longer 80-symbol sequence and so they are five times repeated, as visible in Figure 4 (unless demodulation errors), hence the length of (48+16)×5=320 symbols, or 960 bit since each PSK8 symbol is mapped to a tri-bit sequence (000...111). 

Fig. 5

After the removal of the HF waveform overhead, the well-known 8-bit patterns of RSX.25 emerge (Figure 6). RSX.25 literally stands for R&S adaptation of wired X.25 protocol to the HF radio channel,ie a modified AX.25 packet radio protocol.
Quoting R&S papers: "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 up to 250 data  bytes, in strongly disturbed channels 4 bytes. Errors escaping FEC are eliminated by the ARQ procedure of the RSX.25 protocol." [3]

Fig. 6

The transmitted data are obtained after the removal of RSX.25 encapsulation and packets' reassembly, the file (Hex codes and ASCII text) is edited using the XVI32 hex editor [4] and shown in figure 7. Some known "reserved words" and syntax say that's an email transport performed by the use of UUCP: all messages in the initial handshake begin with a `^P' (a byte with the octal value \020, hex  0x10) and end with a null byte (octal \000, hex 0x00).

 

Fig. 7

UUCP (Unix-to-Unix copy) suite is a set of computer programs and protocols that allow for the remote execution of commands and the transfer of email and files between computers, in this scenario it is used over RSX.25. The human-readable version of  the UUCP "conversation" (just the initial part)  is shown in Figure 8.

 

Fig. 8

The messages can be parsed according to the UUCP protocol internals [5] so to get some other informations about users, SW/HW equipment... and so on.

 

login...Connected...OK 

login section

S Bydgoszcz_HF -pz -vgrade=z -R -N07 ROKN07 Pyie Uy

UUCP handshake 
S  caller hostname = Bydgoszcz_HF
-pz -vgrade=z  requests the called system to only transfer files of the specified grade or higher = z (grades in UUCP links means 'priorities')
-R  caller UUCP understands how to restart failed file transmissions. Supported only by System V Release 4 UUCP, so this is a System V release.
-N07 - caller UUCP understands the Taylor UUCP size negotiation extension (only for UUPlus, so this is UUPlus)
ROKN07 – called station acknowledgement of ‘R’ options. The caller UUCP is acceptable, it specified `-N', and the called UUCP also understands the Taylor UUCP size limiting extensions
Pyie  the called station supports the following UUCP protocols y, i, e
Uy  the calling station selects which protocol to use out of the protocols offered by the called station, in this case the UUCP protocol 'y'

 

pm2mrs -CR D.0097 0666 dso22odn@bydgoszcz.airforce.pl 0x3d26

most likely R&S PostMan II messenger

D.0097 file to send
0666 mode of file, if UUPlus always = 0666 for outgoing files
dso22odn@bydgoszcz.airforce.pl file name
0x3d26 file size (15654 bytes) 

rsmail -v2 -f dso22odn@bydgoszcz.airforce.pl dsocop@warszawa2.airforce.pl

Since PostMan offers  e-mail, fax and file transfer, my guess is that the additional command rsmail (most likely R&S mail)  following the pm2mrs invocation just specifies the email service

dso22odn@bydgoszcz.airforce.pl the caller station (ALE address: BYDGOSZCZ) is the "22 Ośrodek Dowodzenia i Naprowadzania" (22 Command and Guidance Center) [6] located st Bydgoszcz Airport: it's a civilian airport but shared with the Polish Air Force
dsocop@warszawa2.airforce.pl it's the called station (ALE address: WARSZAWA2) , "dso cop" is probably the Armed Forces Operational Command in Warzawa (it's a my guess)

It's interesting to note that in some other recordings the email address are user@warszawa2.airforce.pl and user@bydgoszcz.airforce.pl ("user@" is the common default username as in other message handling systems), although the ALE address remain the same, ie WARSZAWA2 and BYDGOSZCZ.

 

BZh9
Bzip2 4 bytes header, here starts the file to be sent (Bzip compressed)
BZ  Signature (0x425A magic number)
h Bzip2 (h is for Huffman coding)
9  increments of 100 kB block-size uncompressed

It's really obvious that the two stations belong to the Polish Air Force (indeed "airforce.pl" is the email domain name) as well as the use of R&S hardware/software equipment (STANAG/MIL-STD waveforms cannot be used along with the RSX.25 protocol [7]). 

A bit of OSINT demonstrates the R&S support to the Polish Armed Forces:

https://www.epicos.com/article/475115/rohde-schwarz-supports-polish-armed-forces

as well as the use of R&S XK2500L and XK2900L radios (along with Harris RF-5800) at the "Radio Center, Region 4 Air Force ICT Support":

http://www.szpzl-zegrze.waw.pl/pdf/k/29/5.pdf 

https://archiwum-4rwt.wp.mil.pl/pl/31.html 

 

Must be noted that PostMan II (now superseeded by PostMan III) is a combined R&S hardware & software product running on a Unix-like communication server: hence the use of such OS, at least in the mail server of the local nets.

Further catches could offer the chance to gather some more intelligence.

 

https://disk.yandex.com/d/ZapUYqs-xgddiQ 

 

[1] http://plonsk3.proxy.kiwisdr.com:8073/
[2] http://hflink.com/standards/MIL_STD_188-141C.pdf  (A.5.6.9 User unique functions)
[3] https://cdn.rohde-schwarz.com/pws/dl_downloads/.../n155.pdf

[4] http://www.chmaas.handshake.de/delphi/freeware/xvi32/xvi32.htm
[5] http://www.math.utah.edu/docs/info/uucp_5.html

[6] https://22odn.wp.mil.pl/pl/
[7] https://scdn.rohde-schwarz.com/.../Postman_en_.pdf

 

R&S GM2100/2200 waveforms' preamble and its similarity to Link-11 SLEW

Me and my friend ANgazu from radiofrecuencias.es have recently studied curious, and apparently unid, burst transmissions occurred for about two consecutive days (7-8 Sept, ceased on 9 morning) on 12431 KHz USB. The idea of this post just comes during the analysis of that signal, noting an interesting similarity of its preamble to the one of Link-11 SLEW. The post then retraces those steps: from the analysis of the bitstreams (and recognition of the waveform) up to the in-depth examination of the preamble sequences and their coding.
The used waveform is the quite common and well-known PSK-8 & 2400 Bd occupying a 3 KHz bandwidth. The bursts do not appear synched or following a certain timing pattern, even if the sequence highlighted in the FFT-spectrum/time of figure 1 seems to be used.

Fig. 1

The good quality of the recording (courtesy of ANgazu) allow its demodulation using the PSKn demodulator of SA. The resulting bitstreams have a 480/96 bit length period, corresponding to 160/32 tribit PSK8 symbols (figure 2). Since these are bursts, the initial part is likely to consist of one or more TLC sections used for transmitter level control and receiver AGC settling (1). 

Fig. 2

The most interesting thing is that, after reshaping the bitstream to the 96-bit period, I found a 192-symbol  sequence which is the same as the one used in Link-11 SLEW acquisition preamble (figure 3). Indeed, quoting STANAG-5511 paragraph 10.1.1.1: "[the preamble] consists of a 192 tri-bit known sequence generated from a pseudo random code [...] these symbols are not scrambled and are applied directly to the 8 PSK modulator".

Fig. 3 -  the evident matching between the two 192-symbols sequence (*)

Judging from the preamble, it could be said that the bursts are Interrogation Messages of  Link-11 SLEW... but actually their durations and the structures following the preamble are not the same: indeed, Link-11 bursts have a well defined 45-symbols length header [1] which is not reflected in the analyzed bursts:

Link-11 SLEW waveform structure (Figure B-9, Stanag-5511)

So, a question arises: what other waveform has a 192-symbol length preamble? 

Checking my blog I found a match to the preamble of Rohde & Schwarz proprietary waveforms implemented in their GM2100/2200 HF modem [2] (although the term GM 2100 refers to the physical modem, from now on I will use it to refer to its characteristic waveform).  The framing consists of a 192-symbol sequence preamble followed by one ore more data blocks each consisting of 64-symbols: 48 unknown symbols (coded data) + 16 known symbols (test sequences). The postamble terminates the data blocks and consists of a 64-symbol End Of Message sequence. Except for the presence of an initial TLC section(s), the total length is then a multiple of 64 symbols.

Fig. 4 - GM2100 "signal format" waveform structure

To thoroughly analyze the bitstream under consideration, it's useful to refer to figure 5 that shows the ACF/period of a GM2100 transmission heard some years ago: since the 2400 Baud, the 133.45ms value corresponds to 320-symbol, or 5 data blocks, period:

Fig. 5 - GM2100 133.4 ms ACF

Back to our bistream, after removing initial TLC section(s) and preamble, the remaining bits, once reshaped to a 64-symbol pattern, are consistent with the GM2100 framing of figure 4. Moreover, it's easy to see in figure 6 that the five 16-symbol test sequences are repeated and are "segments" of the longer 80-symbol sequence (*):

 

0 2 7 7 3 5 1 0 1 4 0 5 0 0 0 0
4 1 1 2 1 4 1 5 4 2 7 4 5 1 6 4
5 4 3 7 0 7 6 2 6 2 4 6 7 2 4 7
3 0 3 1 3 5 1 2 5 0 1 7 1 4 6 0
0 5 7 7 2 5 2 7 7 4 7 5 5 0 5 6

The repetition of the five test sequences causes the (48+16)×5=320 symbol length period shown in figure 5.

 

Fig. 6 - GM2100 burst, demodulated bitstream (*)

Thanks to ANgazu, another important confirmation of GM2100 was a 188-141A 2G-ALE handshake (heard in that same frequency) which allowed us to identify the user as the Italian "Guardia di Finanza" (GdF): as it's known, they make a large use of R&S equipments in their onshore/offshore stations. Unfortunately, the handshake was not followed by any data traffic.

After identified the waveform, we agreed that the evident correspondence between the 192-symbol preamble sequences of Link-11 SLEW and GM2100 shall be further investigated anyway!

R&S documentation [2] reports the "autobaud" facility of the GM2100 waveforms: "A great advantage of the transmission method employed by GM2100 is automatic detection of the received signal data rate by means of a code received at the start of reception. This means that the receiving data modem need not be told the data rate of the transmitting modem".
A fairly likely conclusion - in my opinion - is that  R&S - as usual in the practice - use Walsh Orthogonal Modulation sequences in the sync preambles for both syncing and coding data-rate, FEC, interleaver, and modulation used in the following data blocks. 
Walsh Orthogonal Modulation is accomplished by taking each three bits (tribit) symbol and selecting a corresponding 4-fold repeated Walsh sequence, represented as octal characters (0 will be 0, and 1 will be 4); the selected four element Walsh sequence is repeated 8 times to yield a 32-element Walsh sequence used for the sync symbols (Table I)

Table I Channel symbol mapping for sync preamble.

The 32-element sequences of  Table I are then modulo 8 added to the scrambling sequence  7 4 3 0 5 1 5 0 2 2 1 1 5 7 4 3 5 0 2 6 2 1 6 2 0 0 5 0 5 2 6 6 (Table II). The scrambling sequence, from what I could find, is chosen from the long pseudorandom sequence of (2^16 -1) bits generated by the LFSR  x^16+x^15+x^13+x^4+1 [3].

Table II

The receive node, knowing the beginning and duration of each sequence, first "removes" the randomizing sequence from the received signal and then the resulting symbols are determined by the maximum likelihood method. 

So, the reason of the corrispondences shown in figure 3 is that both L-11 SLEW and GM2100 code their preamble by using the same 32-element Walsh randomized sequences (2). Notice that a similar method is also used in the preamble pattern generation of MIL-STD-188-110/FED-STD-1052.
By the way, I processed the recording using two GM2100 decoders but the analysis of  the resulting bitstreams did not reveal the presence of some known protocol, specifically the expected RSX.25 (the R&S implementation of X.25) which constitutes the main payload of these waveforms. The duration of the operations (~2 days), their modality and the lack of "consistent" traffic, lead us think about the execution of some test or training.

Ultimately, the practice of coding preambles using 32-element Walsh randomized sequences can lead to inaccurate conclusions or even false positive IDs, especially when analysis is limited to preambles only.

https://disk.yandex.com/d/Q-XCoIrJ2rbDdQ

(*) A comment about the bitstream of figures 3,6
SA is an amazing signals analyzer but it's not a "waveform decoder", this means that its PSKn demodulator does not sync on knowns sequences. When used on phase keyed signals, SA produces correct info and images (number of phases, angles, modulation speed, carrier frequency, ...) but for the same signal it returns different demodulated streams due to the inevitable phase-offset errors (figure 7). Hence, each output stream should be analyzed separately.

Fig. 7

(1) 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 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. (Johnson, Koski, Furman, Jorgenson, "Third Generation and Wideband HF Radio Communications"). 

(2) According to Table II, the sequence of the link-11 SLEW acquisition preamble consists of the symbols 5,7,6,1,4,0 

7 0 3 4 1 1 1 0 2 6 1 5 1 7 0 3 5 4 2 2 6 1 2 2 0 4 5 4 1 2 2 6   5
7 0 7 0 1 1 5 4 2 6 5 1 1 7 4 7 5 4 6 6 6 1 6 6 0 4 1 0 1 2 6 2   7
7 4 7 4 1 5 5 0 2 2 5 5 1 3 4 3 5 0 6 2 6 5 6 2 0 0 1 4 1 6 6 6   6
7 0 3 4 5 5 5 4 2 6 1 5 5 3 4 7 5 4 2 2 2 5 6 6 0 4 5 4 5 6 6 2   1
7 4 3 0 1 5 1 4 2 2 1 1 1 3 0 7 5 0 2 6 6 5 2 6 0 0 5 0 1 6 2 2   4
7 4 3 0 5 1 5 0 2 2 1 1 5 7 4 3 5 0 2 6 2 1 6 2 0 0 5 0 5 2 6 6   0 

[1] https://i56578-swl.blogspot.com/2018/09/link-11-slew-transmission-format.html
[2] https://disk.yandex.com/i/mh2Ev4Bo15Az4Q
[3] https://disk.yandex.com/i/zOmzgHgthPXqMA
[4] https://disk.yandex.com/i/lb5zWmqYic7gBA

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
 

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 

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

UUCP protocol 'conversations' over HF using RSX.25 and GM2X00 waveforms

This post is intended to complete some previous analysis of the protocols used by the German BPOL for their HF ship-shore communications which are based on the R&S implementation of the X.25 protocol and the proprietary R&S GM-2100 waveform: the scenario is shown in Figure 1: UUCP protocol, who sits on top of RS X.25 , is discussed in this post thanks to a friend of mine who pointed my attention on the upper application layer and gave a big help and contribution in UUCP protocol analysis. 

Fig. 1

UUCP (Unix-to-Unix copy) [1] suite is a set of computer programs and protocols that allow for the remote execution of commands and the transfer of email and files between computers, in this scenario it is used over X.25 and HF-link. The UUCP bitstream (uucp-over-hf.bin)  is obtained after the removal of X.25 overhead and it's edited using the XVI32 hex editor [2]: a XVI32 screenshot is shown in Figure 2.

Fig.2 - XVI32 editor

A UUCP session (termed "conversation") consists of three parts: an initial handshake, a series of file transfer requests, and a final handshake. Before the initial handshake, the caller will usually have logged in the called machine and somehow started the UUCP there: since they use the UUF Index "00000000000111" during the 2G-ALE handshake, most likely UUCP is started at the "dial in" stage by means of the command User Unique Function in the 188-141A message section [3]:

(to)BPLEZS (cmd)|[nul][bel] (tis)BP23
1111100 0000000 0000111

 
The initial part concerns the "login", probably the tags  <MPL></MPL> and <SPL></SPL> are XML markers.

0A 0D 0A 6C 6F 67 69 6E 3A 20 55 42 50 4F 4C 42 50 4C 45 5A 53 45 45 5F 48 46 0A

. . . login: U BPOLBPLEZSEE_HF .

3C 4D 50 4C 3E 32 30 31 36 2D 31 31 2D 32 38 20 31 35 3A 34 39 3A 35 32 2B 30 31 2C 42 50 4F 4C 42 50 32 33 3B

<MPL> 2016-11-28 15:49:52+01,BPOLBP23;

32 30 31 36 2D 31 31 2D 42 50 4F 4C 42 50 4C 45 5A 53 45 45 5F 48 46 0A 0D 20 31 35 3A 34 39 3A

2016-11-BPOLBPLE ZSEE_HF .. 15:49:

35 32 2B 30 31 2C 42 50 4F 4C 42 50 32 33 3B

52+01,BPOLBP23;

32 30 31 36 2D 31 31 2D 32 38 20 31 35 3A 34 37 3A 34 35 2B 30 31 2C 42 50 4F 4C 42 50 32 36 3C 2F 4D 50 4C 3E 0A

2016-11-28 15:47: 45+01,BPOLBP26</MPL> .

42 50 4F 4C 42 50 4C 45 5A 53 45 45 5F 48 46 0A 0D

BPOLBPLEZSE E_HF ..

20 31 35 3A 34 39 3A 35 32 2B 30 31 2C 42 50 4F 4C 42 50 32 33 3B

15:49:52+01,BPOLBP23;

32 30 31 36 2D 31 31 2D 3C 53 50 4C 3E 32 30 31 36 2D 31 31 2D 32 38 20 31 35 3A 34 37 3A 34 35 2B 30 31 2C

2016-11-<SPL>2016-11-28 15:47:45+01,

42 50 4F 4C 42 50 32 36 3C 2F 53 50 4C 3E 0A

BPOLBP26</SPL> .

43 6F 6E 6E 65 63 74 65 64 0A

Connected .

All messages in the initial handshake begin with a `^P' (a byte with the octal value \020, hex  0x10) and end with a null byte (octal \000, hex 0x00) and it is begun by the called machine. The session can be parsed according to: 

http://www.math.utah.edu/docs/info/uucp_5.html#SEC45

10 53 68 65 72 65 3D 42 50 4F 4C 42 50 32 33 5F 48 46 00

10 – UUCP initial handshake message start

Shere = – called hostname = BPOLBP23_HF

00 – UUCP initial handshake message end

10 53 42 50 4F 4C 42 50 4C 45 5A 53 45 45 5F 48 46 20 2D 70 7A 20 2D 76 67 72 61 64 65 3D 7A 20 2D 52 20 2D 4E 30 37 00

10 – UUCP initial handshake message start

S – calling hostname = BPOLBPLEZSEE_HF

-pz - requests the called system to only transfer files of the specified grade or higher = z

-vgrade=z - requests the called system to only transfer files of the specified grade or higher = z (grades in UUCP links means 'priorities')

-R - calling UUCP understands how to restart failed file transmissions. Supported only by System V Release 4 UUCP, so this is a System V release.

- N07 - calling UUCP understands the Taylor UUCP size negotiation extension (only for UUPlus, so this is UUPlus)

07 = 000111 – options (in octal)

xxxxx1 – UUCP support size negotiation

xxxx1x – UUCP supports file restart

xxx1xx – UUCP supports ‘E’ command

00 – UUCP initial handshake message end

10 52 4F 4B 4E 30 37 00

10 – UUCP initial handshake message start

ROKN07 – called station acknowledgement of ‘R’ options. The calling UUCP is acceptable, it specified `-N', and the called UUCP also understands the Taylor UUCP size limiting extensions

00 – UUCP initial handshake message end

10 50 79 69 65 00

10 – UUCP initial handshake message start

50 – P = called station supports the following UUCP protocols y, i, e

00 – UUCP initial handshake message end

10 55 79 00

10 – UUCP initial handshake message start

55 – U = The calling UUCP selects which protocol to use out of the protocols offered by the called UUCP

in this case calling station supports the UUCP protocol 'y' (0x79)

00 – UUCP initial handshake message end

 UUCP ‘y’ protocol (uucico Zmodem protocol) starts here, first packet with pkt number = 0 is a ‘sync’ packet

 

00 00 04 00 10 00 01 04 00 00

00 00 – pkt number (little endian) = 0

04 00 – pkt length (little endian) = 4 Bytes

10 00 – check sum (little endian)

01 – version = 1

04 – max pkt size = 32768/4 = 8192 Bytes

00 00 – flags = none defined

/* trailing 0x00 missing */

01 00 03 00 B8 01 48 4E 00

01 00 - pkt number = 1

03 00 – pkt length = 3 Bytes

B8 01 - check sum

48 = ‘H’ hang up command/command response O

4E = ‘N’ = Slave does not agree to hang up

00 – end of pkt

 

02 00 3D 00 19 23 45 20 44 2E 30 35 50 4B 20 44 2E 42 50 4F 4C 42 50 32 43 30 35 50 4B 20 75 75 63 70 20 75 75 63 70 20

02 00 - pkt number = 2

3D 00 – pkt length = 61 Bytes

19 23 - check sum

45 – ‘E’ command

44 2E 30 35 50 4B 20 – file to send = D.05PK

44 2E 42 50 4F 4C 42 50 32 43 30 35 50 4B 20 – file name on slave = D.BPOLBP2C05PK

75 75 63 70 20 – user or application requesting the file transfer = uucp

2D 43 20 44 2E 30 35 50 4B 20 30 36 36 36 20 22 22 20 30 78 36 36 20 72 73 67 70 73 61 64 64 00

2D 43 20 – option: file has been copied to the spool directory = C

44 2E 30 35 50 4B 20 - if the `C' option appears in options, this names the file to be sent = D.05PK

30 36 36 36 20 - mode of file on master; if UUPlus always = 0666 for outgoing files

22 22 20 – notify = "" = notification not enabled

30 78 36 36 20 – file size = 0x66 = 102 Bytes

72 73 67 70 73 61 64 64 – command to be executed = rsgpsadd

(most likely a PostMan II application which sends GPS data to an ashore data base) 

00 - end of pkt 

 

02 00 83 21 66 5A 29 76 4C 40 AC 93 34 6D 98 DF D0 7B

/* is this noise or …? */

03 00 66 00 E3 13

03 00 – pkt number = 3

66 00 – pkt length = 0x0066 = 102 Bytes

E3 13 – check sum

/* BZIP’ed data follows */

42 5A 68 39 31 41 59 26 53 59 31 B5 92 5D 00 00

15 DE 00 00 10 40 0F 7F F0 10 04 C0 00 20 00 40

94 44 C9 B4 8D EA 21 A1 40 D3 43 23 26 24 08 8B

AE 1A 62 1D B0 EF 05 4D 67 25 41 08 B0 A8 3D 51

B2 9C 96 C3 74 66 4E AB 06 83 94 21 E4 D1 AB 4D

EF C3 44 66 9E 13 F8 E8 D9 A3 61 F8 BB 92 29 C2

84 81 8D AC 92 E8

04 00 00 00 FF FF

04 00 – pkt number = 4

00 00 – pkt length = 00 00 /* this indicates end of file */

FF FF – check sum /* because no data bytes are present, the checksum is set equal to its initial setting */

16 B0 F9 F5 37 DE DC 29 AE 6D 48 D4 1F 34 B5 D6 5E 00 FF A4

/* is this noise or …? */

05 00 02 00 8E 00 48 00

05 00 – pkt number

02 00 – pkt data length

8E 00 – checksum

48 – ‘H’ command from master to hang up connection

00 – end of command pkt

05 00 03 00 CE 01 48 59 00

05 00 – pkt number

03 00 – pkt data length

CE 01 – checksum

48 59 – ‘H’ command, ‘Y’ = agrees to hang up the connection

00 – end of pkt

06 00 03 00 CE 01 48 59 00

06 00 – pkt number

03 00 – pkt data length

CE 01 – checksum

48 59 – ‘H’ command, ‘Y’ = agrees to hang up the connection

00 – end of pkt

After the protocol has been shut down, the final handshake is performed. This handshake has no real purpose, and some UUCP packages simply drop the connection rather than do it (in fact, some will drop the connection immediately after both sides agree to hangup, without even closing down the protocol). 
In the final handshake, the calling UUCP sends six letter O's and the called UUCP replies with seven letter O's. Some UUCP packages always send six O's.

10 4F 4F 4F 4F 4F 4F 00

10 – UUCP final handshake message start

4F 4F 4F 4F 4F 4F – final handshake caller closing sequence = OOOOOO

00 – end of final handshake message

10 4F 4F 4F 4F 4F 4F 00

10 – UUCP final handshake message start

4F 4F 4F 4F 4F 4F – final handshake caller closing sequence = OOOOOO

00 – end of final handshake message

10 4F 4F 4F 4F 4F 4F 4F 00

10 – UUCP final handshake message start

4F 4F 4F 4F 4F 4F 4F – final handshake called closing sequence = OOOOOOO

00 – end of final handshake message

10 4F 4F 4F 4F 4F 4F 4F 00

10 – UUCP final handshake message start

4F 4F 4F 4F 4F 4F 4F – final handshake called closing sequence = OOOOOOO

00 – end of final handshake message

https://yadi.sk/d/0IgkbnUO3UnncJ

[1] http://www.math.utah.edu/docs/info/uucp_5.html

[2] http://www.chmaas.handshake.de/delphi/freeware/xvi32/xvi32.htm 
[3] http://hflink.com/standards/MIL_STD_188-141C.pdf (A.5.6.9 User unique functions)