All of lore.kernel.org
 help / color / mirror / Atom feed
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

      reply	other threads:[~2019-10-29  8:14 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-28 21:19 ath11k: (broken) mac address reporting by firmware Sven Eckelmann
2019-10-29  8:14 ` Sven Eckelmann [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1864155.BGtVDA1Edn@bentobox \
    --to=sven@narfation.org \
    --cc=ath11k@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.