Hello, I’m trying to setup a bridge connection on a iMX8MP module with TorizonCore 6.3.0+build.4 (2023/07/25).
My commands:
# Deleting original ethernet interface
nmcli con delete network0
# Create a bridge interface with static IP on my local network
$ nmcli con add type bridge autoconnect yes ifname br0 con-name br0 ipv4.addresses "192.168.87.170/24" ipv4.gateway 192.168.87.254 ipv4.method manual
Connection 'br0' (0830d0df-4e11-4630-a1cf-3e0328e4c543) successfully added.
# Add ethernet0 as a slave of br0 bridge
$ nmcli con add type bridge-slave autoconnect yes con-name ethernet0-br0-slave ifname ethernet0 master br0
[ 1247.346738] imx-dwmac 30bf0000.ethernet ethernet0: Adding VLAN in promisc mode not supported
[ 1247.418834] imx-dwmac 30bf0000.ethernet ethernet0: failed to initialize vlan filtering on this port
Connection 'ethernet0-br0-slave' (eded280c-d213-4d0b-934f-55e6607cf7ae) successfully added.
# Connections now
$ nmcli c
NAME UUID TYPE DEVICE
br0 b2aff9ae-cada-47a2-9476-dedd6c330e78 bridge br0
ethernet0-br0-slave 70ffc2cb-d5d7-4844-a97a-b6da188fc7e0 ethernet --
network1 78c31df4-8c89-31a6-9aeb-d5603e230e4e ethernet --
Then, even if the interface went up I got these messages coming regularly and my bridge isn’t working (cannot access the local network as before with ethernet0):
[ 1247.620951] imx-dwmac 30bf0000.ethernet ethernet0: Adding VLAN in promisc mode not supported
[ 1247.679139] imx-dwmac 30bf0000.ethernet ethernet0: failed to initialize vlan filtering on this port
For information, it looks like there’s a workaround here, maybe TorizonCore needs a patch for this or can I do something without rebuilding the OS from source ?
We were able to reproduce this issue on our side as well with the same results.
For information, it looks like there’s a workaround here , maybe TorizonCore needs a patch for this or can I do something without rebuilding the OS from source ?
Now I’m not sure yet if the info here pertains to this issue you’re seeing. But there’s possibly a way to test this without patching the kernel. In that link you shared it states:
Bridge mode on EQoS module will not work since Linux Kernel 5.10_2.2.0.
And
Before adding Intel’s patch, there is no problem.
So this seems to suggest that this used to work in the past. If that is the case could you try this on one of our version 5.X images instead of 6.X. Our 5.X images use a kernel based on 5.4. Therefore if this is the same problem as the link then it should work on this older version. If that is the case we can more or less confirm whether this is the issue or not before we take further steps.
Also just so I have the full context, what is your use-case/goal here with setting up this bridge network?
This is something I already used with a 5.X image without problems but I’d like to use the newest production ready image if possible!
The bridge network is used to connect the ethernet interface to a tap interface so that we can access ethernet packets programmaticaly. I’ll maybe use it also for a wireguard (wg0) to lte (wwan0) bridge but that is still to decide.
For what it’s worth we are using a bridged setup on an 8MP to bridge several ports on a built-in KSZ9897 switch without issue on 6.x, but we are configuring it via systemd-networkd instead of nmcli.
This is something I already used with a 5.X image without problems
Okay that’s good to know then.
Let’s do a test then if you are able. I created a TorizonCore image with the patch/workaround from that NXP page you linked. The image is here (use Easy Installer to install): https://share.toradex.com/3rgs3763p8u3waj
It’s standard TorizonCore the only difference is the applied patch. Try this image and see if your use-case now works. If it works then I think we can safely confirm that the NXP issue is the same as this issue.
Also if you can confirm this works then I’ll have a better argument to make to our team to possibly include this patch by default.
Your patched image is working for me using the same commands as in my first message.
Hope this will be added in an upcoming release.
Alright that pretty much confirms that the NXP issue here is the same issue you’re experiencing. Thank you for taking the time to test this. I will go ahead and bring this up with our team internally for further discussion then.
