Yes, that's all true. However...
Random MAC address assignment tends to cause devices to be assigned a
different IP address on each reboot.
This often doesn't play nicely with port forwarding.
It's difficult to "prove" the RK3308 cpu serial numbers are unique, but
they should be and the few I've tested have been.
- brent
Kalle Valo wrote:
Larry Finger <Larry.Finger@xxxxxxxxxxxx> writes:
On 2/17/24 23:13, Brent Roman wrote:
Larry,
Radxa confirmed that they do not program the eFUSE on these boards.
We do not get a sensible MAC from the chip, so I derive a one from
the CPU's unique serial number.
It's a hack, but it works well and is standard's compliant.
The RockPI-S a *very* inexpensive board, so I can understand Radxa
wanting to minimize the time spent configuring each one.
https://shop.allnetchina.cn/products/rock-pi-s
The vendor driver seems to deal with this by applying typical gain
parameters when the eFUSE is invalid.
With that driver, this board's WiFi performs beautifully, despite
the unprogrammed eFUSE.
Would you accept a patch to add this logic to RTW88?
Of course a patch would be accepted. Ultimately, the changes should be
made to the wireless-next code base, and sent to this mailing list. To
make things easier, you can send me a patch file for the rtw88 repo,
and I can reformat it for wireless-next and send it to the mailing
list under your signed-off-by. Either one would work.
Thanks for sorting this out. I like the idea of deriving the MAC
address from the CPU serial number. That is unique and reproducible.
But make sure that the CPU serial number is really unique. If it's not
that can cause MAC address collisions which is not good.
Usually wireless drivers create a random address if a stored MAC address
is not available.
--
Brent Roman MBARI
Software Engineer Tel: (831) 775-1808
mailto:brent@xxxxxxxxx http://www.mbari.org/~brent
