netdev - Re: vlan_filtering=1 breaks all traffic

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:   Mon, 7 Dec 2020 20:15:28 +0000
From:   Vladimir Oltean <vladimir.oltean@....com>
To:     Rasmus Villemoes <rasmus.villemoes@...vas.dk>,
        Andrew Lunn <andrew@...n.ch>
CC:     Network Development <netdev@...r.kernel.org>,
        Florian Fainelli <f.fainelli@...il.com>,
        Russell King - ARM Linux <linux@...linux.org.uk>
Subject: Re: vlan_filtering=1 breaks all traffic

On Mon, Dec 07, 2020 at 08:43:18PM +0100, Rasmus Villemoes wrote:
> # uname -a
> Linux (none) 5.10.0-rc7-00035-g66d777e1729d #194 Mon Dec 7 16:00:30 CET
> 2020 ppc GNU/Linux
> # devlink dev
> mdio_bus/mdio@...02120:10
> # mv88e6xxx_dump --device mdio_bus/mdio@...02120:10 --vtu
> VTU:
> Error: devlink: The requested region does not exist.
> devlink answers: Invalid argument
> Unable to snapshot vtu
>
> --atu, --global1 and --global2 does work, but the latter two say
> "Unknown mv88e6xxx chip 186a" (and 186a is 6250 in hex, so I think that
> should have been printed in decimal to reduce confusion). Whether that
> has anything to do with --vtu not working I don't know - the global1/2
> registers to seem to get printed correctly.

Ahh, this is probably because Andrew didn't know how many bits is the
FID field width for 6250. The code has the 6250 treated the same as the
"default" case, which is to error out:

cmd_vtu:
	switch (ctx->chip) {
	case MV88E6190:
	case MV88E6191:
	case MV88E6290:
	case MV88E6390:
		return vtu_mv88e6xxx(ctx, 0x7ff);
	case MV88E6171:
	case MV88E6175:
	case MV88E6350:
	case MV88E6351:
	case MV88E6172:
	case MV88E6176:
	case MV88E6240:
	case MV88E6352:
		return vtu_mv88e6xxx(ctx, 0x7ff);
	case MV88E6141:
	case MV88E6341:
		return vtu_mv88e6xxx(ctx, 0xff);
	case MV88E6320:
	case MV88E6321:
		return vtu_mv88e6xxx(ctx, 0x7ff);
	case MV88E6220:
	case MV88E6250:
	case MV88E6131:
	case MV88E6185:
	case MV88E6123:
	case MV88E6161:
	case MV88E6165:
	default:
		printf("Unknown mv88e6xxx chip %x\n", ctx->chip);
	}

You can probably figure out the width of that field based on your
datasheet. You can probably just put a value in there and get some
output regardless of whether it's actually correct or not.

The kernel takes care of issuing the VTU GetNext operation and performs
a raw read of the VTU Data registers, which are passed to user space
(and where they get interpreted).

Nonetheless, I'm adding Andrew as well.

Andrew, this is the thread, for context, in case you haven't been
following. The threading got broken multiple times, it seems.
https://lore.kernel.org/netdev/6424c14e-bd25-2a06-cf0b-f1a07f9a3604@prevas.dk/