Linux kernel, starting from 2.6.19 allows ip table ids to have 32-bit values.
In order to preserve compatibility, the old 8-bit field: rtm_table is still
in use when table id is lower than 256.
Add support for the 32-bit table id (RTA_TABLE attribute) in:
- ip route print
- ip route modify
- ip rule print
- ip rule modify
Add printing of table ids to ip route.
Changes are compatible with the mainline iproute2 utilities.
These changes are required for compatibility with ConnMan, which by default
uses table ids greater than 255.
function old new delta
print_route 1588 1637 +49
do_iproute 2187 2222 +35
do_iprule 955 987 +32
print_rule 617 630 +13
------------------------------------------------------------------------------
(add/remove: 0/0 grow/shrink: 4/0 up/down: 129/0) Total: 129 bytes
Signed-off-by: Lukasz Nowak <lnowak@tycoint.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
While at it, fix a pathological case where it is not fine:
-r REALM with some 8-kbyte long REALM would overflow the buffer.
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
function old new delta
udhcp_get_option 215 220 +5
udhcp_run_script 802 803 +1
Signed-off-by: Brian Foley <bpfoley@google.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Here, not handling the error is would just eat one input 0xff char.
Correct handling would need even more corner case handling,
as-is buggy handling corrupts the buffer.
Since we just been told by kernel that pty is ready,
EAGAIN should not be happening here anyway.
function old new delta
telnetd_main 1798 1785 -13
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
put_iac2(w,c) is mostly used with constants, fold them into one arg
function old new delta
put_iac2_merged - 46 +46
telnet_main 1603 1583 -20
con_escape 285 257 -28
put_iac2 50 - -50
------------------------------------------------------------------------------
(add/remove: 1/1 grow/shrink: 0/2 up/down: 46/-98) Total: -52 bytes
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
A bit of future-proofing. Some of them can stand just being ignored.
function old new delta
telnetd_main 1791 1798 +7
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
I managed to reproduce the bug, with some difficulty.
function old new delta
telnetd_main 1780 1791 +11
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
If a write to pty is short, remove_iacs() can be run on a buffer repeatedly.
This, for example, can eat 0xff chars (IACs, in telnet terms).
Rework the logic to handle IACs in a special "write to pty" function.
function old new delta
telnetd_main 1662 1750 +88
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
By user's request.
Decided to not use fcntl(F_SETLKW) in lieu of problems with locking
on networked filesystems. The existence of /var/run/ifstate.new
is treated as a write lock. rename() provides atomicity.
function old new delta
ifupdown_main 1019 1122 +103
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Also, much improved help text.
function old new delta
packed_usage 30652 30851 +199
tcpudpsvd_main 1782 1784 +2
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Added NOINLINE to two function, since my version of gcc would actualy increase
code size otherwise.
I see no size changes.
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Remove FEATURE_TRACEROUTE_SOURCE_ROUTE: it's off by default, and
source routing is not used in real world.
Tested that "traceroute -n ::1 100" and "traceroute -n 127.0.0.1 100"
both send 100 byte IP packets (this matches what traceroute on Fedora
Rawhide is doing).
function old new delta
common_traceroute_main 3731 3738 +7
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
User report:
or our board we setup eth0:0 on a 10.10.10.x/29 netwrok.
The problem is ip addr flush dev eth0:0 removes all ip addresses from
eth0. You can see this if you run
ip -stat -stat addr flush dev eth0:0
2: eth0 inet 172.27.105.10/22 brd 172.27.107.255 scope global eth0
valid_lft forever preferred_lft forever
2: eth0 inet 10.10.10.9/29 scope global eth0:0
valid_lft forever preferred_lft forever
2: eth0 inet6 fe80::a2f6:fdff:fe18:2b13/64 scope link
valid_lft forever preferred_lft forever
*** Round 1, deleting 3 addresses ***
*** Flush is complete after 1 round ***
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
A padding to align a message should not only be added between
different attributes of a netlink message, but also at the end of the
message to pad it to the correct size.
Without this patch the following command does not work and returns an
error code:
ip link add type nlmon
Without this ip from busybox sends this:
sendmsg(3, {msg_name={sa_family=AF_NETLINK, nl_pid=0, nl_groups=00000000},
msg_namelen=12, msg_iov=[{iov_base={{len=45, ...},
"\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\20\0\22\0\t\0\1nlmon"}, iov_len=45}],
msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 45
return value: 2
The normal ip utile from iproute2 sends this:
sendmsg(3, {msg_name={sa_family=AF_NETLINK, nl_pid=0, nl_groups=00000000},
msg_namelen=12, msg_iov=[{iov_base={{len=48, ...},
"\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\20\0\22\0\t\0\1nlmon\0\0\0"}, iov_len=48}],
msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 48
return value: 0
With this patch ip from busybox sends this:
sendmsg(3, {msg_name={sa_family=AF_NETLINK, nl_pid=0, nl_groups=00000000},
msg_namelen=12, msg_iov=[{iov_base={{len=48, ...},
"\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\20\0\22\0\t\0\1nlmon\0\0\0"}, iov_len=48}],
msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 48
return value: 0
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
The udhcpc script may be used to setup fallback configuration (E.G. IPv4LL,
fixed IP address, ..) that also needs to be cleaned up on release (E.G.
when SIGUSR2 is called or on shutdown with -R), so unconditionally call
deconfig.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
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>
