netdev - Re: [RFC v2, net-next, PATCH 0/4] Add switchdev on TI-CPSW

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: <20180618150424.GA5865@lunn.ch>
Date:   Mon, 18 Jun 2018 17:04:24 +0200
From:   Andrew Lunn <andrew@...n.ch>
To:     Ilias Apalodimas <ilias.apalodimas@...aro.org>
Cc:     netdev@...r.kernel.org, grygorii.strashko@...com,
        ivan.khoronzhuk@...aro.org, nsekhar@...com, jiri@...nulli.us,
        ivecera@...hat.com, f.fainelli@...il.com, francois.ozog@...aro.org,
        yogeshs@...com, spatton@...com, Jose.Abreu@...opsys.com
Subject: Re: [RFC v2, net-next, PATCH 0/4] Add switchdev on TI-CPSW

Hi Ilias

Thanks for removing the CPU port. That helps a lot moving forward.

> - Multicast testing client-port1(tagged on vlan 100) server-port1
> switch-config is provided by TI (https://git.ti.com/switch-config)
> and is used to verify correct switch configuration.
> 1. switch-config output
> 	- type: vlan , vid = 100, untag_force = 0x4, reg_mcast = 0x6,
> 	unreg_mcast = 0x0, member_list = 0x6
> Server running on sw0p2: iperf -s -u -B 239.1.1.1 -i 1
> Client running on sw0p1: iperf -c 239.1.1.1 -u -b 990m -f m -i 5 -t 3600
> No IGMP reaches the CPU port to add MDBs(since CPU does not receive 
> unregistered multicast as programmed).

Is this something you can work around? Is there a TCAM you can program
to detect IGMP and pass the packets to the CPU? Without receiving
IGMP, multicast is pretty broken.

If i understand right, a multicast listener running on the CPU should
work, since you can add an MDB to receive multicast traffic from the
two ports. Multicast traffic sent from the CPU also works. What does
not work is IGMP snooping of traffic between the two switch ports. You
have no access to the IGMP frames, so cannot snoop. So unless you can
work around that with a TCAM, i think you just have to blindly pass
all multicast between the two ports.

> Setting on/off and IFF_MULTICAST (on eth0/eth1/br0) will affect registered 
> multicast masks programmed in the switch(for port1, port2, cpu port
> respectively).

> This muct occur before adding VLANs on the interfaces. If you change the
> flag after the VLAN configuration you need to re-issue the VLAN config 
> commands. 

This you should fix. You should be able to get the stack to tell you
about all the configured VLANs, so you can re-program the switch.

> - NFS:
> The only way for NFS to work is by chrooting to a minimal environment when 
> switch configuration that will affect connectivity is needed.

You might want to look at the commit history for DSA. Florian added a
patch which makes NFS root work with DSA. It might give you clues as
to what you need to add to make it just work.

   Andrew