function old new delta
select_and_cluster 1088 1093 +5
Signed-off-by: Michael Glembotzki <m.glembo@gmail.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
RFC 2131 says we should do that.
Evidently, since for so many years no one complained, sending them broadcast
works too, but finally we've got someone who wants RFC-compliand behavior.
function old new delta
send_packet 141 179 +38
.rodata 105680 105681 +1
------------------------------------------------------------------------------
(add/remove: 0/0 grow/shrink: 2/0 up/down: 39/0) Total: 39 bytes
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Currently, udhcpc6 does not meet the requirements for
Identity Association in RFC 3315.
This is a specific explanation in RFC 3315 protocol:
https://datatracker.ietf.org/doc/html/rfc3315#section-10
"The IAID uniquely identifies the IA and must be chosen to be unique
among the IAIDs on the client. The IAID is chosen by the client.
For any given use of an IA by the client, the IAID for that IA MUST
be consistent across restarts of the DHCP client."
This patch makes the client generate a consistent IAID based on the MAC address.
function old new delta
send_d6_discover 285 270 -15
Signed-off-by: Zhou Siqi <zhousiqi5@huawei.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Several small improvements to udhcpc6.
- Remove usage text for the nonexistent -B option.
- Fix a segfault when renewing an IA_PD lease without IA_NA (which means
the client hasn't been assigned an ip, so we cannot locally bind to it).
- Fix NAK management: check the option length, and print the status code
and status message
- Add a -m option to always send renew requests as multicast.
These last two changes are useful to deal with hopelessly broken DHCPv6
servers such as the one from the Orange Livebox (one of the main French
ISPs) which I'm currently having the displeasure to have to talk to,
hence the patch.
function old new delta
static.send_d6_renew - 126 +126
.rodata 105598 105649 +51
udhcpc6_main 2607 2650 +43
packed_usage 34933 34953 +20
d6_send_kernel_packet_from_client_data_ifindex 266 282 +16
send_d6_renew 174 - -174
------------------------------------------------------------------------------
(add/remove: 1/1 grow/shrink: 4/0 up/down: 256/-174) Total: 82 bytes
Signed-off-by: Laurent Bercot <ska-dietlibc@skarnet.org>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
- The CAN netlink interface has been added in Linux v2.6.31 with only 3 options [1]:
CAN_CTRLMODE_LOOPBACK 0x1 /* Loopback mode */
CAN_CTRLMODE_LISTENONLY 0x2 /* Listen-only mode */
CAN_CTRLMODE_3_SAMPLES 0x4 /* Triple sampling mode */
So define the other options.
- IFLA_CAN_TERMINATION has been added in Linux 4.11 [2],
define it for older kernels.
[1] https://github.com/torvalds/linux/blob/v2.6.31/include/linux/can/netlink.h#L80-L82
[2] 12a6075cab
Signed-off-by: Thomas Devoogdt <thomas@devoogdt.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
gcc is being rather silly. Usues suboptimal registers,
and does not realize that i and j are never negative,
thus usese even _more_ registers for temporaries
to sign-extend i/j to 64-bit offsets.
function old new delta
sp_256_mont_mul_8 155 132 -23
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
gcc does not necessarily clear upper bits in
64-bit regs if you ask it to load a 32-bit constant.
Cast it to unsigned long. Better yet, hand-write loading
of the constant with a smaller instruction.
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
HTTP headers are case insensitive and therefore the check if a default
header has been overwritten needs to be case insensitive.
Without this patch `--header 'user-agent: test'` results in
`User-Agent: Wget` and `user-agent: test` being send.
function old new delta
------------------------------------------------------------------------------
(add/remove: 0/0 grow/shrink: 0/0 up/down: 0/0) Total: 0 bytes
text data bss dec hex filename
1040876 16443 1840 1059159 102957 busybox_old
1040876 16443 1840 1059159 102957 busybox_unstripped
Signed-off-by: Sertonix <sertonix@posteo.net>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Although "naive" counting function is not too slow and is smaller,
using it on e.g. each of 1024 words of CPU mask feels wrong.
function old new delta
bb_popcnt_32 - 52 +52
get_prefix 323 321 -2
nproc_main 206 199 -7
d4_run_script 739 731 -8
ipcalc_main 533 507 -26
------------------------------------------------------------------------------
(add/remove: 2/0 grow/shrink: 0/4 up/down: 52/-43) Total: 9 bytes
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
I developed this application to test the Linux kernel series [1]. As
described in it I could not use the iproute2 package since the
microcontroller is without MMU.
function old new delta
do_set_can - 920 +920
packed_usage 34645 34908 +263
get_float_1000 - 164 +164
.rodata 105427 105539 +112
do_iplink 1313 1381 +68
------------------------------------------------------------------------------
(add/remove: 2/0 grow/shrink: 3/0 up/down: 1527/0) Total: 1527 bytes
cc: Marc Kleine-Budde <mkl@pengutronix.de>
[1] https://marc.info/?l=linux-netdev&m=167999323611710&w=2
Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
I noticed a commit in connman:
"gdhcp: Avoid leaking stack data via unitiialized variable" [1]
Since gdhcp is just BusyBox udhcp with the serial numbers filed off, I
checked if BusyBox udhcp has a related issue.
The issue is that the get_option logic assumes any data within the
memory area of the buffer is "valid". This reduces the complexity of the
function at the cost of reading past the end of the actually received
data in the case of specially crafted packets. This is not a problem
for the udhcp_recv_kernel_packet data path as the entire memory
area is zeroed. However, d4/d6_recv_raw_packet does not zero the
memory.
Note that a related commit [2] is not required as we are zeroing
any data that can be read by the get_option function.
[1] https://git.kernel.org/pub/scm/network/connman/connman.git/commit/?id=a74524b3e3fad81b0fd1084ffdf9f2ea469cd9b1
[2] https://git.kernel.org/pub/scm/network/connman/connman.git/commit/?id=58d397ba74873384aee449690a9070bacd5676fa
function old new delta
d4_recv_raw_packet 484 497 +13
d6_recv_raw_packet 216 228 +12
.rodata 105390 105381 -9
------------------------------------------------------------------------------
(add/remove: 0/0 grow/shrink: 2/1 up/down: 25/-9) Total: 16 bytes
Signed-off-by: Russ Dill <russ.dill@gmail.com>
Cc: Colin Wee <cwee@tesla.com>
Cc: Denys Vlasenko <vda.linux@googlemail.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
from Adam Goldman <adamg@pobox.com>
This patch makes udhcpd respond correctly to queries from BOOTP clients.
It contains the following changes:
The end field, or DHCP_END option, is required in DHCP requests but
optional in BOOTP requests. However, we still send an end
field in all replies, because some BOOTP clients expect one in replies
even if they didn't send one in the request.
Requests without a DHCP_MESSAGE_TYPE are recognized as BOOTP requests
and handled appropriately, instead of being discarded. We still require
an RFC 1048 options field, but we allow it to be empty.
Since a BOOTP client will keep using the assigned IP forever, we only
send a BOOTP reply if a static lease exists for that client.
BOOTP replies shouldn't contain DHCP_* options, so we omit them if there
was no DHCP_MESSAGE_TYPE in the request. Options other than DHCP_*
options are still sent.
The options field of a BOOTP reply must be exactly 64 bytes. If we
construct a reply with more than 64 bytes of options, we give up and log
an error instead of sending it. udhcp_send_raw_packet already pads the
options field to 64 bytes if it is too short.
This implementation has been tested against an HP PA-RISC client.
function old new delta
.rodata 105247 105321 +74
udhcpd_main 1520 1591 +71
send_offer 419 470 +51
init_packet 81 97 +16
udhcp_init_header 75 88 +13
udhcp_scan_options 192 203 +11
------------------------------------------------------------------------------
(add/remove: 0/0 grow/shrink: 6/0 up/down: 236/0) Total: 236 bytes
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Based on patch by Uwe Kleine-König.
It makes sense to actually see the nitty-gritty details of DNS
querying, so bringing in (commented-out) musl's DNS request code.
function old new delta
nslookup_main 760 822 +62
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
If cgi-bin/ prefix is seen, do not test the rest for existence,
whether it's a dir, and such.
function old new delta
handle_incoming_and_exit 2200 2212 +12
Reported here:
https://lists.zx2c4.com/pipermail/cgit/2023-March/004825.html
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Need to divide by (1<<32), not by (1<<32)-1.
Fraction of 0xffffffff is not 1 whole second.
function old new delta
.rodata 105264 105268 +4
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
The 32-bit integer part of the NTP timestamp overflows in year 2036,
which starts the second NTP era.
Modify the timestamp conversion to shift values between 1900-1970 (in
the first era) to the second era to enable the client to measure its
offset correctly until year 2106 (assuming 64-bit time_t).
Also update the conversion from double used when stepping the clock to
work with 64-bit time_t after reaching the maximum 32-bit value in 2038
and the server conversion to work correctly in the next NTP era.
function old new delta
lfp_to_d 51 64 +13
step_time 326 332 +6
.rodata 105260 105264 +4
d_to_lfp 100 86 -14
------------------------------------------------------------------------------
(add/remove: 0/0 grow/shrink: 3/1 up/down: 23/-14) Total: 9 bytes
Signed-off-by: Miroslav Lichvar <mlichvar@redhat.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Various tools are Linuxish and should thus only attempted to build on
Linux only. Some features are also Linux-only.
Also, libresolv is used on all GNU platforms, notably GNU/Hurd and
GNU/kfreeBSD.
Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
