Anton Moryakov [Sun, 20 Jul 2025 15:38:43 +0000 (18:38 +0300)]
ip: ipmaddr.c: Fix possible integer underflow in read_igmp()
Static analyzer pointed out a potential error:
Possible integer underflow: left operand is tainted. An integer underflow
may occur due to arithmetic operation (unsigned subtraction) between variable
'len' and value '1', when 'len' is tainted { [0, 18446744073709551615] }
The fix adds a check for 'len == 0' before accessing the last character of
the name, and skips the current line in such cases to avoid the underflow.
Reported-by: SVACE static analyzer Signed-off-by: Anton Moryakov <ant.v.moryakov@gmail.com> Signed-off-by: David Ahern <dsahern@kernel.org>
Anton Moryakov [Sat, 19 Jul 2025 10:42:12 +0000 (13:42 +0300)]
misc: fix memory leak in ifstat.c
A memory leak was detected by the static analyzer SVACE in the function
get_nlmsg_extended(). The issue occurred when parsing extended interface
statistics failed due to a missing nested attribute. In this case,
memory allocated for 'n->name' via strdup() was not freed before returning,
resulting in a leak.
The fix adds an explicit 'free(n->name)' call before freeing the containing
structure in the error path.
Reported-by: SVACE static analyzer Signed-off-by: Anton Moryakov <ant.v.moryakov@gmail.com> Signed-off-by: David Ahern <dsahern@kernel.org>
Anton Moryakov [Sat, 19 Jul 2025 16:31:22 +0000 (19:31 +0300)]
misc: ss.c: fix logical error in main function
In the line if (!dump_tcpdiag) { there was a logical error
in checking the descriptor, which the static analyzer complained
about (this action is always false)
fixed by replacing !dump_tcpdiag with !dump_fp
Reported-by: SVACE static analyzer Signed-off-by: Anton Moryakov <ant.v.moryakov@gmail.com> Acked-by: Stephen Hemminger <stephen@networkplumber.org> Signed-off-by: David Ahern <dsahern@kernel.org>
bridge: fdb: Add support for FDB activity notification control
Add support for FDB activity notification control [1].
Users can use this to enable activity notifications on a new FDB entry
that was learned on an ES (Ethernet Segment) peer and mark it as locally
inactive:
The "norefresh" keyword is used to avoid resetting the entry's last
active time (i.e., "updated" time).
User space will receive a notification when the entry becomes inactive
and the control plane will be able to mark the entry as locally
inactive. Note that the entry was converted from a dynamic entry to a
static entry to prevent the kernel from automatically deleting it upon
inactivity.
An existing inactive entry can only be marked as active by the kernel or
by disabling and enabling activity notifications:
$ bridge -d fdb get 00:11:22:33:44:55 br br1
00:11:22:33:44:55 dev bond1 activity_notify inactive master br1 static
# bridge fdb replace 00:11:22:33:44:55 dev bond1 master static activity_notify
$ bridge -d fdb get 00:11:22:33:44:55 br br1
00:11:22:33:44:55 dev bond1 activity_notify inactive master br1 static
# bridge fdb replace 00:11:22:33:44:55 dev bond1 master static
# bridge fdb replace 00:11:22:33:44:55 dev bond1 master static activity_notify
$ bridge -d fdb get 00:11:22:33:44:55 br br1
00:11:22:33:44:55 dev bond1 activity_notify master br1 static
Marking an entry as inactive while activity notifications are disabled
does not make sense and will be rejected by the kernel:
Kernel commit 1bbdb81a9836 ("devlink: Fix excessive stack usage in rate TC bandwidth parsing")
introduced a dedicated attribute set (DEVLINK_RATE_TC_ATTR_*) for entries nested
under DEVLINK_ATTR_RATE_TC_BWS.
Update the parser to reflect this change by validating the nested
attributes and sync the UAPI header to include the changes.
Fixes: c83d1477f8b2 ("Add support for 'tc-bw' attribute in devlink-rate") Signed-off-by: Carolina Jubran <cjubran@nvidia.com> Signed-off-by: David Ahern <dsahern@kernel.org>
Introduce a new attribute 'tc-bw' to devlink-rate, allowing users to
set the bandwidth allocation per traffic class. The new attribute
enables fine-grained QoS configurations by assigning relative bandwidth
shares to each traffic class, supporting more precise traffic shaping,
which helps in achieving more precise bandwidth management across
traffic streams.
Add support for configuring 'tc-bw' via the devlink userspace utility
and parse the 'tc-bw' arguments for accurate bandwidth assignment per
traffic class.
This feature supports 8 traffic classes as defined by the IEEE 802.1Qaz
standard.
Example commands:
- devlink port function rate add pci/0000:08:00.0/group \
tx_share 10Gbit tx_max 50Gbit tc-bw 0:20 1:0 2:0 3:0 4:0 5:80 6:0 7:0
- devlink port function rate set pci/0000:08:00.0/group \
tc-bw 0:20 1:0 2:0 3:0 4:0 5:80 6:0 7:0
Add support for the recently added "extern_valid" flag that can be used
to indicate to the kernel that a neighbor entry was learned and
determined to be valid externally. The kernel will not remove or
invalidate the entry, but it can probe the entry and notify user space
when the entry becomes reachable. The kernel will return the entry to
stale state if it did not receive a confirmation after probing the
entry.
Example usage and output:
# ip neigh add 192.0.2.1 nud none dev br0.10 extern_valid
Error: Cannot create externally validated neighbor with an invalid state.
# ip neigh add 192.0.2.1 lladdr 00:11:22:33:44:55 nud stale dev br0.10 extern_valid
$ ip neigh show dev br0.10
192.0.2.1 lladdr 00:11:22:33:44:55 extern_valid STALE
$ ip -j -p neigh show dev br0.10
[ {
"dst": "192.0.2.1",
"lladdr": "00:11:22:33:44:55",
"extern_valid": null,
"state": [ "STALE" ]
} ]
Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David Ahern <dsahern@kernel.org>
David Ahern [Wed, 2 Jul 2025 14:36:20 +0000 (14:36 +0000)]
Merge branch 'bridge-mcast-state-vlan' into next
Fabian Pfitzner says:
====================
Dump the multicast querier state per vlan.
This commit is almost identical to [1].
The querier state can be seen with:
bridge -d vlan global
The options for vlan filtering and vlan mcast snooping have to be enabled
in order to see the output:
ip link set [dev] type bridge mcast_vlan_snooping 1 vlan_filtering 1
The querier state shows the following information for IPv4 and IPv6
respectively:
1) The ip address of the current querier in the network. This could be
ourselves or an external querier.
2) The port on which the querier was seen
3) Querier timeout in seconds
Fabian Pfitzner [Wed, 25 Jun 2025 08:39:14 +0000 (10:39 +0200)]
bridge: dump mcast querier per vlan
Dump the multicast querier state per vlan.
This commit is almost identical to [1].
The querier state can be seen with:
bridge -d vlan global
The options for vlan filtering and vlan mcast snooping have to be enabled
in order to see the output:
ip link set [dev] type bridge mcast_vlan_snooping 1 vlan_filtering 1
The querier state shows the following information for IPv4 and IPv6
respectively:
1) The ip address of the current querier in the network. This could be
ourselves or an external querier.
2) The port on which the querier was seen
3) Querier timeout in seconds
David Ahern [Mon, 16 Jun 2025 02:15:27 +0000 (02:15 +0000)]
Merge branch 'bridge-vlan-stats' into next
Petr Machata says:
====================
ip stats displays bridge-related multicast and STP stats, but not VLAN
stats. There is code for requesting, decoding and formatting these stats
accessible through `bridge -s vlan', but the `ip stats' suite lacks it. In
this patchset, extract the `bridge vlan' code to a generally accessible
place and extend `ip stats' to use it.
This reuses the existing display and JSON format, and plugs it into the
existing `ip stats' hierarchy:
# ip stats show dev v2 group xstats_slave subgroup bridge suite vlan
2: v2: group xstats_slave subgroup bridge suite vlan
10
RX: 3376 bytes 50 packets
TX: 2824 bytes 44 packets
# ip stats show dev br1 group xstats subgroup bridge suite vlan
211: br1: group xstats subgroup bridge suite vlan
10
RX: 3376 bytes 50 packets
TX: 2824 bytes 44 packets
Petr Machata [Tue, 10 Jun 2025 15:51:27 +0000 (17:51 +0200)]
ip: iplink_bridge: Support bridge VLAN stats in `ip stats'
Add support for displaying bridge VLAN statistics in `ip stats'.
Reuse the existing `bridge vlan' display and JSON format:
# ip stats show dev v2 group xstats_slave subgroup bridge suite vlan
2: v2: group xstats_slave subgroup bridge suite vlan
10
RX: 3376 bytes 50 packets
TX: 2824 bytes 44 packets
# ip stats show dev br1 group xstats subgroup bridge suite vlan
211: br1: group xstats subgroup bridge suite vlan
10
RX: 3376 bytes 50 packets
TX: 2824 bytes 44 packets
Petr Machata [Tue, 10 Jun 2025 15:51:26 +0000 (17:51 +0200)]
lib: bridge: Add a module for bridge-related helpers
`ip stats' displays a range of bridge_slave-related statistics, but not
the VLAN stats. `bridge vlan' actually has code to show these. Extract the
code to libutil so that it can be reused between the bridge and ip stats
tools.
Rename them reasonably so as not to litter the global namespace.
Signed-off-by: Petr Machata <petrm@nvidia.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Acked-by: Nikolay Aleksandrov <razor@blackwall.org> Signed-off-by: David Ahern <dsahern@kernel.org>
Petr Machata [Tue, 10 Jun 2025 15:51:24 +0000 (17:51 +0200)]
ip: ipstats: Iterate all xstats attributes
ipstats_stat_desc_show_xstats() operates by first parsing the attribute
stream into a type-indexed table, and then accessing the right attribute.
But bridge VLAN stats are given as several BRIDGE_XSTATS_VLAN attributes,
one per VLAN. With the above approach to parsing, only one of these
attributes would be shown. Instead, iterate the stream of attributes and
call the show_cb for each one with a matching type.
Signed-off-by: Petr Machata <petrm@nvidia.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Acked-by: Nikolay Aleksandrov <razor@blackwall.org> Signed-off-by: David Ahern <dsahern@kernel.org>
Commit a043bea75002 ("ip route: add support for TCP usec TS") added
support for tcp_usec_ts but the existing code was not adjusted
to handle multiple features in the same invocation:
$ ip route add .. dev .. features tcp_usec_ts ecn
Error: either "to" is duplicate, or "ecn" is garbage.
The code exits the while loop as soon as it encounters any feature,
make it more flexible. Tested with the following:
$ ip route add .. dev .. features tcp_usec_ts ecn
$ ip route add .. dev .. features tcp_usec_ts ecn quickack 1
Cc: Stephen Hemminger <stephen@networkplumber.org> Fixes: a043bea75002 ("ip route: add support for TCP usec TS") Signed-off-by: Stanislav Fomichev <stfomichev@gmail.com> Signed-off-by: David Ahern <dsahern@kernel.org>
Yuyang Huang [Fri, 23 May 2025 03:25:18 +0000 (12:25 +0900)]
iproute2: bugfix - restore ip monitor backward compatibility.
The current ip monitor implementation fails on older kernels that lack
newer RTNLGRP_* definitions. As ip monitor is expected to maintain
backward compatibility, this commit updates the code to check if errno
is not EINVAL when rtnl_add_nl_group() fails. This change restores ip
monitor's backward compatibility with older kernel versions.
Ido Schimmel [Thu, 8 May 2025 11:13:01 +0000 (14:13 +0300)]
ip ntable: Add support for "mcast_reprobes" parameter
Kernel commit 8da86466b837 ("net: neighbour: Add mcast_resolicit to
configure the number of multicast resolicitations in PROBE state.")
added the "NDTPA_MCAST_REPROBES" netlink attribute that allows user
space to set / get the number of multicast probes that are sent by the
kernel in PROBE state after unicast probes did not solicit a response.
Add support for this parameter in iproute2.
Example usage and output:
$ ip ntable show dev dummy0 name arp_cache
inet arp_cache
dev dummy0
refcnt 1 reachable 43430 base_reachable 30000 retrans 1000
gc_stale 60000 delay_probe 5000 queue 101
app_probes 0 ucast_probes 3 mcast_probes 3 mcast_reprobes 0
anycast_delay 1000 proxy_delay 800 proxy_queue 64 locktime 1000
# ip ntable change name arp_cache dev dummy0 mcast_reprobes 5
$ ip ntable show dev dummy0 name arp_cache
inet arp_cache
dev dummy0
refcnt 1 reachable 43430 base_reachable 30000 retrans 1000
gc_stale 60000 delay_probe 5000 queue 101
app_probes 0 ucast_probes 3 mcast_probes 3 mcast_reprobes 5
anycast_delay 1000 proxy_delay 800 proxy_queue 64 locktime 1000
Joseph Huang [Tue, 15 Apr 2025 14:43:06 +0000 (10:43 -0400)]
iplink_bridge: Add mdb_offload_fail_notification
Add mdb_offload_fail_notification option support.
Signed-off-by: Joseph Huang <Joseph.Huang@garmin.com> Acked-by: Nikolay Aleksandrov <razor@blackwall.org> Signed-off-by: David Ahern <dsahern@kernel.org>
Joseph Huang [Tue, 15 Apr 2025 14:43:05 +0000 (10:43 -0400)]
bridge: mdb: Support offload failed flag
Add support for the MDB_FLAGS_OFFLOAD_FAILED flag to indicate that
an attempt to offload an mdb entry to switchdev has failed.
Signed-off-by: Joseph Huang <Joseph.Huang@garmin.com> Acked-by: Nikolay Aleksandrov <razor@blackwall.org> Signed-off-by: David Ahern <dsahern@kernel.org>
ZiAo Li [Wed, 9 Apr 2025 15:03:30 +0000 (23:03 +0800)]
nstat: NULL Dereference when no entries specified
The NULL Pointer Dereference vulnerability happens in load_ugly_table(), misc/nstat.c, in the latest version of iproute2.
The vulnerability can be triggered by:
1. db is set to NULL at struct nstat_ent *db = NULL;
2. n is set to NULL at n = db;
3. NULL dereference of variable n happens at sscanf(p+1, "%llu", &n->val) != 1
Signed-off-by: ZiAo Li <23110240084@m.fudan.edu.cn> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Ben Hutchings [Wed, 26 Mar 2025 14:08:56 +0000 (15:08 +0100)]
color: Do not use dark blue in dark-background palette
In GNOME Terminal's default dark colour schemes, the default (dark)
blue on a black background is barely readable. Light blue is
significantly more readable to me, and is also easily readable on a
white background.
In Konsole, rxvt, and xterm, I can see little if any difference
between dark and light blue in the default dark colour schemes.
So replace dark blue with light blue in the dark-background palette.
Ben Hutchings [Wed, 26 Mar 2025 14:08:29 +0000 (15:08 +0100)]
color: Assume background is dark if unknown
We rely on the COLORFGBG environment variable to tell us whether the
background is dark. This variable is set by Konsole and rxvt but not
by GNOME Terminal or xterm. This means we use the wrong set of
colours when GNOME Terminal or xterm is configured with a dark
background.
It appears to me that the dark-background colour palette works better
on a light background than vice versa. So it is better to assume a
dark background if we cannot find this out from $COLORFGBG.
- Change the initial value of is_dark_bg to 1.
- In set_color_palette(). conditinally set is_dark_bg to 0 with an
inverted test of the colour.
Ben Hutchings [Wed, 19 Mar 2025 21:51:57 +0000 (22:51 +0100)]
color: Handle NO_COLOR environment variable in default_color_opt()
The NO_COLOR environment variable is a widely supported way for users
to disable coloured text output. See <https://no-color.org/>. In
case iproute2 is configured to use colours by default, allow this to
be overridden by setting NO_COLOR.
This is done in default_color_opt() so that colours can still be
explicitly enabled with a command-line option.
Signed-off-by: Ben Hutchings <benh@debian.org> Signed-off-by: David Ahern <dsahern@kernel.org>
Ben Hutchings [Wed, 19 Mar 2025 21:51:01 +0000 (22:51 +0100)]
color: Introduce and use default_color_opt() function
As a preparatory step for supporting the NO_COLOR environment
variable, replace the direct use of CONF_COLOR with a
default_color_opt() function which initially returns CONF_COLOR.
Signed-off-by: Ben Hutchings <benh@debian.org> Signed-off-by: David Ahern <dsahern@kernel.org>
David Ahern [Mon, 24 Mar 2025 02:47:33 +0000 (02:47 +0000)]
Merge branch 'rdma-optional-counters' into next
Patrisious Haddad says:
====================
Add optional-counters binding support together with new packets/bytes
counters. Previously optional-counters were on a per link basis, this
series allows users to bind optional-counters to a specific counter,
which allows tracking optional-counter over a specific QP group.
The support is added for both binding modes, automatic and manual,
in both cases the bound optional counters are those that are currently
configured over the link when trying to bind the QP.
In addition introduce four new optional-counters :
rdma_tx_bytes, rdma_tx_packets, rdma_rx_bytes, rdma_rx_packets
That just as their name implies allow tracking RDMA egress and ingress
traffic.
This is exposed to users through the iproute2 package which needs to be
updated as well to provide the support for this feature.
Example commands:
- rdma stat set link rocep8s0f0/1 optional-counters
rdma_tx_bytes,rdma_rx_packets
Enables rdma_tx_bytes and rdma_rx_packets optional-counters over
the link.
- rdma stat qp set link rocep8s0f0/1 auto type on optional-counters on
Enabled link automatic counter binding for QPs of same type,
with optional-counter binding support.
- rdma stat qp bind link rocep8s0f0/1 lqpn 134
Manually bind QP number 134 to all available counters.
- rdma stat qp bind link rocep8s0f0/1 lqpn 134 cntn 4
Manually bind QP number 134 to counter number 4 depending on its
configured counters.
Torben Nielsen [Thu, 6 Mar 2025 11:25:19 +0000 (12:25 +0100)]
tc: nat: Fix mask calculation
In parse_nat_args the network mask is calculated as
sel->mask = htonl(~0u << (32 - addr.bitlen));
According to ISO/IEC 9899:TC3 6.5.7 Bitwise shift operators:
The integer promotions are performed on each of the operands.
The type of the result is that of the promoted left operand.
If the value of the right operand is negative or is greater
than or equal to the width of the promoted left operand,
the behavior is undefined
Specifically this means that the mask is undefined for
addr.bitlen = 0
On x86_64 the result is 0xffffffff, on armv7l it is 0.
Promoting the left operand of the shift operator solves this issue.
Signed-off-by: Torben Nielsen <torben.nielsen@prevas.dk> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
ss: mptcp: subflow: display seq counters as decimal
This is similar to commit cfa70237 ("ss: mptcp: display seq related
counters as decimal") but for the subflow info this time. This is also
aligned with what is printed for TCP sockets.
That looks better to do the same with the subflow info (ss -ti), to
compare with the MPTCP info (ss -Mi), or for those who want to easily
count how many bytes have been exchanged between two runs without having
to think in hexa.
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Xin Long [Mon, 10 Mar 2025 14:35:46 +0000 (10:35 -0400)]
man: document tunnel options in ip-route.8.in
Add missing tunnel options [GENEVE_OPTS | VXLAN_OPTS | ERSPAN_OPTS] and
their descriptions to ip-route.8.in.
Additionally, document each parameter of the ip ENCAPHDR section, aligning
it with the style used for other ENCAPHDR descriptions. Most of the
content is adapted from tc-tunnel_key.8 for consistency.
Signed-off-by: Xin Long <lucien.xin@gmail.com> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Ido Schimmel [Tue, 25 Feb 2025 09:09:17 +0000 (11:09 +0200)]
iprule: Add DSCP mask support
Add DSCP mask support, allowing users to specify a DSCP value with an
optional mask. Example:
# ip rule add dscp 1 table 100
# ip rule add dscp 0x02/0x3f table 200
# ip rule add dscp AF42/0x3f table 300
# ip rule add dscp 0x10/0x30 table 400
In non-JSON output, the DSCP mask is not printed in case of exact match
and the DSCP value is printed in hexadecimal format in case of inexact
match:
$ ip rule show
0: from all lookup local
32762: from all lookup 400 dscp 0x10/0x30
32763: from all lookup 300 dscp AF42
32764: from all lookup 200 dscp 2
32765: from all lookup 100 dscp 1
32766: from all lookup main
32767: from all lookup default
Dump can be filtered by DSCP value and mask:
$ ip rule show dscp 1
32765: from all lookup 100 dscp 1
$ ip rule show dscp AF42
32763: from all lookup 300 dscp AF42
$ ip rule show dscp 0x10/0x30
32762: from all lookup 400 dscp 0x10/0x30
In JSON output, the DSCP mask is printed as an hexadecimal string to be
consistent with other masks. The DSCP value is printed as an integer in
order not to break existing scripts:
The mask attribute is only sent to the kernel in case of inexact match
so that iproute2 will continue working with kernels that do not support
the attribute.
Signed-off-by: Ido Schimmel <idosch@nvidia.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Signed-off-by: David Ahern <dsahern@kernel.org>
Ido Schimmel [Tue, 25 Feb 2025 09:09:16 +0000 (11:09 +0200)]
iprule: Add port mask support
Add port mask support, allowing users to specify a source or destination
port with an optional mask. Example:
# ip rule add sport 80 table 100
# ip rule add sport 90/0xffff table 200
# ip rule add dport 1000-2000 table 300
# ip rule add sport 0x123/0xfff table 400
# ip rule add dport 0x4/0xff table 500
# ip rule add dport 0x8/0xf table 600
# ip rule del dport 0x8/0xf table 600
In non-JSON output, the mask is not printed in case of exact match:
$ ip rule show
0: from all lookup local
32761: from all dport 0x4/0xff lookup 500
32762: from all sport 0x123/0xfff lookup 400
32763: from all dport 1000-2000 lookup 300
32764: from all sport 90 lookup 200
32765: from all sport 80 lookup 100
32766: from all lookup main
32767: from all lookup default
Dump can be filtered by port value and mask:
$ ip rule show sport 80
32765: from all sport 80 lookup 100
$ ip rule show sport 90
32764: from all sport 90 lookup 200
$ ip rule show sport 0x123/0x0fff
32762: from all sport 0x123/0xfff lookup 400
$ ip rule show dport 4/0xff
32761: from all dport 0x4/0xff lookup 500
In JSON output, the port mask is printed as an hexadecimal string to be
consistent with other masks. The port value is printed as an integer in
order not to break existing scripts:
$ ip -j -p rule show sport 0x123/0xfff table 400
[ {
"priority": 32762,
"src": "all",
"sport": 291,
"sport_mask": "0xfff",
"table": "400"
} ]
The mask attribute is only sent to the kernel in case of inexact match
so that iproute2 will continue working with kernels that do not support
the attribute.
Signed-off-by: Ido Schimmel <idosch@nvidia.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Signed-off-by: David Ahern <dsahern@kernel.org>
Jonathan Lennox [Wed, 26 Feb 2025 18:53:21 +0000 (18:53 +0000)]
tc: Fix rounding in tc_calc_xmittime and tc_calc_xmitsize.
Currently, tc_calc_xmittime and tc_calc_xmitsize round from double to
int three times — once when they call tc_core_time2tick /
tc_core_tick2time (whose argument is int), once when those functions
return (their return value is int), and then finally when the tc_calc_*
functions return. This leads to extremely granular and inaccurate
conversions.
As a result, for example, on my test system (where tick_in_usec=15.625,
clock_factor=1, and hz=1000000000) for a bitrate of 1Gbps, all tc htb
burst values between 0 and 999 bytes get encoded as 0 ticks; all values
between 1000 and 1999 bytes get encoded as 15 ticks (equivalent to 960
bytes); all values between 2000 and 2999 bytes as 31 ticks (1984 bytes);
etc.
The patch changes the code so these calculations are done internally in
floating-point, and only rounded to integer values when the value is
returned. It also changes tc_calc_xmittime to round its calculated value
up, rather than down, to ensure that the calculated time is actually
sufficient for the requested size.
Signed-off-by: Jonathan Lennox <jonathan.lennox@8x8.com> Signed-off-by: David Ahern <dsahern@kernel.org>
Jordan Rife [Wed, 26 Feb 2025 17:06:13 +0000 (09:06 -0800)]
ip: link: netkit: Support scrub options
Add "scrub" option to configure IFLA_NETKIT_SCRUB and
IFLA_NETKIT_PEER_SCRUB when setting up a link. Add "scrub" and
"peer scrub" to device details as well when printing.
$ sudo ./ip/ip link add jordan type netkit scrub default peer scrub none
$ ./ip/ip -details link show jordan
43: jordan@nk0: <BROADCAST,MULTICAST,NOARP,M-DOWN> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff promiscuity 0 allmulti 0 minmtu 68 maxmtu 65535
netkit mode l3 type primary policy forward peer policy forward scrub default peer scrub none numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 tso_max_size 524280 tso_max_segs 65535 gro_max_size 65536 gso_ipv4_max_size 65536 gro_ipv4_max_size 65536
v2->v3: Updated man page.
v1->v2: Added some spaces around "scrub SCRUB" in the help message.
Michal Koutný [Fri, 21 Feb 2025 09:29:26 +0000 (10:29 +0100)]
ss: Tone down cgroup path resolution
Sockets and cgroups have different lifetimes (e.g. fd passing between
cgroups) so obtaining a cgroup id to a removed cgroup dir is not an
error. Furthermore, the message is printed for each such a socket (which
is redundant each such socket's cgroup is shown as 'unreachable').
Improve user experience by silencing these specific errors.
Anton Moryakov [Mon, 17 Feb 2025 16:21:53 +0000 (19:21 +0300)]
lib: remove redundant checks in get_u64 and get_s64
Static analyzer reported:
1. if (res > 0xFFFFFFFFFFFFFFFFULL)
Expression 'res > 0xFFFFFFFFFFFFFFFFULL' is always false , which may be caused by a logical error:
'res' has a type 'unsigned long long' with minimum value '0' and a maximum value '18446744073709551615'
2. if (res > INT64_MAX || res < INT64_MIN)
Expression 'res > INT64_MAX' is always false , which may be caused by a logical error: 'res' has a type 'long long'
with minimum value '-9223372036854775808' and a maximum value '9223372036854775807'
Expression 'res < INT64_MIN' is always false , which may be caused by a logical error: 'res' has a type 'long long'
with minimum value '-9223372036854775808' and a maximum value '9223372036854775807'
Corrections explained:
- Removed redundant check `res > 0xFFFFFFFFFFFFFFFFULL` in `get_u64`,
as `res` cannot exceed this value due to its type.
- Removed redundant checks `res > INT64_MAX` and `res < INT64_MIN` in `get_s64`,
as `res` cannot exceed the range of `long long`.
Triggers found by static analyzer Svace.
Signed-off-by: Anton Moryakov <ant.v.moryakov@gmail.com> Signed-off-by: David Ahern <dsahern@kernel.org>
Anton Moryakov [Mon, 17 Feb 2025 16:21:52 +0000 (19:21 +0300)]
ip: remove duplicate condition in ila_csum_name2mode in
Static analyzer reported:
expression is identical to previous conditio
Corrections explained:
The condition checking for "neutral-map-auto" was duplicated in the
ila_csum_name2mode function. This commit removes the redundant check
to improve code readability and maintainability.
Triggers found by static analyzer Svace.
Signed-off-by: Anton Moryakov <ant.v.moryakov@gmail.com> Signed-off-by: David Ahern <dsahern@kernel.org>
Anton Moryakov [Mon, 17 Feb 2025 16:21:51 +0000 (19:21 +0300)]
ip: handle NULL return from localtime in strxf_time in
Static analyzer reported:
Pointer 'tp', returned from function 'localtime' at ipxfrm.c:352, may be NULL
and is dereferenced at ipxfrm.c:354 by calling function 'strftime'.
Corrections explained:
The function localtime() may return NULL if the provided time value is
invalid. This commit adds a check for NULL and handles the error case
by copying "invalid-time" into the output buffer.
Unlikely, but may return an error
Triggers found by static analyzer Svace.
Signed-off-by: Anton Moryakov <ant.v.moryakov@gmail.com> Signed-off-by: David Ahern <dsahern@kernel.org>
Anton Moryakov [Mon, 17 Feb 2025 16:21:50 +0000 (19:21 +0300)]
ip: check return value of iproute_flush_cache() in irpoute.c
Static analyzer reported:
Return value of function 'iproute_flush_cache', called at iproute.c:1732,
is not checked. The return value is obtained from function 'open64' and possibly contains an error code.
Corrections explained:
The function iproute_flush_cache() may return an error code, which was
previously ignored. This could lead to unexpected behavior if the cache
flush fails. Added error handling to ensure the function fails gracefully
when iproute_flush_cache() returns an error.
Triggers found by static analyzer Svace.
Signed-off-by: Anton Moryakov <ant.v.moryakov@gmail.com> Signed-off-by: David Ahern <dsahern@kernel.org>
Where 'TCA_STATS_BASIC' carries the combined software and hardware
packets (32-bits) and bytes (64-bit) counters and 'TCA_STATS_BASIC_HW'
carries the hardware statistics.
When the number of packets exceeds 0xffffffff, the kernel emits the
'TCA_STATS_PKT64' attribute:
This layout is not ideal as the only way for user space to know what
each 'TCA_STATS_PKT64' attribute carries is to check which attribute
precedes it, which is exactly what some applications are doing [1].
Do the same in iproute2 so that users with existing kernels could read
the 64-bit hardware packets counter of tc actions instead of reading the
truncated 32-bit counter.
Before:
$ tc -s filter show dev swp2 ingress
filter protocol all pref 1 flower chain 0
filter protocol all pref 1 flower chain 0 handle 0x1
skip_sw
in_hw in_hw_count 1
action order 1: mirred (Egress Redirect to device swp1) stolen
index 1 ref 1 bind 1 installed 47 sec used 23 sec
Action statistics:
Sent 368689092544 bytes 5760767071 pkt (dropped 0, overlimits 0 requeues 0)
Sent software 0 bytes 0 pkt
Sent hardware 368689092544 bytes 1465799775 pkt
backlog 0b 0p requeues 0
used_hw_stats immediate
Petr Machata [Mon, 20 Jan 2025 15:43:06 +0000 (16:43 +0100)]
ip: vxlan: Support IFLA_VXLAN_RESERVED_BITS
A new attribute, IFLA_VXLAN_RESERVED_BITS, was added in Linux kernel
commit 6c11379b104e ("vxlan: Add an attribute to make VXLAN header
validation configurable") (See the link below for the full patchset).
The payload is a 64-bit binary field that covers the VXLAN header. The set
bits indicate which bits in a VXLAN packet header should be allowed to
carry 1's. Support the new attribute through a CLI keyword "reserved_bits".
Yuyang Huang [Fri, 17 Jan 2025 03:20:41 +0000 (12:20 +0900)]
iproute2: add 'ip monitor acaddress' support
Enhanced the 'ip monitor' command to track changes in IPv6
anycast addresses. This update allows the command to listen for
events related to anycast address additions and deletions by
registering to the newly introduced RTNLGRP_IPV6_ACADDR netlink group.
This patch depends on the kernel patch that adds RTNLGRP_IPV6_ACADDR
being merged first.
Here is an example usage:
root@uml-x86-64:/# ip monitor acaddress
2: if2 inet6 any 2001:db8:7b:0:528e:a53a:9224:c9c5 scope global
valid_lft forever preferred_lft forever
Deleted 2: if2 inet6 any 2001:db8:7b:0:528e:a53a:9224:c9c5 scope global
valid_lft forever preferred_lft forever
Cc: Maciej Żenczykowski <maze@google.com> Cc: Lorenzo Colitti <lorenzo@google.com> Signed-off-by: Yuyang Huang <yuyanghuang@google.com> Signed-off-by: David Ahern <dsahern@kernel.org>
Ido Schimmel [Mon, 30 Dec 2024 08:58:10 +0000 (10:58 +0200)]
iprule: Add flow label support
Add support for 'flowlabel' selector in ip-rule.
Rules can be added with or without a mask in which case exact match is
used:
# ip -6 rule add flowlabel 0x12345 table 100
# ip -6 rule add flowlabel 0x11/0xff table 200
# ip -6 rule add flowlabel 0x54321 table 300
# ip -6 rule del flowlabel 0x54321 table 300
Dump output:
$ ip -6 rule show
0: from all lookup local
32764: from all lookup 200 flowlabel 0x11/0xff
32765: from all lookup 100 flowlabel 0x12345
32766: from all lookup main
Dump can be filtered by flow label value and mask:
$ ip -6 rule show flowlabel 0x12345
32765: from all lookup 100 flowlabel 0x12345
$ ip -6 rule show flowlabel 0x11/0xff
32764: from all lookup 200 flowlabel 0x11/0xff
Yuyang Huang [Wed, 11 Dec 2024 08:24:53 +0000 (17:24 +0900)]
iproute2: add 'ip monitor maddress' support
Enhanced the 'ip monitor' command to track changes in IPv4 and IPv6
multicast addresses. This update allows the command to listen for
events related to multicast address additions and deletions by
registering to the newly introduced RTNLGRP_IPV4_MCADDR and
RTNLGRP_IPV6_MCADDR netlink groups.
This patch depends on the kernel patch that adds RTNLGRP_IPV4_MCADDR
and RTNLGRP_IPV6_MCADDR being merged first.
The flower tc parser was using XATTR_SIZE_MAX from linux/limits.h,
but this constant is intended to before extended filesystem attributes
not for TC. Replace it with a local define.
This fixes issue on systems with musl and XATTR_SIZE_MAX is not
defined in limits.h there.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
The recent report of issues with missing limits.h impacting musl
suggested looking at what files are and are not included in ip code.
The standard practice is to put standard headers first, then system,
then local headers. Used iwyu to get suggestions about missing
and extraneous headers.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>