PLATFORM_LINUX is a hidden configuration option which is disabled by
default and enabled at over a hundred locations for features that are
deemed to be Linux specific.
The only effect of PLATFORM_LINUX is to control compilation of
libbb/match_fstype.c. This file is only needed by mount and umount.
Remove all references to PLATFORM_LINUX and compile match_fstype.c
if mount or umount is enabled.
Signed-off-by: Ron Yorston <rmy@pobox.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
> 2018-07-25:
> ntpd: increase MIN_FREQHOLD by 3
> This means we'll start correcting frequency ~5 minutes after start,
> not ~3.5 ones.
> With previous 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.
Review of real-world results of the above shows that with small
initial offsets, freq correction can be allowed to kick in sooner,
whereas with large (~0.8s) offsets, we still start freq correction
a bit too soon.
Let's rebalance this a bit.
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Back in 2007, commit 0c97c9d437 ("'simple' error message functions by
Loic Grenie") introduced bb_simple_perror_msg() to allow for a lower
overhead call to bb_perror_msg() when only a string was being printed
with no parameters. This saves space for some CPU architectures because
it avoids the overhead of a call to a variadic function. However there
has never been a simple version of bb_error_msg(), and since 2007 many
new calls to bb_perror_msg() have been added that only take a single
parameter and so could have been using bb_simple_perror_message().
This changeset introduces 'simple' versions of bb_info_msg(),
bb_error_msg(), bb_error_msg_and_die(), bb_herror_msg() and
bb_herror_msg_and_die(), and replaces all calls that only take a
single parameter, or use something like ("%s", arg), with calls to the
corresponding 'simple' version.
Since it is likely that single parameter calls to the variadic functions
may be accidentally reintroduced in the future a new debugging config
option WARN_SIMPLE_MSG has been introduced. This uses some macro magic
which will cause any such calls to generate a warning, but this is
turned off by default to avoid use of the unpleasant macros in normal
circumstances.
This is a large changeset due to the number of calls that have been
replaced. The only files that contain changes other than simple
substitution of function calls are libbb.h, libbb/herror_msg.c,
libbb/verror_msg.c and libbb/xfuncs_printf.c. In miscutils/devfsd.c,
networking/udhcp/common.h and util-linux/mdev.c additonal macros have
been added for logging so that single parameter and multiple parameter
logging variants exist.
The amount of space saved varies considerably by architecture, and was
found to be as follows (for 'defconfig' using GCC 7.4):
Arm: -92 bytes
MIPS: -52 bytes
PPC: -1836 bytes
x86_64: -938 bytes
Note that for the MIPS architecture only an exception had to be made
disabling the 'simple' calls for 'udhcp' (in networking/udhcp/common.h)
because it made these files larger on MIPS.
Signed-off-by: James Byrne <james.byrne@origamienergy.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Between Busybox 1.24.2 and 1.25.0 the bb_info_msg() function was
eliminated and calls to it changed to be bb_error_msg(). The downside of
this is that daemons now log all messages to syslog at the LOG_ERR level
which makes it hard to filter errors from informational messages.
This change optionally re-introduces bb_info_msg(), controlled by a new
option FEATURE_SYSLOG_INFO, restores all the calls to bb_info_msg() that
were removed (only in applets that set logmode to LOGMODE_SYSLOG or
LOGMODE_BOTH), and also changes informational messages in ifplugd and
ntpd.
The code size change of this is as follows (using 'defconfig' on x86_64
with gcc 7.3.0-27ubuntu1~18.04)
function old new delta
bb_info_msg - 182 +182
bb_vinfo_msg - 27 +27
static.log7 194 198 +4
log8 190 191 +1
log5 190 191 +1
crondlog 45 - -45
------------------------------------------------------------------------------
(add/remove: 2/1 grow/shrink: 3/0 up/down: 215/-45) Total: 170 bytes
If you don't care about everything being logged at LOG_ERR level
then when FEATURE_SYSLOG_INFO is disabled Busybox actually gets smaller:
function old new delta
static.log7 194 200 +6
log8 190 193 +3
log5 190 193 +3
syslog_level 1 - -1
bb_verror_msg 583 581 -2
crondlog 45 - -45
------------------------------------------------------------------------------
(add/remove: 0/2 grow/shrink: 3/1 up/down: 12/-48) Total: -36 bytes
Signed-off-by: James Byrne <james.byrne@origamienergy.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Add support for MD5 message authentication as described in RFC 5905.
This patch also supports SHA1 authentication.
The key file format is the same file format as used by ntpd.
The configuration file format follows standard Unix conventions
(# comments) with lines consist of the following fields separated by whitespace:
<key identifier, [1,65535]> <SHA1|MD5> <an ASCII string of up to 20 characters|an octet string [a-zA-F0-9] of up to 40 characters>.
https://www.ietf.org/rfc/rfc5905.txt
function old new delta
ntp_init 473 987 +514
hash - 125 +125
recv_and_process_peer_pkt 889 961 +72
packed_usage 33066 33130 +64
ntpd_main 1226 1277 +51
find_key_entry - 29 +29
add_peers 195 207 +12
recv_and_process_client_pkt 509 514 +5
------------------------------------------------------------------------------
(add/remove: 2/0 grow/shrink: 6/0 up/down: 872/0) Total: 872 bytes
Signed-off-by: Brandon P. Enochs <enochs.brandon@gmail.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Managed to make ntpd on one of my machines to be stuck getting
"root distance too high" all the time, but log is not giving me
more informatin what exactly is happening...
function old new delta
select_and_cluster 1045 1095 +50
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
On fast network, I've seen "delay:0.002000" shown for all packets,
thus completely losing information on what real delays are.
The new code is careful to not reject packets with tiny delays
if the delay "grows a lot" but is still tiny:
0.000009 is "much larger" than 0.000001 (nine times larger),
but is still very good small delay.
function old new delta
recv_and_process_peer_pkt 863 889 +26
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
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>
