mac address for bridge not set on bridged devices (patch attached)

[Maddes <maddes_trac@…>]

If a mac address is set for the lan bridge, e.g.

network.lan.macaddr=00:11:22:33:44:55

then it is only set on the bridge itself and not on the bridged sub-devices

br-lan    Link encap:Ethernet  HWaddr 00:11:22:33:44:55
lan1      Link encap:Ethernet  HWaddr 00:00:00:00:51:81
lan2      Link encap:Ethernet  HWaddr 00:00:00:00:51:81
lan3      Link encap:Ethernet  HWaddr 00:00:00:00:51:81
lan4      Link encap:Ethernet  HWaddr 00:00:00:00:51:81

The attached patch (just 3 lines) also sets the mac address on the
bridged sub-devices.
It is tested and used for some weeks on LinkSys WRT350Nv2 by some forum members.

It is also a prerequisite of the mac address fix for the WRT350Nv2.

---

Set mac address from bridge also on bridged sub-devices.

Signed-off by: Matthias Buecher <mail@…> and Peter van Valderen <p.v.valderen@…>

[Maddes <maddes_trac@…>]

The above mentioned mac address fix for WRT350Nv2 is available at #7113

[Maddes <maddes_trac@…>]

Setting a different LAN mac address on WRT54G v2.2 with Backfire brcm47xx (Linux 2.6) also makes the router inaccessible from LAN.
The patch fixes this issue also on WRT54G v2.2.

[Maddes <maddes_trac@…>]

Recognized that the initial description missed the point that this issue renders the router inaccessible from LAN.
So without a working WLAN or serial/JTAG connection the device is like a bricked router - nearly unfixable for normal end users.

[Maddes <maddes_trac@…>]

Please set Version to "Backfire 10.03" (Release).

[Maddes <maddes_trac@…>]

Just to show how it is on a WRT350Nv2:

Stock Firmware (v2.0.20)

# Web interface:
Internet MAC Address: 00:1a:70:a0:38:81
Local    MAC Address: 00:1a:70:a0:38:80
Wireless MAC Address: 00:1a:70:a0:38:80
# ifconfig | grep -e 'HWaddr'
ath0      Link encap:Ethernet  HWaddr 00:1A:70:A0:38:80
br0       Link encap:Ethernet  HWaddr 00:1A:70:A0:38:80
eth0      Link encap:Ethernet  HWaddr 00:1A:70:A0:38:80
eth1      Link encap:Ethernet  HWaddr 00:1A:70:A0:38:81
wifi0     Link encap:Ethernet  HWaddr 00:1A:70:A0:38:80

OpenWrt (Backfire)
a) unfixed config.sh without a set mac

# uci show network  | grep macaddr
# ifconfig | grep HWaddr
br-lan    Link encap:Ethernet  HWaddr 00:00:00:00:51:81
eth0      Link encap:Ethernet  HWaddr 00:00:00:00:51:81
lan1      Link encap:Ethernet  HWaddr 00:00:00:00:51:81
lan2      Link encap:Ethernet  HWaddr 00:00:00:00:51:81
lan3      Link encap:Ethernet  HWaddr 00:00:00:00:51:81
lan4      Link encap:Ethernet  HWaddr 00:00:00:00:51:81
wan       Link encap:Ethernet  HWaddr 00:00:00:00:51:81

00:00:00:00:51:81 is used on all WRT350Nv2 machines, due to the wrongly set U-Boot env var "ethaddr".
So having two WRT350Nv2 in a network results in a MAC conflict in ARP (several machines with the same MAC).
That's why people will tend to change the LAN MAC or apply #7113.

b) unfixed config.sh with a set mac
The device switch is not working due to different MAC addresses for br-lan and lanX.

