1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
|
WHATSNEW in 5.5
===============
In 5.4 the new NAT friendly behaviour was achieved by sending packets
with an rport of 0 to the server. In 5.5 this is no longer needed since
the server looks at the version number; hence 5.5 packets still go out
with rport set, making them compatible with servers of versions 5.3 or lower.
This was a small change/correction and 5.5 is a minor update.
WHATSNEW in 5.4
===============
DHIS packet messages leaving a host will now leave from the DHIS
return port (58800 by default) instead of a randomly assigned port.
Messages sent by this client to a server are marked with a return port of 0 in
the payload of the DHIS packet which causes the server to reply to the UDP port
from which it receives a packet. In other words, the return UDP port is no
longer embedded in a DHIS packet but instead is taken by the server from the
UDP layer of the network packet.
This feature (dhis client) only works with a DHIS server that implements it;
hence, a dhisd server of version 5.4 or above is required for a 5.4 client to
operate.
This feature is particularly useful in systems behind NAT; whereas before a
NAT redirect rule to the return DHIS port (58800 by default) was required, with
DHIS 5.4 this is no longer required since NAT boxes should keep the UDP state
and redirect back to the right host.
A new protocol is also implemented with DHID 5.4; instead of waiting for
server checks with CHECK_REQ, the client refreshes itself to the server
by sending periodic ECHO_REQ packets to it (every refresh period). The
server keeps the host online and only brings it offline it it doesn't
see any ECHO_REQ packets for up to 3 times the refresh period.
WHATSNEW in 5.3
===============
The documentation was updated.
DHID can now be executed under any user (not only root) without
changes to the code.
The pid file default location was changed to /var/run/dhid.pid
WHATSNEW in 5.2
===============
BUG: Client crashes when server reply comes from a different IP address
than that to which the initial packet had been sent. Fixed.
BUG: SIG_CHLD set to SIG_IGN but wait() used. Fixed. SIG_IGN was removed.
WHATSNEW Since Release 5.0
==========================
1) OnCmd and OffCmd options now are executed with the hostid parameter,
the local IPv4 dynamic IP address and additional parameters specified
in dhid.conf
WHATSNEW Since Release 4.0
==========================
1) Mail relay commands are no longer implemented (CTL4_MXSTART, CTL4_MXEND)
2) Interactive mode is no longer possible
3) The client now supports multiple servers on multiple addresses and/or
multiple ports (see dhid.conf.sample)
4) The client now is able to update multiple clients within one server
(see dhid.conf.sample)
5) The client may now propose how often it wishes the server to verify
connectivity with CHECK_REQs. (see refresh option in dhid.conf.sample)
6) For each record updated (a host entry withing dhid.conf) it is possible
to execute external scripts at the times of online and offline transitions.
(see OnCmd and OffCmd options in dhid.conf.sample)
7) Pid file can now be specified on command line using the -P option
8) The -p command line option now permits changing of the local UDP port.
9) Server port can now be specified individually in dhid.conf for each
record (see ISAddr)
10)ISAddr now accepts an FQDN as well as an IP address
WHATSNEW Since Release 3.1
==========================
Two major changes. Release 3 clients can however still connect to
an R4 server.
1) The protocol has been redisigned. The old simple broadcast packet
has been replaced by a full message exchange process. The client now
sends an ECHO_REQ to the server with no information and expects an
ECHO_ACK reply (a connection has been established).
The client then issues an AUTH_REQ and expects an AUTH_ACK or
AUTH_DENY. If insecure mode is used the password is inserted
in the AUTH_REQ packet. Otherwise, please see below.
When the online stage is achieved the client stands in listening mode.
Unlike in DHIS R3, it does not send a broadcast packet, but expects
instead a query (CHECK_REQ) from the server, upon which must
reply with a CHECK_ACK. If the server doesn't receive CHECK_ACKs
for a period of time the host is considered to have become offline.
If the client doesn't receive queries for a period of time it
returns to poll mode (ECHO_REQs are sent again).
2) Public key security has been introduced (QRC). If selected,
after an AUTH_REQ the client expects an AUTH_SY upon which
replies with an AUTH_SX for successful authentication.
The algorithm is as follows:
The client holds a pair of private keys, P and Q.
These are long integers both prime and congruent to 3 mod 4.
The server keeps the client's public key generated
by P * Q.
Upon an authentication request the server generates a
random number X (relatively prime to N) and calculates
its square (mod N) Y. Y is sent back to the client.
The client then has to prove that it is able to calculate
its square root (mod N) (X) which may only be performed
with the two prime factors P and Q. In order to do it,
the client calculates the square root mod P and mod Q
of Y and applies the Chinese Remainder Theorem to calculate
the square root mod N. Having done this, the calculated
X is sent back to the server for comparission with the
original value.
|
