This is why you use ath9k hardware, folks. You get the source code that implements the MAC and management layers so you can see exactly what they are doing.
Sounds useful in general, but in this case the problem wasn’t that low-level. It was just some daemon that decided to include a copy of the MAC address in the body of a UDP packet it was sending.
When you have the baseband source code, you can remove the part that allows the host to read the EEPROM MAC address. Replace it with a random number generated on each request.
Then you don't have to care what some daemon does with that random number.
Instead of worrying about handling these unique identifiers, solve the problem at its source: get rid of the unique identifier. Much more reliable solution. The baseband firmware is the lowest level of software at which this fix can be made (everything below it is hardware). If you fix it at some higher level you can never be sure the fix hasn't been circumvented.
comex|2 years ago
KirillPanov|2 years ago
Then you don't have to care what some daemon does with that random number.
Instead of worrying about handling these unique identifiers, solve the problem at its source: get rid of the unique identifier. Much more reliable solution. The baseband firmware is the lowest level of software at which this fix can be made (everything below it is hardware). If you fix it at some higher level you can never be sure the fix hasn't been circumvented.