# uci show network  | grep macaddr
network.eth0.macaddr=00:1a:70:a0:38:80
network.wan.macaddr=00:1a:70:a0:38:81
network.lan.macaddr=00:1a:70:a0:38:80
# ifconfig | grep HWaddr
br-lan    Link encap:Ethernet  HWaddr 00:1A:70:A0:38:80
eth0      Link encap:Ethernet  HWaddr 00:1A:70:A0:38:80
lan1      Link encap:Ethernet  HWaddr 00:00:00:00:51:81
lan2      Link encap:Ethernet  HWaddr 00:00:00:00:51:81
lan3      Link encap:Ethernet  HWaddr 00:00:00:00:51:81
lan4      Link encap:Ethernet  HWaddr 00:00:00:00:51:81
wan       Link encap:Ethernet  HWaddr 00:1A:70:A0:38:81

c) fixed config.sh with a set mac

# uci show network  | grep macaddr
network.eth0.macaddr=00:1a:70:a0:38:80
network.wan.macaddr=00:1a:70:a0:38:81
network.lan.macaddr=00:1a:70:a0:38:80
# ifconfig | grep HWaddr
br-lan    Link encap:Ethernet  HWaddr 00:1A:70:A0:38:80
eth0      Link encap:Ethernet  HWaddr 00:1A:70:A0:38:80
lan1      Link encap:Ethernet  HWaddr 00:1A:70:A0:38:80
lan2      Link encap:Ethernet  HWaddr 00:1A:70:A0:38:80
lan3      Link encap:Ethernet  HWaddr 00:1A:70:A0:38:80
lan4      Link encap:Ethernet  HWaddr 00:1A:70:A0:38:80
wan       Link encap:Ethernet  HWaddr 00:1A:70:A0:38:81

[Maddes <maddes_trac@…>]

The patch still applies to the current trunk (r21403) but with a little offset.
Backfire is unchanged.

The blocks are now at:

...
@@ -144,6 +144,8 @@
...
@@ -168,7 +170,7 @@
...

[EqUaTe <chris@…>]

I needed to make a slight change to this to make it work on a WAG354G

I had to add

ifconfig "$iface" down

before

ifconfig "$iface" ${macaddr:+hw ether "${macaddr}"} up 2>/dev/null >/dev/null

Once this was done it worked for me on reboot or restarting the networking.

[maddes]

Updated to r21573 + added EqUaTe's fix. Apply with -p0 to clean trunk, then merge with Backfire.

[maddes]

Updated the patch to current trunk and added EqUaTe's fix.

[nbd]

applied in r21577, r21581

[maddes]

nbd, you missed the last update of the patch (see comment:8).
Some hardware needs an explicit ifdown.
Added a delta patch for your convienence.

[maddes]

-p0 patch for trunk/backfire

[anonymous]

With the additional ifdown I also got rid of the arp update problems, when changing the MAC address. Before I had to restart all switches to connect to my router again.

[nbd]

i just noticed that adding an unconditional ifconfig down there might cause problems with at least some wifi drivers. we might need to handle the mac address issue somewhere else, before the interface is even brought up for the first time.

[maddes]

applied in r21595 with condition

The conditional ifconfig down looks much better, also fits to the other coding in the script where ifconfig down is used.
For me this looks like the final solution.

Thanks to all for getting this straight.

[nbd]

I think even this condition is not enough. We need to move the mac address change to a different place in the code.

[maddes]

Just some brain storming:

• The changes here are for bridged devices.
  In what cases is WLAN/Wifi bridged?
• ifconfig down is used several times in ​config.sh.
  So is this usage a general issue?
  Right now it seems to be better than before, we have a working LAN connection with a manually set MAC address.
• Are cases reproducible where ifconfig down is causing problems?

[nbd]

Actually, most people using access point mode have their WLAN interface bridged.
In all of the cases where ifconfig down is used, it seems that this is only done if the MAC address is changed. Right now it's not changed for the interface by default, but in the future I'd like to change that.
I know that at least madwifi goes mad with race conditions if it gets ifconfig down and up in rapid succession. Other drivers might just lose their active configuration.

[EqUaTe <chris@…>]

Put in a sleep 1 if the iface being changed is the wireless interface?

[maddes]

Would this code

