2016-08-25 15:19 GMT+02:00 Stanislaw Gruszka <[email protected]>: > On Thu, Aug 25, 2016 at 01:12:22PM +0200, Mathias Kresin wrote: >> 2016-08-25 11:33 GMT+02:00 Stanislaw Gruszka <[email protected]>: >> > On Thu, Aug 25, 2016 at 10:19:22AM +0200, Mathias Kresin wrote:
>> CPE = Customer Premises Equipment or the small plastic box from your >> ISP at home. The whole point of the patch is that the MAC stored in >> the wifi EEPROM might not be unique and need to be overridden. I'm >> aware of three different "home router", where each model has the same >> generic ralink MAC address stored in the wifi EEPROM. This can cause >> nasty issues. > > I think we still want MAC from EEPROM instead of random one on systems > without OF. Otherwise we could just use random MAC every time, but this > does not seems lika a good idea. Either I got you wrong, the code does something different than I intended/tested or you misread the code. The mac address stored in the EEPROM is only overridden in case: a) a mac address is defined in the device tree. b) invalid/no mac stored in EEPROM => random one If none of the above is true, the EEPROM mac will be used. What I've added is a). Everything else is the same as before. > Can we check against that particular MAC that repeats on those CPEs and > if it match use random one ? Or use some other identification to find > out that EEPROM MAC is not good ? IMHO this would be a wonky approach. I had a look at the EEPROM MACs from two of the affected devices and spotted just now a coherence with the used wifi chip: VGV7510KW22 (RT3062F): 00:0C:43:30:62:00 ARV7506 (RT3060F): 00:0C:43:30:60:00 IMHO, it would be reckless to assume that it's the same for other affected models. You know, ODMs doing silly things. Personally I prefer to deal with the issue in device tree rather than forcing a random MAC address. This way I can set the MAC used with the stock firmware to fix the issue. Mathias
