Re: ath11k: (broken) mac address reporting by firmware

From: Sven Eckelmann <sven@narfation.org>
To: ath11k@lists.infradead.org
Subject: Re: ath11k: (broken) mac address reporting by firmware
Date: Tue, 29 Oct 2019 09:14:19 +0100	[thread overview]
Message-ID: <1864155.BGtVDA1Edn@bentobox> (raw)
In-Reply-To: <6869330.LJuu87LXsD@bentobox>

[-- Attachment #1.1: Type: text/plain, Size: 1948 bytes --]

On Monday, 28 October 2019 22:19:02 CET Sven Eckelmann wrote:
> I've just tested here WLAN.HK.2.0.0.1-00043-QCAHKSWPL_SILICONZ-1 and noticed 
> that the mac addresses returned by the firmware are not the ones stored in the 
> caldata.bin. It was observed that:
> 
> * first octet is always set to 0x00
> * octet 2, 3 & 4 are copied over from the caldata.bin
> * octet 5 is random
> * octet 6 is random
[...]

Forgot to post the actual raw values (word0 and word1) from the firmware. So 
here this part:

* WMI_TAG_READY_EVENT:

  - addresses: 3 (but only 2 radios)
  - mac_addr:

    + addr: 00:d9:b8:17:76:76
    + word0: 0x17b8d900
    + word1: 0x00007676

* WMI_TAG_ARRAY_FIXED_STRUCT:

  - addr_list[0]:

    + addr: 00:d9:b8:17:aa:db
    + word0: 0x17b8d900
    + word1: 0x0000dbaa

  - addr_list[1]:

    + addr: 00:d9:b8:17:46:a7
    + word0: 0x17b8d900
    + word1: 0x0000a746

  - addr_list[2]:

    + addr: 00:03:7f:12:f2:c3
    + word0: 0x127f0300
    + word1: 0x0000c3f2

So it is also not a problem of incorrectly shifted addresses. They are really 
not the addresses which are in the caldata.bin

[...]
> Is this a known bug in the firmware? Is it possible to retrieve the actual mac 
> address(es) from the firmware? Using hardware with randomly changing mac 
> addresses is not really a nice thing.

It seems like the problem can be solved by changing following things:

* Offset 0x03E: 0 -> 1 (enable non random mac address reporting?)
* Offset 0x224: 6 -> 2 (report only two mac addresses for the two radios)

The checksum has to be recalculated using:

1. set the two bytes on offset 0xa and 0xb to 0xff
2. calculate the checksum[0] by XORing all odd bytes
3. calculate the checksum[1] by XORing all even bytes
4. save the checksum[0] to offset 0xa
5. save the checksum[1] to offset 0xb

Maybe someone can correct me here because I've just documented what I found
without spec or access to the firmware code.

Kind regards,
	Sven

[-- Attachment #1.2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 146 bytes --]

_______________________________________________
ath11k mailing list
ath11k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath11k