Bug 206241 - iproute2 (ip link show) breaks -o with -d if egress-qos-map/ingress-qos-map is set
Summary: iproute2 (ip link show) breaks -o with -d if egress-qos-map/ingress-qos-map i...
Status: NEW
Alias: None
Product: Networking
Classification: Unclassified
Component: Other (show other bugs)
Hardware: All Linux
: P1 low
Assignee: Stephen Hemminger
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-01-17 15:50 UTC by George Shuklin
Modified: 2020-01-19 01:18 UTC (History)
1 user (show)

See Also:
Kernel Version: 5.4.0-11-generic #14-Ubuntu
Subsystem:
Regression: No
Bisected commit-id:


Attachments

Description George Shuklin 2020-01-17 15:50:18 UTC
ip -o -d link show makes multiline output if vlan interface has ingress-qos-map/egress-qos-map configured.

Steps to reproduce:
ip link add dev veth90 type veth
ip link add link veth90 name veth90.4000 type vlan ingress-qos-map 1:2  egress-qos-map 2:1 id 4000
ip -oneline -details link show veth90.4000


Expected behavior: one-line output with '\' instead of newline characters (per man page which says '-o, -oneline - output each record on a single line').

Actual result:

multiline output:

16: veth90@veth0: <BROADCAST,MULTICAST,M-DOWN> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000\    link/ether 72:04:1d:dc:52:32 brd ff:ff:ff:ff:ff:ff promiscuity 0 minmtu 68 maxmtu 65535 \    veth addrgenmode eui64 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 
21: veth90.4000@veth90: <BROADCAST,MULTICAST,M-DOWN> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000\    link/ether 72:04:1d:dc:52:32 brd ff:ff:ff:ff:ff:ff promiscuity 0 minmtu 0 maxmtu 65535 \    vlan protocol 802.1Q id 4000 <REORDER_HDR> 
      ingress-qos-map { 1:2 } 
      egress-qos-map { 2:1 } addrgenmode eui64 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 


iproute2 version: 5.2.0-1ubuntu2
Comment 1 vsd 2020-01-18 22:59:57 UTC
i'm not sure why this is raised in the kernel tracker. the kernel sends the interface details via a netlink message which has a proper format:

# uname -r
5.5.0-0.rc1.git2.1.fc32.x86_64

# strace -fvxt ip -oneline -details link show veth90.4000
... bla ...
23:14:27 recvmsg(4, {msg_name={sa_family=AF_NETLINK, nl_pid=0, nl_groups=00000000}, msg_namelen=12, msg_iov=[{iov_base={{len=1032, type=RTM_NEWLINK, flags=0, seq=1579385668, pid=3858000215}, {ifi_family=AF_UNSPEC, ifi_type=ARPHRD_ETHER, ifi_index=if_nametoindex("veth90.4000"), ifi_flags=IFF_BROADCAST|IFF_MULTICAST, ifi_change=0}, [{{nla_len=16, nla_type=IFLA_IFNAME}, "veth90.4000"}, {{nla_len=8, nla_type=IFLA_TXQLEN}, 1000}, ... bla ...

it is an 'ip' binary from (fedora's case):

# rpm -qa iproute
iproute-5.4.0-1.fc32.x86_64

which formats and prints the details as coded in:

https://mirrors.edge.kernel.org/pub/linux/utils/net/iproute2/

namely, in:

[ ip/iplink_vlan.c ]
static void vlan_print_map(FILE *f,
			   const char *name_json,
			   const char *name_fp,
			   struct rtattr *attr)
{ ... }

static void vlan_print_opt(struct link_util *lu, FILE *f, struct rtattr *tb[])
{       ...
	if (tb[IFLA_VLAN_INGRESS_QOS])
		vlan_print_map(f,
			       "ingress_qos",
			       "ingress-qos-map",
			       tb[IFLA_VLAN_INGRESS_QOS]);
	if (tb[IFLA_VLAN_EGRESS_QOS])
		vlan_print_map(f,
			       "egress_qos",
			       "egress-qos-map",
			       tb[IFLA_VLAN_EGRESS_QOS]);

yes, this looks like a (minor) bug and as https://lwn.net/Articles/805654/ states:

> Report problems (or enhancements) to the netdev@vger.kernel.org mailing list.

you can check https://lore.kernel.org/netdev/ and see posts starting with "[PATCH iproute2-next] ip route: " as a proof. i probably can send a patch for that in some time, as a reply to your post if you post the same ^^^ there or standalone.

or (i'm not sure if you've evaluated this option):

you can use ip's json output mode right now which has proper formatting and easily parseable:

# ip -json -details link show veth90.4000
[{"ifindex":5,"link":"veth90","ifname":"veth90.4000","flags":["BROADCAST","MULTICAST","M-DOWN"],"mtu":1500,"qdisc":"noop","operstate":"DOWN","linkmode":"DEFAULT","group":"default","txqlen":1000,"link_type":"ether","address":"26:9a:05:af:db:00","broadcast":"ff:ff:ff:ff:ff:ff","promiscuity":0,"min_mtu":0,"max_mtu":65535,"linkinfo":{"info_kind":"vlan","info_data":{"protocol":"802.1Q","id":4000,"flags":["REORDER_HDR"],"ingress_qos":[{"from":1,"to":2}],"egress_qos":[{"from":2,"to":1}]}},"inet6_addr_gen_mode":"eui64","num_tx_queues":1,"num_rx_queues":1,"gso_max_size":65536,"gso_max_segs":65535}]
Comment 2 vsd 2020-01-19 01:18:47 UTC
suddenly, that was not overwhelmingly hard:

https://lore.kernel.org/netdev/20200119011251.7153-1-vdronov@redhat.com/T/#u

Note You need to log in before you can comment on or make changes to this bug.