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.
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
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 ...
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.
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
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
No comments:
Post a Comment