Marcel,
Looks like there were two problems related to xon/xoff (and maybe other
parameters) in the rfcomm_recv_rpn() function.
Here's what's happening: (Please excuse me if I'm slightly off on the
terminology)
1. The tester sends a parameter negotiation packet with valid settings an=
d
all bits in the mask set.
2. We send back a response with the XON bit in the mask still set
(indicating that we liked it), but the XON_CHAR field is set to 0. We're
supposed to reply with the valid XON character.
I just took a quick look at the code and it appears that if we like the
value then xon_char is left as the default value of 0, and then sent as suc=
h
at the bottom of the function.
And, yes, we have hcidump -w logs (just not yet at my fingertips to send
you). I'll forward them as soon as I get them.
-Daryl.
-------------------------------------------------------
This SF.net email is sponsored by: ObjectStore.
If flattening out C++ or Java code to make your application fit in a
relational database is painful, don't do it! Check out ObjectStore.
Now part of Progress Software. http://www.objectstore.net/sourceforge
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
James,
> > Finally got some results on those latest rfcomm changes for=20
> > qualification. Looks like there are a few more problems. :(=20
> But we're=20
> > close. :)
> >=20
> Can you outline what hardware you are using to do the test.
> Is it:
> 1) USB bluetooth adapters
> 2) PCI bluetooth adapters
> 3) PCMCIA bluetooth adapters
> 4) Serial bluetooth adapters.
We are using an Ericsson ROK 104001 bluetooth module. It's connected to a
high-speed UART. The stack is running on an ARM processor.
Once qualification testing is complete I'll put together a list of all test=
s
that were performed, and what kind of software tools or programs needed to
be used for each test.
-Daryl.
Daryl Van Vorst wrote:
> James,
>
> Unfortunately I'm not going to be of much help with SCO testing... We've
> been doing our testing with Cetecom (they're on the CC list).
>
> It may be possible for you to arrange something with them if you (or someone
> else) are making a product. Contact Ben Ko ([email protected]) if
> you'd like to discuss it.
>
> -Daryl.
>
I am just an open source developer. I am not making any products or
otherwise profiting from what I am doing.
So, unless CetecomUSA.com do testing for free, I don't think your
suggestion will help me much.
Cheers
James
Daryl Van Vorst wrote:
> Marcel,
>
> Finally got some results on those latest rfcomm changes for qualification.
> Looks like there are a few more problems. :( But we're close. :)
>
Can you outline what hardware you are using to do the test.
Is it:
1) USB bluetooth adapters
2) PCI bluetooth adapters
3) PCMCIA bluetooth adapters
4) Serial bluetooth adapters.
Cheers
James
James,
Unfortunately I'm not going to be of much help with SCO testing... We've
been doing our testing with Cetecom (they're on the CC list).
It may be possible for you to arrange something with them if you (or someon=
e
else) are making a product. Contact Ben Ko ([email protected]) if
you'd like to discuss it.
-Daryl.
> -----Original Message-----
> From: [email protected]=20
> [mailto:[email protected]] On Behalf Of=20
> James Courtier-Dutton
> Sent: July 8, 2003 2:47 PM
> To: Daryl Van Vorst
> Cc: BlueZ Mailing List; 'Marcel Holtmann'
> Subject: Re: [Bluez-devel] Qualification testing - rfcomm
>=20
>=20
> Daryl Van Vorst wrote:
> > Marcel,
> >=20
> > Finally got some results on those latest rfcomm changes for=20
> > qualification. Looks like there are a few more problems. :(=20
> But we're=20
> > close. :)
> >=20
> > TP/RFC/BV-09-C:
> > "Verify that the IUT handles flow control correctly when=20
> the Tester,=20
> > acting as a device conforming to Bluetooth version 1.0B,=20
> controls the=20
> > data flow using the Modem Status Command. The IUT's device=20
> role is of=20
> > no importance."
> >=20
> > The command and console output:
> >=20
> > root@jack-00000000:~>./rctest -s -P 1 -b 20 00:A0:96:1F:83:71
> > rctest[351]: Connected
> > rctest[351]: Sending ...
> > rctest[351]: Send failed. Resource temporarily unavailable(11)
> >=20
> > The IUT sends data in 5 frames, then stops for aboue 20s,=20
> then sends 5=20
> > more, then stops, etc. Technically, this test passed because we did=20
> > stop sending data after the tester send MSC stop to the IUT. But=20
> > something's clearly not right.
> >=20
> > There is an hcidump of the session attached.
> >=20
> > TP/RFC/BV-12-C:
> > "Verify that the IUT handles aggregate flow control=20
> correctly when the=20
> > Tester, acting as a device conforming to Bleutooth version 1.0B,=20
> > controls the data flow using the Flow Control on/off=20
> commands FCon and=20
> > FCoff. The IUT's device role is of no importance."
> >=20
> > The command and console output:
> >=20
> > root@jack-00000000:~>./rctest -s -P 1 -b 20 00:A0:96:1F:83:71
> > rctest[362]: Connected
> > rctest[362]: Sending ...
> > rfcomm_recv_mcc: Unknown control type 0x18
> > rfcomm_recv_mcc: Unknown control type 0x28
> >=20
> > The IUT does not respond to FCoff with FCoff, and continues sending=20
> > data. It also does not respond to FCon with FCon.
> >=20
> > There is an hcidump of the session attached.
> >=20
> > -Daryl.
>=20
> Any chance of doing some tests with SCO ?
> It might help us with some of the currently problems there=20
> are with SCO=20
> and usb dongles.
> Cheers
> James
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email sponsored by: Parasoft
> Error proof Web apps, automate testing & more.
> Download & eval WebKing and get a free book.=20
> http://www.parasoft.com/bulletproofapps=20
> _______________________________________________
> Bluez-devel mailing list
> [email protected]=20
> https://lists.sourceforge.net/lists/listinfo/b> luez-devel
>=20
Daryl Van Vorst wrote:
> Marcel,
>
> Finally got some results on those latest rfcomm changes for qualification.
> Looks like there are a few more problems. :( But we're close. :)
>
> TP/RFC/BV-09-C:
> "Verify that the IUT handles flow control correctly when the Tester, acting
> as a device conforming to Bluetooth version 1.0B, controls the data flow
> using the Modem Status Command. The IUT's device role is of no importance."
>
> The command and console output:
>
> root@jack-00000000:~>./rctest -s -P 1 -b 20 00:A0:96:1F:83:71
> rctest[351]: Connected
> rctest[351]: Sending ...
> rctest[351]: Send failed. Resource temporarily unavailable(11)
>
> The IUT sends data in 5 frames, then stops for aboue 20s, then sends 5 more,
> then stops, etc. Technically, this test passed because we did stop sending
> data after the tester send MSC stop to the IUT. But something's clearly not
> right.
>
> There is an hcidump of the session attached.
>
> TP/RFC/BV-12-C:
> "Verify that the IUT handles aggregate flow control correctly when the
> Tester, acting as a device conforming to Bleutooth version 1.0B, controls
> the data flow using the Flow Control on/off commands FCon and FCoff. The
> IUT's device role is of no importance."
>
> The command and console output:
>
> root@jack-00000000:~>./rctest -s -P 1 -b 20 00:A0:96:1F:83:71
> rctest[362]: Connected
> rctest[362]: Sending ...
> rfcomm_recv_mcc: Unknown control type 0x18
> rfcomm_recv_mcc: Unknown control type 0x28
>
> The IUT does not respond to FCoff with FCoff, and continues sending data. It
> also does not respond to FCon with FCon.
>
> There is an hcidump of the session attached.
>
> -Daryl.
Any chance of doing some tests with SCO ?
It might help us with some of the currently problems there are with SCO
and usb dongles.
Cheers
James