Kernel commit 70e4272b4c81 ("net: bridge: add no_linklocal_learn bool
option") added the no_linklocal_learn bridge option that can be set via
sysfs or netlink.
Add iproute2 support, allowing it to query and set the option via
netlink.
The option is useful, for example, in scenarios where we want the bridge
to be able to refresh dynamic FDB entries that were added by user space
and are pointing to locked bridge ports, but do not want the bridge to
populate its FDB from EAPOL frames used for authentication.
Example:
$ ip -j -d link show dev br0 | jq ".[][\"linkinfo\"][\"info_data\"][\"no_linklocal_learn\"]"
0
$ cat /sys/class/net/br0/bridge/no_linklocal_learn
0
# ip link set dev br0 type bridge no_linklocal_learn 1
$ ip -j -d link show dev br0 | jq ".[][\"linkinfo\"][\"info_data\"][\"no_linklocal_learn\"]"
1
$ cat /sys/class/net/br0/bridge/no_linklocal_learn
1
# ip link set dev br0 type bridge no_linklocal_learn 0
$ ip -j -d link show dev br0 | jq ".[][\"linkinfo\"][\"info_data\"][\"no_linklocal_learn\"]"
0
$ cat /sys/class/net/br0/bridge/no_linklocal_learn
0
Signed-off-by: Ido Schimmel <idosch@nvidia.com>
Signed-off-by: David Ahern <dsahern@kernel.org>
Doing make check on iproute2 runs several checks including man page
checks for common errors. Recent addition of linecard support to
devlink introduced this error.
Checking manpages for syntax errors...
an-old.tmac: <standard input>: line 31: 'R' is a string (producing the registered sign), not a macro.
Error in devlink-lc.8
Fixes: 4cb0bec374 ("devlink: add support for linecard show and type set")
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Currently, when using `ip monitor`, family-specific rtnl multicast groups
(ex. RTNLGRP_IPV4_IFADDR) are used when specifying the '-family' option (or
one of its short forms) and an object type is specified (ex. `ip -4 monitor
addr`) but not when listening for changes to all object types (ex. `ip -4
monitor`). In that case, multicast groups for all families, regardless of
the '-family' option, are used. Depending on the object type, this leads to
ignoring the '-family' selection (MROUTE, ADDR, NETCONF), or printing stray
prefix headers with no event (ROUTE, RULE).
Rewrite the parameter parsing code so that per-family rtnl multicast groups
are selected in all cases.
The issue can be witnessed while running `ip -4 monitor label` at the same
time as the following command:
ip link add dummy0 address 02:00:00:00:00:01 up type dummy
The output includes:
[ROUTE][ROUTE][ADDR]9: dummy0 inet6 fe80::ff:fe00:1/64 scope link
valid_lft forever preferred_lft forever
Notice the stray "[ROUTE]" labels (related to filtered out ipv6 routes) and
the ipv6 ADDR entry. Those do not appear if using `ip -4 monitor label
route address`.
Fixes: aba5acdfdb ("(Logical change 1.3)")
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Signed-off-by: Benjamin Poirier <bpoirier@nvidia.com>
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
It seems that stats were omitted from `ip monitor` and `ip monitor all`.
Since all other event types are included, include stats as well. Use the
same logic as for nexthops.
Fixes: a05a27c07c ("ipmonitor: Add monitoring support for stats events")
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Signed-off-by: Benjamin Poirier <bpoirier@nvidia.com>
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
`ip monitor stats` listens for changes to nexthops and stats. It should
listen for stats only.
Fixes: a05a27c07c ("ipmonitor: Add monitoring support for stats events")
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Signed-off-by: Benjamin Poirier <bpoirier@nvidia.com>
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
When using `bridge monitor` with the '-timestamp' option or the "all"
parameter, prefixes are printed before the actual event descriptions.
Currently, those prefixes are printed for each netlink message that's
received. However, some netlink messages do not lead to an event
description being printed. That's usually because a message is not related
to AF_BRIDGE. This results in stray prefixes being printed.
Restructure accept_msg() and its callees such that prefixes are only
printed after a message has been checked for eligibility.
The issue can be witnessed using the following commands:
ip link add dummy0 type dummy
# Start `bridge monitor all` now in another terminal.
# Cause a stray "[LINK]" to be printed (family 10).
# It does not appear yet because the output is line buffered.
ip link set dev dummy0 up
# Cause a stray "[NEIGH]" to be printed (family 2).
ip neigh add 10.0.0.1 lladdr 02:00:00:00:00:01 dev dummy0
# Cause a genuine entry to be printed, which flushes the previous
# output.
bridge fdb add 02:00:00:00:00:01 dev dummy0
# We now see:
# [LINK][NEIGH][NEIGH]02:00:00:00:00:01 dev dummy0 self permanent
Fixes: d04bc300c3 ("Add bridge command")
Signed-off-by: Benjamin Poirier <bpoirier@nvidia.com>
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Add a new function rtnl_echo_talk() that could be used when the
sub-component supports NLM_F_ECHO flag. With this function we can
remove the redundant code added by commit b264b4c656 ("ip: add
NLM_F_ECHO support").
Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
Signed-off-by: David Ahern <dsahern@kernel.org>
Similar to other bool opts that could be set by the user, move the
global variable use_iec to be part of struct dl.
Signed-off-by: Jiri Pirko <jiri@nvidia.com>
Signed-off-by: David Ahern <dsahern@kernel.org>
Upstream commit "sched: add extack for tfilter_notify" will make
tc event contain extack message, which could be used for logging
offloading failures. Let's print the extack message in tc monitor.
e.g.
# tc monitor
added chain dev enp3s0f1np1 parent ffff: chain 0
added filter dev enp3s0f1np1 ingress protocol all pref 49152 flower chain 0 handle 0x1
ct_state +trk+new
not_in_hw
action order 1: gact action drop
random type none pass val 0
index 1 ref 1 bind 1
Warning: mlx5_core: matching on ct_state +new isn't supported.
Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
Signed-off-by: David Ahern <dsahern@kernel.org>
There is no rule to have an error code after NLMSG_DONE msg. The only reason
we has this offset is that kernel function netlink_dump_done() has an error
code followed by the netlink message header.
Making nl_dump_ext_ack_done() has an offset parameter. So we can adjust
this for NLMSG_DONE message without error code.
Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
Signed-off-by: David Ahern <dsahern@kernel.org>
Support the "dsa" kind of rtnl_link_ops exported by the kernel, and
export reads/writes to IFLA_DSA_MASTER.
Examples:
$ ip link set swp0 type dsa conduit eth1
$ ip -d link show dev swp0
(...)
dsa conduit eth0
$ ip -d -j link show swp0
[
{
"link": "eth1",
"linkinfo": {
"info_kind": "dsa",
"info_data": {
"conduit": "eth1"
}
},
}
]
Note that by construction and as shown in the example, the IFLA_LINK
reported by a DSA user port is identical to what is reported through
IFLA_DSA_MASTER. However IFLA_LINK is not writable, and overloading its
meaning to make it writable would clash with other users of IFLA_LINK
(vlan etc) for which writing this property does not make sense.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: David Ahern <dsahern@kernel.org>
This counter is based on the same principle that the 'promiscuity' counter:
the flag ALLMULTI is displayed only when it is explicitly requested by the
userland. This counter enables to know if 'allmulti' is configured on an
interface.
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Signed-off-by: David Ahern <dsahern@kernel.org>
When user space configures the kernel with netlink messages, it can set the
NLM_F_ECHO flag to request the kernel to send the applied configuration back
to the caller. This allows user space to retrieve configuration information
that are filled by the kernel (either because these parameters can only be
set by the kernel or because user space let the kernel choose a default
value).
NLM_F_ACK is also supplied incase the kernel doesn't support NLM_F_ECHO
and we will wait for the reply forever. Just like the update in
iplink.c, which I plan to post a patch to kernel later.
A new parameter -echo is added when user want to get feedback from kernel.
e.g.
# ip -echo addr add 192.168.0.1/24 dev eth1
3: eth1 inet 192.168.0.1/24 scope global eth1
valid_lft forever preferred_lft forever
# ip -j -p -echo addr del 192.168.0.1/24 dev eth1
[ {
"deleted": true,
"index": 3,
"dev": "eth1",
"family": "inet",
"local": "192.168.0.1",
"prefixlen": 24,
"scope": "global",
"label": "eth1",
"valid_life_time": 4294967295,
"preferred_life_time": 4294967295
} ]
Suggested-by: Guillaume Nault <gnault@redhat.com>
Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
Signed-off-by: David Ahern <dsahern@kernel.org>
As described in RFC 8986 [1], processing operations carried out by SRv6
End, End.X and End.T (End* for short) behaviors can be modified or
extended using the "flavors" mechanism. This patch adds the support for
PSP,USP,USD flavors (defined in [1]) and for NEXT-C-SID flavor (defined
in [2]) in SRv6 End* behaviors. Specifically, we add a new optional
attribute named "flavors" that can be leveraged by the user to enable
specific flavors while creating an SRv6 End* behavior instance.
Multiple flavors can be specified together by separating them using
commas.
If a specific flavor (or a combination of flavors) is not supported by the
underlying Linux kernel, an error message is reported to the user and the
creation of the specific behavior instance is aborted.
When the flavors attribute is omitted, the regular SRv6 End* behavior is
performed.
Flavors such as PSP, USP and USD do not accept additional configuration
attributes. Conversely, the NEXT-C-SID flavor can be configured to support
user-provided Locator-Block and Locator-Node Function lengths using,
respectively, the lblen and the nflen attributes.
Both lblen and nflen values must be evenly divisible by 8 and their sum
must not exceed 128 bit (i.e. the C-SID container size).
If the lblen attribute is omitted, the default value chosen by the Linux
kernel is 32-bit. If the nflen attribute is omitted, the default value
chosen by the Linux kernel is 16-bit.
Some examples:
ip -6 route add 2001:db8::1 encap seg6local action End flavors next-csid dev eth0
ip -6 route add 2001:db8::2 encap seg6local action End flavors next-csid lblen 48 nflen 16 dev eth0
Standard Output:
ip -6 route show 2001:db8::2
2001:db8::2 encap seg6local action End flavors next-csid lblen 48 nflen 16 dev eth0 metric 1024 pref medium
JSON Output:
ip -6 -j -p route show 2001:db8::2
[ {
"dst": "2001:db8::2",
"encap": "seg6local",
"action": "End",
"flavors": [ "next-csid" ],
"lblen": 48,
"nflen": 16,
"dev": "eth0",
"metric": 1024,
"flags": [ ],
"pref": "medium"
} ]
[1] - https://datatracker.ietf.org/doc/html/rfc8986
[2] - https://datatracker.ietf.org/doc/html/draft-ietf-spring-srv6-srh-compression
Signed-off-by: Paolo Lungaroni <paolo.lungaroni@uniroma2.it>
Signed-off-by: David Ahern <dsahern@kernel.org>
Update the user manual describing how to use extended packet number (XPN)
feature for macsec. As part of configuring XPN, providing ssci and salt is
required hence update user manual on how to provide the above as part of
the ip macsec command.
Signed-off-by: Emeel Hakim <ehakim@nvidia.com>
Reviewed-by: Sabrina Dubroca <sd@queasysnail.net>
Signed-off-by: David Ahern <dsahern@kernel.org>
This patch adds support for extended packet number (XPN).
XPN can be configured by passing 'cipher gcm-aes-xpn-128' as part of
the ip link add command using macsec type.
In addition, using 'xpn' keyword instead of the 'pn', passing a 12
bytes salt using the 'salt' keyword and passing short secure channel
id (ssci) using the 'ssci' keyword as part of the ip macsec command
is required (see example).
e.g:
create a MACsec device on link eth0 with enabled xpn
# ip link add link eth0 macsec0 type macsec port 11
encrypt on cipher gcm-aes-xpn-128
configure a secure association on the device
# ip macsec add macsec0 tx sa 0 xpn 1024 on ssci 5
salt 838383838383838383838383
key 01 81818181818181818181818181818181
configure a secure association on the device with ssci = 5
# ip macsec add macsec0 tx sa 0 xpn 1024 on ssci 5
salt 838383838383838383838383
key 01 82828282828282828282828282828282
Signed-off-by: Emeel Hakim <ehakim@nvidia.com>
Reviewed-by: Sabrina Dubroca <sd@queasysnail.net>
Signed-off-by: David Ahern <dsahern@kernel.org>
Some driver provide no region snapshot unless created first with the
'new' operation. Add documentation and example.
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
mnlu_gen_socket_open opens a socket and configures it for use with a
generic netlink family. As part of this process it sends a
CTRL_CMD_GETFAMILY to get the ID for the family name requested.
In addition to the family id, this command reports a few other useful
values including the maximum attribute. The maximum attribute is useful in
order to know whether a given attribute is supported and for knowing the
necessary size to allocate for other operations such as policy dumping.
Since we already have to issue a CTRL_CMD_GETFAMILY to get the id, we can
also store the maximum attribute as well. Modify the callback functions to
parse the maximum attribute NLA and store it in the mnlu_gen_socket
structure.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Signed-off-by: David Ahern <dsahern@kernel.org>
Commit 62ff25e51b ("devlink: Use generic socket helpers from library")
removed all of the users of struct mnlg_socket, but didn't remove the
structure itself. Fix that.
Fixes: 62ff25e51b ("devlink: Use generic socket helpers from library")
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Signed-off-by: David Ahern <dsahern@kernel.org>
Now that it is possible to flash multiple devlink instances in parallel,
the notification processing callback needs to count in the fact that it
receives message that belongs to different devlink instance. So handle
the it gracefully and don't error out.
Reported-by: Vikas Gupta <vikas.gupta@broadcom.com>
Signed-off-by: Jiri Pirko <jiri@nvidia.com>
Signed-off-by: David Ahern <dsahern@kernel.org>
So far, the port-ifname map was loaded during devlink init
no matter if actually needed or not. Port dump cmd which is utilized
for this in kernel takes lock for every devlink instance.
That may lead to unnecessary blockage of command.
Load the map only in time it is needed to lookup ifname.
Signed-off-by: Jiri Pirko <jiri@nvidia.com>
Signed-off-by: David Ahern <dsahern@kernel.org>
Jacob Keller says:
====================
This series removes the dl_argv_parse_put function which both parses the
command line arguments and places them into the netlink header.
This was originally sent as an RFC at
https://lore.kernel.org/netdev/20220805234155.2878160-1-jacob.e.keller@intel.com/
Since there is some ongoing work around policy code being generated from
YAML, I thought it best to wait on the devlink policy portion of this series
for now.
Jiri mentioned he wanted to base some work on top of this, so I am sending
just the cleanup patches.
The primary motivation for this is due to the fact that dl_argv_parse_put
requires a netlink header, meaning a command must have already been
prepared. This prevents addition of a different netlink command to get the
policy data, and thus prevents us from using this variant while checking
netlink policy.
====================
Signed-off-by: David Ahern <dsahern@kernel.org>
The dl_argv_parse_put function is used to extract arguments from the
command line and convert them to the appropriate netlink attributes. This
function is a combination of calling dl_argv_parse and dl_put_opts.
A future change is going to refactor dl_argv_parse to check the kernel's
netlink policy for the command. This requires issuing another netlink
message which requires calling dl_argv_parse before
mnlu_gen_socket_cmd_prepare. Otherwise, the get policy command issued in
dl_argv_parse would overwrite the prepared buffer.
This conflicts with dl_argv_parse_put which requires being called after
mnlu_gen_socket_cmd_prepare.
Remove dl_argv_parse_put and replace it with appropriate calls to
dl_argv_parse and dl_put_opts. This allows us to ensure dl_argv_parse is
called before mnlu_gen_socket_cmd_prepare while dl_put_opts is called
afterwards.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Reviewed-by: Jiri Pirko <jiri@nvidia.com>
Signed-off-by: David Ahern <dsahern@kernel.org>
Use the helper dl_no_arg function to check for whether the command has any
arguments.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Reviewed-by: Jiri Pirko <jiri@nvidia.com>
Signed-off-by: David Ahern <dsahern@kernel.org>
These are the post-merge of netwoking user headers.
Note: this fixes compilation with gcc-12
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
The final vdpa.h header from upstream has slightly different
definition of VDPA stats get.
Fixes: 6f97e9c933 ("vdpa: Add support for reading vdpa device statistics")
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
If line card object contains a nested devlink, expose it.
Example:
$ devlink lc show pci/0000:01:00.0 lc 1
pci/0000:01:00.0:
lc 1 state active type 16x100G nested_devlink auxiliary/mlxsw_core.lc.0
supported_types:
16x100G
$ devlink dev show auxiliary/mlxsw_core.lc.0
auxiliary/mlxsw_core.lc.0
Signed-off-by: Jiri Pirko <jiri@nvidia.com>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Signed-off-by: David Ahern <dsahern@kernel.org>
glibc defines this function only as gnu extention
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Add commands and helper APIs to run selftests.
Include a selftest id for a non volatile memory i.e. flash.
Also, update the man page and bash-completion for selftests
commands.
Examples:
$ devlink dev selftests run pci/0000:03:00.0 id flash
pci/0000:03:00.0:
flash:
status passed
$ devlink dev selftests show pci/0000:03:00.0
pci/0000:03:00.0
flash
$ devlink dev selftests show pci/0000:03:00.0 -j
{"selftests":{"pci/0000:03:00.0":["flash"]}}
$ devlink dev selftests run pci/0000:03:00.0 id flash -j
{"selftests":{"pci/0000:03:00.0":{"flash":{"status":"passed"}}}}
Signed-off-by: Vikas Gupta <vikas.gupta@broadcom.com>
Reviewed-by: Jiri Pirko <jiri@nvidia.com>
Signed-off-by: David Ahern <dsahern@kernel.org>
This patch adds the support for the reduced version of the H.Encaps and
H.L2Encaps behaviors as defined in RFC 8986 [1].
H.Encaps.Red and H.L2Encaps.Red SRv6 behaviors are an optimization of the
H.Encaps and H.L2Encaps aiming to reduce the length of the SID List carried
in the pushed SRH. Specifically, the reduced version of the behaviors
removes the first SID contained in the SID List (i.e. SRv6 Policy) by
storing it into the IPv6 Destination Address. When SRv6 Policy is made of
only one SID, the reduced version of the behaviors omits the SRH at all and
pushes that SID directly into the IPv6 DA.
Some examples:
ip -6 route add 2001:db8::1 encap seg6 mode encap.red segs fcf0:1::e,fcf0:2::d6 dev eth0
ip -6 route add 2001:db8::2 encap seg6 mode l2encap.red segs fcf0:1::d2 dev eth0
Standard Output:
ip -6 route show 2001:db8::1
2001:db8::1 encap seg6 mode encap.red segs 2 [ fcf0:1::e fcf0:2::d6 ] dev eth0 metric 1024 pref medium
JSON Output:
ip -6 -j -p route show 2001:db8::1
[ {
"dst": "2001:db8::1",
"encap": "seg6",
"mode": "encap.red",
"segs": [ "fcf0:1::e","fcf0:2::d6" ],
"dev": "eth0",
"metric": 1024,
"flags": [ ],
"pref": "medium"
} ]
[1] - https://datatracker.ietf.org/doc/html/rfc8986
Signed-off-by: Paolo Lungaroni <paolo.lungaroni@uniroma2.it>
Signed-off-by: David Ahern <dsahern@kernel.org>
Update kernel headers to commit
63757225a933 ("Merge tag 'mlx5-updates-2022-07-28' of git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux")
Signed-off-by: David Ahern <dsahern@kernel.org>
Wojciech Drewek says:
====================
This patchset implements support for matching
on PPPoE specific fields using tc-flower.
First patch introduces small refactor which allows
to use same mechanism of finding protocol for
both ppp and ether protocols. Second patch
adds support for parsing ppp protocols.
Last patch is about parsing PPPoE fields.
Kernel changes (merged):
https://lore.kernel.org/netdev/20220726203133.2171332-1-anthony.l.nguyen@intel.com/T/#t
====================
Signed-off-by: David Ahern <dsahern@kernel.org>
Introduce PPPoE specific fields in tc-flower:
- session id (16 bits)
- ppp protocol (16 bits)
Those fields can be provided only when protocol was set to
ETH_P_PPP_SES. ppp_proto works similar to vlan_ethtype, i.e.
ppp_proto overwrites eth_type. Thanks to that, fields from
encapsulated protocols (such as src_ip) can be specified.
e.g.
# tc filter add dev ens6f0 ingress prio 1 protocol ppp_ses \
flower \
pppoe_sid 1234 \
ppp_proto ip \
dst_ip 127.0.0.1 \
src_ip 127.0.0.2 \
action drop
Vlan and cvlan is also supported, in this case cvlan_ethtype
or vlan_ethtype has to be set to ETH_P_PPP_SES.
e.g.
# tc filter add dev ens6f0 ingress prio 1 protocol 802.1Q \
flower \
vlan_id 2 \
vlan_ethtype ppp_ses \
pppoe_sid 1234 \
ppp_proto ip \
dst_ip 127.0.0.1 \
src_ip 127.0.0.2 \
action drop
Signed-off-by: Wojciech Drewek <wojciech.drewek@intel.com>
Acked-by: Guillaume Nault <gnault@redhat.com>
Signed-off-by: David Ahern <dsahern@kernel.org>
PPP protocol field uses different values than ethertype. Introduce
utilities for translating PPP protocols from strings to values
and vice versa. Use generic API from utils in order to get
proto id and name.
Signed-off-by: Wojciech Drewek <wojciech.drewek@intel.com>
Acked-by: Guillaume Nault <gnault@redhat.com>
Signed-off-by: David Ahern <dsahern@kernel.org>
