wlan0 interface mac/ether address being identical when making identical systems in production

GoogleGroups
1

Hi,
I am trying to make identical embedded systems in production with an SD card, the SD card image is flashed from a working BBBW board. The issue I have is the newly programmed BBBW would have the same wlan0 mac/ether address as the original board, as opposed to their own MAC address one would expect. With all the programmed systems having the same interface mac address they will get the same IP from a DHCP server, which is obviously not acceptable.

I am not using /etc/network/interfaces file to configure wlan0, I assume the interface is configured and brought up by connman service. I am thinking there might be two ways to resolve this:

  1. find out how the interface mac address is assigned at startup and hopefully there is a way to fix it there.
  2. manually re-assign the correct wlan0 mac address with a script at startup, but not sure what’s the best approach here either.

Any input would be much appreciated.

Thanks,
Dan

2

For the BBBW, by default we grab cpsw0 for wlan0..

https://github.com/rcn-ee/repos/blob/master/bb-wl18xx-firmware/suite/jessie/debian/bb-wl18xx-wlan0#L210

set_wlan_0_mac_from_cpsw_0:

https://github.com/rcn-ee/repos/blob/master/bb-wl18xx-firmware/suite/jessie/debian/bb-wl18xx-wlan0#L132

set_wlan_0_mac:

https://github.com/rcn-ee/repos/blob/master/bb-wl18xx-firmware/suite/jessie/debian/bb-wl18xx-wlan0#L57

In set_wlan_0_mac, it looks ugly*, as we actually "patch" the firmware
( /lib/firmware/ti-connectivity/wl1271-nvs.bin ), but then make sure
when updated it's stored in the initramfs.

TI has a crazier tool that required even more stuff running, then the
6 dd commands we use..

Regards,

3

Thanks very much for your help Robert, this is exactly what I was looking for.

Cheers,
Dan

4

Hi Robert,

By the way, I’m curious why don’t you just use 00:00:00:00:00:00 as a MAC instead? If you patch wl1271-nvs.bin and replace ‘deadbeef’ with 00:…, TI WLAN driver will attempt to read wl1271-nvs.bin, and if ‘00:00…’ is stored, it will automatically use wl18xx built-in MAC, which is unique for every wireless chip produced by TI. Of course, this will only work for wl18xx chips, but most wireless-capable Beaglebones come with wl18xx.

In other words, if you patch wl1271-nvs.bin and replace ‘deadbeef’ with ‘00:00:00…’, or completely remove wl1271-nvs.bin, no other patches or scripts will be required, and WLAN MAC will be assigned automatically.

5

Are you Serious?

Jason? can you confirm with TI's wifi team?

I'm about to jump on an airplane to Europe, but i'll throw a bbgw into
my luggage and test this when i land tomorrow.

If this works with all our wl1835 productions units, i'll pre-patch
the firmware at image create time and rip out all the "eeprom/mac"
hacks that waste boot time..

Regards,

6

Yep, I’m serious. It works on our custom BBGW-like hardware.

/drivers/net/wireless/ti/wl18xx/main.c: wl18xx_get_mac() retrieves built-in MAC from the fuses (WL18XX_REG_FUSE_BD_ADDR_1) and stores into fuse_oui_addr.



Next, in:

/drivers/net/wireless/ti/wlcore/main.c: [wl1271_register_hw](https://elixir.bootlin.com/linux/v3.9/source/drivers/net/wireless/ti/wlcore/v3.9/ident/wl1271_register_hw)() the code checks for nvs_len and retrieves nic_addr+out_addr from nvs_ptr.



However:

if (oui_addr == 0 && nic_addr == 0) {
		oui_addr = wl->fuse_oui_addr;


...



So, if NVS is zeroed or conf file is missing, built-in 'fused' MAC is used.

Of course, 'correct' way to fix that would involve a bit more work in the kernel: not only check for '00:00..', but also for 'DE:AD:BE:EF', so that the same wl1271-nvs.bin can be used for all wireless modules.

But for our own needs, just removing wl1271-nvs.bin or patching it with 00:00... worked flawlessly.



 Eugene