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
|
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.
|
