All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marcel Holtmann <marcel@holtmann.org>
To: Archie Pusaka <apusaka@google.com>
Cc: "An, Tedd" <tedd.an@intel.com>,
	"linux-bluetooth@vger.kernel.org"
	<linux-bluetooth@vger.kernel.org>
Subject: Re: [BlueZ] monitor: Fix the incorrect vendor name
Date: Fri, 16 Apr 2021 07:23:25 +0200	[thread overview]
Message-ID: <852D4FDC-5A9E-45B0-83AD-95DB203022B0@holtmann.org> (raw)
In-Reply-To: <CAJQfnxFirWC+ned2sCrJb7nAiBqjCkO6guMNZU_5NCqkAdKzpg@mail.gmail.com>

Hi Archie,

>>> This patch fixes the vendor name is alwasy shown as "Microsoft" even
>>> though a different vendor.
>>> 
>>> < HCI Command: Microsoft Secure Send (0x3f|0x0009) plen 249
>>>       Type: Data fragment (0x01)
>>>> HCI Event: Command Complete (0x0e) plen 4
>>>     Microsoft Secure Send (0x3f|0x0009) ncmd 31
>>>       Status: Success (0x00)
>>> ---
>>> monitor/packet.c | 12 +++---------
>>> 1 file changed, 3 insertions(+), 9 deletions(-)
>>> 
>>> diff --git a/monitor/packet.c b/monitor/packet.c
>>> index d729a01cc..91d2294ff 100644
>>> --- a/monitor/packet.c
>>> +++ b/monitor/packet.c
>>> @@ -9325,18 +9325,12 @@ static const char *get_supported_command(int bit)
>>> 
>>> static const char *current_vendor_str(void)
>>> {
>>> - uint16_t manufacturer, msft_opcode;
>>> + uint16_t manufacturer;
>>> 
>>> - if (index_current < MAX_INDEX) {
>>> + if (index_current < MAX_INDEX)
>>>          manufacturer = index_list[index_current].manufacturer;
>>> -         msft_opcode = index_list[index_current].msft_opcode;
>>> - } else {
>>> + else
>>>          manufacturer = fallback_manufacturer;
>>> -         msft_opcode = BT_HCI_CMD_NOP;
>>> - }
>>> -
>>> - if (msft_opcode != BT_HCI_CMD_NOP)
>>> -         return "Microsoft";
>> 
>>    seems we have a bug here, but the fix can not be correct either. If we are running on Intel firmware and the Microsoft extension is used, it should show Microsoft and not Intel for the vendor commands.
>> 
>> I submitted v2 and I think I took care of the msft_opcode handling but I realized that the msft_event_opcode is also like msft_opcode - each vendor will have a different value.
>> I know the msft_event_code for Intel, which is 0x50, but don't know for Realtek. (Do you happen to know?)
> 
> On my Realtek device the msft_event_code is 8 bytes long: 0x23 0x79
> 0x54 0x33 0x77 0x88 0x97 0x68.


I remember having seen different event prefixes for Realtek controllers. However after re-testing it seems to be the same.

My latest 5.1 dongle has this:

> HCI Event: Command Complete (0x0e) plen 22
      Microsoft Extension (0x3f|0x00f0) ncmd 2
      Read Supported Features (0x00)
        Status: Success (0x00)
        Features: 0x3f 0x00 0x00 0x00 0x00 0x00 0x00 0x00
          RSSI Monitoring feature for BR/EDR
          RSSI Monitoring feature for LE connections
          RSSI Monitoring of LE advertisements
          Advertising Monitoring of LE advertisements
          Verifying the validity of P-192 and P-256 keys
          Continuous Advertising Monitoring
        Event prefix length: 8
        23 79 54 33 77 88 97 68 

And my older 4.2 dongle has this:

> HCI Event: Command Complete (0x0e) plen 22
      Microsoft Extension (0x3f|0x00f0) ncmd 2
      Read Supported Features (0x00)
        Status: Success (0x00)
        Features: 0x0f 0x00 0x00 0x00 0x00 0x00 0x00 0x00
          RSSI Monitoring feature for BR/EDR
          RSSI Monitoring feature for LE connections
          RSSI Monitoring of LE advertisements
          Advertising Monitoring of LE advertisements
        Event prefix length: 8
        23 79 54 33 77 88 97 68

Regards

Marcel


  parent reply	other threads:[~2021-04-16  5:23 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <Tedd Ho-Jeong An <tedd.an@intel.com>
2021-04-14  4:38 ` [BlueZ] monitor: Fix the incorrect vendor name Tedd Ho-Jeong An
2021-04-14  5:07   ` bluez.test.bot
2021-04-14 10:08   ` Marcel Holtmann
2021-04-15  2:25     ` An, Tedd
2021-04-15  3:47       ` Archie Pusaka
2021-04-15  4:34         ` Tedd Ho-Jeong An
2021-04-16  5:23         ` Marcel Holtmann [this message]
2021-04-15  1:48 ` [RFC BlueZ v2] " Tedd Ho-Jeong An
2021-04-15  2:35   ` [RFC,BlueZ,v2] " bluez.test.bot
2021-04-16  5:56 ` [BlueZ PATCH] monitor: Update manpage Tedd Ho-Jeong An
2021-04-16  6:43   ` [BlueZ] " bluez.test.bot
2021-04-16 20:06 ` [BlueZ PATCH] monitor: Add Intel read supported VS features command Tedd Ho-Jeong An
2021-04-16 20:39   ` [BlueZ] " bluez.test.bot
2021-04-17  0:34 ` [BlueZ v2] " Tedd Ho-Jeong An
2021-04-17  1:30   ` [BlueZ,v2] " bluez.test.bot
2021-04-19 13:01   ` [BlueZ v2] " Marcel Holtmann

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=852D4FDC-5A9E-45B0-83AD-95DB203022B0@holtmann.org \
    --to=marcel@holtmann.org \
    --cc=apusaka@google.com \
    --cc=linux-bluetooth@vger.kernel.org \
    --cc=tedd.an@intel.com \
    /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.