Intel i225 bridging issue

I am not sure whether this is the right group.

We are working with an x86 device based on the Intel® Atom® C3436L CPU. It uses the Intel 2.5G i225 Ethernet controller on 4 interfaces.

We are using OpenWRT 21.02.

We seem to have discovered that the standard way of configuring a bridge device does not work with 2.5G interfaces.

The 2.5G interfaces are: eth2, eth3, eth4, eth5. Our network configuration for the bridge looks like this:

config interface 'loopback'
	option device 'lo'
	option proto 'static'
	option ipaddr '127.0.0.1'
	option netmask '255.0.0.0'

config globals 'globals'
	option ula_prefix 'fd26:0c59:7588::/48'

config device
	option name 'br-lan'
	option type 'bridge'
	list ports 'eth2'
	list ports 'eth3'
	list ports 'eth4'
	list ports 'eth5'
	option macaddr '00:08:A2:12:DD:7F'

config interface 'lan'
	option device 'br-lan'
	option proto 'static'
	option ipaddr '192.168.1.1'
	option netmask '255.255.255.0'
	option ip6assign '60'

config interface 'wan'
	option device 'eth1'
	option proto 'dhcp'

config interface 'wan6'
	option device 'eth1'
	option proto 'dhcpv6'

With this configuration, a host connected to eth2 interface will get an IP address via DHCP from the device and is able to ping 192.168.1.1, the device LAN address.

However, a host connected to eth3, eth4, eth5, only gets an IP address via DHCP but is not able to ping 192.168.1.1. ARP requests are not answered.

We found a "workaround". By assigning the same MAC address to br-lan, eth2, eth3, eth4, eth5, we are able to make eth3, eth4, eth5 interfaces function as they should with this configuration:

config interface 'loopback'
	option device 'lo'
	option proto 'static'
	option ipaddr '127.0.0.1'
	option netmask '255.0.0.0'

config globals 'globals'
	option ula_prefix 'fd26:0c59:7588::/48'

config device
	option name 'br-lan'
	option type 'bridge'
	list ports 'eth2'
	list ports 'eth3'
	list ports 'eth4'
	list ports 'eth5'
	option macaddr '00:08:A2:12:DD:7F'

config interface 'lan'
	option device 'br-lan'
	option proto 'static'
	option ipaddr '192.168.1.1'
	option netmask '255.255.255.0'
	option ip6assign '60'

config interface 'wan'
	option device 'eth1'
	option proto 'dhcp'

config interface 'wan6'
	option device 'eth1'
	option proto 'dhcpv6'

config device
	option name 'eth3'
	option macaddr '00:08:A2:12:DD:7F'

config device
	option name 'eth4'
	option macaddr '00:08:A2:12:DD:7F'

config device
	option name 'eth5'
	option macaddr '00:08:A2:12:DD:7F'

config device
	option name 'eth2'
	option macaddr '00:08:A2:12:DD:7F'

We think that this is possibly a bug with OpenWRT bridge when using the Intel 2.5G interface controller.

What led us to believe that it is a bridge issue are 2 experiments.

First experiment involves configuring a bridge with 1G interface controllers (the device has a couple of those as well). Everything works as it should with 1G.

Second experiment involves running Ubuntu 21.10 on the device. Bridging 2.5G interfaces works fine with Ubuntu.

Since the 2.5G driver would be the same in Ubuntu and OpenWRT, this leads us to think that the issue is the OpenWRT bridge.

Again, not sure if this is the right group, or whether this should be filed as a bug with OpenWRT.

Does the 21.10 Ubuntu use the same kernel as openwrt 21.02 ?

It does not...

Ubuntu 21.10 uses the 5.13 kernel.

thnx for checking,

in that case the i225 driver probably isn't the same, after all.

to bad modinfo igc doesn't show the version :frowning:

@ar74spider if you want to bring the openwrt kernel closer to the one in Ubuntu,
install the snapshots instead.

I have the same issue, but sanpshots version is working properly.

1 Like

thnx for confirming.

Thanks for everyone's comments and advice. We have confirmed that i225 bridging works on the master branch.

Apparently there was a recent commit: https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=7a1ce08bdbd36a132fbd0d4114346fb5e4d3aa36

We were able to build on 21.02 branch with the 5.10 kernel and got bridging working.

Looking forward to the next stable release and assuming 5.10 kernel will be there.

Hello,

Is there any possibility that we can get the fix in the trunk backported to the 21.02 branch?