Some user managed to hit a race where iface is gone between SIOCGIFFLAGS
and SIOCSIFFLAGS (!). If SIOCSIFFLAGS fails, treat it the same as failed
SIOCGIFFLAGS
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 is necessary for multi-hosted TLSed web sites.
function old new delta
spawn_https_helper_openssl 334 441 +107
Based on a patch by Jeremy Chadwick <jdc@koitsu.org>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
It was doing way too simplistic work of just querying the server,
no redirects, no query massaging. This required user to know a lot about whois,
and enter at least three queries for each host to get meaningful information.
function old new delta
whois_main 209 646 +437
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
The bug was seen when the following is done:
# killall 1 udhpc; killall 2 udhpc
Performing a DHCP renew
state: 2 -> 5
Sending renew...
Entering released state
state: 5 -> 6 <<<<<<<<<<<<<< not calling script!!!!
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>
The ICMP RFC says that identifier and sequence number may be zero.
Having them zero for a Echo message, along with a data of zero's
as well will result in a Echo reply message with only zero's.
Some NAT implementations seem to get the checksum wrong on these
packages. Setting a checksum of 0x0 instead of 0xffff.
Through NAT:
Internet Control Message Protocol
Type: 0 (Echo (ping) reply)
Code: 0
Checksum: 0x0000 [incorrect, should be 0xffff]
Identifier (BE): 0 (0x0000)
Identifier (LE): 0 (0x0000)
Sequence number (BE): 0 (0x0000)
Sequence number (LE): 0 (0x0000)
Data (56 bytes)
Data: 000000000000000000000000000000000000000000000000...
[Length: 56]
Without NAT:
Internet Control Message Protocol
Type: 0 (Echo (ping) reply)
Code: 0
Checksum: 0xffff [correct]
Identifier (BE): 0 (0x0000)
Identifier (LE): 0 (0x0000)
Sequence number (BE): 0 (0x0000)
Sequence number (LE): 0 (0x0000)
[Request frame: 189]
[Response time: 0.024 ms]
Data (56 bytes)
Data: 000000000000000000000000000000000000000000000000...
[Length: 56]
And this in turn will make some hardware MAC checksum offloading
engines drop the packet.
(This was seen with a Synopsis MAC, the same one used in for instance the
stmmac Ethernet driver in the linux kernel.)
This change can be seen as a workaround for bugs in other layers.
But just setting an identifier for the Echo message packet will
avoid prodding the hornets nest.
function old new delta
common_ping_main 424 500 +76
Signed-off-by: Jonas Danielsson <jonasdn@axis.com>
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 is the only non-debug use of ether_ntoa(). By not using it,
we reduce bss:
function old new delta
arping_main 1568 1665 +97
static.asc 18 - -18
ether_ntoa 57 - -57
------------------------------------------------------------------------------
(add/remove: 0/2 grow/shrink: 1/0 up/down: 97/-75) Total: 22 bytes
text data bss dec hex filename
911020 493 7352 918865 e0551 busybox_old
911069 493 7336 918898 e0572 busybox_unstripped
Also, "standard" arping zero-pads MAC. ether_ntoa() does not.
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Use designated initializers for struct msghdr.
The struct layout is non-portable and musl libc does not match what busybox expects.
Signed-off-by: Szabolcs Nagy <nsz@port70.net>
Tested-by: Waldemar Brodkorb <wbx@openadk.org>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
The result of looking at "grep -F -B2 '*fill*' busybox_unstripped.map"
text data bss dec hex filename
829901 4086 1904 835891 cc133 busybox_before
829665 4086 1904 835655 cc047 busybox
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Otherwise, "-t 0" usage may end up sending them forever
if server does not respond.
function old new delta
udhcpc_main 2846 2836 -10
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
RFC2131 paragraph 4.1 states DHCP messages broadcast by a client prior to
that client obtaining its IP address must have the source IP address
field in the header set to 0.
Request messages transmitted in renewing and rebinding state need to use
the obtained IP address as source IP address in the header; this behavior
lines up with other implementations like ISC dhcp client.
Signed-off-by: Hans Dedecker <dedeckeh@gmail.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Let udhcpd retain the information about expired leases when restarting
so that the leases are reserved until they possibly become the oldest
expired lease.
This reduces the frequency of IP address changes for example when the
DHCP server and a group of clients, who do not store and request their
previously offered IP address across restarts, are collectively restarted
and the startup order of the clients are not guaranteed.
Signed-off-by: Christian Lindeberg <christian.lindeberg@axis.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
This patch allow to have multiple interface definitions, much like
Debian's ifupdown. More specifically, it removes the check for a
duplicate definition, so the impact on binary size should be fairly
minimal.
This configuration:
iface eth0 inet static
address 192.168.0.15
netmask 255.255.0.0
gateway 192.168.0.1
iface eth0 inet static
address 10.0.0.1
netmask 255.255.255.0
Will add two addresses to eth0 if ip is used. If ifconfig is used,
the standards methods will likely not stack, but the administrator may
still use the manual method. The DHCP method may work depending on the
DHCP client in use.
This is a fairly advanced feature for power users who knows what they
are doing. There are not many other network configuration systems that
allows multiple addresses on an interface.
Signed-off-by: Nicolas Cavallari <nicolas.cavallari@green-communications.fr>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
After commit 8e74adab01
("libbb: make INET[6]_rresolve use sockaddr2{host,dotted}_noport")
INET_sprint6 uses more than just sin6_addr, it also tries to display the
scope id, which is uninitialized when called from ife_print6.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
