On 10/18/2016 12:00 AM, John Crispin wrote:
On 18/10/2016 08:54, J Mo wrote:
On 10/17/2016 11:22 PM, John Crispin wrote:
+boot_hook_add preinit_main preinit_assign_mtd2block
diff --git 
new file mode 100644
index 0000000..b8246ab
--- /dev/null
+++ b/target/linux/ipq806x/base-files/lib/preinit/05_set_iface_mac_ipq806x.sh
@@ -0,0 +1,21 @@
+# Copyright (C) 2009 OpenWrt.org
+. /lib/ipq806x.sh
+. /lib/functions/system.sh
+preinit_set_mac_address() {
+       case $(ipq806x_board_name) in
+               nbg6817)
+                       mac_lan=$(dd if=/dev/mtdblock9 bs=1 skip=4 count=65532 
2>/dev/null | tr \\0 \\n | grep ^ethaddr= | cut -d= -f2)
+                       [ -n "$mac_lan" ] && {
+                               ifconfig eth0 hw ether "$mac_lan"
+                               mac_wan=$(macaddr_add "$mac_lan" 1)
+                               ifconfig eth1 hw ether "$mac_wan"
+                       }
+                       ;;
+       esac
please set this inside
target/linux/ipq806x/base-files/etc/board.d/02_network   you can find an
example of how to set the mac inside

This needs to go into preinit or the non-unique MAC addresses will be
propagated to all user-configured VLAN subinterfaces, if VLANs are used.
I have the same problem with my ipq806x device.

Putting the config into the board.d network file is not sufficient,
because it will only set the correct MAC address on whichever interface
belongs to the "wan" and/or "lan" interface-policy(or whatever you call
it). If that interface is a sub-interface (eth0.1), then the hardware
interface (eth0) remains unfixed, and thus all other VLAN sub-interfaces
end up with with the non-unique MAC addresses, resulting in ethernet
address conflicts if more than one device is connected to a network.

I am not sure why the other ipq806x devices are not doing this. They all
have the same problem.
in that case the board.d config generating code needs to be fixed. a
workaround hack just hides the real issue.

There are about two dozen other devices with this workaround/hack already in LEDE, all for various reasons of not having proper MAC addresses set in the hardware.

Isn't this exactly what the preinit stage is for? Basically a staging point that an initrd would normally perform (if all devices had one)?

I'm agnostic for how it gets fixed, but I'm not confident that doing something after pre-init will be certain to prevent further issues. I'm also not qualified to claim that it will be a problem either, so don't take me too seriously. I don't know the boot process well enough, or how/if LEDE intends to change it.

Lede-dev mailing list

Reply via email to