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
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel