This means we'll start correcting frequency ~5 minutes after start,
not ~3.5 ones.
With previos settings I still often see largish ~0.7s initial offsets
only about 1/2 corrected before frequency correction kicks in,
resulting in ~200ppm "correction" which is then slowly undone.
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Update QoS markers.
Use DSCP AF21 for interactive traffic. DSCP is defined in RFC2474.
Many modern equipment no longer support IPTOS.
Signed-off-by: Codarren Velvindron <codarren@hackers.mu>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Bad case: send request to server1good.com; then try to resolve server2bad.com -
this fails, and failure takes ~5 secs; then receive server1's
response 5 seconds later. We'll never sync up in this case...
function old new delta
ntpd_main 1079 1106 +27
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
This is particularly useful if hostname resolution is triggered by
host non-reachability: I saw this in real-life, without the message
it is not at all obvious that IP that we use for a specific host
has changed.
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Run the namelookup from the main loop so a misspelled first ntp server
name does not block everything forever.
This fixes the following situation which would block forever:
$ sudo ./busybox ntpd -dn -p foobar -p pool.ntp.org
ntpd: bad address 'foobar'
ntpd: bad address 'foobar'
ntpd: bad address 'foobar'
...
New behavior:
ntpd: bad address 'foobar'
ntpd: sending query to 137.190.2.4
ntpd: reply from 137.190.2.4: offset:-1.009775 delay:0.175550 status:0x24 strat:1 refid:0x00535047 rootdelay:0.000000 reach:0x01
ntpd: sending query to 137.190.2.4
ntpd: reply from 137.190.2.4: offset:-1.009605 delay:0.175461 status:0x24 strat:1 refid:0x00535047 rootdelay:0.000000 reach:0x03
ntpd: sending query to 137.190.2.4
ntpd: reply from 137.190.2.4: offset:-1.005327 delay:0.167027 status:0x24 strat:1 refid:0x00535047 rootdelay:0.000000 reach:0x07
ntpd: sending query to 137.190.2.4
ntpd: bad address 'foobar'
ntpd: reply from 137.190.2.4: offset:-1.046349 delay:0.248705 status:0x24 strat:1 refid:0x00535047 rootdelay:0.000000 reach:0x0f
This patch is based on Kaarle Ritvanens work.
http://lists.busybox.net/pipermail/busybox/2016-May/084197.html
function old new delta
ntpd_main 1061 1079 +18
ntp_init 556 560 +4
resolve_peer_hostname 81 75 -6
------------------------------------------------------------------------------
(add/remove: 0/0 grow/shrink: 2/1 up/down: 22/-6) Total: 16 bytes
Signed-off-by: Kaarle Ritvanen <kaarle.ritvanen@datakunkku.fi>
Signed-off-by: Natanael Copa <ncopa@alpinelinux.org>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
The busybox NTP implementation doesn't check the NTP mode of packets
received on the server port and responds to any packet with the right
size. This includes responses from another NTP server. An attacker can
send a packet with a spoofed source address in order to create an
infinite loop of responses between two busybox NTP servers. Adding
more packets to the loop increases the traffic between the servers
until one of them has a fully loaded CPU and/or network.
Signed-off-by: Miroslav Lichvar <mlichvar@redhat.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
This resolves the following use case problem:
"I start ntpd by default from /etc/init.d
There might be no working network connection (not configured properly for
whatever reason, hardware problems, whatelse).
With busybox 1.25 ntpd seems to loop forever if now NTP servers are found,
blocking the boot process and I never get a login to solve a possible pb or
to do a first time configuration."
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Some users start ntpd on boot, and don't babysit it. If it dies because
DNS is not yet up and therefore NTP servers can't be found, users are
not happy.
Example behavior with a peer name which can't be resolved:
ntpd: bad address 'qwe.rty.ghj.kl'
...5 sec...
ntpd: bad address 'qwe.rty.ghj.kl'
ntpd: bad address 'qwe.rty.ghj.kl'
ntpd: bad address 'qwe.rty.ghj.kl'
ntpd: bad address 'qwe.rty.ghj.kl'
ntpd: bad address 'qwe.rty.ghj.kl'
ntpd: bad address 'qwe.rty.ghj.kl'
ntpd: bad address 'qwe.rty.ghj.kl'
ntpd: bad address 'qwe.rty.ghj.kl'
ntpd: bad address 'qwe.rty.ghj.kl'
...
Based on the patch by Kaarle Ritvanen <kaarle.ritvanen@datakunkku.fi>
function old new delta
resolve_peer_hostname - 81 +81
ntpd_main 1130 1061 -69
------------------------------------------------------------------------------
(add/remove: 1/0 grow/shrink: 0/1 up/down: 81/-69) Total: 12 bytes
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
This speeds up syncing - now happens only just
two replies from a peer. Especially useful for "ntpd -q".
Shouldn't have ill effects: if we chose a bad peer,
we will discover it later and switch to another one.
The code is even smaller this way.
Suggested by Miroslav Lichvar <mlichvar@redhat.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
OpenNTPd is licensed under ISC-style license so it's good idea to keep
ntpd applet under same license to avoid mess, instead of having
our changes to be under GPL.
Names of original code's authors are added.
Signed-off-by: Adam Tkac <vonsch@gmail.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
The offset to jitter ratio is now calculated before updating
jitter to make the test more sensitive.
function old new delta
ntp_init 460 474 +14
update_local_clock 752 764 +12
------------------------------------------------------------------------------
(add/remove: 0/0 grow/shrink: 2/0 up/down: 26/0) Total: 26 bytes
Signed-off-by: Miroslav Lichvar <mlichvar@redhat.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
To avoid polling servers frequently slowly increase the interval up
to BIGPOLL when
- no replies are received from a peer
- no source can be selected
- peer claims to be unsynchronized (e.g. we are polling it too
frequently)
When recv() returns with an error, drop code to try to continue
on network errors: I'm not convinced those cases happen in real life.
function old new delta
recv_and_process_peer_pkt 919 838 -81
Signed-off-by: Miroslav Lichvar <mlichvar@redhat.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
* on step, poll interval drops to 8.5 mins instead of 32 seconds
* on total loss of all replies (no replies from any peer
for last 8 requests), also drop poll interval to 8.5 mins
instead of 32 seconds
* on send abd recv errors, RETRY_INTERVAL is now 32 seconds,
not 5 seconds
* on timing out listening to reply, instead of unconditional
shortening poll interval by x4, clamp it to NOREPLY_INTERVAL
(512 seconds)
* if a largish offset is seen, clamp nexp poll interval
to 128 seconds, not 64 seconds
function old new delta
clamp_pollexp_and_set_MAXSTRAT - 37 +37
recv_and_process_peer_pkt 861 869 +8
poll_interval 52 48 -4
update_local_clock 762 752 -10
ntpd_main 1063 1050 -13
------------------------------------------------------------------------------
(add/remove: 1/0 grow/shrink: 1/3 up/down: 45/-27) Total: 18 bytes
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
The burst mode needs to be stopped even when no replies are received.
Signed-off-by: Miroslav Lichvar <mlichvar@redhat.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Before this cahnge, sometimes they were used after the next packet
from another peer was received, because we did updare some peer stats
from high delay packet before dropping it.
function old new delta
recv_and_process_peer_pkt 922 966 +44
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
rand() is the most standard C library function,
and on uclibc they are the same. I guess
they are the same in most todays' libc...
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
GCC complained about since_last_update being set but not used.
Signed-off-by: Bartosz Golaszewski <bartekgola@gmail.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
