netdev - Re: [patch net-next] mlxsw: spectrum_switchdev: Allow port enslavement to a VLAN-unaware bridge

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20180221202432.GA18451@splinter.mtl.com>
Date:   Wed, 21 Feb 2018 22:24:32 +0200
From:   Ido Schimmel <idosch@...sch.org>
To:     David Ahern <dsahern@...il.com>
Cc:     Jiri Pirko <jiri@...nulli.us>, netdev@...r.kernel.org,
        davem@...emloft.net, idosch@...lanox.com, mlxsw@...lanox.com
Subject: Re: [patch net-next] mlxsw: spectrum_switchdev: Allow port
 enslavement to a VLAN-unaware bridge

On Wed, Feb 21, 2018 at 12:41:39PM -0700, David Ahern wrote:
> On 2/21/18 12:25 PM, Ido Schimmel wrote:
> >>
> >> and can talk to the hosts:
> >> # ping6 ff02::2%br0
> > 
> > Can you try ff02::1 ?
> 
> same result.
> 
> > 
> >> PING ff02::2%br0(ff02::2) 56 data bytes
> >> 64 bytes from fe80::7efe:90ff:fee8:3a79: icmp_seq=1 ttl=64 time=0.073 ms
> >> 64 bytes from fe80::202:ff:fe00:2: icmp_seq=1 ttl=64 time=0.661 ms (DUP!)
> >> 64 bytes from fe80::202:ff:fe00:5: icmp_seq=1 ttl=64 time=0.705 ms (DUP!)
> >> 64 bytes from fe80::202:ff:fe00:1: icmp_seq=1 ttl=64 time=0.720 ms (DUP!)
> >> 64 bytes from fe80::202:ff:fe00:3: icmp_seq=1 ttl=64 time=0.729 ms (DUP!)
> >> 64 bytes from fe80::202:ff:fe00:6: icmp_seq=1 ttl=64 time=0.739 ms (DUP!)
> >> 64 bytes from fe80::202:ff:fe00:4: icmp_seq=1 ttl=64 time=0.748 ms (DUP!)
> >> 64 bytes from fe80::202:ff:fe00:7: icmp_seq=1 ttl=64 time=0.757 ms (DUP!)
> >> 64 bytes from fe80::202:ff:fe00:8: icmp_seq=1 ttl=64 time=0.766 ms (DUP!)
> >>
> >> but the hosts can not talk to each other:
> >>
> >> cumulus@...t3:~$ net show lldp
> >>
> >> LocalPort  Speed  Mode          RemoteHost   RemotePort
> >> ---------  -----  ------------  -----------  ----------
> >> swp1       10G    Interface/L3  mlx-2700-05  swp1s2
> >>
> >> cumulus@...t3:~$ ping6 3000:1000:1000:1000::2
> >> PING 3000:1000:1000:1000::2(3000:1000:1000:1000::2) 56 data bytes
> >> ^C
> >> --- 3000:1000:1000:1000::2 ping statistics ---
> >> 3 packets transmitted, 0 received, 100% packet loss, time 1999ms
> > 
> > Can you please try
> > 
> > # brctl showstp br0
> > 
> > To make sure STP state is set to forwarding?
> 
> it is.
> 
> > 
> > Does it matter if you try IPv4 ping or if vlan_filtering is set 1?
> > Unfortunately, I can't reproduce on my switch.
> 
> Bring up the hosts and then reboot the switch. At that point I get no
> host to host communication. As soon as I flap the port on host1 host3 to
> host1 starts working.
> 
> So it seems to be something about the initial boot state.

You didn't have IPv6 *and* IPv4 ping? I'm asking because it's possible
host1 sent an MLD join to the Solicited-node multicast address before
the bridge started listening, which means it didn't have a corresponding
MDB entry.

Assuming your hosts aren't functioning as multicast routers and sending
MLD queries and that you didn't configure them as mrouter ports on the
switch, then when host3 sent a neighbour solicitation message to host1's
Solicited-node multicast address it wasn't flooded to host3 which
prevented ping from passing.

This also explains why it started working when you flapped the port on
host1, as Linux generates MLD joins in these cases.

You can try to disable snooping:

# ip link set dev br0 type bridge mcast_snooping 0

Just a guess, but worth a try.

Thanks!