Currently, the output of "tc qdisc add dev lo taprio help" looks
absolutely horrible, it looks better in the source code. Put new lines
in the output everywhere where the text switches to a new line in the
source code.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
tc-taprio(8) has a synopsis which is much easier to follow, because it
breaks up the command line arguments on multiple lines. Do this in
tc-mqprio(8) too.
Also, the highlighting (bold) of the keywords is all wrong. Take the
opportunity to fix that.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
It is confusing and easy to get lost in the soup of brackets when trying
to explain that min_rate and max_rate are only accepted as optional
arguments when "shaper" takes the value "bw_rlimit".
Before (synopsis):
[ shaper dcb| [ bw_rlimit min_rate min_rate1 min_rate2 ... max_rate max_rate1 max_rate2 ... ]]
After (synopsis):
[ shaper dcb|bw_rlimit ] [ min_rate min_rate1 min_rate2 ... ] [ max_rate max_rate1 max_rate2 ... ]
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
The closing ] bracket doesn't close anything, it is extraneous.
Remove it.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Since kernel commit a3d91b2c6f6b ("net/sched: taprio: warn about missing
size table"), the kernel emits a warning netlink extack if the user
doesn't specify a stab. We want the user be aware of the fact that the
L1 overhead is determined by taprio exactly based on the overhead of the
stab, so we want to encourage users to add a size table to the Qdisc.
Teach them how.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Although the max-sdu argument is documented in the PARAMETERS section,
it is absent from the SYNOPSIS. Add it there too.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Update kernel headers to commit:
fbc1449d385d ("Merge tag 'mlx5-updates-2023-04-20' of git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux")
Signed-off-by: David Ahern <dsahern@kernel.org>
'ip link set foo netns /proc/1/ns/net' is a valid command.
Let's update the doc accordingly.
Fixes: 0dc34c7713 ("iproute2: Add processless network namespace support")
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Reviewed-by: Simon Horman <simon.horman@corigine.com>
Reviewed-by: David Marchand <david.marchand@redhat.com>
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Use NETNSNAME everywhere to ensure consistency between man pages and help
of the 'ip' command.
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Reviewed-by: Simon Horman <simon.horman@corigine.com>
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Avoid assuming that segbuf is 1024 bytes. Use sizeof() in
places where it is being updated.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
The code for parsing segments in lwtunnel would trigger a warning
about strncpy if address sanitizer was enabled. Simpler to just
use strlcpy() like elsewhere.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
The same tag "dst" was being used for both the route destination
and the encap destination. This made it hard for JSON parsers.
Change to put the per-encap information under a nested JSON
object (similar to ip link type info).
Original output
[ {
"dst": "192.168.11.0/24",
"encap": "ip6",
"id": 0,
"src": "::",
"dst": "fd00::c0a8:2dd",
"hoplimit": 0,
"tc": 0,
"protocol": "5",
"scope": "link",
"flags": [ ]
} ]
Revised output
[ {
"dst": "192.168.11.0/24",
"encap": {
"encap_type": "ip6",
"id": 0,
"src": "::",
"dst": "fd00::c0a8:2dd",
"hoplimit": 0,
"tc": 0
},
"protocol": "5",
"scope": "link",
"flags": [ ]
} ]
Reported-by: Lars Ekman <uablrek@gmail.com>
Fixes: 663c3cb231 ("iproute: implement JSON and color output")
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
The tunnel encap type is passed as unsigned 16 bit value
in/out of kernel. Keep it unsigned in the encode/decode
logic.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
If attempt is made to change an IPv6 tunnel by using IPv4
parameters, a stack overflow would happen and garbage request
would be passed to kernel.
Example:
ip tunnel add gre1 mode ip6gre local 2001:db8::1 remote 2001:db8::2 ttl 255
ip tunnel change gre1 mode gre local 192.168.0.0 remote 192.168.0.1 ttl 255
The second command should fail because it attempting set IPv4 addresses
on a GRE tunnel that is IPv6.
Do best effort detection of this mismatch by giving a bigger buffer to get
tunnel request, and checking that the IP header is IPv4. It is still possible
but unlikely that byte would match in IPv6 tunnel paramater, but good enough
to catch the obvious cases.
Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1032642
Tested-by: Luca Boccassi <bluca@debian.org>
Reported-by: Robin <imer@imer.cc>
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
add control plane for setting TCA_TUNNEL_KEY_NO_FRAG flag on
act_tunnel_key actions.
Signed-off-by: Davide Caratti <dcaratti@redhat.com>
Reviewed-by: Simon Horman <simon.horman@corigine.com>
Signed-off-by: David Ahern <dsahern@kernel.org>
The help text claims that setdefault takes ACTION values, ie block |
allow. In reality, xfrm_str_to_policy takes block | accept.
We could also fix that by changing the help text/manpage, but then
it'd be frustrating to have multiple ACTION with similar values used
in different subcommands.
I'm not changing the output in xfrm_policy_to_str because some
userspace somewhere probably depends on the "accept" value.
Fixes: 76b30805f9 ("xfrm: enable to manage default policies")
Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
Acked-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Petr Machata says:
====================
IPv4 and IPv6 addresses can be assigned a protocol value that indicates the
provenance of the IP address. The attribute is modeled after ip route
protocols, and essentially allows the administrator or userspace stack to
tag addresses in some way that makes sense to the actor in question.
Support for this feature was merged with commit 47f0bd503210 ("net: Add new
protocol attribute to IP addresses"), for kernel 5.18.
In this patchset, add support for setting the protocol attribute at IP
address addition, replacement, and listing requests.
====================
Signed-off-by: David Ahern <dsahern@kernel.org>
IPv4 and IPv6 addresses can be assigned a protocol value that indicates the
provenance of the IP address. The attribute is modeled after ip route
protocols, and essentially allows the administrator or userspace stack to
tag addresses in some way that makes sense to the actor in question.
Support for this feature was merged with commit 47f0bd503210 ("net: Add new
protocol attribute to IP addresses"), for kernel 5.18.
In this patch, add support for setting the protocol attribute at IP address
addition, replacement, and listing requests.
An example session with the feature in action:
# ip address add dev d 192.0.2.1/28 proto 0xab
# ip address show dev d
26: d: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether 06:29:74:fd:1f:eb brd ff:ff:ff:ff:ff:ff
inet 192.0.2.1/28 scope global proto 0xab d
valid_lft forever preferred_lft forever
# ip address replace dev d 192.0.2.1/28 proto 0x11
# ip address show dev d
26: d: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether 06:29:74:fd:1f:eb brd ff:ff:ff:ff:ff:ff
inet 192.0.2.1/28 scope global proto 0x11 d
valid_lft forever preferred_lft forever
A JSON dump. The protocol value is always provided as a string, even in
numeric mode, to provide a consistent interface.
# ip -j address show dev d | jq
[
{
"ifindex": 26,
"ifname": "d",
"flags": [
"BROADCAST",
"NOARP"
],
"mtu": 1500,
"qdisc": "noop",
"operstate": "DOWN",
"group": "default",
"txqlen": 1000,
"link_type": "ether",
"address": "06:29:74:fd:1f:eb",
"broadcast": "ff:ff:ff:ff:ff:ff",
"addr_info": [
{
"family": "inet",
"local": "192.0.2.1",
"prefixlen": 28,
"scope": "global",
"protocol": "0x11",
"label": "d",
"valid_life_time": 4294967295,
"preferred_life_time": 4294967295
}
]
}
]
Signed-off-by: Petr Machata <petrm@nvidia.com>
Signed-off-by: David Ahern <dsahern@kernel.org>
This patch adds support for setting the broadcast queueing threshold
on macvlan devices. This controls which multicast packets will be
processed in a workqueue instead of inline.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
ip/iplink_macvlan.c | 26 ++++++++++++++++++++++++--
man/man8/ip-link.8.in | 18 ++++++++++++++++++
3 files changed, 43 insertions(+), 2 deletions(-)
Signed-off-by: David Ahern <dsahern@kernel.org>
Ido Schimmel says:
====================
Add support for new VXLAN MDB attributes.
See kernel merge commit abf36703d704 ("Merge branch
'vxlan-MDB-support'") for background and motivation.
====================
Signed-off-by: David Ahern <dsahern@kernel.org>
Document the catchall MDB entries used to transmit IPv4 and IPv6
unregistered multicast packets.
In deployments where inter-subnet multicast forwarding is used, not all
the VTEPs in a tenant domain are members in all the broadcast domains.
It is therefore advantageous to transmit BULL (broadcast, unknown
unicast and link-local multicast) and unregistered IP multicast traffic
on different tunnels. If the same tunnel was used, a VTEP only
interested in IP multicast traffic would also pull all the BULL traffic
and drop it as it is not a member in the originating broadcast domain
[1].
[1] https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-irb-mcast#section-2.6
Signed-off-by: Ido Schimmel <idosch@nvidia.com>
Reviewed-by: Nikolay Aleksandrov <razor@blackwall.org>
In a similar fashion to VXLAN FDB entries, allow user space to program
and view the outgoing interface of VXLAN MDB entries. Specifically, add
support for the 'MDBE_ATTR_IFINDEX' and 'MDBA_MDB_EATTR_IFINDEX'
attributes in request and response messages, respectively.
The outgoing interface will be forced during the underlay route lookup
and is required when the underlay destination IP is multicast, as the
multicast routing tables are not consulted.
Example:
# bridge mdb add dev vxlan0 port vxlan0 grp 239.1.1.1 permanent dst 198.51.100.1 via dummy10
$ bridge -d -s mdb show
dev vxlan0 port vxlan0 grp 239.1.1.1 permanent filter_mode exclude proto static dst 198.51.100.1 via dummy10 0.00
$ bridge -d -s -j -p mdb show
[ {
"mdb": [ {
"index": 10,
"dev": "vxlan0",
"port": "vxlan0",
"grp": "239.1.1.1",
"state": "permanent",
"filter_mode": "exclude",
"protocol": "static",
"flags": [ ],
"dst": "198.51.100.1",
"via": "dummy10",
"timer": " 0.00"
} ],
"router": {}
} ]
Signed-off-by: Ido Schimmel <idosch@nvidia.com>
Reviewed-by: Nikolay Aleksandrov <razor@blackwall.org>
In a similar fashion to VXLAN FDB entries, allow user space to program
and view the source VNI of VXLAN MDB entries. Specifically, add support
for the 'MDBE_ATTR_SRC_VNI' and 'MDBA_MDB_EATTR_SRC_VNI' attributes in
request and response messages, respectively.
The source VNI is only relevant when the VXLAN device is in external
mode, where multiple VNIs can be multiplexed over a single VXLAN device.
Example:
# bridge mdb add dev vxlan0 port vxlan0 grp 239.1.1.1 permanent dst 198.51.100.1 src_vni 2222
$ bridge -d -s mdb show
dev vxlan0 port vxlan0 grp 239.1.1.1 permanent filter_mode exclude proto static dst 198.51.100.1 src_vni 2222 0.00
$ bridge -d -s -j -p mdb show
[ {
"mdb": [ {
"index": 16,
"dev": "vxlan0",
"port": "vxlan0",
"grp": "239.1.1.1",
"state": "permanent",
"filter_mode": "exclude",
"protocol": "static",
"flags": [ ],
"dst": "198.51.100.1",
"src_vni": 2222,
"timer": " 0.00"
} ],
"router": {}
} ]
Signed-off-by: Ido Schimmel <idosch@nvidia.com>
Reviewed-by: Nikolay Aleksandrov <razor@blackwall.org>
In a similar fashion to VXLAN FDB entries, allow user space to program
and view the destination VNI of VXLAN MDB entries. Specifically, add
support for the 'MDBE_ATTR_VNI' and 'MDBA_MDB_EATTR_VNI' attributes in
request and response messages, respectively.
This is useful when ingress replication (IR) is used and the destination
VXLAN tunnel endpoint (VTEP) is not a member of the source broadcast
domain (BD). In this case, the ingress VTEP should transmit the packet
using the VNI of the Supplementary Broadcast Domain (SBD) in which all
the VTEPs are member of [1].
Example:
# bridge mdb add dev vxlan0 port vxlan0 grp 239.1.1.1 permanent dst 198.51.100.1 vni 1111
$ bridge -d -s mdb show
dev vxlan0 port vxlan0 grp 239.1.1.1 permanent filter_mode exclude proto static dst 198.51.100.1 vni 1111 0.00
$ bridge -d -s -j -p mdb show
[ {
"mdb": [ {
"index": 15,
"dev": "vxlan0",
"port": "vxlan0",
"grp": "239.1.1.1",
"state": "permanent",
"filter_mode": "exclude",
"protocol": "static",
"flags": [ ],
"dst": "198.51.100.1",
"vni": 1111,
"timer": " 0.00"
} ],
"router": {}
} ]
[1] https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-irb-mcast#section-3.2.2
Signed-off-by: Ido Schimmel <idosch@nvidia.com>
Reviewed-by: Nikolay Aleksandrov <razor@blackwall.org>
In a similar fashion to VXLAN FDB entries, allow user space to program
and view the UDP destination port of VXLAN MDB entries. Specifically,
add support for the 'MDBE_ATTR_DST_PORT' and 'MDBA_MDB_EATTR_DST_PORT'
attributes in request and response messages, respectively.
Use the keyword "dst_port" instead of "port" as the latter is already
used to specify the net device associated with the MDB entry.
Example:
# bridge mdb add dev vxlan0 port vxlan0 grp 239.1.1.1 permanent dst 198.51.100.1 dst_port 1234
$ bridge -d -s mdb show
dev vxlan0 port vxlan0 grp 239.1.1.1 permanent filter_mode exclude proto static dst 198.51.100.1 dst_port 1234 0.00
$ bridge -d -s -j -p mdb show
[ {
"mdb": [ {
"index": 15,
"dev": "vxlan0",
"port": "vxlan0",
"grp": "239.1.1.1",
"state": "permanent",
"filter_mode": "exclude",
"protocol": "static",
"flags": [ ],
"dst": "198.51.100.1",
"dst_port": 1234,
"timer": " 0.00"
} ],
"router": {}
} ]
Signed-off-by: Ido Schimmel <idosch@nvidia.com>
Reviewed-by: Nikolay Aleksandrov <razor@blackwall.org>
Update kernel headers to commit:
fcb3a4653bc5 ("net/sched: act_api: use the correct TCA_ACT attributes in dump")
Signed-off-by: David Ahern <dsahern@kernel.org>
We can't use TCA_EXT_WARN_MSG directly in tc action as it's using different
enum with filter. Let's use a new TCA_ROOT_EXT_WARN_MSG for tc action
specifically.
Fixes: 6035995665 ("tc: add new attr TCA_EXT_WARN_MSG")
Reviewed-by: Andrea Claudi <aclaudi@redhat.com>
Reported-and-tested-by: Davide Caratti <dcaratti@redhat.com>
Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
This reverts commit 70b9ebae63.
The TCA_EXT_WARN_MSG is not sit within the TCA_ACT_TAB hierarchy. It's
belong to the TCA_MAX namespace. I will fix the issue in another patch.
Reviewed-by: Andrea Claudi <aclaudi@redhat.com>
Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Cleanup and rewrite netem man page.
Incorporate the examples from the old LF netem wiki
so that it can be removed/deprecated.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
'action nat index 1' is a valid cli according to TC's
architecture. Fix the grammar parsing to accept it.
tdc tests:
1..28
ok 1 7565 - Add nat action on ingress with default control action
ok 2 fd79 - Add nat action on ingress with pipe control action
ok 3 eab9 - Add nat action on ingress with continue control action
ok 4 c53a - Add nat action on ingress with reclassify control action
ok 5 76c9 - Add nat action on ingress with jump control action
ok 6 24c6 - Add nat action on ingress with drop control action
ok 7 2120 - Add nat action on ingress with maximum index value
ok 8 3e9d - Add nat action on ingress with invalid index value
ok 9 f6c9 - Add nat action on ingress with invalid IP address
ok 10 be25 - Add nat action on ingress with invalid argument
ok 11 a7bd - Add nat action on ingress with DEFAULT IP address
ok 12 ee1e - Add nat action on ingress with ANY IP address
ok 13 1de8 - Add nat action on ingress with ALL IP address
ok 14 8dba - Add nat action on egress with default control action
ok 15 19a7 - Add nat action on egress with pipe control action
ok 16 f1d9 - Add nat action on egress with continue control action
ok 17 6d4a - Add nat action on egress with reclassify control action
ok 18 b313 - Add nat action on egress with jump control action
ok 19 d9fc - Add nat action on egress with drop control action
ok 20 a895 - Add nat action on egress with DEFAULT IP address
ok 21 2572 - Add nat action on egress with ANY IP address
ok 22 37f3 - Add nat action on egress with ALL IP address
ok 23 6054 - Add nat action on egress with cookie
ok 24 79d6 - Add nat action on ingress with cookie
ok 25 4b12 - Replace nat action with invalid goto chain control
ok 26 b811 - Delete nat action with valid index
ok 27 a521 - Delete nat action with invalid index
ok 28 2c81 - Reference nat action object in filter
Fixes: fc2d02069b ("Add NAT action")
Reviewed-by: Jamal Hadi Salim <jhs@mojatatu.com>
Signed-off-by: Pedro Tammela <pctammela@mojatatu.com>
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
'action mpls index 1' is a valid cli according to TC's
architecture. Fix the grammar parsing to accept it.
tdc tests:
1..54
ok 1 a933 - Add MPLS dec_ttl action with pipe opcode
ok 2 08d1 - Add mpls dec_ttl action with pass opcode
ok 3 d786 - Add mpls dec_ttl action with drop opcode
ok 4 f334 - Add mpls dec_ttl action with reclassify opcode
ok 5 29bd - Add mpls dec_ttl action with continue opcode
ok 6 48df - Add mpls dec_ttl action with jump opcode
ok 7 62eb - Add mpls dec_ttl action with trap opcode
ok 8 09d2 - Add mpls dec_ttl action with opcode and cookie
ok 9 c170 - Add mpls dec_ttl action with opcode and cookie of max length
ok 10 9118 - Add mpls dec_ttl action with invalid opcode
ok 11 6ce1 - Add mpls dec_ttl action with label (invalid)
ok 12 352f - Add mpls dec_ttl action with tc (invalid)
ok 13 fa1c - Add mpls dec_ttl action with ttl (invalid)
ok 14 6b79 - Add mpls dec_ttl action with bos (invalid)
ok 15 d4c4 - Add mpls pop action with ip proto
ok 16 91fb - Add mpls pop action with ip proto and cookie
ok 17 92fe - Add mpls pop action with mpls proto
ok 18 7e23 - Add mpls pop action with no protocol (invalid)
ok 19 6182 - Add mpls pop action with label (invalid)
ok 20 6475 - Add mpls pop action with tc (invalid)
ok 21 067b - Add mpls pop action with ttl (invalid)
ok 22 7316 - Add mpls pop action with bos (invalid)
ok 23 38cc - Add mpls push action with label
ok 24 c281 - Add mpls push action with mpls_mc protocol
ok 25 5db4 - Add mpls push action with label, tc and ttl
ok 26 7c34 - Add mpls push action with label, tc ttl and cookie of max length
ok 27 16eb - Add mpls push action with label and bos
ok 28 d69d - Add mpls push action with no label (invalid)
ok 29 e8e4 - Add mpls push action with ipv4 protocol (invalid)
ok 30 ecd0 - Add mpls push action with out of range label (invalid)
ok 31 d303 - Add mpls push action with out of range tc (invalid)
ok 32 fd6e - Add mpls push action with ttl of 0 (invalid)
ok 33 19e9 - Add mpls mod action with mpls label
ok 34 1fde - Add mpls mod action with max mpls label
ok 35 0c50 - Add mpls mod action with mpls label exceeding max (invalid)
ok 36 10b6 - Add mpls mod action with mpls label of MPLS_LABEL_IMPLNULL (invalid)
ok 37 57c9 - Add mpls mod action with mpls min tc
ok 38 6872 - Add mpls mod action with mpls max tc
ok 39 a70a - Add mpls mod action with mpls tc exceeding max (invalid)
ok 40 6ed5 - Add mpls mod action with mpls ttl
ok 41 77c1 - Add mpls mod action with mpls ttl and cookie
ok 42 b80f - Add mpls mod action with mpls max ttl
ok 43 8864 - Add mpls mod action with mpls min ttl
ok 44 6c06 - Add mpls mod action with mpls ttl of 0 (invalid)
ok 45 b5d8 - Add mpls mod action with mpls ttl exceeding max (invalid)
ok 46 451f - Add mpls mod action with mpls max bos
ok 47 a1ed - Add mpls mod action with mpls min bos
ok 48 3dcf - Add mpls mod action with mpls bos exceeding max (invalid)
ok 49 db7c - Add mpls mod action with protocol (invalid)
ok 50 b070 - Replace existing mpls push action with new ID
ok 51 95a9 - Replace existing mpls push action with new label, tc, ttl and cookie
ok 52 6cce - Delete mpls pop action
ok 53 d138 - Flush mpls actions
ok 54 7a70 - Reference mpls action object in filter
Fixes: fb57b0920f ("tc: add mpls actions")
Reviewed-by: Jamal Hadi Salim <jhs@mojatatu.com>
Signed-off-by: Pedro Tammela <pctammela@mojatatu.com>
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
'action csum index 1' is a valid cli according to TC's
architecture. Fix the grammar parsing to accept it.
tdc tests:
1..24
ok 1 6d84 - Add csum iph action
ok 2 1862 - Add csum ip4h action
ok 3 15c6 - Add csum ipv4h action
ok 4 bf47 - Add csum icmp action
ok 5 cc1d - Add csum igmp action
ok 6 bccc - Add csum foobar action
ok 7 3bb4 - Add csum tcp action
ok 8 759c - Add csum udp action
ok 9 bdb6 - Add csum udp xor iph action
ok 10 c220 - Add csum udplite action
ok 11 8993 - Add csum sctp action
ok 12 b138 - Add csum ip & icmp action
ok 13 eeda - Add csum ip & sctp action
ok 14 0017 - Add csum udp or tcp action
ok 15 b10b - Add all 7 csum actions
ok 16 ce92 - Add csum udp action with cookie
ok 17 912f - Add csum icmp action with large cookie
ok 18 879b - Add batch of 32 csum tcp actions
ok 19 b4e9 - Delete batch of 32 csum actions
ok 20 0015 - Add batch of 32 csum tcp actions with large cookies
ok 21 989e - Delete batch of 32 csum actions with large cookies
ok 22 d128 - Replace csum action with invalid goto chain control
ok 23 eaf0 - Add csum iph action with no_percpu flag
ok 24 c619 - Reference csum action object in filter
Fixes: 3822cc986c ("tc: add ACT_CSUM action support (csum)")
Reviewed-by: Jamal Hadi Salim <jhs@mojatatu.com>
Signed-off-by: Pedro Tammela <pctammela@mojatatu.com>
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Previously, the code returned directly within the switch statement in
the functions print_{ipv4, ipv6}. While this approach was functional,
after the commit 721435dc, we can no longer return directly because we
need to close the match object. To resolve this issue, replace the return
statement with break.
Fixes: 721435dcfd ("tc: u32: add json support in `print_raw`, `print_ipv4`, `print_ipv6`")
Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
We previously printed an asterisk if there was no 'sel' or
'TC_U32_TERMINAL' flag. However,
commit 1ff227545c ("u32: fix json formatting of flowid")
changed the logic to print an asterisk only if there is a
'TC_U32_TERMINAL' flag. Therefore, we need to fix this
regression.
Before the fix, the tdc u32 test failed:
1..11
not ok 1 afa9 - Add u32 with source match
Could not match regex pattern. Verify command output:
filter protocol ip pref 1 u32 chain 0
filter protocol ip pref 1 u32 chain 0 fh 800: ht divisor 1
filter protocol ip pref 1 u32 chain 0 fh 800::800 order 2048 key ht 800 bkt 0 *flowid 1:1 not_in_hw
match 7f000001/ffffffff at 12
action order 1: gact action pass
random type none pass val 0
index 1 ref 1 bind 1
After fix, the test passed:
1..11
ok 1 afa9 - Add u32 with source match
Fixes: 1ff227545c ("u32: fix json formatting of flowid")
Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
Reviewed-by: Victor Nogueira <victor@mojatatu.com>
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Back in 2006 kernel commit 334c29a64507 ("[GENETLINK]: Move
command capabilities to flags.") removed some attributes and
moved the capabilities to flags. Corresponding iproute2
commit 26328fc393 ("Add controller support for new features
exposed") added the ability to print those caps.
Printing is gated on version of the family, but we're checking
the version of each individual family rather than the control
family. The format of attributes in the control family
is dictated by the version of the control family alone.
In fact the entire version check is not strictly necessary.
The code is not using the old attributes, so on older kernels
it will simply print nothing either way.
Families can't use flags for random things, because kernel core
has a fixed interpretation.
Thanks to this change caps will be shown for all families
(assuming kernel newer than 2.6.19), not just those which
by coincidence have their local version >= 2.
For instance devlink, before:
$ genl ctrl get name devlink
Name: devlink
ID: 0x15 Version: 0x1 header size: 0 max attribs: 179
commands supported:
#1: ID-0x1
#2: ID-0x5
#3: ID-0x6
...
after:
$ genl ctrl get name devlink
Name: devlink
ID: 0x15 Version: 0x1 header size: 0 max attribs: 179
commands supported:
#1: ID-0x1
Capabilities (0xe):
can doit; can dumpit; has policy
#2: ID-0x5
Capabilities (0xe):
can doit; can dumpit; has policy
#3: ID-0x6
Capabilities (0xb):
requires admin permission; can doit; has policy
Fixes: 26328fc393 ("Add controller support for new features exposed")
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Reviewed-by: Jamal Hadi Salim <jhs@mojatatu.com>
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
The current mqprio manual is not detailed about queue mapping
and priorities, this patch adds some examples to it.
Suggested-by: Ferenc Fejes <fejes@inf.elte.hu>
Signed-off-by: Péter Antal <peti.antal99@gmail.com>
Acked-by: Ferenc Fejes <fejes@inf.elte.hu>
Acked-by: Péter Antal <peti.antal99@gmail.com>
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
It should sit within the TCA_ACT_TAB hierarchy, otherwise the access to
tb is out of bounds:
./tc action ls action csum
total acts 1
action order 0: csum (?empty) action pass
index 1 ref 1 bind 0
not_in_hw
Segmentation fault (core dumped)
Fixes: 60359956 ("tc: add new attr TCA_EXT_WARN_MSG")
Reviewed-by: Jamal Hadi Salim <jhs@mojatatu.com>
Signed-off-by: Pedro Tammela <pctammela@mojatatu.com>
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
This is missing a separator, that was accidently removed
when JSON was added.
Fixes: 010a8388ae ("tc: Add JSON output to tc-class")
Signed-off-by: Christian Hesse <mail@eworm.de>
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