[ "$config" = 'lan' ] && ifconfig "$iface" down 2>/dev/null >/dev/null

be a reasonable workaround until the MAC address handling will be re-worked?
It should exclude all WLAN/Wifi, shouldn't it? (Sorry, haven't set my router into AP mode yet).

[maddes]

Maybe an even better interim solution:

ifconfig "$iface" down 2>/dev/null >/dev/null
case "$iface" in
 lan*)
	;;
 wifi*|radio*|wlan*|*)
	sleep 1
	;;
esac

[maddes]

-p0 patch for trunk/backfire from comment:21

[EqUaTe <chris@…>]

That's not so good actually - not all interface names start with lan/wifi/radio/wlan ..

Certainly on the wag354g's, the interfaces show up as ethX - lan and wan..

[maddes]

Please note the '*' at the end of "wifi*|....|*)", so for all other interface names there will be an extra sleep of one second.
If more LAN-only interface names can be found, then these can be added to "lan*)" to avoid sleep for them.
Maybe uci_get_state 'network.lan.ifname' could be useful here too, if it is populated at that time.

[nbd]

I think the bridge should not touch the MAC address of member devices. It is unnecessary and it would cause severe issues with wifi devices. If the MAC address of DSA devices is wrong, then that should be fixed instead (and that belongs to a different ticket).

[jow]

Milestone Backfire 10.03.2 deleted

[christof.schulze@…]

I just wasted quite some time debugging why arp packages are received on the members interfaces but not seen and answered on the bridge. Setting the MAC addresses of bridge and members to be the same solved the issue. If changing the MAC addresses of the members is unnecessary, then there must be another way to get connectivity. What is the proper way of solving this, if not by changing the mac?

[geek007]

I found same bug in CC 15.05.1 for wan bridge.

root@openwrt:/# ifconfig | grep HWaddr
br-lan Link encap:Ethernet HWaddr 92:A2:59:B1:FF:10
br-wan Link encap:Ethernet HWaddr 92:A2:59:B1:FF:11
eth0 Link encap:Ethernet HWaddr 92:A2:59:B1:FF:10
eth0.2 Link encap:Ethernet HWaddr 92:A2:59:B1:FF:10
eth0.3 Link encap:Ethernet HWaddr 92:A2:59:B1:FF:10
eth0.4 Link encap:Ethernet HWaddr 92:A2:59:B1:FF:10
eth0.5 Link encap:Ethernet HWaddr 92:A2:59:B1:FF:10
eth0.6 Link encap:Ethernet HWaddr 92:A2:59:B1:FF:10

root@openwrt:/# brctl show

bridge name bridge id STP enabled interfaces

br-lan 7fff.92a259b1ff10 no eth0.3

eth0.4

eth0.5
eth0.6

br-wan 7fff.92a259b1ff11 no eth0.2

br-wan and eth0.2 has different MAC.

CC use netifd which is in C instead of network scripts in older versions.
It makes it very difficult to fix this bug, I am still working on it.
If someone find fix, please update here.

UPDATE 1:
I also found eth0 eth0.2 eth0.3 eth0.4 eth0.5 eth0.6 MAC change for every reboot.
but br-lan and br-wan MAC is set from /etc/config/network.

root@openwrt:/# ifconfig | grep HWaddr
br-lan Link encap:Ethernet HWaddr 1E:C9:28:27:23:8E
br-wan Link encap:Ethernet HWaddr 1E:C9:28:27:23:8D
eth0 Link encap:Ethernet HWaddr C2:B8:74:D9:92:CE
eth0.2 Link encap:Ethernet HWaddr C2:B8:74:D9:92:CE
eth0.3 Link encap:Ethernet HWaddr C2:B8:74:D9:92:CE
eth0.4 Link encap:Ethernet HWaddr C2:B8:74:D9:92:CE
eth0.5 Link encap:Ethernet HWaddr C2:B8:74:D9:92:CE
eth0.6 Link encap:Ethernet HWaddr C2:B8:74:D9:92:CE