From: "Daryl Van Vorst" <daryl@wideray.com>
To: "'Marcel Holtmann'" <marcel@rvs.uni-bielefeld.de>
Cc: "'BlueZ Mailing List'" <bluez-devel@lists.sourceforge.net>
Subject: RE: Rfcomm qualification
Date: Wed, 30 Jul 2003 09:25:12 -0700 [thread overview]
Message-ID: <000501c356b7$2887faf0$1a01010a@baked> (raw)
In-Reply-To: <1059519805.26914.127.camel@pegasus>
Marcel,
Yes, it's ok that the tester doesn't send the PN command. In 1.0B, the PN
command is optional. In the 1.1 spec, part F:1, section 5.5.3 "DLC paramete=
r
negotiation (PN)", it says that it is optional in the TS 07.10 spec, but is
mandatory in BT spec 1.1 and later.
Will making the default value of credits zero break other things?
-Daryl.
> -----Original Message-----
> From: Marcel Holtmann [mailto:marcel@rvs.uni-bielefeld.de]=20
> Sent: July 29, 2003 4:03 PM
> To: Daryl Van Vorst
> Cc: BlueZ Mailing List
> Subject: Re: Rfcomm qualification
>=20
>=20
> Hi Daryl,
>=20
> > We ran into another 1.0B problem with rfcomm testing. We=20
> didn't notice=20
> > this last time because the tests were done slightly differently=20
> > (without an automated tester).
> >=20
> > The tester acts as a 1.0B device and establishes a=20
> connection with the=20
> > IUT. The IUT sent credits (pf bit =3D 1) after the MSC echange. It=20
> > shouldn't. Attached is an hcidump of it.
>=20
> the problem is that the tester don't sends a PN CMD (btw is=20
> this really
> allowed?) and so we use RFCOMM_MAX_CREDITS at two points=20
> (once for the session and for every DLC). If the PN CMD is=20
> present and shows us a 1.0b device we set credits to zero and=20
> don't make use of credit based flow control. It seems that=20
> the default value of credits must be zero and not RFCOMM_MAX_CREDITS.
>=20
> Regards
>=20
> Marcel
>=20
>=20
>=20
next prev parent reply other threads:[~2003-07-30 16:25 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-07-29 20:58 Rfcomm qualification Daryl Van Vorst
2003-07-29 23:03 ` [Bluez-devel] " Marcel Holtmann
2003-07-30 16:25 ` Daryl Van Vorst [this message]
2003-07-30 17:22 ` [Bluez-devel] " Marcel Holtmann
2003-07-30 21:43 ` Marcel Holtmann
2003-07-31 0:01 ` Max Krasnyansky
2003-07-31 0:48 ` Marcel Holtmann
2003-08-05 17:10 ` Max Krasnyansky
2003-08-05 22:04 ` Marcel Holtmann
2003-08-11 16:43 ` Daryl Van Vorst
2003-08-11 19:03 ` Marcel Holtmann
2003-08-14 17:39 ` Daryl Van Vorst
2003-08-14 17:48 ` 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='000501c356b7$2887faf0$1a01010a@baked' \
--to=daryl@wideray.com \
--cc=bluez-devel@lists.sourceforge.net \
--cc=marcel@rvs.uni-bielefeld.de \
/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.