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>
Does not configure anything. L2 configuration hook scripts should do
their job on receiving ADDRFAM=link. Configuration will be done only
once, irrespective of L3 protocols used.
Using the 'link' family in the interfaces file conforms to the Debian
implementation:
http://sources.debian.net/src/ifupdown/0.7.47.1/link.defn
function old new delta
link_methods - 12 +12
addr_link - 12 +12
link_up_down - 6 +6
static.addr_fams 12 16 +4
------------------------------------------------------------------------------
(add/remove: 3/0 grow/shrink: 1/0 up/down: 34/0) Total: 34 bytes
Signed-off-by: Kaarle Ritvanen <kaarle.ritvanen@datakunkku.fi>
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>
There's no reason to call gethostbyname() on the value returned
by uname() when asked just for a short name of a host. This may
also be wrong, when uname is set to one value, but in /etc/hosts
(or elsewhere) the "canonical" name is different. This is often
the case for localhost entry in /etc/hosts:
127.0.0.1 localhost myname
With this content of /etc/hosts, and uname being set to myname,
busybox hostname -s will return localhost, while regular
hostname utility returns myname.
Fix this by not calling gethostbyname() for the simple
'hostname -s' use.
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
GNU wget: wget google.com // ok
bb before: wget google.com // wget: not an http or ftp url
function old new delta
parse_url 317 339 +22
Signed-off-by: Lauri Kasanen <curaga@operamail.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Used to set p->filter_datapoint[i].d_dispersion = MAXDISP
and clear reachable bits, but this proved to be too agressive:
after step (tested with suspinding laptop for ~30 secs),
this caused all previous data to be considered invalid,
making us needing to collect full ~8 datapoins per peer
after step in order to start trusting them.
In turn, this was making poll interval decrease even after
step was done. (Poll interval decreases already before step
in this scenario, because we see large offsets and end up with
no good peer to select).
function old new delta
reset_peer_stats 157 139 -18
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
This change adds a definition for DHCP option 209. RFC 5071 defines code
209 as a configuration file for a PXE bootloader; this change uses
the string "pxeconffile" as its text identifier.
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Commit b8b72f02 removed all padding from DHCP packets
to fix operation with buggy servers which can't handle
maximum sized packets. But it introduced a regression
with buggy routers which drop DHCP packets smaller
than 300 bytes (i.e. 342 byte ethernet packets).
Add back some padding to work around.
function old new delta
udhcp_send_kernel_packet 268 292 +24
udhcp_send_raw_packet 462 473 +11
------------------------------------------------------------------------------
(add/remove: 0/0 grow/shrink: 2/0 up/down: 35/0) Total: 35 bytes
Signed-off-by: Johannes Stezenbach <js@sig21.net>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
function old new delta
open_socket 33 64 +31
wget_main 2182 2194 +12
Signed-off-by: Lauri Kasanen <curaga@operamail.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Fron bug report:
If a CGI or proxied connection is rudely aborted (SIG_{KILL,BUS,SEGV})
then httpd will spin madly the poll loop in:
networking/httpd.c:1080
cgi_io_loop_and_exit()
Upon investigation I found that pfd[0].revents == 0x0018 (POLLHUP|POLLERR),
which leads to empty read, but the pfd[0].fd (STDIN_FILENO) is left open,
and in the FD list given to poll() which immediately returns to once
again inform the loop of (POLLHUP|POLLERR) condition of pfd[0].fd.
This continues until pfd[FROM_CGI].revents != 0
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
