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 |
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
(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
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:
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
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
[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)
[3] http://hflink.com/standards/MIL_STD_188-141C.pdf (A.5.6.9 User unique functions)
Great job, Antonio.
ReplyDeletevery interesting.