Hi Community,
I have 3 GooBang Doo M8S-II S905 boxes; CoreELEC runs just fine on them however I’ve run into a problem that existed for me in LibreELEC and carries over here as well. I did some reading and learned that MAC address is dynamically generated from CPU serial # but all my units have the same MAC address and end up fighting for the same IP address delivered to them.
Is there a way for me to generate one for each unit? What I do is install onto a USB key, configure my “base image” and write that out to each unit as I progress in configuration (so I template them, basically) but the problem is the MAC address. Is there a best practice in how to force a unique MAC for each unit?
Model: GooBang Doo M8S-II S905
DTB file: gxbb_p200_2G_1Gbit.dtb
Everything works - just have this one issue.
Anyone have any guidance?
MAC address is only generated for boxes that have no MAC, ie LePotato or are using the default MAC (00:15:18:01:81:31) or have an invalid MAC, so I’m guessing your boxes falls outside of this.
Which MAC are your devices using?
All three units are using 02:00:08:EB:86:27
CoreELEC:~ # ifconfig -a
eth0 Link encap:Ethernet HWaddr 02:00:08:EB:86:27
inet addr:192.168.1.142 Bcast:192.168.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1318192 errors:0 dropped:0 overruns:0 frame:0
TX packets:325866 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1902889123 (1.7 GiB) TX bytes:22001606 (20.9 MiB)
Interrupt:40
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:4096 Metric:1
RX packets:9 errors:0 dropped:0 overruns:0 frame:0
TX packets:9 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:480 (480.0 B) TX bytes:480 (480.0 B)
wlan0 Link encap:Ethernet HWaddr E0:76:D0:1A:DA:4A
inet6 addr: fe80::e276:d0ff:fe1a:da4a/64 Scope:Link
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:37 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:12967 (12.6 KiB)
CoreELEC:~ # lsmod
Module Size Used by
sha1_generic 2204 0
hci_uart 30134 1
bluetooth 339002 2 hci_uart
6lowpan_iphc 10183 1 bluetooth
8021q 19007 0
dhd 752447 0
cfg80211 374858 1 dhd
mali 192433 5
ir_lirc_codec 4996 0
lirc_dev 11232 1 ir_lirc_codec
wifi_dummy 806 0
ir_mce_kbd_decoder 4796 0
ir_jvc_decoder 2511 0
ir_sanyo_decoder 2899 0
ir_sony_decoder 2417 0
ir_rc6_decoder 3423 0
ir_rc5_decoder 2439 0
ir_nec_decoder 3367 0
meson_ir 4021 0
rc_core 17268 11 lirc_dev,meson_ir,ir_lirc_codec,ir_rc5_decoder,ir_nec_decoder,ir_sony_decoder,ir_mce_kbd_decoder,ir_jvc_decoder,ir_rc6_decoder,ir_sanyo_decoder
amlvideodri 12066 0
videobuf_res 5322 1 amlvideodri
videobuf_core 16549 2 amlvideodri,videobuf_res
videodev 131761 1 amlvideodri
dwc_otg 233249 0
fbcon 38031 0
bitblit 4468 1 fbcon
softcursor 1168 1 bitblit
font 7327 1 fbcon
CoreELEC:~ # cat /proc/cpuinfo
Processor : AArch64 Processor rev 4 (aarch64)
processor : 0
processor : 1
processor : 2
processor : 3
Features : fp asimd evtstrm crc32 wp half thumb fastmult vfp edsp neon vfpv3 tlsi vfpv4 idiva idivt
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x0
CPU part : 0xd03
CPU revision : 4
Hardware : Amlogic
Serial : 1f0c13003209a3a13e932786eb080000
CoreELEC:~ # cat /proc/interrupts
CPU0 CPU1 CPU2 CPU3
29: 0 0 0 0 GIC 29 arch_timer
30: 5599505 6833535 6352126 5580923 GIC 30 arch_timer
35: 1124628 0 0 0 GIC 35 osd_vsync, vsync
38: 2440852 0 0 0 GIC 38 timerC
40: 683411 0 0 0 GIC 40 eth0
58: 3235 0 0 0 GIC 58 meson_uart
61: 12077228 0 0 0 GIC 61
62: 0 0 0 0 GIC 62 dwc_otg, dwc_otg_hcd:usb2
63: 0 0 26855035 0 GIC 63 dwc_otg, dwc_otg_hcd:usb1
64: 286323 0 0 0 GIC 64 parser
76: 192776 0 0 0 GIC 76 vdec-1
78: 0 0 0 0 GIC 78 deinterlace
89: 13 0 0 0 GIC 89 hdmitx
92: 0 0 0 0 GIC 92 Meson TimerF
99: 1 0 0 0 GIC 99 sd_in
100: 4102 0 0 0 GIC 100 bcmsdh_sdmmc
101: 1 0 0 0 GIC 101 sd_out
121: 1124626 0 0 0 GIC 121 rdma
182: 6 0 0 0 GIC 182 ge2d
192: 257509 0 0 0 GIC 192 Mali_GP
193: 0 0 0 0 GIC 193 Mali_GP_MMU
194: 128768 0 0 0 GIC 194 Mali_PP_Broadcast
196: 0 0 0 0 GIC 196 Mali_PP0
197: 0 0 0 0 GIC 197 Mali_PP0_MMU
198: 0 0 0 0 GIC 198 Mali_PP1
199: 0 0 0 0 GIC 199 Mali_PP1_MMU
200: 0 0 0 0 GIC 200 Mali_PP2
201: 0 0 0 0 GIC 201 Mali_PP2_MMU
225: 1 0 0 0 GIC 225 meson_uart
228: 32 0 0 0 GIC 228 ir-meson
231: 0 590 0 0 GIC 231 hdmi_aocec
241: 94195 0 0 0 GIC 241
242: 303164 0 0 0 GIC 242
248: 24907 0 0 0 GIC 248 sd_emmc
249: 0 0 0 0 GIC 249 sd_emmc
250: 94783 0 0 0 GIC 250 sd_emmc
IPI0: 1860403 1753036 2322117 1739753 Rescheduling interrupts
IPI1: 74 78 69 74 Function call interrupts
IPI2: 15 12 10 20 Single function call interrupts
IPI3: 0 0 0 0 CPU stop interrupts
IPI4: 0 0 0 0 Timer broadcast interrupts
IPI5: 73634 15836 54502 61855 IRQ work interrupts
CoreELEC:~ # cat /proc/partitions
major minor #blocks name
7 0 149960 loop0
179 0 7634944 mmcblk0
179 1 4096 mmcblk0p1
179 2 65536 mmcblk0p2
179 3 524288 mmcblk0p3
179 4 8192 mmcblk0p4
179 5 32768 mmcblk0p5
179 6 32768 mmcblk0p6
179 7 8192 mmcblk0p7
179 8 8192 mmcblk0p8
179 9 32768 mmcblk0p9
179 10 32768 mmcblk0p10
179 11 524288 mmcblk0p11
179 12 32768 mmcblk0p12
179 13 1048576 mmcblk0p13
179 14 5148672 mmcblk0p14
179 96 512 mmcblk0rpmb
179 64 4096 mmcblk0boot1
179 32 4096 mmcblk0boot0
I just noticed this:
Serial : 1f0c13003209a3a13e932786eb080000
Do all 3 of your devices have the same CPU serial?
No, they’re all unique. Since I’m having the MAC collision, I decided to put one on WiFi (vs wired) and interestingly enough, the eth0 MAC is unique. But if I don’t use WiFi and boot up with wired, it gets the same MAC address as one already online (thus the collision.)
CoreELEC:~ # cat /proc/cpuinfo
Processor : AArch64 Processor rev 4 (aarch64)
processor : 0
processor : 1
processor : 2
processor : 3
Features : fp asimd evtstrm crc32 wp half thumb fastmult vfp edsp neon vfpv3 tlsi vfpv4 idiva idivt
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x0
CPU part : 0xd03
CPU revision : 4
Hardware : Amlogic
Serial : 1f0c13003209a3a13e932786eb086f51
CoreELEC:~ # ifconfig -a
eth0 Link encap:Ethernet HWaddr 52:6F:08:EB:86:27
inet addr:192.168.1.146 Bcast:192.168.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:75 errors:0 dropped:0 overruns:0 frame:0
TX packets:98 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:6492 (6.3 KiB) TX bytes:12989 (12.6 KiB)
Interrupt:40
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:4096 Metric:1
RX packets:9 errors:0 dropped:0 overruns:0 frame:0
TX packets:9 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:480 (480.0 B) TX bytes:480 (480.0 B)
wlan0 Link encap:Ethernet HWaddr AC:83:F3:05:C1:34
inet addr:192.168.1.104 Bcast:192.168.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:6893 errors:0 dropped:0 overruns:0 frame:0
TX packets:4852 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:8481870 (8.0 MiB) TX bytes:481732 (470.4 KiB)
The only thing that isn’t unique amongst them is that they’re all connecting to my main switch via Powerline adapters - I have other hardware (non-CoreELEC related) doing this without issue. I’ll conduct some more testing but if I were to now disable WiFi and boot up with the wired connection, it’ll get the same MAC as one box I already have online (in the living room.)
OK - interesting update. The unit I enabled WiFi on (and subsequently disabled) is retaining the unique MAC address I posted above when in wired mode. I’ll need to write out CoreELEC to the unit and reboot to verify it sticks and then boot the USB stick in the other unit (which has unique serial# btw) to see if it’s retaining the new unique MAC address. If so, I’ll try enabling WiFi and see if it decides to generate a new unique MAC.
I wonder if enabling WiFi forced some sort of cache update? I remember seeing something here in the forum where network information is cached somewhere in the directory structure and with enabling WiFi, forced it to update or cleared entirely? Just a guess.
Wonder if there’d be a good reason to have some sort of toggle that allows a user to force network update/cache clear/generate unique MAC on boot? Something to that effect that fits the project design?
EDIT: typo; MAC==serial#
Rebooted several times, it’s sticking - haven’t had a chance to run installtointernal but I suspect it’ll be fine. I’ll be trying the 3rd box this weekend and will report what I find.
@anon88919003: Is the MAC address held/set by connman? I found this directory under .cache:
Original image:
CoreELEC:~/.cache/connman # ls -la
total 16
drwxr-xr-x 3 root root 4096 Dec 31 2014 .
drwxr-xr-x 10 root root 4096 May 10 18:24 ..
drwx------ 2 root root 4096 Dec 31 2014 ethernet_000000000000_cable
-rw------- 1 root root 136 Dec 31 2014 settings
CoreELEC:~/.cache/connman/ethernet_000000000000_cable # ls -la
total 16
drwx------ 2 root root 4096 Dec 31 2014 .
drwxr-xr-x 3 root root 4096 Dec 31 2014 ..
-rw------- 1 root root 4096 Dec 31 2014 data
-rw------- 1 root root 269 Dec 31 2014 settings
CoreELEC:~/.cache/connman/ethernet_000000000000_cable # cat settings
[ethernet_000000000000_cable]
Name=Wired
AutoConnect=true
Modified=2015-01-01T00:00:22.346345Z
IPv4.method=dhcp
IPv6.method=off
IPv6.privacy=disabled
IPv4.netmask_prefixlen=24
IPv4.local_address=192.168.1.34
IPv4.gateway=192.168.1.1
IPv4.DHCP.LastAddress=192.168.1.142
WiFi enabled-disabled box:
CoreELEC:~/.cache/connman # ls -la
total 5
drwxr-xr-x 4 root root 1024 Dec 31 2014 .
drwxr-xr-x 11 root root 1024 Jun 29 09:20 ..
drwx------ 2 root root 1024 Dec 31 2014 ethernet_000000000000_cable
-rw------- 1 root root 136 Dec 31 2014 settings
drwx------ 2 root root 1024 Jun 29 09:11 wifi_ac83f305c134_45445741533234_managed_psk
CoreELEC:~/.cache/connman/ethernet_000000000000_cable # ls -la
total 8
drwx------ 2 root root 1024 Dec 31 2014 .
drwxr-xr-x 4 root root 1024 Dec 31 2014 ..
-rw------- 1 root root 4096 Dec 31 2014 data
-rw------- 1 root root 186 Dec 31 2014 settings
-rw------- 1 root root 186 Dec 31 2014 settings.PUCNRX
CoreELEC:~/.cache/connman/ethernet_000000000000_cable # cat settings
[ethernet_000000000000_cable]
Name=Wired
AutoConnect=true
Modified=2015-01-01T00:01:10.925485Z
IPv4.method=dhcp
IPv4.DHCP.LastAddress=192.168.1.146
IPv6.method=off
IPv6.privacy=disabled
CoreELEC:~/.cache/connman/ethernet_000000000000_cable # cat settings.PUCNRX
[ethernet_000000000000_cable]
Name=Wired
AutoConnect=true
Modified=2015-01-01T00:01:10.762486Z
IPv4.method=dhcp
IPv4.DHCP.LastAddress=192.168.1.142
IPv6.method=off
IPv6.privacy=disabled
The file “data” has a what looks to be control-char/regex in it (both units are the same content):
Just wondering if I run into a dupe MAC on the 3rd box if clearing this would help rather than connecting WiFi and disconnecting it (which seems to work around my issue.)
Just for clarity - the “original image” is the 8.90.4 image I originally created on a USB key and wrote out via installtointernal on the living room box, the WiFi-enabled-disabled unit is in my bedroom and currently booting off the same key but not written to internal yet.
Well bad news - I rebooted the box I did the WiFi-enabled-disabled on and it’s back the duplicate MAC address again. Not sure how else to troubleshoot this.
EDIT: /proc/cpuinfo shows the same serial # as the box in the living room 
- will continue to troubleshoot as best as I can.
EDIT: Tried clearing out /storage/.cache/connman/ethernet* and wifi* and rebooted; the ethernet profile was recreated but box still has duplicate MAC and CPU serial #
EDIT: Tried fw_setenv ethaddr - no luck, survives reboots but MAC remains the same
EDIT: Sigh… after a dozen reboots or so trying various things, the MAC/Serial# is unique again and not duplicated
EDIT: Installing CoreELEC fresh from USB key to device (installtointernal) it is retaining the duplicate MAC/Serial# - I’m out of road and short of changing the MAC creation based on serial# I don’t know what else to do.
@anon88919003 - an idea, instead of using CPU Serial# (which after much googling, is apparently common for some Amlogic devices) how about something like this:
KODIMASTERBDRM:~ # dbus-uuidgen | cut -c1-12 | sed -e 's/../:&/2g' -e 's/^://' | tr [:lower:] [:upper:]
F1:20:CC:8F:57:95
Figured it out - finally…
If I reset (reboot) the device the MAC/Serial# doesn’t change. However, if I choose to power the device down (via Power Menu) and pull the power/reseat it, the device comes up with a unique MAC/Serial#
Not sure what to do with this information other than pass it on and resolve the issue if it occurs. Unfortunately, my remote will not power back on the unit but seeing as how they generally just stay powered on 99.999% of the time, it’s do-able.
