Bogus mac addresses for wifi interfaces on engenius eap1300 ipq40xx ath10k

For Developers
1

I have a number of EnGenius EAP1300 APs, and I'm working on getting them supported a bit better in OpenWRT.

The mac addresses for the wifi interfaces are not getting populated correctly at boot.

I have tried adding entries for the EAP1300 /etc/hotplug.d/firmware/11-ath10k-caldata and confirmed by adding some debugging code that the board and both radios are being matched, and the caldata seems to be patched appropriately. However, the mac addresses still come up based on the data in the 0:ART mtd partition.

What should I do next to troubleshoot this? It seems like the driver is loading the data directly from the 0:ART partition, which comes up as read-only, so I can't patch it there.

2

See if it's not the same problem

or add this to your wifi-iface section:

option macaddr 'xx:xx:xx:xx:xx:xx'
3

The .dts file doesn't have anything controlling the wifi mac address.

I know I can do various hacks to override the mac address after the device is loaded, but I would strongly prefer to "properly" fix it.

4

What you mean dts doesnt controlling mac address? Mac address info was program in to art partition, the dts file was informed where art partition and where off set mac address is.

5

Looking at Openwrt master/snapshot:
Because the device is now using nvmem to provide the caldata: https://github.com/openwrt/openwrt/commit/cfc13c44595db591092859fc6adc71f1d8159c50#diff-fdefa47b984cdf9d942d1094cf5442c6baecda84abad25b7a41321ff230a6fcb, the caldata file built by the hotplug script probably won't be reached by the ath10k driver. The caldata loaded through nvmem from the device flash should already have the correct MACs, but sometimes manufactures don't bother to set this per-device, or get it wrong.

You can also provide a mac-address nvmem cell, and OpenWrt has the mac-address-increment DTS property available to adjust this. Example in qcom-ipq4018-rutx.dtsi: https://github.com/openwrt/openwrt/commit/cfc13c44595db591092859fc6adc71f1d8159c50#diff-676d793247392f87cf022313d00b8b66877f4be1988a641e1e7d81f246b2bab9. So find where a MAC address is reliably stored somewhere on flash, set up an nvmem cell for it, add that cell to the wifi node. Increment it if need be. Can also be fetch from u-boot env, with the appropriate driver: https://github.com/openwrt/openwrt/commit/952c738c0fe360ae074fbf6a87d03883157bc2dd
Make a note in your commit message detailing how OEM firmware uses these MAC addresses, and if/what they are marked as on the sticker on the device.

1 Like
6

Thank you!

sometimes manufactures don't bother to set this per-device

Indeed, this one did not. I found the OEM startup script which sets it with iwpriv wifiX setHwaddr XX:XX:XX:XX:XX:XX...

I did figure out how to update the caldata with the correct mac address myself from u-boot via serial. Apparently the vendor doesn't bother to set any of the flash partitions read-only, so I could just modify it before flashing openwrt.

stored somewhere on flash

Yeah, it's in u-boot env as uppercase ascii...

Can also be fetch from u-boot env

So, I'd then mark the partition as u-boot, in the dts?

7

Example here:

Create, or add the u-boot,env flash partition with that compatible.
That lets the u-boot NVMEM parser (when available―will need to activate it in kernel config) parse the u-boot key value store: https://github.com/openwrt/openwrt/blob/master/target/linux/generic/backport-5.15/807-v6.1-0002-nvmem-add-driver-handling-U-Boot-environment-variabl.patch

Then you can refer to the NVMEM cell by the DTS label for it:

1 Like
8

Great, I will try that and submit a patch if it works!

9

It does work, but I have to pull the mac-address-ascii patch into the hacks-5.10 directory for 22.03.3.

10

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.