Thread (5 messages) 5 messages, 2 authors, 2015-09-17

Re: kernel 4.2 : "bridge vlan" command return empty result (works with kernel 4.1.3)

flat view

From: Alexandre DERUMIER <hidden>
Date: 2015-09-17 03:36:58
Subsystem: networking [general], the rest · Maintainers: "David S. Miller", Eric Dumazet, Jakub Kicinski, Paolo Abeni, Linus Torvalds

quoted
he problem went away on my box with the following patch. I 
will submit an official patch in a bit.
Hi, I confirm that your patch fix the problem for me too.

Regards,

Alexandre
----- Mail original -----
De: "roopa" [off-list ref]
À: "aderumier" [off-list ref]
Cc: "netdev" <redacted>, "Scott Feldman" <redacted>
Envoyé: Mardi 15 Septembre 2015 21:02:34
Objet: Re: kernel 4.2 : "bridge vlan" command return empty result (works with kernel 4.1.3)

On 9/15/15, 10:39 AM, Alexandre DERUMIER wrote: 
Hi, 

since kernel 4.2, "bridge vlan" command return empty result. 


kernel 4.1.3 
------------ 
# bridge vlan 
port vlan ids 
eth0 1 PVID Egress Untagged 
90 
91 
92 
93 
94 
95 
96 
97 
98 
99 
100 

vmbr0 1 PVID Egress Untagged 
94 



kernel 4.2 
---------------- 
# bridge vlan 
port vlan ids 



Note that vlans are correctly working,it seem that is just the display. 

tcpdump -e -i vmbr0 

19:38:08.005055 00:08:7c:bd:ae:40 (oui Unknown) > 00:18:8b:7c:c8:37 (oui Unknown), ethertype 802.1Q (0x8100), length 64: vlan 94, p 0, ethertype IPv4, 172.20.0.17.52299 > kvmtest2.odiso.net.ssh: Flags [.], ack 339613, win 5523, length 0 
19:38:08.007730 00:08:7c:bd:ae:40 (oui Unknown) > 00:18:8b:7c:c8:37 (oui Unknown), ethertype 802.1Q (0x8100), length 64: vlan 94, p 0, ethertype IPv4, 172.20.0.17.52299 > kvmtest2.odiso.net.ssh: Flags [.], ack 342145, win 5568, length 0 
19:38:08.010977 00:08:7c:bd:ae:40 (oui Unknown) > 00:18:8b:7c:c8:37 (oui Unknown), ethertype 802.1Q (0x8100), length 64: vlan 94, p 0, ethertype IPv4, 172.20.0.17.52299 > kvmtest2.odiso.net.ssh: Flags [.], ack 344677, win 5614, length 0 
19:3 
I was able to reproduce this when there is a bond in the system. 

Looks like this was due to 85fdb956726ff2a ("switchdev: cut over to new 
switchdev_port_bridge_getlink"). 
When CONFIG_SWITCHDEV is off, nodes that use switchdev api for 
ndo_bridge_getlink (example, bonds, teams, rocker) can return 
-EOPNOTSUPP. The problem went away on my box with the following patch. I 
will submit an official patch in a bit. 
Do you have a bond in your system ?. 
diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c 
index 01ced4a..bdb3842 100644 
--- a/net/core/rtnetlink.c 
+++ b/net/core/rtnetlink.c 
@@ -3013,6 +3013,7 @@ static int rtnl_bridge_getlink(struct sk_buff 
*skb, struct 
u32 portid = NETLINK_CB(cb->skb).portid; 
u32 seq = cb->nlh->nlmsg_seq; 
u32 filter_mask = 0; 
+ int err; 

if (nlmsg_len(cb->nlh) > sizeof(struct ifinfomsg)) { 
struct nlattr *extfilt; 
@@ -3033,20 +3034,25 @@ static int rtnl_bridge_getlink(struct sk_buff 
*skb, stru 
struct net_device *br_dev = 
netdev_master_upper_dev_get(dev); 

if (br_dev && br_dev->netdev_ops->ndo_bridge_getlink) { 
- if (idx >= cb->args[0] && 
- br_dev->netdev_ops->ndo_bridge_getlink( 
- skb, portid, seq, dev, filter_mask, 
- NLM_F_MULTI) < 0) 
- break; 
+ if (idx >= cb->args[0]) { 
+ err = 
br_dev->netdev_ops->ndo_bridge_getlink( 
+ skb, portid, seq, dev, 
+ filter_mask, NLM_F_MULTI); 
+ if ( err < 0 && err != -EOPNOTSUPP) 
+ break; 
+ } 
idx++; 
} 

if (ops->ndo_bridge_getlink) { 
- if (idx >= cb->args[0] && 
- ops->ndo_bridge_getlink(skb, portid, seq, dev, 
- filter_mask, 
- NLM_F_MULTI) < 0) 
- break; 
+ if (idx >= cb->args[0]) { 
+ err = ops->ndo_bridge_getlink(skb, portid, 
+ seq, dev, 
+ filter_mask, 
+ NLM_F_MULTI); 
+ if ( err < 0 && err != -EOPNOTSUPP) 
+ break; 
+ } 
idx++; 
} 
} 
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help