netdev - Re: [PATCH] net: dsa: mv88e6xxx: egress all frames

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]

Date:   Wed, 23 Nov 2016 10:59:13 -0500
From:   Vivien Didelot <vivien.didelot@...oirfairelinux.com>
To:     Stefan Eichenberger <stefan.eichenberger@...module.com>,
        Andrew Lunn <andrew@...n.ch>
Cc:     Stefan Eichenberger <eichest@...il.com>, f.fainelli@...il.com,
        netdev@...r.kernel.org
Subject: Re: [PATCH] net: dsa: mv88e6xxx: egress all frames

Hi Stefan,

Stefan Eichenberger <stefan.eichenberger@...module.com> writes:

>> Now, the different families are not 100% compatible with each
>> other. We never had access to a 6097, so it has not been tested
>> recently, and we have probably broken it... My guess would be,
>> anywhere mv88e6xxx_6095_family(chip) is used, there also needs to be
>> an mv88e6xxx_6097_family(chip). But i could be wrong.
>
> I think I probably found the problem. For EDSA type switches the bit
> PORT_CONTROL_FORWARD_UNKNOWN_MC is set on the cpu port but not for DSA 
> type switches. Broadcast addresses are threaded as multicast addresses, 
> so unknown frames will never leave the switch.

The Port Control Register (0x04) is one of these registers which changes
almost completely among chip models.

Are you able to give us the layout of the port register 0x04 on your
88E6097? I don't have access to its datasheet.

For instance on 88E6185 bit 3 is reserved, on 88E6352 and 88E6390 bit
3:2 are "Egress Floods" and 0x2 means "Do not egress any frame with an
unknown unicast DA".

> Do you know if there is a reason why this bit isn't set for DSA type
> switches too? The patch would be extremely simple and it seems to work
> perfectly with this bit set on the CPU port.

All these family checks for bit masking are quite messy and ideally need
proper abstraction...

Can you give us the chunk of patch you are refering to?

Thanks,

        Vivien