All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marcel Holtmann <marcel@holtmann.org>
To: BlueZ development <bluez-devel@lists.sourceforge.net>
Subject: Re: [Bluez-devel] hcidump EDR packet type
Date: Tue, 23 Jan 2007 18:25:11 +0100	[thread overview]
Message-ID: <1169573111.5861.12.camel@violet> (raw)
In-Reply-To: <45B5AD79.8020104@st.com>

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

  reply	other threads:[~2007-01-23 17:25 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-01-23  3:42 [Bluez-devel] hcidump EDR packet type Quinton Yuan
2007-01-23  6:23 ` Marcel Holtmann
2007-01-23  6:38 ` Mayank BATRA
2007-01-23 17:25   ` Marcel Holtmann [this message]
2007-01-29 10:38     ` Mayank BATRA
2007-01-29 10:55       ` Marcel Holtmann
2007-01-29 11:08         ` Mayank BATRA

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=1169573111.5861.12.camel@violet \
    --to=marcel@holtmann.org \
    --cc=bluez-devel@lists.sourceforge.net \
    /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.