[Bluez-devel] hcidump EDR packet type

[Bluez-devel] hcidump EDR packet type

[Quinton Yuan]

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

Hi, There

 

Wondering someone can help to enlighten me on where hci packet type bit
is reversed for  change connection packet type command (issued by
hcitool) for EDR mode, based on the below hcidump, seems 0x2000 is
passed down (which should be 0x1306), however, return message ptype
0x1306 is correct even decoding is not right.

 

Thanks/Quinton

 

ot@localhost btsco]# hcidump -V

HCI sniffer - Bluetooth packet analyzer ver 1.32

device: hci0 snap_len: 1028 filter: 0xffffffff

< HCI Command: Change Connection Packet Type (0x01|0x000f) plen 4

    handle 1 ptype 0x2000

    Packet type: 3-DH5 

> HCI Event: Command Status (0x0f) plen 4

    Change Connection Packet Type (0x01|0x000f) status 0x00 ncmd 1

> HCI Event: Connection Packet Type Changed (0x1d) plen 5

    status 0x00 handle 1 ptype 0x1306

    Packet type: 2-DH1 2-DH3 2-DH5 3-DH1 3-DH3 

> HCI Event: Command Status (0x0f) plen 4

    Unknown (0x00|0x0000) status 0x00 ncmd 2

 


[-- Attachment #1.2: Type: text/html, Size: 5120 bytes --]

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

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

[-- Attachment #3: Type: text/plain, Size: 164 bytes --]

_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] hcidump EDR packet type

[Marcel Holtmann]

Hi,

> Wondering someone can help to enlighten me on where hci packet type
> bit is reversed for  change connection packet type command (issued by
> hcitool) for EDR mode, based on the below hcidump, seems 0x2000 is
> passed down (which should be 0x1306), however, return message ptype
> 0x1306 is correct even decoding is not right.

what does "hciconfig hci0 features version" tell you about your chip
version and manufacturer.

Regards

Marcel



-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] hcidump EDR packet type

[Mayank BATRA]

Hi Quinton,

> Wondering someone can help to enlighten me on where hci packet type bit
> is reversed for  change connection packet type command (issued by
> hcitool) for EDR mode, based on the below hcidump, seems 0x2000 is
> passed down (which should be 0x1306), however, return message ptype
> 0x1306 is correct even decoding is not right.

In case you wanted to change the packet type to 3-DH5 0x2000 is
perfectly fine since EDR packets are inverted i.e. they will be selected
if the corresponding bit is 0 and not 1. Internally, before sending the
change connection packet type command all stacks (hopefully BlueZ as
well) will xor the packet mask with the EDR packet type list. Thus if
you enabled an EDR packet (eg 0x2000 for 3-DH5), the bit for 3-DH5 will
be made 0 and bits for remaining EDR packets shall be made 1.

0x1306 means that 3-DH5 and DM1 have been selected on the ACL link which
is logical since DM1 is by default selected on all ACL links and you
just changed the packet type to 3-DH5.

=> There is nothing wrong going on except hcidump should be corrected to
parse the packet type mask properly. Here it should have shown only DM1
and 3-DH5.

Best Regards,

Mayank



--
Random Quote Follows:
"In my opinion, shareware tends to combine the worst of commercial
software (no sources) with the worst of free software (no finishing
touches). I simply do not believe in the shareware market at all."
                                              -- Linus Torvalds

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] hcidump EDR packet type

[Marcel Holtmann]

Hi Mayank,

> > Wondering someone can help to enlighten me on where hci packet type bit
> > is reversed for  change connection packet type command (issued by
> > hcitool) for EDR mode, based on the below hcidump, seems 0x2000 is
> > passed down (which should be 0x1306), however, return message ptype
> > 0x1306 is correct even decoding is not right.
> 
> In case you wanted to change the packet type to 3-DH5 0x2000 is
> perfectly fine since EDR packets are inverted i.e. they will be selected
> if the corresponding bit is 0 and not 1. Internally, before sending the
> change connection packet type command all stacks (hopefully BlueZ as
> well) will xor the packet mask with the EDR packet type list. Thus if
> you enabled an EDR packet (eg 0x2000 for 3-DH5), the bit for 3-DH5 will
> be made 0 and bits for remaining EDR packets shall be made 1.
> 
> 0x1306 means that 3-DH5 and DM1 have been selected on the ACL link which
> is logical since DM1 is by default selected on all ACL links and you
> just changed the packet type to 3-DH5.

actually it is totally wrong. Sending the 3-DH5 bit only means that you
wanna enable DM1 and all EDR packets except 3-DH5, because setting that
bit means you disable that packet type. The corresponding response
should be DM1 + 3-DH5 bit set.

Since this is custom firmware, it is interpreting the bitmask of the
change connection packet type in the wrong way.

And to be clear on this, I don't care about the packet mask at all and
nobody should mess with it (except for testing). Let the link manager
decide which packet type to use. BlueZ can't make any intelligent
decision on which is the best packet type. It doesn't know anything
about the piconet it is using besides its handle.

Regards

Marcel



-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] hcidump EDR packet type

[Mayank BATRA]

Hi Marcel,

> actually it is totally wrong. Sending the 3-DH5 bit only means that you
> wanna enable DM1 and all EDR packets except 3-DH5, because setting that
> bit means you disable that packet type. The corresponding response
> should be DM1 + 3-DH5 bit set.
> 
> Since this is custom firmware, it is interpreting the bitmask of the
> change connection packet type in the wrong way.
> 
> And to be clear on this, I don't care about the packet mask at all and
> nobody should mess with it (except for testing). Let the link manager
> decide which packet type to use. BlueZ can't make any intelligent
> decision on which is the best packet type. It doesn't know anything
> about the piconet it is using besides its handle.

OK. But my question is why display different packet lists in the command
and event?
< HCI Command: Change Connection Packet Type (0x01|0x000f) plen 4
    handle 1 ptype 0x2000
    Packet type: 3-DH5

...

> HCI Event: Connection Packet Type Changed (0x1d) plen 5
    status 0x00 handle 1 ptype 0x1306
    Packet type: 2-DH1 2-DH3 2-DH5 3-DH1 3-DH3

Both of them should show the same packet list. Isn't it?

Best Regards,

Mayank

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] hcidump EDR packet type

[Marcel Holtmann]

Hi Mayank,

> > actually it is totally wrong. Sending the 3-DH5 bit only means that you
> > wanna enable DM1 and all EDR packets except 3-DH5, because setting that
> > bit means you disable that packet type. The corresponding response
> > should be DM1 + 3-DH5 bit set.
> > 
> > Since this is custom firmware, it is interpreting the bitmask of the
> > change connection packet type in the wrong way.
> > 
> > And to be clear on this, I don't care about the packet mask at all and
> > nobody should mess with it (except for testing). Let the link manager
> > decide which packet type to use. BlueZ can't make any intelligent
> > decision on which is the best packet type. It doesn't know anything
> > about the piconet it is using besides its handle.
> 
> OK. But my question is why display different packet lists in the command
> and event?
> < HCI Command: Change Connection Packet Type (0x01|0x000f) plen 4
>     handle 1 ptype 0x2000
>     Packet type: 3-DH5
> 
> ...
> 
> > HCI Event: Connection Packet Type Changed (0x1d) plen 5
>     status 0x00 handle 1 ptype 0x1306
>     Packet type: 2-DH1 2-DH3 2-DH5 3-DH1 3-DH3
> 
> Both of them should show the same packet list. Isn't it?

that must be a bug in their firmware. They should be the same with the
only exception of DM1.

My assumption is that change connection packet type is treating this
command as enable 3-DH5 only. However that is not what that command
means. It means enable DM1 and all 2-* and 3-* packets except 3-DH5.

Regards

Marcel



-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] hcidump EDR packet type

[Mayank BATRA]

Hi Marcel,

> that must be a bug in their firmware. They should be the same with the
> only exception of DM1.
> 
> My assumption is that change connection packet type is treating this
> command as enable 3-DH5 only. However that is not what that command
> means. It means enable DM1 and all 2-* and 3-* packets except 3-DH5.

You are right. Its the job of the firmware and not the host to toggle
the EDR packet type bits (in contrast to what I said in a previous post).

Best Regards,

Mayank

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel