This way, we can zero them all in one go.
We do malloc() anyway, thus nothing is lost by mallocing "globals"
function old new delta
arping_main 1683 1686 +3
finish 100 86 -14
catcher 350 310 -40
------------------------------------------------------------------------------
(add/remove: 0/0 grow/shrink: 1/2 up/down: 3/-54) Total: -51 bytes
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
ARPING 192.168.1.1 from 192.168.1.172 wlan0
Unicast reply from 192.168.1.1 [F4:F2:6D:52:A8:DE] 1.672ms
Sent 1 probes (1 broadcast(s))
Received 1 response(s)
ARPING 192.168.1.1 from 192.168.1.172 wlan0
Unicast reply from 192.168.1.1 [f4:f2:6d:52:a8:de] 1.152ms
Sent 1 probe(s) (1 broadcast(s))
Received 1 response(s) (0 request(s), 0 broadcast(s))
function old new delta
finish 120 100 -20
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Do not clear extra bits on option_mask32, it's not necessary.
Move DAD bit to 2, this makes exit logic simpler.
function old new delta
arping_main 1655 1629 -26
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Since bb_info_msg() was eliminated type of buffering on stdout is not important
function old new delta
udhcpd_main 1463 1451 -12
udhcpc_main 2735 2723 -12
setlinebuf 19 - -19
------------------------------------------------------------------------------
(add/remove: 0/2 grow/shrink: 0/2 up/down: 0/-43) Total: -43 bytes
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
The current standard (RFC 3542) is for IPV6_RECVPKTINFO to be given to
setsockopt, and IPV6_PKTINFO to be used as the packet type. Previously,
RFC 2292 required IPV6_PKTINFO to be used for both, but RFC 3542
re-purposed IPV6_PKTINFO when given to setsockopt. The special
Linux-specific IPV6_2292PKTINFO has the same semantics as IPV6_PKTINFO
in RFC 2292, but was introduced at the same time as IPV6_RECVPKTINFO.
Therefore, if we have IPV6_RECVPKTINFO available, we can use the RFC
3542 style, and if not, we assume that only the RFC 2292 API is
available, using IPV6_PKTINFO for both.
Signed-off-by: James Clarke <jrtc27@jrtc27.com>
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>
iproute.c: In function 'print_route':
iproute.c:85:9: error: 'RTA_TABLE' undeclared (first use in this function)
iproute.c:85:9: note: each undeclared identifier is reported only once for each function it appears in
iproute.c: In function 'iproute_modify':
iproute.c:467:36: error: 'RTA_TABLE' undeclared (first use in this function)
Fix it by partially #ifdef'ing the code added in b42107f21538e39d9a344376372f8261aed589b2
Signed-off-by: Eugene Rudoy <gene.devel@gmail.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
With new code, we request that target IP (server ID) must be directly reachable.
If it's not, this happens:
udhcpc: waiting 2000 seconds
udhcpc: entering listen mode: kernel
udhcpc: opening listen socket on *:68 wlan0
udhcpc: entering renew state
udhcpc: sending renew to 1.1.1.1
udhcpc: send: Network is unreachable
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 1.1.1.1 needs routing, this is fishy!
udhcpc: entering rebinding state
udhcpc: entering listen mode: raw
udhcpc: created raw socket
udhcpc: sending renew to 0.0.0.0
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ going to use broadcast
which is the desired behavior. Before the patch, packet to 1.1.1.1 was routed
over eth0 (!) and maybe even into Internet (!!!).
function old new delta
udhcpc_main 2752 2763 +11
udhcp_send_kernel_packet 295 301 +6
send_renew 82 84 +2
send_packet 166 168 +2
bcast_or_ucast 23 25 +2
------------------------------------------------------------------------------
(add/remove: 0/0 grow/shrink: 5/0 up/down: 23/0) Total: 23 bytes
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
I see random field values like sll_hatype=0x267 when I strace.
They seem to not matter, but just in case they sometimes do,
let's at least have deterministic values (via memset(0)).
function old new delta
change_listen_mode 308 322 +14
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
