Max, Marcel,
We've started bluetooth qualification testing with Cetecom for our product
(which uses the bluez stack). Most tests passed, but there were several tha=
t
failed. Below is a summary of the testing that was performed and a list of
failed tests. We are only testing the portions which are relevant to our
product, so this is list is not necessarily a complete list of qualificatio=
n
related problems. I believe most of the problems will be relatively easy to
fix. Could you guys take a look?
The tests were performed on a system running a slightly out-of-date bluez
stack, so it's possible that some of the problems have already been
resolved. If you could point out any items that have already been resolved
(or are probably resolved), it would be much appreciated. A qualified
bluetooth module was not available for testing (but will be soon), so if it
appears that any of these problems are likely due to a malfunctioning
module, please let me know.
The tests were performed on a system running the following bluez component
versions:
bluez-kernel-2.3
bluez-libs-2.3
bluez-sdp-1.0rc3
The test specifications are available to download on the bluetooth website,
under Technology->Testing (you must be logged in):
http://www.bluetooth.org
The portions of each of these required for SPP server and OPP client were
tested so far: SDP, GAP, RFCOMM, L2CAP. For the most part, optional things
were not tested. Testing wasn't 100% complete.
Qualification failures/problems: (I can get tester logs for most of these
failures if they would be helpful.)
SDP:
PASS! (for our purposes), but there were a few things of note:
1.) The SDP entry for the SDP server itself should have a Language
Base Attribute ID List (because there are text descriptions). I'm not
absolutely clear on whether or not it is mandatory, but it would make the
testers happy. Can an application add an attribute to that record, or would
sdpd have to be modified?
2.) There appears to be a problem handling continuation states.
Handling continuation state is optional. We found that if the querying
device sends a maximum byte count of 100, the continutation state worked
fine. But if the querying device sent a maximum byte count of 8, the
continuation state doesn't work (the continuation flag wasn't recognized in
the next packet). I can dig up an example log if it would help.
GAP: PASS.
L2CAP:
1.) TP/COS/CED/BI-01: Verifies that the IUT rejects an unkown
signalling command. The tester sends an unkown L2CAP command. The IUT shoul=
d
respond with an L2CAP_Reject with reason 0 "Command not understood". The IU=
T
did not.
2.) TP/COS/CFD/BV-01: Tests that IUT is able to handle the receivin=
g
of more than one request for configuration of data channel. Tester sends
L2CAP_Config Req with flag=3D1, IUT responds with flag=3D0. According to se=
ction
5.4 p.290 of the version 1.1 spec, "When used in the Configuration Response=
,
the continuation flag must be set if the flag is set in the Request".
3.) TP/COS/CFD/BV-02: Tests that IUT is able to perform negotiation
while the tester rejects the configuration of a data channel. The IUT sends
a configuration request and the tester rejects it. The IUT should send
another configuration request, but it does not.
4.) TP/COS/RCO/BI-01, BI-02: These tests verify that the IUT
performs a consistency check on the data. Both tests send two packets to th=
e
IUT. In each test, the first packet has a mistake. In BI-01 the first packe=
t
is too short by one byte, and in BI-02 the first packet is too long by one
byte. In both cases the stack must correctly receive the second packet, but
not the first. The data should be discarded in the case of the
inconsistencies, and an error reported to the application.
RFCOMM:
Note: Some of these comments don't apply to a specific test case
(they are more general).
1.) Must not modify pbits in pn (parameter negotiation) response.
The pbits are dependent on which DLC is being configured. Apparently this i=
s
a common problem, and one that has been argued about with the SIG because
apparently nobody uses the bits - but the SIG would not give in (refer to
erratum 364). They are specified in the TS GSM 07.10 630 spec, section
5.4.6.3.1.
2.) TP/RFC/BV-07: Closing rfcomm doesn't appear to close l2cap. Is
this true? This isn't actually required to pass this test, but it did
confuse the tester. This may have been a mistake on my part. I just hit
ctrl-c when rctest was connected and assumed that everything would get
closed. Would calling close() have a different effect?
3.) TP/RFC/BV-13-C: Verifies that the IUT responds to a Remote Line
Status command from the tester. When the remote line status command is
received, the remote device must respond with a remote line status response=
.
We responded with NSC (not supported command) instead of RLS response.
4.) TP/RFC/BV-17-C: RFCOMM Parameter Negotiation: RFCOMM doesn't
respond with desired parameters in RPN response (it responds with 0's). I
took a quick look at the RFCOMM code (our older version) and it's apparent
that variables are being set with the desired values when the tester
requests values that we don't like, but those variables are not the ones
that are actually sent in the response. The parameter mask is set correctly
though.
5.) Once an RFCOMM channel is established, the IUT must exchange
MSC's (modem status commands) before sending data. That is, it must send an
MSC, wait for a response, wait for the sender's MSC, and respond to it
before sending data. Our device sent an MSC and then immediately started
sending data when we used rctest. This applies to many test cases.
6.) If a connecting device doesn't send a PN command with CL bits
set to 0x0f, then it means it is not a 1.1 device and we must not use credi=
t
based flow control. In our case, when such a PN command was received, data
was sent using credit based flow control but shouldn't have been. This
applies to many test cases.
-Daryl.
Senior Hardware Engineer
WideRay Corp.
604-233-1104
-------------------------------------------------------
Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
The only event dedicated to issues related to Linux enterprise solutions
http://www.enterpriselinuxforum.com
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Max,
Here's where we're at with this one: We either need to pass this test, or
issue an erratum. Issuing an erratum is going to be a very time-consuming
task and we can't be certain of the outcome.
About the only scenario we could come up with where this makes any sense at
all is if the remote device wants to send data larger than the default MTU
of 672, and the local application doesn't specifically tell the stack that
it can handle a larger MTU before calling connect(). Is it in our interest
to handle this?
Is it possible to give the app control during the CONFIG state so that it
can do the negotiation with the remote side? Am I correct in assuming that
as it is now the app only gets control once we enter the OPEN state?
The original test MSC (Message Sequence Chart) showed the application
sending L2CA_ConfigReq to the top end of the stack and the stack sending
L2CAP_ConfigReq to the remote device. The L2CAP_ConfigReq was also sent up
to the application as L2CA_ConfigCfm (with status=3Dreject and the values t=
hat
the remote device wants to see). It was then up to the app to send another
L2CA_ConfigReq to the stack to be forwarded to the remote device. The MSC
was later updated to remove the involvement of the application, but the sam=
e
reject-then-re-request sequence is there.
Perhaps we could put in a "hack" (if we're going to call it that) which
allows us to pass the test. We could, at the same time, write up an errata
requesting that this test be optional or changed so that we would pass the
test without the "hack". Once the erratum is accepted, we could remove the
hack.
Is there any chance that you could make this change? Or, if not, could you
help me determine where in the code to do it? The behaviour that would make
it pass is as follows:
1. We send a config request.
2. We get a config response rejecting our request which contains the
tester's desired values.
3. We re-send the config request with those values (the tester will accept
this request).
4. At this point if the config request is not accepted we can close the lin=
k
like we would normally.
Maybe we could add a setsockopt() l2cap option like LM_FLEXIBLEINMTU to tur=
n
on this behaviour (not sure if making it optional will pass - I'll check).
Apparently, in step 3 above, if we send a config request with no options it
will also pass the test. How silly is that? (specially considering that's
what we send by default in the first place!)
-Daryl.
> -----Original Message-----
> From: Max Krasnyansky [mailto:[email protected]]=20
> Sent: May 19, 2003 2:19 PM
> To: Daryl Van Vorst; 'Marcel Holtmann'
> Cc: 'BlueZ Mailing List'
> Subject: RE: [Bluez-devel] Qualification Testing
>=20
>=20
> At 11:01 AM 5/16/2003, Daryl Van Vorst wrote:
> >Max,
> >
> >> >> I sent the above quote to Cetecom last week. They=20
> responded saying=20
> >> >> that MTU isn't the only negotiated parameter.
> >>=20
> >> FlushTO _must_ be 0xffff for reliable ACL link. So far none
> >> of the profiles specified use of unreliable links.=20
> >>=20
> >> Support for QOS is totally optional. We're only required to
> >> support 'best effort'. Which means that even if they want=20
> >> something other than 'best effort' (i.e. they reject=20
> >> default settings) we won't be able to accept it simply=20
> >> because we don't support it.
> >>=20
> >> So I'm not sure what can be negotiated there.
> >
> >Ok. I'll see what they say about that too.
> >
> >> btw Can this fancy Merlin viewer export trace in plain text ?
> >> I'm too lazy to install that stuff. And it looks like I=20
> need to see=20
> >> what is it exactly that they request/reject.
> >
> >
> >Before we start the test, we must specify to the tester the=20
> parameters=20
> >that we'll accept. The tester will reject the first set of=20
> values, no=20
> >matter what they are. In its response it will send new=20
> values (which we=20
> >specify) that it expects to see in the next request from the IUT.
>=20
> Any updates on this one ?
>=20
> Max
>=20
>=20
>=20
Max,
> >Before we start the test, we must specify to the tester the
> parameters
> >that we'll accept. The tester will reject the first set of
> values, no
> >matter what they are. In its response it will send new
> values (which we
> >specify) that it expects to see in the next request from the IUT.
>
> Any updates on this one ?
Not yet... Had a long weekend here. Much needed break. :)
-Daryl.
At 11:01 AM 5/16/2003, Daryl Van Vorst wrote:
>Max,
>
>> >> I sent the above quote to Cetecom last week. They responded
>> >> saying that MTU isn't the only negotiated parameter.
>>
>> FlushTO _must_ be 0xffff for reliable ACL link. So far none
>> of the profiles specified use of unreliable links.
>>
>> Support for QOS is totally optional. We're only required to
>> support 'best effort'. Which means that even if they want
>> something other than 'best effort' (i.e. they reject
>> default settings) we won't be able to accept it simply
>> because we don't support it.
>>
>> So I'm not sure what can be negotiated there.
>
>Ok. I'll see what they say about that too.
>
>> btw Can this fancy Merlin viewer export trace in plain text ?
>> I'm too lazy to install that stuff. And it looks like I need to see
>> what is it exactly that they request/reject.
>
>
>Before we start the test, we must specify to the tester the parameters that
>we'll accept. The tester will reject the first set of values, no matter what
>they are. In its response it will send new values (which we specify) that it
>expects to see in the next request from the IUT.
Any updates on this one ?
Max
We now have full support for SO_LINGER socket option (2.4 BK is already updated).
I also added -L option and some more error checking to l2test and rctest.
./l2test -L 60 -s -b 1000 -N 10
this will enabled SO_LINGER for 60 seconds and report an error if channel disconnect
timed out or failed for any other reason.
I tested it with HCIEmu and everything seems to work as expected.
btw Regarding RFCOMM disconnect problem that Marcel mentioned. I check the spec again
and it's indeed option to send DISC for DCL 0.
"5.2.2 Close-down procedure
The device closing the last connection (DLC) on a particular session is responsible
for closing the multiplexer by closing the corresponding L2CAP channel.
Closing the multiplexer by first sending a DISC command frame on DLCI 0 is
optional, but it is mandatory to respond correctly to a DISC (with UA response)."
So I think it's ok that we don't wait for UA response before closing L2CAP channel.
Max
Hi Daryl,
> > btw Can this fancy Merlin viewer export trace in plain text ?
> > I'm too lazy to install
> > that stuff. And it looks like I need to see what is it
> > exactly that they request/reject.
>
> Not that I'm aware of. Marcel - you're probably more experienced with Merlin
> than me. Do you know of a way?
not that I know of, but you can expand the complete view and print it
and so it should be possible to convert it to a PDF.
Regards
Marcel
-------------------------------------------------------
Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
The only event dedicated to issues related to Linux enterprise solutions
http://www.enterpriselinuxforum.com
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Max,
> >> I sent the above quote to Cetecom last week. They responded
> >> saying that MTU isn't the only negotiated parameter.
>=20
> FlushTO _must_ be 0xffff for reliable ACL link. So far none=20
> of the profiles specified use of unreliable links.=20
>=20
> Support for QOS is totally optional. We're only required to=20
> support 'best effort'. Which means that even if they want=20
> something other than 'best effort' (i.e. they reject=20
> default settings) we won't be able to accept it simply=20
> because we don't support it.
>=20
> So I'm not sure what can be negotiated there.=20
Ok. I'll see what they say about that too.
> btw Can this fancy Merlin viewer export trace in plain text ?=20
> I'm too lazy to install=20
> that stuff. And it looks like I need to see what is it=20
> exactly that they request/reject.
Not that I'm aware of. Marcel - you're probably more experienced with Merli=
n
than me. Do you know of a way?
Before we start the test, we must specify to the tester the parameters that
we'll accept. The tester will reject the first set of values, no matter wha=
t
they are. In its response it will send new values (which we specify) that i=
t
expects to see in the next request from the IUT.
-Daryl.
Max,
> btw We want to get all your changes that are useful for
> qualification. I'm talking about changes to l2test/rctest/etc
> that you had to make to support
> particular tests.
You'll definitely get them. :)
So far the l2test change that I gave you yesterday is all that I've needed.
I wasn't actually using it though, I was using a hacked version that would
only send 1 packet. But the updated l2test should be fine.
The l2test and rctest tools that are already available have been great for
testing. Most of the tests are very simple on the IUT end. You either have
to listen for a connection or make a connection, and either send or receive
data or neither.
Oh yeah, I'm going to have to make a tool or an addition to l2test which
will receive data and send data at the same time. I'll pass whatever I come
up with there along. Do we have something simple that'll do that already?
(We have to be able to see that it received the data)
-Daryl.
At 07:43 AM 5/16/2003, Daryl Van Vorst wrote:
>> How about support for L2CAP_LM_RELAIBLE ?
>> The error returned by recvmsg()/sendmsg()/read()/etc is ECOMM.
>
>Wasn't sure if you wanted me to do that stuff.
>Sure, I can take a swing at it.
btw We want to get all your changes that are useful for qualification.
I'm talking about changes to l2test/rctest/etc that you had to make to support
particular tests.
Max
At 02:25 PM 5/15/2003, Daryl Van Vorst wrote:
>Max,
>
>Regarding the L2CAP parameter negotiation. Not sure if you saw this (see
>below).
>
>This is the one remaining problem impeding qualification. Except, of course,
>for the possibility of more failures in the next round of testing.
>
>What are your thoughts on it?
I'm trying to come up with an excuse to not implement it ;-)
Just kidding. Read below.
>> What about flowspec and flush timeout?
>>
>> In section 6.4.2 FlushTO is listed as one of the items in the
>> response path (along with MTU and InFlow). But in section 7.5
>> only MTU and InFlow are listed.
>>
>> I sent the above quote to Cetecom last week. They responded
>> saying that MTU isn't the only negotiated parameter.
FlushTO _must_ be 0xffff for reliable ACL link. So far none of the profiles
specified use of unreliable links.
Support for QOS is totally optional. We're only required to support 'best effort'.
Which means that even if they want something other than 'best effort' (i.e. they reject
default settings) we won't be able to accept it simply because we don't support it.
So I'm not sure what can be negotiated there.
btw Can this fancy Merlin viewer export trace in plain text ? I'm too lazy to install
that stuff. And it looks like I need to see what is it exactly that they request/reject.
Max
> How about support for L2CAP_LM_RELAIBLE ?
> The error returned by recvmsg()/sendmsg()/read()/etc is ECOMM.
Wasn't sure if you wanted me to do that stuff.
Sure, I can take a swing at it.
-Daryl.
Hi Daryl,
> Here you go (sorry about that):
patch is applied. The next time please do the patch against the CVS
version, because it is easier for us to apply.
Regards
Marcel
-------------------------------------------------------
Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
The only event dedicated to issues related to Linux enterprise solutions
http://www.enterpriselinuxforum.com
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
At 03:35 PM 5/14/2003, Daryl Van Vorst wrote:
>Here you go (sorry about that):
Thanks. Marcel or I will apply it.
How about support for L2CAP_LM_RELAIBLE ?
The error returned by recvmsg()/sendmsg()/read()/etc is ECOMM.
Max
Max,
Regarding the L2CAP parameter negotiation. Not sure if you saw this (see
below).
This is the one remaining problem impeding qualification. Except, of course=
,
for the possibility of more failures in the next round of testing.
What are your thoughts on it?
Thanks,
-Daryl.
> -----Original Message-----
> From: [email protected]=20
> [mailto:[email protected]] On Behalf Of=20
> Daryl Van Vorst
> Sent: May 13, 2003 11:36 AM
> To: 'Max Krasnyansky'; 'Marcel Holtmann'
> Cc: 'BlueZ Mailing List'
> Subject: RE: [Bluez-devel] Qualification Testing
>=20
>=20
> Max,
>=20
> > >Max - You mentioned that the spec says that what the stack
> > does with a
> > >config reject can be implementation specific. I just had a
> > look at the
> > >spec and couldn't find it. Could you tell me where to look
> > in the spec?
> >=20
> > section 6.1
> > page 297
> >=20
> > "Since all L2CAP implementations are capable to support a
> > minimum L2CAP packet size, see Section 4 on page 280, MTU is=20
> > not really a negotiated value but rather an informational=20
> > parameter to the remote device that the local device can=20
> > accommodate in this channel an MTU larger than the minimum=20
> > required. In the unlikely case that the remote device is only=20
> > willing to send L2CAP packets in this channel that are larger=20
> > than the MTU announced by the local device, then this=20
> > Configuration Request will receive a negative response in=20
> > which the remote device will include the value of MTU that is=20
> > indented to transmit. In this case, it is implementation=20
> > specific on whether the local device will continue the=20
> > configuration process or even maintain this channel."
>=20
> What about flowspec and flush timeout?
>=20
> In section 6.4.2 FlushTO is listed as one of the items in the=20
> response path (along with MTU and InFlow). But in section 7.5=20
> only MTU and InFlow are listed.
>=20
> I sent the above quote to Cetecom last week. They responded=20
> saying that MTU isn't the only negotiated parameter.
>=20
> -Daryl.
>=20
>=20
>=20
> -------------------------------------------------------
> Enterprise Linux Forum Conference & Expo, June 4-6, 2003,=20
> Santa Clara The only event dedicated to issues related to=20
> Linux enterprise solutions http://www.enterpriselinuxforum.com
>=20
> _______________________________________________
> Bluez-devel mailing list
> [email protected]=20
> https://lists.sourceforge.net/lists/listinfo/b> luez-devel
>=20
-------------------------------------------------------
Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
The only event dedicated to issues related to Linux enterprise solutions
http://www.enterpriselinuxforum.com
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Here you go (sorry about that):
--- /home/daryl/bluez/bluez-utils-2.3/test/l2test.c Wed May 14 15:11:32
2003
+++ l2test.c Wed May 14 15:10:58 2003
@@ -71,6 +71,9 @@
bdaddr_t bdaddr;
unsigned short psm = 10;
+/* Default number of blocks to send */
+int num_blocks = -1; // Infinite
+
int master = 0;
int auth = 0;
int encrypt = 0;
@@ -324,7 +327,7 @@
buf[i]=0x7f;
seq = 0;
- while (1) {
+ while ((num_blocks == -1) || (num_blocks-- > 0)) {
*(uint32_t *) buf = htobl(seq++);
*(uint16_t *)(buf+4) = htobs(data_size);
@@ -386,9 +389,9 @@
printf("Options:\n"
"\t[-b bytes] [-S bdaddr] [-P psm]\n"
"\t[-I imtu] [-O omtu]\n"
+ "\t[-N num] send num blocks (default = infinite)\n"
"\t[-D] use connectionless channel (datagram)\n"
"\t[-E] request encryption\n"
- "\t[-E] request encryption\n"
"\t[-M] become master\n");
}
@@ -402,7 +405,7 @@
mode = RECV; need_addr = 0;
- while ((opt=getopt(argc,argv,"rdscuwmnb:P:I:O:S:MAED")) != EOF) {
+ while ((opt=getopt(argc,argv,"rdscuwmnb:P:I:O:S:N:MAED")) != EOF) {
switch(opt) {
case 'r':
mode = RECV;
@@ -477,6 +480,10 @@
socktype = SOCK_DGRAM;
break;
+ case 'N':
+ num_blocks = atoi(optarg);
+ break;
+
default:
usage();
exit(1);
> -----Original Message-----
> From: Marcel Holtmann [mailto:[email protected]]
> Sent: May 14, 2003 3:27 PM
> To: Daryl Van Vorst
> Cc: 'Max Krasnyansky'; 'BlueZ Mailing List'
> Subject: RE: [Bluez-devel] Qualification Testing
>
>
> Hi Daryl,
>
> > Got to it a bit quicker than expected. I haven't needed to change
> > rctest for testing, so I haven't modified that one yet.
> >
> > Here's the diff.
>
> thats great, but can you please use "diff -urN". Because a
> unified diff is much more easier to read.
>
> Regards
>
> Marcel
>
>
>
Hi Daryl,
> Got to it a bit quicker than expected. I haven't needed to change rctest for
> testing, so I haven't modified that one yet.
>
> Here's the diff.
thats great, but can you please use "diff -urN". Because a unified diff
is much more easier to read.
Regards
Marcel
-------------------------------------------------------
Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
The only event dedicated to issues related to Linux enterprise solutions
http://www.enterpriselinuxforum.com
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Max,
Got to it a bit quicker than expected. I haven't needed to change rctest fo=
r
testing, so I haven't modified that one yet.
Here's the diff.
-Daryl.
*** /home/daryl/bluez/bluez-utils-2.3/test/l2test.c Wed May 14 15:11:32
2003
--- l2test.c Wed May 14 15:10:58 2003
***************
*** 71,76 ****
--- 71,79 ----
bdaddr_t bdaddr;
unsigned short psm =3D 10;
=20
+ /* Default number of blocks to send */
+ int num_blocks =3D -1; // Infinite
+=20
int master =3D 0;
int auth =3D 0;
int encrypt =3D 0;
***************
*** 324,330 ****
buf[i]=3D0x7f;
=20
seq =3D 0;
! while (1) {
*(uint32_t *) buf =3D htobl(seq++);
*(uint16_t *)(buf+4) =3D htobs(data_size);
=09
--- 327,333 ----
buf[i]=3D0x7f;
=20
seq =3D 0;
! while ((num_blocks =3D=3D -1) || (num_blocks-- > 0)) {
*(uint32_t *) buf =3D htobl(seq++);
*(uint16_t *)(buf+4) =3D htobs(data_size);
=09
***************
*** 386,394 ****
printf("Options:\n"
"\t[-b bytes] [-S bdaddr] [-P psm]\n"
"\t[-I imtu] [-O omtu]\n"
"\t[-D] use connectionless channel (datagram)\n"
"\t[-E] request encryption\n"
- "\t[-E] request encryption\n"
"\t[-M] become master\n");
}
=20
--- 389,397 ----
printf("Options:\n"
"\t[-b bytes] [-S bdaddr] [-P psm]\n"
"\t[-I imtu] [-O omtu]\n"
+ "\t[-N num] send num blocks (default =3D infinite)\n"
"\t[-D] use connectionless channel (datagram)\n"
"\t[-E] request encryption\n"
"\t[-M] become master\n");
}
=20
***************
*** 402,408 ****
=20
mode =3D RECV; need_addr =3D 0;
=09
! while ((opt=3Dgetopt(argc,argv,"rdscuwmnb:P:I:O:S:MAED")) !=3D EOF) {
switch(opt) {
case 'r':
mode =3D RECV;
--- 405,411 ----
=20
mode =3D RECV; need_addr =3D 0;
=09
! while ((opt=3Dgetopt(argc,argv,"rdscuwmnb:P:I:O:S:N:MAED")) !=3D EOF) {
switch(opt) {
case 'r':
mode =3D RECV;
***************
*** 477,482 ****
--- 480,489 ----
socktype =3D SOCK_DGRAM;
break;
=20
+ case 'N':
+ num_blocks =3D atoi(optarg);
+ break;
+=20
default:
usage();
exit(1);
> -----Original Message-----
> From: [email protected]=20
> [mailto:[email protected]] On Behalf Of=20
> Daryl Van Vorst
> Sent: May 14, 2003 2:12 PM
> To: 'Max Krasnyansky'; 'Marcel Holtmann'
> Cc: 'BlueZ Mailing List'
> Subject: RE: [Bluez-devel] Qualification Testing
>=20
>=20
> Max,
>=20
> > >Another addition to l2test (and maybe rctest) that would be
> > handy for
> > >testing is an option to specify how many packets to send. It
> > would be
> > >nice to have the option of sending only a few packets=20
> rather than an
> > >infinite number. None of the tests that I've encountered so=20
> > far require
> > >sending large amounts of data... Just a packet or two. For rfcomm
> > >testing I could probably just do an "rfcomm connect /dev/something=20
> > >etc.." and redirect something small to /dev/something if rctest is=20
> > >causing trouble.
> > Go for it. I mean l2test/rctest changes. And sent us a patch(es).
>=20
> Ok. Will do. I probably won't be able to get to it for a=20
> while, but I don't
> think anyone else cares at the moment anyway. ;)
>=20
> -Daryl.
>=20
>=20
>=20
> -------------------------------------------------------
> Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
> The only event dedicated to issues related to Linux=20
> enterprise solutions
> http://www.enterpriselinuxforum.com
>=20
> _______________________________________________
> Bluez-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/bluez-devel
>=20
Max,
> >Another addition to l2test (and maybe rctest) that would be
> handy for
> >testing is an option to specify how many packets to send. It
> would be
> >nice to have the option of sending only a few packets rather than an
> >infinite number. None of the tests that I've encountered so
> far require
> >sending large amounts of data... Just a packet or two. For rfcomm
> >testing I could probably just do an "rfcomm connect /dev/something
> >etc.." and redirect something small to /dev/something if rctest is
> >causing trouble.
> Go for it. I mean l2test/rctest changes. And sent us a patch(es).
Ok. Will do. I probably won't be able to get to it for a while, but I don't
think anyone else cares at the moment anyway. ;)
-Daryl.
At 09:02 AM 5/14/2003, Daryl Van Vorst wrote:
>Hey Marcel,
>
>> > L2CAP_LM_RELIABLE
>
>L2CAP_LM_RETENTIVE? ;) (Not sure if the slang meaning of that word comes
>through in other countries. The real meaning may not be appropriate.) Some
>others: intolerant, cautious.
I think 'reliable' is ok.
>> > Now we just need to add support for it in l2test.
>>
>> Daryl, it is your test :)
>
>Cool. :)
>
>Another addition to l2test (and maybe rctest) that would be handy for
>testing is an option to specify how many packets to send. It would be nice
>to have the option of sending only a few packets rather than an infinite
>number. None of the tests that I've encountered so far require sending large
>amounts of data... Just a packet or two. For rfcomm testing I could probably
>just do an "rfcomm connect /dev/something etc.." and redirect something
>small to /dev/something if rctest is causing trouble.
Go for it. I mean l2test/rctest changes. And sent us a patch(es).
Max
Hey Marcel,
> > L2CAP_LM_RELIABLE
L2CAP_LM_RETENTIVE? ;) (Not sure if the slang meaning of that word comes
through in other countries. The real meaning may not be appropriate.) Some
others: intolerant, cautious.
> > Now we just need to add support for it in l2test.
>=20
> Daryl, it is your test :)
Cool. :)
Another addition to l2test (and maybe rctest) that would be handy for
testing is an option to specify how many packets to send. It would be nice
to have the option of sending only a few packets rather than an infinite
number. None of the tests that I've encountered so far require sending larg=
e
amounts of data... Just a packet or two. For rfcomm testing I could probabl=
y
just do an "rfcomm connect /dev/something etc.." and redirect something
small to /dev/something if rctest is causing trouble.
-Daryl.
Hi Max,
> >But I don't like the name and your meaning of this options. It sounds
> >like something that it is not and will never be. For the description of
> >this option I think it should be something like
> >
> > "Notify me when you detect an error in the ACL payload"
> ACL is a lower lever. If baseband detects error in ACL payload it retransmits
> a packet :).
ok, so "L2CAP frame" would be the better and correct description.
> >And the option name can be L2CAP_CHECKACL. This is not very good, I
> >know, so any other proposals?
> L2CAP_LM_RELIABLE
I don't like it either, because we can't detect all errors which makes
the connection unreliable. But I don't know a better name :(
> Implementation is very very very simple and code for 2.4 is already in BK :).
> http://linux-bt.bkbits.net:8080/bt-2.4/[email protected]?nav=index.html|ChangeSet@-1h|[email protected]
>
> We didn't even need a new socket option. Just another LM (link mode) flag. And common case
> is not affected at all.
Very nice and small patch. I will delay the new -mh patches because of
this and hopefully the SO_LINGER support. Can you please also take a
look at the RFCOMM problem I posted to the list. My day is definitive
over and I will take some sleep :)
> Now we just need to add support for it in l2test.
Daryl, it is your test :)
Regards
Marcel
-------------------------------------------------------
Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
The only event dedicated to issues related to Linux enterprise solutions
http://www.enterpriselinuxforum.com
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
At 04:19 PM 5/13/2003, Marcel Holtmann wrote:
>so if we detect a failure in an ACL packet, we notify all L2CAP
>connections on the ACL link that have this option set. This sounds a
>little bit better to me. I understand you wrong at the first time and
>now I think we should have such extra stuff.
>
>But I don't like the name and your meaning of this options. It sounds
>like something that it is not and will never be. For the description of
>this option I think it should be something like
>
> "Notify me when you detect an error in the ACL payload"
ACL is a lower lever. If baseband detects error in ACL payload it retransmits
a packet :).
>And the option name can be L2CAP_CHECKACL. This is not very good, I
>know, so any other proposals?
L2CAP_LM_RELIABLE
Implementation is very very very simple and code for 2.4 is already in BK :).
http://linux-bt.bkbits.net:8080/bt-2.4/[email protected]?nav=index.html|ChangeSet@-1h|[email protected]
We didn't even need a new socket option. Just another LM (link mode) flag. And common case
is not affected at all.
Now we just need to add support for it in l2test.
Max
Hi Max,
> >> Hmm, ok :). But after thinking more about this I think that we probably still need
> >> some way to tell the apps that link became unreliable. I mean parsing syslogs is
> >> not very elegant solution :). Also even though Cetecom accepted it as a solution
> >> other BQBs might not.
> >>
> >> Here is what I had in mind. We could add L2CAP socket option L2CAP_RELIABILITY,
> >> which will be used by the apps that are "paranoid" :) about link reliability.
> >> Then whenever we receive corrupted L2CAP frame we'd check connected sockets, attached
> >> to this connection, that have this option enabled and signal error condition on them.
> >> i.e. read/recvmsg will return error. Application can then either clear that error with
> >> getsockopt(SO_ERROR) and continue or close the socket.
> >
> >the idea itself sounds very good. But I see no advantage in implementing
> >such kind of extra functionality. We can not detect if a frame is
> >currupt or not, because we have no checksum mechanism. The only thing we
> >can detect is a length mismatch. What about a corrupted cid?
> >If you notify the wrong socket and the application on that socket can't deal
> >with such an error.
> Definition of the L2CAP_RELAIBILITY option is rather broad :). In general it would mean
> "Notify me when you can no longer guaranty reliable transmission".
> You're right what we don't have checksum. But we can detect failures other than
> the wrong length. For example missing start frame or missing continuation frame.
> CID we're going to have to ignore because it doesn't necessarily mean that connection
> became unreliable.
> So there is no such thing as notifying the wrong socket in this case. If L2CAP detects
> that connection became unreliable it notifies all sockets on that connection (those
> that explicitly requested notification of course).
so if we detect a failure in an ACL packet, we notify all L2CAP
connections on the ACL link that have this option set. This sounds a
little bit better to me. I understand you wrong at the first time and
now I think we should have such extra stuff.
But I don't like the name and your meaning of this options. It sounds
like something that it is not and will never be. For the description of
this option I think it should be something like
"Notify me when you detect an error in the ACL payload"
And the option name can be L2CAP_CHECKACL. This is not very good, I
know, so any other proposals?
Regards
Marcel
-------------------------------------------------------
Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
The only event dedicated to issues related to Linux enterprise solutions
http://www.enterpriselinuxforum.com
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
At 03:31 PM 5/13/2003, Marcel Holtmann wrote:
>Hi Max,
>
>> Hmm, ok :). But after thinking more about this I think that we probably still need
>> some way to tell the apps that link became unreliable. I mean parsing syslogs is
>> not very elegant solution :). Also even though Cetecom accepted it as a solution
>> other BQBs might not.
>>
>> Here is what I had in mind. We could add L2CAP socket option L2CAP_RELIABILITY,
>> which will be used by the apps that are "paranoid" :) about link reliability.
>> Then whenever we receive corrupted L2CAP frame we'd check connected sockets, attached
>> to this connection, that have this option enabled and signal error condition on them.
>> i.e. read/recvmsg will return error. Application can then either clear that error with
>> getsockopt(SO_ERROR) and continue or close the socket.
>
>the idea itself sounds very good. But I see no advantage in implementing
>such kind of extra functionality. We can not detect if a frame is
>currupt or not, because we have no checksum mechanism. The only thing we
>can detect is a length mismatch. What about a corrupted cid?
>If you notify the wrong socket and the application on that socket can't deal
>with such an error.
Definition of the L2CAP_RELAIBILITY option is rather broad :). In general it would mean
"Notify me when you can no longer guaranty reliable transmission".
You're right what we don't have checksum. But we can detect failures other than
the wrong length. For example missing start frame or missing continuation frame.
CID we're going to have to ignore because it doesn't necessarily mean that connection
became unreliable.
So there is no such thing as notifying the wrong socket in this case. If L2CAP detects
that connection became unreliable it notifies all sockets on that connection (those
that explicitly requested notification of course).
Comments ?
Max
Hi Max,
> Hmm, ok :). But after thinking more about this I think that we probably still need
> some way to tell the apps that link became unreliable. I mean parsing syslogs is
> not very elegant solution :). Also even though Cetecom accepted it as a solution
> other BQBs might not.
>
> Here is what I had in mind. We could add L2CAP socket option L2CAP_RELIABILITY,
> which will be used by the apps that are "paranoid" :) about link reliability.
> Then whenever we receive corrupted L2CAP frame we'd check connected sockets, attached
> to this connection, that have this option enabled and signal error condition on them.
> i.e. read/recvmsg will return error. Application can then either clear that error with
> getsockopt(SO_ERROR) and continue or close the socket.
the idea itself sounds very good. But I see no advantage in implementing
such kind of extra functionality. We can not detect if a frame is
currupt or not, because we have no checksum mechanism. The only thing we
can detect is a length mismatch. What about a corrupted cid? If you
notify the wrong socket and the application on that socket can't deal
with such an error.
Regards
Marcel
-------------------------------------------------------
Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
The only event dedicated to issues related to Linux enterprise solutions
http://www.enterpriselinuxforum.com
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Max,
> >Max - You mentioned that the spec says that what the stack
> does with a
> >config reject can be implementation specific. I just had a
> look at the
> >spec and couldn't find it. Could you tell me where to look
> in the spec?
>
> section 6.1
> page 297
>
> "Since all L2CAP implementations are capable to support a
> minimum L2CAP packet size, see Section 4 on page 280, MTU is
> not really a negotiated value but rather an informational
> parameter to the remote device that the local device can
> accommodate in this channel an MTU larger than the minimum
> required. In the unlikely case that the remote device is only
> willing to send L2CAP packets in this channel that are larger
> than the MTU announced by the local device, then this
> Configuration Request will receive a negative response in
> which the remote device will include the value of MTU that is
> indented to transmit. In this case, it is implementation
> specific on whether the local device will continue the
> configuration process or even maintain this channel."
What about flowspec and flush timeout?
In section 6.4.2 FlushTO is listed as one of the items in the response path
(along with MTU and InFlow). But in section 7.5 only MTU and InFlow are
listed.
I sent the above quote to Cetecom last week. They responded saying that MTU
isn't the only negotiated parameter.
-Daryl.
Max,
> >Having the messages appear on the console is enough to pass=20
> testing. We=20
> >shouldn't need a special app that monitors syslog. We could submit a=20
> >copy of the syslog if necessary.
> Hmm, ok :). But after thinking more about this I think that=20
> we probably still need=20
> some way to tell the apps that link became unreliable. I mean=20
> parsing syslogs is=20
> not very elegant solution :). Also even though Cetecom=20
> accepted it as a solution=20
> other BQBs might not.
Technically Cetecom hasn't accepted it yet. That's just preliminary. The BQ=
B
hasn't reviewed the data.
> Here is what I had in mind. We could add L2CAP socket option=20
> L2CAP_RELIABILITY, which will be used by the apps that are=20
> "paranoid" :) about link reliability. Then whenever we=20
> receive corrupted L2CAP frame we'd check connected sockets,=20
> attached to this connection, that have this option enabled=20
> and signal error condition on them.=20
> i.e. read/recvmsg will return error. Application can then=20
> either clear that error with=20
> getsockopt(SO_ERROR) and continue or close the socket.
>=20
> Comments ?
That sounds great to me! That's the sort of thing I was hoping for in the
beginning, but I knew too little about sockets to suggest a workable
solution. :)
-Daryl.
At 05:04 PM 5/12/2003, Marcel Holtmann wrote:
>Hi Max,
>
>> > Daryl, so it is now up to you to do your tests with Cetecom
>> > again and see what we pass and what we fail. The RFCOMM layer
>> > should now perform perfect, but the L2CAP config stuff will
>> > still fail. You can use 2.4.18-mh4 and apply these 5 patches
>> > from the bt-2.4 repository to it:
>>
>> Great work guys! Thanks!
>
>maybe we have another RFCOMM misbehaviour, which doesn't matter in the
>real world, but can confuse the tester.
>
> < ACL data: handle 0x0029 flags 0x02 dlen 8
> L2CAP(d): cid 0x45 len 4 [psm 3]
> RFCOMM(s): DISC: cr 1 dlci 2 pf 1 ilen 0 fcs 0xb8
> > ACL data: handle 0x0029 flags 0x02 dlen 8
> L2CAP(d): cid 0x40 len 4 [psm 3]
> RFCOMM(s): UA: cr 1 dlci 2 pf 1 ilen 0 fcs 0x92
> < ACL data: handle 0x0029 flags 0x02 dlen 8
> L2CAP(d): cid 0x45 len 4 [psm 3]
> RFCOMM(s): DISC: cr 1 dlci 0 pf 1 ilen 0 fcs 0xfd
> < ACL data: handle 0x0029 flags 0x02 dlen 12
> L2CAP(s): Disconn req: dcid 0x0045 scid 0x0040
> > ACL data: handle 0x0029 flags 0x02 dlen 8
> L2CAP(d): cid 0x40 len 4 [psm 3]
> RFCOMM(s): UA: cr 1 dlci 0 pf 1 ilen 0 fcs 0xd7
> > ACL data: handle 0x0029 flags 0x02 dlen 12
> L2CAP(s): Disconn rsp: dcid 0x0045 scid 0x0040
>
>The dump above is from a disconnect sequence of RFCOMM. We don't wait
>for the UA of the DISC on the dlci 0. We send the L2CAP disconnect
>request right after the disconnect of the dlci 0. The L2CAP channel
>should be closed after receiving the UA or after a timeout.
Yeah, this one probably needs to be fixed. Although I think I've heard that
simply closing L2CAP channel is enough, I mean even sending DISC is optional.
But we need to verify that in the spec.
Max
At 04:37 PM 5/12/2003, Daryl Van Vorst wrote:
>Re: l2cap config stuff:
>
>We don't need any more logs or anything for that do we? I think we're just
>trying to understand what it is exactly that we're supposed to do and why.
Yep. No need for logs.
>Max - You mentioned that the spec says that what the stack does with a
>config reject can be implementation specific. I just had a look at the spec
>and couldn't find it. Could you tell me where to look in the spec?
section 6.1
page 297
"Since all L2CAP implementations are capable to support a minimum L2CAP
packet size, see Section 4 on page 280, MTU is not really a negotiated value
but rather an informational parameter to the remote device that the local device
can accommodate in this channel an MTU larger than the minimum required. In
the unlikely case that the remote device is only willing to send L2CAP packets
in this channel that are larger than the MTU announced by the local device,
then this Configuration Request will receive a negative response in which the
remote device will include the value of MTU that is indented to transmit. In this
case, it is implementation specific on whether the local device will continue the
configuration process or even maintain this channel."
Max
At 03:51 PM 5/12/2003, Daryl Van Vorst wrote:
>Marcel,
>
>I'm replying to myself again. But I said I would, so I guess that makes it
>ok. ;)
>
>Cetecom is happy with the decision you guys have made. Sending the error to
>syslog so that it can be displayed on the system console and put in the
>system log file is good enough. If an app must know, it can monitor syslog.
>Everyone's in agreement that this is the right thing to do.
>
>Having the messages appear on the console is enough to pass testing. We
>shouldn't need a special app that monitors syslog. We could submit a copy of
>the syslog if necessary.
Hmm, ok :). But after thinking more about this I think that we probably still need
some way to tell the apps that link became unreliable. I mean parsing syslogs is
not very elegant solution :). Also even though Cetecom accepted it as a solution
other BQBs might not.
Here is what I had in mind. We could add L2CAP socket option L2CAP_RELIABILITY,
which will be used by the apps that are "paranoid" :) about link reliability.
Then whenever we receive corrupted L2CAP frame we'd check connected sockets, attached
to this connection, that have this option enabled and signal error condition on them.
i.e. read/recvmsg will return error. Application can then either clear that error with
getsockopt(SO_ERROR) and continue or close the socket.
Comments ?
Max
Hi Daryl,
> How do I get those 5 patches from the bt-2.4 repository? Or better yet:
> Where is the bt-2.4 repository?
you can find the repository at http://linux-bt.bkbits.net/ and you need
to use Bitkeeper. You have to clone to repository as specified in the
bk-kernel-howto.txt and after that you can extract each patch step by
step.
bk export -tpatch -du -h -r<cset>
Another way is the BK->CVS thing, but I never tried it.
If you have problems with Bitkeeper and you need the patches now, I can
send them to you. The new -mh patches have to wait until I finished some
other things.
Regards
Marcel
-------------------------------------------------------
Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
The only event dedicated to issues related to Linux enterprise solutions
http://www.enterpriselinuxforum.com
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Marcel,
How do I get those 5 patches from the bt-2.4 repository? Or better yet:
Where is the bt-2.4 repository?
> Daryl, so it is now up to you to do your tests with Cetecom
> again and see what we pass and what we fail. The RFCOMM layer
> should now perform perfect, but the L2CAP config stuff will
> still fail. You can use 2.4.18-mh4 and apply these 5 patches
> from the bt-2.4 repository to it:
>
> [email protected], 2003-05-09 21:11:49-07:00
> [Bluetooth] RFCOMM must wait for MSC exchange to complete
> before sending the data.
>
> [email protected], 2003-05-09 16:41:45-07:00
> [Bluetooth] Detect and log error condition when first L2CAP
> fragment is too long.
>
> [email protected], 2003-05-09 11:55:22-07:00
> [Bluetooth] L2CAP config req/rsp handling fixes.
>
> [email protected], 2003-05-09 03:22:06+02:00
> [Bluetooth] Handle priority bits in parameter negotiation
>
> [email protected], 2003-05-09 02:07:07+02:00
> [Bluetooth] Send the correct values in RPN response
>
> Max, please go ahead and forward them to Marcelo and Linus.
> If you have some extra time, please update my repositories
> with the new stuff.
>
> I will make some new -mh patches on monday or tuesday.
-Daryl.
Marcel,
> maybe we have another RFCOMM misbehaviour, which doesn't=20
> matter in the real world, but can confuse the tester.
>=20
> < ACL data: handle 0x0029 flags 0x02 dlen 8
> L2CAP(d): cid 0x45 len 4 [psm 3]
> RFCOMM(s): DISC: cr 1 dlci 2 pf 1 ilen 0 fcs 0xb8=20
> > ACL data: handle 0x0029 flags 0x02 dlen 8
> L2CAP(d): cid 0x40 len 4 [psm 3]
> RFCOMM(s): UA: cr 1 dlci 2 pf 1 ilen 0 fcs 0x92=20
> < ACL data: handle 0x0029 flags 0x02 dlen 8
> L2CAP(d): cid 0x45 len 4 [psm 3]
> RFCOMM(s): DISC: cr 1 dlci 0 pf 1 ilen 0 fcs 0xfd=20
> < ACL data: handle 0x0029 flags 0x02 dlen 12
> L2CAP(s): Disconn req: dcid 0x0045 scid 0x0040
> > ACL data: handle 0x0029 flags 0x02 dlen 8
> L2CAP(d): cid 0x40 len 4 [psm 3]
> RFCOMM(s): UA: cr 1 dlci 0 pf 1 ilen 0 fcs 0xd7=20
> > ACL data: handle 0x0029 flags 0x02 dlen 12
> L2CAP(s): Disconn rsp: dcid 0x0045 scid 0x0040
>=20
> The dump above is from a disconnect sequence of RFCOMM. We=20
> don't wait for the UA of the DISC on the dlci 0. We send the=20
> L2CAP disconnect request right after the disconnect of the=20
> dlci 0. The L2CAP channel should be closed after receiving=20
> the UA or after a timeout.
I'd have to learn more about the spec to be able to talk with you
intelligently about this. There were quite a few RFCOMM tests we had to ski=
p
due to the other problems, so if you think you've found something that
doesn't quite follow the spec then we might get caught on it when we do the
rest of the tests. I'll query Cetecom about it.
> > I'll hold off on more testing until we've figured out a=20
> solution for=20
> > the L2CAP config stuff. More than likely something else=20
> will come out=20
> > the woodwork too, but probably not much. A number of tests=20
> had to be=20
> > postponed due to the previous failures.
>=20
> Daryl, this is your decision (and of course your money), but=20
> I think it will be good to see if our patches fixes the=20
> problems. New code can introduce new bugs :)
It'll definitely get tested! I just want to do the testing in batches. We'r=
e
only one failed test away from having a complete set.
-Daryl.
Hi Max,
> > Daryl, so it is now up to you to do your tests with Cetecom
> > again and see what we pass and what we fail. The RFCOMM layer
> > should now perform perfect, but the L2CAP config stuff will
> > still fail. You can use 2.4.18-mh4 and apply these 5 patches
> > from the bt-2.4 repository to it:
>
> Great work guys! Thanks!
maybe we have another RFCOMM misbehaviour, which doesn't matter in the
real world, but can confuse the tester.
< ACL data: handle 0x0029 flags 0x02 dlen 8
L2CAP(d): cid 0x45 len 4 [psm 3]
RFCOMM(s): DISC: cr 1 dlci 2 pf 1 ilen 0 fcs 0xb8
> ACL data: handle 0x0029 flags 0x02 dlen 8
L2CAP(d): cid 0x40 len 4 [psm 3]
RFCOMM(s): UA: cr 1 dlci 2 pf 1 ilen 0 fcs 0x92
< ACL data: handle 0x0029 flags 0x02 dlen 8
L2CAP(d): cid 0x45 len 4 [psm 3]
RFCOMM(s): DISC: cr 1 dlci 0 pf 1 ilen 0 fcs 0xfd
< ACL data: handle 0x0029 flags 0x02 dlen 12
L2CAP(s): Disconn req: dcid 0x0045 scid 0x0040
> ACL data: handle 0x0029 flags 0x02 dlen 8
L2CAP(d): cid 0x40 len 4 [psm 3]
RFCOMM(s): UA: cr 1 dlci 0 pf 1 ilen 0 fcs 0xd7
> ACL data: handle 0x0029 flags 0x02 dlen 12
L2CAP(s): Disconn rsp: dcid 0x0045 scid 0x0040
The dump above is from a disconnect sequence of RFCOMM. We don't wait
for the UA of the DISC on the dlci 0. We send the L2CAP disconnect
request right after the disconnect of the dlci 0. The L2CAP channel
should be closed after receiving the UA or after a timeout.
> I'll hold off on more testing until we've figured out a solution for the
> L2CAP config stuff. More than likely something else will come out the
> woodwork too, but probably not much. A number of tests had to be postponed
> due to the previous failures.
Daryl, this is your decision (and of course your money), but I think it
will be good to see if our patches fixes the problems. New code can
introduce new bugs :)
Regards
Marcel
-------------------------------------------------------
Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
The only event dedicated to issues related to Linux enterprise solutions
http://www.enterpriselinuxforum.com
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Marcel,
> Daryl, so it is now up to you to do your tests with Cetecom
> again and see what we pass and what we fail. The RFCOMM layer
> should now perform perfect, but the L2CAP config stuff will
> still fail. You can use 2.4.18-mh4 and apply these 5 patches
> from the bt-2.4 repository to it:
Great work guys! Thanks!
I'll hold off on more testing until we've figured out a solution for the
L2CAP config stuff. More than likely something else will come out the
woodwork too, but probably not much. A number of tests had to be postponed
due to the previous failures.
Re: l2cap config stuff:
We don't need any more logs or anything for that do we? I think we're just
trying to understand what it is exactly that we're supposed to do and why.
Max - You mentioned that the spec says that what the stack does with a
config reject can be implementation specific. I just had a look at the spec
and couldn't find it. Could you tell me where to look in the spec? Is the
following quote from section 5.5 Configure Response what you were referring
to?
"The decision on the amount of time (or messages) spent arbitrating the
channel parameters before terminating the negotiation is left to the
implementation."
-Daryl.
Hi Daryl,
> Cetecom is happy with the decision you guys have made. Sending the error to
> syslog so that it can be displayed on the system console and put in the
> system log file is good enough. If an app must know, it can monitor syslog.
> Everyone's in agreement that this is the right thing to do.
>
> Having the messages appear on the console is enough to pass testing. We
> shouldn't need a special app that monitors syslog. We could submit a copy of
> the syslog if necessary.
this is good to hear. Another test passed :)
Regards
Marcel
-------------------------------------------------------
Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
The only event dedicated to issues related to Linux enterprise solutions
http://www.enterpriselinuxforum.com
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Marcel,
I'm replying to myself again. But I said I would, so I guess that makes it
ok. ;)
Cetecom is happy with the decision you guys have made. Sending the error to
syslog so that it can be displayed on the system console and put in the
system log file is good enough. If an app must know, it can monitor syslog.
Everyone's in agreement that this is the right thing to do.
Having the messages appear on the console is enough to pass testing. We
shouldn't need a special app that monitors syslog. We could submit a copy o=
f
the syslog if necessary.
-Daryl.
> -----Original Message-----
> From: [email protected]=20
> [mailto:[email protected]] On Behalf Of=20
> Daryl Van Vorst
> Sent: May 10, 2003 8:57 PM
> To: 'Marcel Holtmann'; 'Max Krasnyansky'
> Cc: 'BlueZ Mailing List'
> Subject: RE: [Bluez-devel] Qualification Testing
>=20
>=20
> Marcel,
>=20
> > Daryl, can you please check with Cetecom what is really
> > needed to pass this test. From my understanding we do all=20
> > right, because we notifier the application (ok, in this case=20
> > the complete Linux system) with an error message in the syslog.
> >=20
> > How must the testing application react on these errors. Is it
> > enough to put an error on the screen, or must it close the=20
> > L2CAP connection. I think we should write a test application=20
> > which reads the syslog and deals with the L2CAP error=20
> > messages in some way.
>=20
> I think it is enough to put an error message on the screen.=20
> If necessary we could make the application look at syslog -=20
> which would definitely demonstrate the ability for the stack=20
> to notify the app.
>=20
> I'll verify this on Monday.
>=20
> -Daryl.
>=20
>=20
>=20
> -------------------------------------------------------
> Enterprise Linux Forum Conference & Expo, June 4-6, 2003,=20
> Santa Clara The only event dedicated to issues related to=20
> Linux enterprise solutions http://www.enterpriselinuxforum.com
>=20
> _______________________________________________
> Bluez-devel mailing list
> [email protected]=20
> https://lists.sourceforge.net/lists/listinfo/b> luez-devel
>=20
Hey Steve,
Unfortunately it will be a while until I can get a dump showing exactly wha=
t
happens. You saw the Merlin logs right? Was that not enough info? I assume
you just want the hcidump to see exactly what the stack is getting and
sending in case there is some problem with the module.
I have to do the tests in batches. I'll do another run of tests once I get
everything else resolved (or believe to be resolved). When I do the next se=
t
of tests I'll do an hcidump -w for all failures.
-Daryl.
> -----Original Message-----
> From: [email protected]=20
> [mailto:[email protected]] On Behalf Of=20
> Stephen Crane
> Sent: May 12, 2003 9:37 AM
> To: Daryl Van Vorst
> Cc: [email protected]
> Subject: RE: [Bluez-devel] Qualification Testing
>=20
>=20
> Hi Daryl,
>=20
> On Thu, 2003-05-08 at 03:18, Daryl Van Vorst wrote:
> > Steve,
> >=20
> > > > 2.) There appears to be a problem handling continuation
> > > > states. Handling continuation state is optional. We found=20
> > > that if the
> > > > querying device sends a maximum byte count of 100, the
> > > continutation
> > > > state worked fine. But if the querying device sent a=20
> maximum byte
> > > > count of 8, the continuation state doesn't work (the=20
> > > continuation flag
> > > > wasn't recognized in the next packet). I can dig up an
> > > example log if
> > > > it would help.
> > >=20
> > > Yeah it would be good to get a log. I imagine 8-bytes is
> > > pretty close to the minimum size.
>=20
> Would it be possible to get an hcidump from the machine on=20
> which the SDP server is running? (I am interested to see what=20
> data the SDP server is actually returning.)
>=20
> (hcidump -x -w file.dump -i hci0)
>=20
> Thanks,
> Steve
> --=20
> Stephen Crane, Rococo Software Ltd. http://www.rococosoft.com=20
> [email protected] +353-1-6601315 (ext 209)
>=20
>=20
>=20
> -------------------------------------------------------
> Enterprise Linux Forum Conference & Expo, June 4-6, 2003,=20
> Santa Clara The only event dedicated to issues related to=20
> Linux enterprise solutions http://www.enterpriselinuxforum.com
>=20
> _______________________________________________
> Bluez-devel mailing list
> [email protected]=20
> https://lists.sourceforge.net/lists/listinfo/b> luez-devel
>=20
-------------------------------------------------------
Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
The only event dedicated to issues related to Linux enterprise solutions
http://www.enterpriselinuxforum.com
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Daryl,
On Thu, 2003-05-08 at 03:18, Daryl Van Vorst wrote:
> Steve,
>
> > > 2.) There appears to be a problem handling continuation
> > > states. Handling continuation state is optional. We found
> > that if the
> > > querying device sends a maximum byte count of 100, the
> > continutation
> > > state worked fine. But if the querying device sent a maximum byte
> > > count of 8, the continuation state doesn't work (the
> > continuation flag
> > > wasn't recognized in the next packet). I can dig up an
> > example log if
> > > it would help.
> >
> > Yeah it would be good to get a log. I imagine 8-bytes is
> > pretty close to the minimum size.
Would it be possible to get an hcidump from the machine on which the SDP
server is running? (I am interested to see what data the SDP server is
actually returning.)
(hcidump -x -w file.dump -i hci0)
Thanks,
Steve
--
Stephen Crane, Rococo Software Ltd. http://www.rococosoft.com
[email protected] +353-1-6601315 (ext 209)
-------------------------------------------------------
Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
The only event dedicated to issues related to Linux enterprise solutions
http://www.enterpriselinuxforum.com
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Max,
> > > Ok. I've fixed that (and pushed changes to BK). My idea about
> > > with TX_THROTTLED flag didn't work. Well, it worked but only in
> > > one direction :). Changing state machine would've been fairly big
> > > change and could've affected compatibility.
> > > So I added a simple logic to track MSC exchange state. Works beautifully
> >
> > I like to see this logic in the state machine, but I agree with with you
> > that it is not the right time for changing it. Your patch works also
> > fine for me and I have a new 2.4.20 with all patches up and running.
> >
> Actually MSC exchange is not part of the connect procedure. After UA is
> received DLC is considered connected. Which means some implementations
> might not send first MSC before they have data to send, that's what
> meant that changing state machine could affect compatibility.
> Besides MSC exchange, just like L2CAP config, doesn't have strict
> sequence which makes it hard to track with a single state. i.e they
> sent MSC first, we sent MSC first, etc. So I think we're ok.
good point. And with your argument, I feel that you have choosen the
absolute correct way to implement this.
Regards
Marcel
-------------------------------------------------------
Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
The only event dedicated to issues related to Linux enterprise solutions
http://www.enterpriselinuxforum.com
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
On Sat, 2003-05-10 at 09:30, Marcel Holtmann wrote:
> > Ok. I've fixed that (and pushed changes to BK). My idea about
> > with TX_THROTTLED flag didn't work. Well, it worked but only in
> > one direction :). Changing state machine would've been fairly big
> > change and could've affected compatibility.
> > So I added a simple logic to track MSC exchange state. Works beautifully
>
> I like to see this logic in the state machine, but I agree with with you
> that it is not the right time for changing it. Your patch works also
> fine for me and I have a new 2.4.20 with all patches up and running.
>
Actually MSC exchange is not part of the connect procedure. After UA is
received DLC is considered connected. Which means some implementations
might not send first MSC before they have data to send, that's what
meant that changing state machine could affect compatibility.
Besides MSC exchange, just like L2CAP config, doesn't have strict
sequence which makes it hard to track with a single state. i.e they
sent MSC first, we sent MSC first, etc. So I think we're ok.
> Max, please go ahead and forward them to Marcelo and Linus. If you have
> some extra time, please update my repositories with the new stuff.
Will do.
Max
Marcel,
> Daryl, can you please check with Cetecom what is really
> needed to pass this test. From my understanding we do all
> right, because we notifier the application (ok, in this case
> the complete Linux system) with an error message in the syslog.
>
> How must the testing application react on these errors. Is it
> enough to put an error on the screen, or must it close the
> L2CAP connection. I think we should write a test application
> which reads the syslog and deals with the L2CAP error
> messages in some way.
I think it is enough to put an error message on the screen. If necessary we
could make the application look at syslog - which would definitely
demonstrate the ability for the stack to notify the app.
I'll verify this on Monday.
-Daryl.
Hi Max,
> > > >> 5.) Once an RFCOMM channel is established, the IUT must exchange
> > > >> MSC's (modem status commands) before sending data. That is, it must send an
> > > >> MSC, wait for a response, wait for the sender's MSC, and respond to it
> > > >> before sending data. Our device sent an MSC and then immediately started
> > > >> sending data when we used rctest. This applies to many test cases.
> > > >
> > > >We send the MSC after the UA. But we also go into BT_CONNECTED state and
> > > >in this state you can also start sending data. We should maybe go from
> > > >BT_CONNECT -> BT_CONFIG and only switch to BT_CONNECTED after the
> > > >successful exchange of MSC.
> > > I remember thinking about that. But they way I interpreted spec was that we
> > > don't have to wait for MSC response.
> > > This should be easy to fix.
> >
> > I leave this up to you to fix.
> >
> > > btw When CFC is not enabled we will have to wait for MSC from the other side. Notice that we set
> > > THROTTLED flag in that case. Which is cleared by the MSC or more credits.
> > > So I guess we can just always set that flag and clear it when we get MSC which will fix the MSC
> > > test case without messing with the state machine.
> >
> > Sounds reasonable to me.
>
> Ok. I've fixed that (and pushed changes to BK). My idea about
> with TX_THROTTLED flag didn't work. Well, it worked but only in
> one direction :). Changing state machine would've been fairly big
> change and could've affected compatibility.
> So I added a simple logic to track MSC exchange state. Works beautifully
I like to see this logic in the state machine, but I agree with with you
that it is not the right time for changing it. Your patch works also
fine for me and I have a new 2.4.20 with all patches up and running.
Daryl, so it is now up to you to do your tests with Cetecom again and
see what we pass and what we fail. The RFCOMM layer should now perform
perfect, but the L2CAP config stuff will still fail. You can use
2.4.18-mh4 and apply these 5 patches from the bt-2.4 repository to it:
[email protected], 2003-05-09 21:11:49-07:00
[Bluetooth] RFCOMM must wait for MSC exchange to complete before sending the data.
[email protected], 2003-05-09 16:41:45-07:00
[Bluetooth] Detect and log error condition when first L2CAP fragment is too long.
[email protected], 2003-05-09 11:55:22-07:00
[Bluetooth] L2CAP config req/rsp handling fixes.
[email protected], 2003-05-09 03:22:06+02:00
[Bluetooth] Handle priority bits in parameter negotiation
[email protected], 2003-05-09 02:07:07+02:00
[Bluetooth] Send the correct values in RPN response
Max, please go ahead and forward them to Marcelo and Linus. If you have
some extra time, please update my repositories with the new stuff.
I will make some new -mh patches on monday or tuesday.
Regards
Marcel
-------------------------------------------------------
Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
The only event dedicated to issues related to Linux enterprise solutions
http://www.enterpriselinuxforum.com
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Max,
> > The main problem is that wrong packets should not arrive at the L2CAP
> > layer. If they do and we decect them (like a length mismatch), we have
> > to close down all channels and remove the infected ACL link.
> The key words is 'should not' here. I've seen it happen because of USB problems
> or UART H4 problems. Not the wrong length but missing fragments and
> stuff.
and that's so stupid about this test. If you have problems with this, it
is not the fault of the L2CAP layer. You have to look for problems in
the HCI transport layer. Anyway I never had these problems with USB, I
only see them with a out of sync H4 driver.
> > Max, what do you think? This way is a little bit radical, but I think it
> > is an acceptable way of handling these errors. And with this method we
> > will pass this test.
> Yeah, I think it's a bit to aggressive. BNEP connection, for example,
> survives missing frags and pretty much anything else just fine.
>
> I'd rather keep the current code. Which I fixed btw to correctly drop
> frame if first fragment is too long. It was a real bug which could cause
> kernel oops in certain conditions.
Please don't understand me wrong. I like the current code, because it
gives us a chance to survice bad packets and didn't blow up the code
with some nasty checks that can't help us in this situation.
Daryl, can you please check with Cetecom what is really needed to pass
this test. From my understanding we do all right, because we notifier
the application (ok, in this case the complete Linux system) with an
error message in the syslog.
How must the testing application react on these errors. Is it enough to
put an error on the screen, or must it close the L2CAP connection. I
think we should write a test application which reads the syslog and
deals with the L2CAP error messages in some way.
Regards
Marcel
-------------------------------------------------------
Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
The only event dedicated to issues related to Linux enterprise solutions
http://www.enterpriselinuxforum.com
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
On Fri, 2003-05-09 at 17:26, Marcel Holtmann wrote:
> > Here's Cetecom's response to your comment:
> >
> > "Good point ! I agree, in a messed up remote L2CAP stack, CID could be wrong
> > as well if length is wrong. But I think it is a good approach to check
> > first, if that CID exists and if yes, notify the app about that channel."
> >
> > So how about we do this: As above, if it exists then we close it. If not,
> > we log an error.
>
> the proposal from Cetecom makes no sense.
>
> If you have one channel with correct data and you get a wrong packet
> which was for another channel, but the CID is corrupt and show now the
> value of the correct channel. You will infect a correct working channel
> with a false packet.
Yep. We could do that but it simply makes no sense. I'm glad our IP
stack doesn't kill random sockets when it receives corrupted IP packets,
just because it wants to indicate an error to an application and port
number happened to exist :-).
> The main problem is that wrong packets should not arrive at the L2CAP
> layer. If they do and we decect them (like a length mismatch), we have
> to close down all channels and remove the infected ACL link.
The key words is 'should not' here. I've seen it happen because of USB problems
or UART H4 problems. Not the wrong length but missing fragments and
stuff.
> Max, what do you think? This way is a little bit radical, but I think it
> is an acceptable way of handling these errors. And with this method we
> will pass this test.
Yeah, I think it's a bit to aggressive. BNEP connection, for example,
survives missing frags and pretty much anything else just fine.
I'd rather keep the current code. Which I fixed btw to correctly drop
frame if first fragment is too long. It was a real bug which could cause
kernel oops in certain conditions.
Max
On Thu, 2003-05-08 at 18:14, Marcel Holtmann wrote:
> > >> 2.) TP/RFC/BV-07: Closing rfcomm doesn't appear to close l2cap. Is
> > >> this true? This isn't actually required to pass this test, but it did
> > >> confuse the tester. This may have been a mistake on my part. I just hit
> > >> ctrl-c when rctest was connected and assumed that everything would get
> > >> closed. Would calling close() have a different effect?
> > >
> > >This is working fine for me. After closing the channel, we close dlci 0
> > >and this also closes the L2CAP connection.
> > Yes. I'm 100% sure it works. rfcomm_session_del() kills L2CAP socket.
>
> Can you remember if we had a problem with this in bluez-kernel-2.3 ?
It should work even in 2.3. But I wouldn't bet on it :)
> > >> 5.) Once an RFCOMM channel is established, the IUT must exchange
> > >> MSC's (modem status commands) before sending data. That is, it must send an
> > >> MSC, wait for a response, wait for the sender's MSC, and respond to it
> > >> before sending data. Our device sent an MSC and then immediately started
> > >> sending data when we used rctest. This applies to many test cases.
> > >
> > >We send the MSC after the UA. But we also go into BT_CONNECTED state and
> > >in this state you can also start sending data. We should maybe go from
> > >BT_CONNECT -> BT_CONFIG and only switch to BT_CONNECTED after the
> > >successful exchange of MSC.
> > I remember thinking about that. But they way I interpreted spec was that we
> > don't have to wait for MSC response.
> > This should be easy to fix.
>
> I leave this up to you to fix.
>
> > btw When CFC is not enabled we will have to wait for MSC from the other side. Notice that we set
> > THROTTLED flag in that case. Which is cleared by the MSC or more credits.
> > So I guess we can just always set that flag and clear it when we get MSC which will fix the MSC
> > test case without messing with the state machine.
>
> Sounds reasonable to me.
Ok. I've fixed that (and pushed changes to BK). My idea about
with TX_THROTTLED flag didn't work. Well, it worked but only in
one direction :). Changing state machine would've been fairly big
change and could've affected compatibility.
So I added a simple logic to track MSC exchange state. Works beautifully
:)
Max
> > So how about we do this: As above, if it exists then we
> close it. If
> > not, we log an error.
>
> the proposal from Cetecom makes no sense.
>
> If you have one channel with correct data and you get a wrong
> packet which was for another channel, but the CID is corrupt
> and show now the value of the correct channel. You will
> infect a correct working channel with a false packet.
>
> The main problem is that wrong packets should not arrive at
> the L2CAP layer. If they do and we decect them (like a length
> mismatch), we have to close down all channels and remove the
> infected ACL link.
>
> Max, what do you think? This way is a little bit radical, but
> I think it is an acceptable way of handling these errors. And
> with this method we will pass this test.
I like it. If the other end is that screwed up we should get rid of it
completely.
-Daryl.
Hi Daryl,
> > I was going to just drop the frame and log an error. The
> > thing is, if the packet header is corrupted (i.e. wrong
> > length, etc) we can't really trust its content. I mean if
> > length is wrong how do we know that CID is right. It means
> > that we don't really know which channel should be closed
> > (i.e. which app should be notified).
>
> Here's Cetecom's response to your comment:
>
> "Good point ! I agree, in a messed up remote L2CAP stack, CID could be wrong
> as well if length is wrong. But I think it is a good approach to check
> first, if that CID exists and if yes, notify the app about that channel."
>
> So how about we do this: As above, if it exists then we close it. If not,
> we log an error.
the proposal from Cetecom makes no sense.
If you have one channel with correct data and you get a wrong packet
which was for another channel, but the CID is corrupt and show now the
value of the correct channel. You will infect a correct working channel
with a false packet.
The main problem is that wrong packets should not arrive at the L2CAP
layer. If they do and we decect them (like a length mismatch), we have
to close down all channels and remove the infected ACL link.
Max, what do you think? This way is a little bit radical, but I think it
is an acceptable way of handling these errors. And with this method we
will pass this test.
Regards
Marcel
-------------------------------------------------------
Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
The only event dedicated to issues related to Linux enterprise solutions
http://www.enterpriselinuxforum.com
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Max,
> I was going to just drop the frame and log an error. The=20
> thing is, if the packet header is corrupted (i.e. wrong=20
> length, etc) we can't really trust its content. I mean if=20
> length is wrong how do we know that CID is right. It means=20
> that we don't really know which channel should be closed=20
> (i.e. which app should be notified).
Here's Cetecom's response to your comment:
"Good point ! I agree, in a messed up remote L2CAP stack, CID could be wron=
g
as well if length is wrong. But I think it is a good approach to check
first, if that CID exists and if yes, notify the app about that channel."
So how about we do this: As above, if it exists then we close it. If not,
we log an error.
-Daryl.
Max,
> I was going to just drop the frame and log an error. The=20
> thing is, if the packet header is corrupted (i.e. wrong=20
> length, etc) we can't really trust its content. I mean if=20
> length is wrong how do we know that CID is right. It means=20
> that we don't really know which channel should be closed=20
> (i.e. which app should be notified).
Interesting point.
To pass qualification it's easy enough for us to just close the channel. Bu=
t
I agree, it's risky. I'll pass your comment along.
-Daryl.
On Fri, 2003-05-09 at 14:52, Daryl Van Vorst wrote:
> > > Not sure if you saw a slightly more recent post from me. The test
> > > isn't quite as stupid as it seems. When the tester rejects
> > the config
> > > request, it gives desired configuration values inside that
> > response.
> > > We're supposed to return those values in the next config request
> > > (providing we like them well enough). It'll accept those
> > values. This
> > > behaviour makes sense to me now. Thoughts?
> > It's still stupid :).
> > First of all there is an inconsistency between core spec and
> > test spec. Core spec says that response to config reject is
> > implementation specific and implementation may chose to close
> > the channel. So test spec has test case to test
> > _implementation specific_ thing :) It also doesn't make much
> > sense if you think about real applications.
>
> If you're right about the inconsistency then we should be able to argue our
> way to a pass verdict on that test. I just had a look at the L2CAP spec and
> it sure looks like you're right. I'll pass that along to Cetecom. We'll see
> what they say...
Good luck :)
> > > I sent a raw HCI dump for the two test cases in another
> > message to the
> > > list yesterday. Is that enough information?
> > Should be enough. I think I found a bug in that code. We'd
> > incorrectly handle that case when received l2cap frame is
> > larger than length in the header. I'll fix that.
>
> Good news: I just got a note from Cetecom regarding this. They say it's ok
> if the stack closes the connection after detecting the inconsistency, since
> the remote side seems to be screwed up. The next packet is _NOT_ required to
> be received (I was wrong about thinking that the next packet needed to be
> received). The 2nd packet sent by the tester just has the purpose to give a
> L2CAP start packet indication (to avoid waiting for any outstanding data).
>
> So with your fix will L2CAP close the connection and report an error to the
> application for these two test malformed l2cap test cases?
I was going to just drop the frame and log an error. The thing is, if
the packet header is corrupted (i.e. wrong length, etc) we can't really
trust its content. I mean if length is wrong how do we know that CID is
right. It means that we don't really know which channel should be closed
(i.e. which app should be notified).
Max
Max,
> > > > >> 3.) TP/COS/CFD/BV-02: Tests that IUT is able=20
> to perform
> > > > >> negotiation while the tester rejects the=20
> configuration of a data=20
> > > > >> channel. The IUT sends a configuration request and=20
> the tester=20
> > > > >> rejects it. The IUT should send another configuration=20
> > > request, but
> > > > >> it does not.
> > > > >
> > > > >Currently the channel is closed if they reject our config=20
> > > > >request,
> > > > >because we don't know how to proceed if they don't like=20
> > > our settings.
> > > > >We can sent them again, but they will be rejected=20
> again. For this
> > > > >case I also have to read the L2CAP in detail.
> > > > Yeah we talked about that. Test is stupid. I'm not sure=20
> how to fix
> > > > that without
> > > > affecting general logic.=20
> > >=20
> > > I put this to the last item on the list. At the moment I
> > > don't care, but I will spent some time to look at it.
> >=20
> > Not sure if you saw a slightly more recent post from me. The test=20
> > isn't quite as stupid as it seems. When the tester rejects=20
> the config=20
> > request, it gives desired configuration values inside that=20
> response.=20
> > We're supposed to return those values in the next config request=20
> > (providing we like them well enough). It'll accept those=20
> values. This=20
> > behaviour makes sense to me now. Thoughts?
> It's still stupid :).
> First of all there is an inconsistency between core spec and=20
> test spec. Core spec says that response to config reject is=20
> implementation specific and implementation may chose to close=20
> the channel. So test spec has test case to test=20
> _implementation specific_ thing :) It also doesn't make much=20
> sense if you think about real applications.
If you're right about the inconsistency then we should be able to argue our
way to a pass verdict on that test. I just had a look at the L2CAP spec and
it sure looks like you're right. I'll pass that along to Cetecom. We'll see
what they say...
> > > > >> 4.) TP/COS/RCO/BI-01, BI-02: These tests verify that=20
> > > > >> the
> > > > >> IUT performs a consistency check on the data. Both tests=20
> > > send two
> > > > >> packets to the IUT. In each test, the first packet has a
> > > mistake.
> > > > >> In BI-01 the first packet is too short by one byte, and in=20
> > > > >> BI-02
> > > > >> the first packet is too long by one byte. In both cases=20
> > > the stack
> > > > >> must correctly receive the second packet, but not the first.=20
> > > > >> The
> > > > >> data should be discarded in the case of the=20
> > > inconsistencies, and an
> > > > >> error reported to the application.
> > > > >
> > > > >It seems that we can't handle this case complete correctly, if=20
> > > > >the
> > > > >data was put only in one fragment. But in the basics this=20
> > > should work
> > > > >and the malformed packets should be dropped. Did you have
> > > a detailed
> > > > >log of this test which shows us byte by byte which request
> > > was sent?
> > > > Hmm, how should we return error to the application. Most socket=20
> > > > app
> > > > close
> > > > the socket than read() returns error. i.e. Even if we fix=20
> > > the kernel to
> > > > return some BT specific error, test will fail on other apps
> > > which will
> > > > simply close the socket.
> > > > Also are those corrupted data packets or signaling packets ? If=20
> > > > signalling we're not supposed to return error to all
> > > L2CAP apps are we ? ;-)
> > >=20
> > > The test should pass if we correctly drop those wrong
> > > packets. But we need to see how the test acts. We need a=20
> > > "hcidump -w <file>".=20
> >=20
> > I sent a raw HCI dump for the two test cases in another=20
> message to the=20
> > list yesterday. Is that enough information?
> Should be enough. I think I found a bug in that code. We'd=20
> incorrectly handle that case when received l2cap frame is=20
> larger than length in the header. I'll fix that.
Good news: I just got a note from Cetecom regarding this. They say it's ok
if the stack closes the connection after detecting the inconsistency, since
the remote side seems to be screwed up. The next packet is _NOT_ required t=
o
be received (I was wrong about thinking that the next packet needed to be
received). The 2nd packet sent by the tester just has the purpose to give a
L2CAP start packet indication (to avoid waiting for any outstanding data).
So with your fix will L2CAP close the connection and report an error to the
application for these two test malformed l2cap test cases?
-Daryl.
On Fri, 2003-05-09 at 11:11, Daryl Van Vorst wrote:
> > > >> 3.) TP/COS/CFD/BV-02: Tests that IUT is able to perform
> > > >> negotiation while the tester rejects the configuration of a data
> > > >> channel. The IUT sends a configuration request and the tester
> > > >> rejects it. The IUT should send another configuration
> > request, but
> > > >> it does not.
> > > >
> > > >Currently the channel is closed if they reject our config request,
> > > >because we don't know how to proceed if they don't like
> > our settings.
> > > >We can sent them again, but they will be rejected again. For this
> > > >case I also have to read the L2CAP in detail.
> > > Yeah we talked about that. Test is stupid. I'm not sure how to fix
> > > that without
> > > affecting general logic.
> >
> > I put this to the last item on the list. At the moment I
> > don't care, but I will spent some time to look at it.
>
> Not sure if you saw a slightly more recent post from me. The test isn't
> quite as stupid as it seems. When the tester rejects the config request, it
> gives desired configuration values inside that response. We're supposed to
> return those values in the next config request (providing we like them well
> enough). It'll accept those values. This behaviour makes sense to me now.
> Thoughts?
It's still stupid :).
First of all there is an inconsistency between core spec and test spec.
Core spec says that response to config reject is implementation specific
and implementation may chose to close the channel. So test spec has
test case to test _implementation specific_ thing :)
It also doesn't make much sense if you think about real applications.
> > > >> 4.) TP/COS/RCO/BI-01, BI-02: These tests verify that the
> > > >> IUT performs a consistency check on the data. Both tests
> > send two
> > > >> packets to the IUT. In each test, the first packet has a
> > mistake.
> > > >> In BI-01 the first packet is too short by one byte, and in BI-02
> > > >> the first packet is too long by one byte. In both cases
> > the stack
> > > >> must correctly receive the second packet, but not the first. The
> > > >> data should be discarded in the case of the
> > inconsistencies, and an
> > > >> error reported to the application.
> > > >
> > > >It seems that we can't handle this case complete correctly, if the
> > > >data was put only in one fragment. But in the basics this
> > should work
> > > >and the malformed packets should be dropped. Did you have
> > a detailed
> > > >log of this test which shows us byte by byte which request
> > was sent?
> > > Hmm, how should we return error to the application. Most socket app
> > > close
> > > the socket than read() returns error. i.e. Even if we fix
> > the kernel to
> > > return some BT specific error, test will fail on other apps
> > which will
> > > simply close the socket.
> > > Also are those corrupted data packets or signaling packets ?
> > > If signalling we're not supposed to return error to all
> > L2CAP apps are we ? ;-)
> >
> > The test should pass if we correctly drop those wrong
> > packets. But we need to see how the test acts. We need a
> > "hcidump -w <file>".
>
> I sent a raw HCI dump for the two test cases in another message to the list
> yesterday. Is that enough information?
Should be enough. I think I found a bug in that code. We'd incorrectly
handle that case when received l2cap frame is larger than length in the
header. I'll fix that.
Max
Hi Daryl,
> Not sure if you saw a slightly more recent post from me. The test isn't
> quite as stupid as it seems. When the tester rejects the config request, it
> gives desired configuration values inside that response. We're supposed to
> return those values in the next config request (providing we like them well
> enough). It'll accept those values. This behaviour makes sense to me now.
> Thoughts?
I have seen your post, but I don't have started to look deeper into it.
> I sent a raw HCI dump for the two test cases in another message to the list
> yesterday. Is that enough information?
Please send me the binary dump file, because it is easier for me to work
with it.
Regards
Marcel
-------------------------------------------------------
Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
The only event dedicated to issues related to Linux enterprise solutions
http://www.enterpriselinuxforum.com
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Max, Marcel,
> > >> 1.) TP/COS/CED/BI-01: Verifies that the IUT rejects an
> > >> unkown signalling command. The tester sends an unkown L2CAP
> > >> command. The IUT should respond with an L2CAP_Reject
> with reason 0
> > >> "Command not understood". The IUT did not.
> > >
> > >We have a fixme for this in the l2cap.c code, but
> currently no code
> > >exists. Should be easy to fix, but nobody cares about it.
> > Hold on. That's exactly what we do
> > if (err) {
> > l2cap_cmd_rej rej;
> > BT_DBG("error %d", err);
> >
> > /* FIXME: Map err to a valid reason. */
> > rej.reason = __cpu_to_le16(0);
> > l2cap_send_rsp(conn, cmd.ident,
> L2CAP_COMMAND_REJ, L2CAP_CMD_REJ_SIZE, &rej);
> > }
> > Reason is always set to 0.
> > Test should not fail.
>
> you are right. This test should not fail.
Ok. That could have been something else going wrong then. When I get the
detailed logs I'll look through them closely. If it still appears that
something's wrong with the stack, I'll forward the details.
> > >> 2.) TP/COS/CFD/BV-01: Tests that IUT is able to
> handle the
> > >> receiving of more than one request for configuration of data
> > >> channel. Tester sends L2CAP_Config Req with flag=1, IUT responds
> > >> with flag=0. According to section 5.4 p.290 of the version 1.1
> > >> spec, "When used in the Configuration Response, the continuation
> > >> flag must be set if the flag is set in the Request".
> > >
> > >This seems to be a bug in the current code. But I have to
> re-read the
> > >L2CAP specification for the details.
> > Easy.
> >
> > --- 1.9/net/bluetooth/l2cap.c Wed Apr 23 04:45:41 2003
> > +++ edited/net/bluetooth/l2cap.c Thu May 8 17:26:28 2003
> > @@ -1320,15 +1320,18 @@
> > {
> > l2cap_conf_rsp *rsp = (l2cap_conf_rsp *) data;
> > void *ptr = rsp->data;
> > + u16 flags = 0;
> >
> > BT_DBG("sk %p complete %d", sk, result ? 1 : 0);
> >
> > if (result)
> > *result = l2cap_conf_output(sk, &ptr);
> > + else
> > + flags |= 0x0001;
> >
> > rsp->scid = __cpu_to_le16(l2cap_pi(sk)->dcid);
> > rsp->result = __cpu_to_le16(result ? *result : 0);
> > - rsp->flags = __cpu_to_le16(0);
> > + rsp->flags = __cpu_to_le16(flags);
> >
> > return ptr - data;
> >
> > I'll commit this to my BK.
>
> Fine.
Thanks guys. :)
> > >> 3.) TP/COS/CFD/BV-02: Tests that IUT is able to perform
> > >> negotiation while the tester rejects the configuration of a data
> > >> channel. The IUT sends a configuration request and the tester
> > >> rejects it. The IUT should send another configuration
> request, but
> > >> it does not.
> > >
> > >Currently the channel is closed if they reject our config request,
> > >because we don't know how to proceed if they don't like
> our settings.
> > >We can sent them again, but they will be rejected again. For this
> > >case I also have to read the L2CAP in detail.
> > Yeah we talked about that. Test is stupid. I'm not sure how to fix
> > that without
> > affecting general logic.
>
> I put this to the last item on the list. At the moment I
> don't care, but I will spent some time to look at it.
Not sure if you saw a slightly more recent post from me. The test isn't
quite as stupid as it seems. When the tester rejects the config request, it
gives desired configuration values inside that response. We're supposed to
return those values in the next config request (providing we like them well
enough). It'll accept those values. This behaviour makes sense to me now.
Thoughts?
> > >> 4.) TP/COS/RCO/BI-01, BI-02: These tests verify that the
> > >> IUT performs a consistency check on the data. Both tests
> send two
> > >> packets to the IUT. In each test, the first packet has a
> mistake.
> > >> In BI-01 the first packet is too short by one byte, and in BI-02
> > >> the first packet is too long by one byte. In both cases
> the stack
> > >> must correctly receive the second packet, but not the first. The
> > >> data should be discarded in the case of the
> inconsistencies, and an
> > >> error reported to the application.
> > >
> > >It seems that we can't handle this case complete correctly, if the
> > >data was put only in one fragment. But in the basics this
> should work
> > >and the malformed packets should be dropped. Did you have
> a detailed
> > >log of this test which shows us byte by byte which request
> was sent?
> > Hmm, how should we return error to the application. Most socket app
> > close
> > the socket than read() returns error. i.e. Even if we fix
> the kernel to
> > return some BT specific error, test will fail on other apps
> which will
> > simply close the socket.
> > Also are those corrupted data packets or signaling packets ?
> > If signalling we're not supposed to return error to all
> L2CAP apps are we ? ;-)
>
> The test should pass if we correctly drop those wrong
> packets. But we need to see how the test acts. We need a
> "hcidump -w <file>".
I sent a raw HCI dump for the two test cases in another message to the list
yesterday. Is that enough information?
-Daryl.
Hi Max,
> >> 1.) TP/COS/CED/BI-01: Verifies that the IUT rejects an unkown
> >> signalling command. The tester sends an unkown L2CAP command. The IUT should
> >> respond with an L2CAP_Reject with reason 0 "Command not understood". The IUT
> >> did not.
> >
> >We have a fixme for this in the l2cap.c code, but currently no code
> >exists. Should be easy to fix, but nobody cares about it.
> Hold on. That's exactly what we do
> if (err) {
> l2cap_cmd_rej rej;
> BT_DBG("error %d", err);
>
> /* FIXME: Map err to a valid reason. */
> rej.reason = __cpu_to_le16(0);
> l2cap_send_rsp(conn, cmd.ident, L2CAP_COMMAND_REJ, L2CAP_CMD_REJ_SIZE, &rej);
> }
> Reason is always set to 0.
> Test should not fail.
you are right. This test should not fail.
> >> 2.) TP/COS/CFD/BV-01: Tests that IUT is able to handle the receiving
> >> of more than one request for configuration of data channel. Tester sends
> >> L2CAP_Config Req with flag=1, IUT responds with flag=0. According to section
> >> 5.4 p.290 of the version 1.1 spec, "When used in the Configuration Response,
> >> the continuation flag must be set if the flag is set in the Request".
> >
> >This seems to be a bug in the current code. But I have to re-read the
> >L2CAP specification for the details.
> Easy.
>
> --- 1.9/net/bluetooth/l2cap.c Wed Apr 23 04:45:41 2003
> +++ edited/net/bluetooth/l2cap.c Thu May 8 17:26:28 2003
> @@ -1320,15 +1320,18 @@
> {
> l2cap_conf_rsp *rsp = (l2cap_conf_rsp *) data;
> void *ptr = rsp->data;
> + u16 flags = 0;
>
> BT_DBG("sk %p complete %d", sk, result ? 1 : 0);
>
> if (result)
> *result = l2cap_conf_output(sk, &ptr);
> + else
> + flags |= 0x0001;
>
> rsp->scid = __cpu_to_le16(l2cap_pi(sk)->dcid);
> rsp->result = __cpu_to_le16(result ? *result : 0);
> - rsp->flags = __cpu_to_le16(0);
> + rsp->flags = __cpu_to_le16(flags);
>
> return ptr - data;
>
> I'll commit this to my BK.
Fine.
> >> 3.) TP/COS/CFD/BV-02: Tests that IUT is able to perform negotiation
> >> while the tester rejects the configuration of a data channel. The IUT sends
> >> a configuration request and the tester rejects it. The IUT should send
> >> another configuration request, but it does not.
> >
> >Currently the channel is closed if they reject our config request,
> >because we don't know how to proceed if they don't like our settings. We
> >can sent them again, but they will be rejected again. For this case I
> >also have to read the L2CAP in detail.
> Yeah we talked about that. Test is stupid. I'm not sure how to fix that without
> affecting general logic.
I put this to the last item on the list. At the moment I don't care, but
I will spent some time to look at it.
> >> 4.) TP/COS/RCO/BI-01, BI-02: These tests verify that the IUT
> >> performs a consistency check on the data. Both tests send two packets to the
> >> IUT. In each test, the first packet has a mistake. In BI-01 the first packet
> >> is too short by one byte, and in BI-02 the first packet is too long by one
> >> byte. In both cases the stack must correctly receive the second packet, but
> >> not the first. The data should be discarded in the case of the
> >> inconsistencies, and an error reported to the application.
> >
> >It seems that we can't handle this case complete correctly, if the data
> >was put only in one fragment. But in the basics this should work and the
> >malformed packets should be dropped. Did you have a detailed log of this
> >test which shows us byte by byte which request was sent?
> Hmm, how should we return error to the application. Most socket app close
> the socket than read() returns error. i.e. Even if we fix the kernel to
> return some BT specific error, test will fail on other apps which will
> simply close the socket.
> Also are those corrupted data packets or signaling packets ?
> If signalling we're not supposed to return error to all L2CAP apps are we ? ;-)
The test should pass if we correctly drop those wrong packets. But we
need to see how the test acts. We need a "hcidump -w <file>".
> >> RFCOMM:
> >> Note: Some of these comments don't apply to a specific test case
> >> (they are more general).
> >> 1.) Must not modify pbits in pn (parameter negotiation) response.
> >> The pbits are dependent on which DLC is being configured. Apparently this is
> >> a common problem, and one that has been argued about with the SIG because
> >> apparently nobody uses the bits - but the SIG would not give in (refer to
> >> erratum 364). They are specified in the TS GSM 07.10 630 spec, section
> >> 5.4.6.3.1.
> Yeah, we can fix that. We simply have to copy those bits into response.
> Another one of those useless rules.
I have fixed this already.
> >> 2.) TP/RFC/BV-07: Closing rfcomm doesn't appear to close l2cap. Is
> >> this true? This isn't actually required to pass this test, but it did
> >> confuse the tester. This may have been a mistake on my part. I just hit
> >> ctrl-c when rctest was connected and assumed that everything would get
> >> closed. Would calling close() have a different effect?
> >
> >This is working fine for me. After closing the channel, we close dlci 0
> >and this also closes the L2CAP connection.
> Yes. I'm 100% sure it works. rfcomm_session_del() kills L2CAP socket.
Can you remember if we had a problem with this in bluez-kernel-2.3 ?
> >> 5.) Once an RFCOMM channel is established, the IUT must exchange
> >> MSC's (modem status commands) before sending data. That is, it must send an
> >> MSC, wait for a response, wait for the sender's MSC, and respond to it
> >> before sending data. Our device sent an MSC and then immediately started
> >> sending data when we used rctest. This applies to many test cases.
> >
> >We send the MSC after the UA. But we also go into BT_CONNECTED state and
> >in this state you can also start sending data. We should maybe go from
> >BT_CONNECT -> BT_CONFIG and only switch to BT_CONNECTED after the
> >successful exchange of MSC.
> I remember thinking about that. But they way I interpreted spec was that we
> don't have to wait for MSC response.
> This should be easy to fix.
I leave this up to you to fix.
> >> 6.) If a connecting device doesn't send a PN command with CL bits
> >> set to 0x0f, then it means it is not a 1.1 device and we must not use credit
> >> based flow control. In our case, when such a PN command was received, data
> >> was sent using credit based flow control but shouldn't have been. This
> >> applies to many test cases.
> I don't believe your testing software :).
> So you should check your tester app :).
I think we changed some code of the credit based flow control handling
from bluez-kernel-2.3 to the current state.
> btw When CFC is not enabled we will have to wait for MSC from the other side. Notice that we set
> THROTTLED flag in that case. Which is cleared by the MSC or more credits.
> So I guess we can just always set that flag and clear it when we get MSC which will fix the MSC
> test case without messing with the state machine.
Sounds reasonable to me.
Regards
Marcel
-------------------------------------------------------
Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
The only event dedicated to issues related to Linux enterprise solutions
http://www.enterpriselinuxforum.com
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
At 06:43 AM 5/8/2003, Marcel Holtmann wrote:
>> L2CAP:
>> 1.) TP/COS/CED/BI-01: Verifies that the IUT rejects an unkown
>> signalling command. The tester sends an unkown L2CAP command. The IUT should
>> respond with an L2CAP_Reject with reason 0 "Command not understood". The IUT
>> did not.
>
>We have a fixme for this in the l2cap.c code, but currently no code
>exists. Should be easy to fix, but nobody cares about it.
Hold on. That's exactly what we do
if (err) {
l2cap_cmd_rej rej;
BT_DBG("error %d", err);
/* FIXME: Map err to a valid reason. */
rej.reason = __cpu_to_le16(0);
l2cap_send_rsp(conn, cmd.ident, L2CAP_COMMAND_REJ, L2CAP_CMD_REJ_SIZE, &rej);
}
Reason is always set to 0.
Test should not fail.
>> 2.) TP/COS/CFD/BV-01: Tests that IUT is able to handle the receiving
>> of more than one request for configuration of data channel. Tester sends
>> L2CAP_Config Req with flag=1, IUT responds with flag=0. According to section
>> 5.4 p.290 of the version 1.1 spec, "When used in the Configuration Response,
>> the continuation flag must be set if the flag is set in the Request".
>
>This seems to be a bug in the current code. But I have to re-read the
>L2CAP specification for the details.
Easy.
--- 1.9/net/bluetooth/l2cap.c Wed Apr 23 04:45:41 2003
+++ edited/net/bluetooth/l2cap.c Thu May 8 17:26:28 2003
@@ -1320,15 +1320,18 @@
{
l2cap_conf_rsp *rsp = (l2cap_conf_rsp *) data;
void *ptr = rsp->data;
+ u16 flags = 0;
BT_DBG("sk %p complete %d", sk, result ? 1 : 0);
if (result)
*result = l2cap_conf_output(sk, &ptr);
+ else
+ flags |= 0x0001;
rsp->scid = __cpu_to_le16(l2cap_pi(sk)->dcid);
rsp->result = __cpu_to_le16(result ? *result : 0);
- rsp->flags = __cpu_to_le16(0);
+ rsp->flags = __cpu_to_le16(flags);
return ptr - data;
I'll commit this to my BK.
>> 3.) TP/COS/CFD/BV-02: Tests that IUT is able to perform negotiation
>> while the tester rejects the configuration of a data channel. The IUT sends
>> a configuration request and the tester rejects it. The IUT should send
>> another configuration request, but it does not.
>
>Currently the channel is closed if they reject our config request,
>because we don't know how to proceed if they don't like our settings. We
>can sent them again, but they will be rejected again. For this case I
>also have to read the L2CAP in detail.
Yeah we talked about that. Test is stupid. I'm not sure how to fix that without
affecting general logic.
>> 4.) TP/COS/RCO/BI-01, BI-02: These tests verify that the IUT
>> performs a consistency check on the data. Both tests send two packets to the
>> IUT. In each test, the first packet has a mistake. In BI-01 the first packet
>> is too short by one byte, and in BI-02 the first packet is too long by one
>> byte. In both cases the stack must correctly receive the second packet, but
>> not the first. The data should be discarded in the case of the
>> inconsistencies, and an error reported to the application.
>
>It seems that we can't handle this case complete correctly, if the data
>was put only in one fragment. But in the basics this should work and the
>malformed packets should be dropped. Did you have a detailed log of this
>test which shows us byte by byte which request was sent?
Hmm, how should we return error to the application. Most socket app close
the socket than read() returns error. i.e. Even if we fix the kernel to
return some BT specific error, test will fail on other apps which will
simply close the socket.
Also are those corrupted data packets or signaling packets ?
If signalling we're not supposed to return error to all L2CAP apps are we ? ;-)
>> RFCOMM:
>> Note: Some of these comments don't apply to a specific test case
>> (they are more general).
>> 1.) Must not modify pbits in pn (parameter negotiation) response.
>> The pbits are dependent on which DLC is being configured. Apparently this is
>> a common problem, and one that has been argued about with the SIG because
>> apparently nobody uses the bits - but the SIG would not give in (refer to
>> erratum 364). They are specified in the TS GSM 07.10 630 spec, section
>> 5.4.6.3.1.
Yeah, we can fix that. We simply have to copy those bits into response.
Another one of those useless rules.
>> 2.) TP/RFC/BV-07: Closing rfcomm doesn't appear to close l2cap. Is
>> this true? This isn't actually required to pass this test, but it did
>> confuse the tester. This may have been a mistake on my part. I just hit
>> ctrl-c when rctest was connected and assumed that everything would get
>> closed. Would calling close() have a different effect?
>
>This is working fine for me. After closing the channel, we close dlci 0
>and this also closes the L2CAP connection.
Yes. I'm 100% sure it works. rfcomm_session_del() kills L2CAP socket.
>> 5.) Once an RFCOMM channel is established, the IUT must exchange
>> MSC's (modem status commands) before sending data. That is, it must send an
>> MSC, wait for a response, wait for the sender's MSC, and respond to it
>> before sending data. Our device sent an MSC and then immediately started
>> sending data when we used rctest. This applies to many test cases.
>
>We send the MSC after the UA. But we also go into BT_CONNECTED state and
>in this state you can also start sending data. We should maybe go from
>BT_CONNECT -> BT_CONFIG and only switch to BT_CONNECTED after the
>successful exchange of MSC.
I remember thinking about that. But they way I interpreted spec was that we
don't have to wait for MSC response.
This should be easy to fix.
>> 6.) If a connecting device doesn't send a PN command with CL bits
>> set to 0x0f, then it means it is not a 1.1 device and we must not use credit
>> based flow control. In our case, when such a PN command was received, data
>> was sent using credit based flow control but shouldn't have been. This
>> applies to many test cases.
I don't believe your testing software :).
static int rfcomm_apply_pn(struct rfcomm_dlc *d, int cr, struct rfcomm_pn *pn)
{
...
if (cr) {
if (pn->flow_ctrl == 0xf0) {
d->tx_credits = pn->credits;
} else {
set_bit(RFCOMM_TX_THROTTLED, &d->flags);
d->credits = 0;
}
...
static int rfcomm_send_pn(struct rfcomm_session *s, int cr, struct rfcomm_dlc *d)
{
...
if (d->credits) {
pn->flow_ctrl = cr ? 0xf0 : 0xe0;
pn->credits = RFCOMM_DEFAULT_CREDITS;
} else {
pn->flow_ctrl = 0;
pn->credits = 0;
}
...
And thought out the code we have things like
if (d->credits) {
/* CFC enabled.
* Give them some credits */
if (!test_bit(RFCOMM_RX_THROTTLED, &d->flags) &&
d->rx_credits <= (d->credits >> 2)) {
rfcomm_send_credits(d->session, d->addr, d->credits - d->rx_credits);
d->rx_credits = d->credits;
}
} else {
/* CFC disabled.
* Give ourselves some credits */
d->tx_credits = 5;
}
So you should check your tester app :).
btw When CFC is not enabled we will have to wait for MSC from the other side. Notice that we set
THROTTLED flag in that case. Which is cleared by the MSC or more credits.
So I guess we can just always set that flag and clear it when we get MSC which will fix the MSC
test case without messing with the state machine.
Max
Hi Daryl,
> Have a look at the rfcomm_recv_rpn() function pasted below. I did a diff
> between it and the latest, and the only difference is how a variable is
> declared - nothing significant.
>
> Here's what I see happening:
>
> Take a look at XON and XOFF. If we see a value we don't like, we set
> rpn->xon_char to the value that we would like to see. We also update the
> rpn_mask variable. Then at the bottom of the function we call
> rfcomm_send_rpn() with xon_char and not rpn->xon_char. So it sends 0 instead
> of the desired character, but it does send the correct rpn_mask.
>
> It looks to me like most of the tests act on the right variables. Just xon,
> xoff, and flow control appear to have the problem.
>
> Do you agree?
it seems that you are right. I have a fix for this in my repository.
Regards
Marcel
-------------------------------------------------------
Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
The only event dedicated to issues related to Linux enterprise solutions
http://www.enterpriselinuxforum.com
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Steve,
> > 2.) There appears to be a problem handling continuation
> > states. Handling continuation state is optional. We found
> that if the
> > querying device sends a maximum byte count of 100, the
> continutation
> > state worked fine. But if the querying device sent a maximum byte
> > count of 8, the continuation state doesn't work (the
> continuation flag
> > wasn't recognized in the next packet). I can dig up an
> example log if
> > it would help.
>
> Yeah it would be good to get a log. I imagine 8-bytes is
> pretty close to the minimum size.
Attached is a log of the failed query. It's from a CATC Merlin. You'll
have to download a free viewer from CATC:
http://www.catc.com/support/software/bluetooth_trace_viewer.html
To see the query the following steps should work (I'm new to this software.
These steps worked for me.):
1. Open the .blt file in the viewer.
2. In the display area, right click and select Display Options.
3. In the General tab (the one that comes up by default) check SDP Protocol
(it'll check SDP messages and L2CAP automatically), and click Apply.
4. Click the Hiding tab in Display Options.
5. On the bottom right under "Levels to Hide", check Packets, then click
Apply.
Now the screen should show a number of L2CAP packets, and two SDP queries.
The first SDP query works, the second fails (the view shows "Error
Incomplete" in red). On the left, click (left click) the box that says
"SDP/1" (there's a little arrow in it hinting that it can be expanded) and
click Expand Transaction. You can see the that the transaction fails due to
a confusion about the continuation state.
-Daryl.
Hi Daryl,
> It'll take me a bit of time to gather all of the logs. I'll send them to you
> as I get them. The logs are a bit lengthy, so I'll send them directly to you
> instead of the list.
no problem. My mailbox can accept large emails.
> The product hasn't been released yet, so I can't publicly discuss too much.
> We could talk a bit off-list about it if you'd like.
Maybe you can send me a short discription off-list.
> Yeah, I figured. It took a bit of work, but I now have a 2.4.18 kernel up
> to mh4 (the latest on your site).
The 2.4.18-mh4 should work fine and the Bluetooth subsystem is the same
as the 2.4.20-mh7 and the not released 2.4.21-rc2.
> Yup. From here on it will be done on an up-to-date kernel (Is 2.4.18 with
> your most recent patch level considered up-to-date? Moving to 2.4.20 would
> be a major hassle). I would have done that earlier, but I didn't realize how
> outdated the bluez-kernel package was until it was too late.
You don't get any problem with an updated Bluetooth subsystem of the
2.4.18. If no other subsystem will break your setup, you are still on
the safe way.
> Heh heh. I care! ;) Are you going to take a look at that? I could have a
> look, but it might take me a while to figure it out.
I can't promise anything, but I will try to fix most of them :)
Regards
Marcel
-------------------------------------------------------
Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
The only event dedicated to issues related to Linux enterprise solutions
http://www.enterpriselinuxforum.com
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Marcel,
Here's Cetecom's response:
"Yes, that's the way it should be.
SABM (DLCI0)
UA
SABM (DLCIn)
UA
MSC exchange (IUT initiated)
MSC exchange (Tester inititated)
Send data"
-Daryl.
> > > 5.) Once an RFCOMM channel is established, the IUT must
> > > exchange MSC's (modem status commands) before sending data.
> > That is,
> > > it must send an MSC, wait for a response, wait for the
> > sender's MSC,
> > > and respond to it before sending data. Our device sent an
> > MSC and then
> > > immediately started sending data when we used rctest. This
> > applies to
> > > many test cases.
> >
> > We send the MSC after the UA. But we also go into
> > BT_CONNECTED state and in this state you can also start
> > sending data. We should maybe go from BT_CONNECT -> BT_CONFIG
> > and only switch to BT_CONNECTED after the successful
> exchange of MSC.
>
> That sounds good to me. Not sure about the UA though... I'll
> check on it.
Marcel,
Have a look at the rfcomm_recv_rpn() function pasted below. I did a diff
between it and the latest, and the only difference is how a variable is
declared - nothing significant.
Here's what I see happening:
Take a look at XON and XOFF. If we see a value we don't like, we set
rpn->xon_char to the value that we would like to see. We also update the
rpn_mask variable. Then at the bottom of the function we call
rfcomm_send_rpn() with xon_char and not rpn->xon_char. So it sends 0 instea=
d
of the desired character, but it does send the correct rpn_mask.
It looks to me like most of the tests act on the right variables. Just xon,
xoff, and flow control appear to have the problem.=20
Do you agree?
-Daryl.
> > > 4.) TP/RFC/BV-17-C: RFCOMM Parameter Negotiation: RFCOMM
> > > doesn't respond with desired parameters in RPN response (it=20
> > responds
> > > with 0's). I took a quick look at the RFCOMM code (our
> > older version)
> > > and it's apparent that variables are being set with the
> > desired values
> > > when the tester requests values that we don't like, but those
> > > variables are not the ones that are actually sent in the=20
> > response. The
> > > parameter mask is set correctly though.
> >=20
> > Please enable RFCOMM debug output and send us the request
> > that the Tester performs.
>=20
> It'll take a bit of work to accomplish that because testing=20
> is being done remotely... But if we need to do it, we can.
>=20
> As a first step I'll send you an e-mail with the snippet of=20
> code I'm talking about and point out what I think the problem=20
> is. And when I get tester logs I'll send them too.
static int rfcomm_recv_rpn(struct rfcomm_session *s, int cr, int len, struc=
t
sk_buff *skb)
{
struct rfcomm_rpn *rpn =3D (void *) skb->data;
int dlci =3D __get_dlci(rpn->dlci);
u8 bit_rate =3D 0;
u8 data_bits =3D 0;
u8 stop_bits =3D 0;
u8 parity =3D 0;
u8 flow_ctrl =3D 0;
u8 xon_char =3D 0;
u8 xoff_char =3D 0;
u16 rpn_mask =3D RFCOMM_RPN_PM_ALL;
=09
BT_DBG("dlci %d cr %d len 0x%x bitr 0x%x line 0x%x flow 0x%x xonc
0x%x xoffc 0x%x pm 0x%x",=20
dlci, cr, len, rpn->bit_rate, rpn->line_settings,
rpn->flow_ctrl,
rpn->xon_char, rpn->xoff_char, rpn->param_mask);
=09
if (!cr)=20
return 0;
=09
if (len =3D=3D 1) {
/* request: return default setting */
bit_rate =3D RFCOMM_RPN_BR_115200;
data_bits =3D RFCOMM_RPN_DATA_8;
stop_bits =3D RFCOMM_RPN_STOP_1;
parity =3D RFCOMM_RPN_PARITY_NONE;
flow_ctrl =3D RFCOMM_RPN_FLOW_NONE;
xon_char =3D RFCOMM_RPN_XON_CHAR;
xoff_char =3D RFCOMM_RPN_XOFF_CHAR;
goto rpn_out;
}
/* check for sane values: ignore/accept bit_rate, 8 bits, 1 stop
bit, no parity,
no flow control lines, normal XON/XOFF
chars */
if (rpn->param_mask & RFCOMM_RPN_PM_DATA) {
data_bits =3D __get_rpn_data_bits(rpn->line_settings);
if (data_bits !=3D RFCOMM_RPN_DATA_8) {
BT_DBG("RPN data bits mismatch 0x%x", data_bits);
data_bits =3D RFCOMM_RPN_DATA_8;
rpn_mask ^=3D RFCOMM_RPN_PM_DATA;
}
}
if (rpn->param_mask & RFCOMM_RPN_PM_STOP) {
stop_bits =3D __get_rpn_stop_bits(rpn->line_settings);
if (stop_bits !=3D RFCOMM_RPN_STOP_1) {
BT_DBG("RPN stop bits mismatch 0x%x", stop_bits);
stop_bits =3D RFCOMM_RPN_STOP_1;
rpn_mask ^=3D RFCOMM_RPN_PM_STOP;
}
}
if (rpn->param_mask & RFCOMM_RPN_PM_PARITY) {
parity =3D __get_rpn_parity(rpn->line_settings);
if (parity !=3D RFCOMM_RPN_PARITY_NONE) {
BT_DBG("RPN parity mismatch 0x%x", parity);
parity =3D RFCOMM_RPN_PARITY_NONE;
rpn_mask ^=3D RFCOMM_RPN_PM_PARITY;
}
}
if (rpn->param_mask & RFCOMM_RPN_PM_FLOW) {
if (rpn->flow_ctrl !=3D RFCOMM_RPN_FLOW_NONE) {
BT_DBG("RPN flow ctrl mismatch 0x%x",
rpn->flow_ctrl);
rpn->flow_ctrl =3D RFCOMM_RPN_FLOW_NONE;
rpn_mask ^=3D RFCOMM_RPN_PM_FLOW;
}
}
if (rpn->param_mask & RFCOMM_RPN_PM_XON) {
if (rpn->xon_char !=3D RFCOMM_RPN_XON_CHAR) {
BT_DBG("RPN XON char mismatch 0x%x", rpn->xon_char);
rpn->xon_char =3D RFCOMM_RPN_XON_CHAR;
rpn_mask ^=3D RFCOMM_RPN_PM_XON;
}
}
if (rpn->param_mask & RFCOMM_RPN_PM_XOFF) {
if (rpn->xoff_char !=3D RFCOMM_RPN_XOFF_CHAR) {
BT_DBG("RPN XOFF char mismatch 0x%x",
rpn->xoff_char);
rpn->xoff_char =3D RFCOMM_RPN_XOFF_CHAR;
rpn_mask ^=3D RFCOMM_RPN_PM_XOFF;
}
}
rpn_out:
rfcomm_send_rpn(s, 0, dlci,=20
bit_rate, data_bits, stop_bits, parity, flow_ctrl,
xon_char, xoff_char, rpn_mask);
return 0;
}
Marcel,
> > > 3.) TP/COS/CFD/BV-02: Tests that IUT is able to perform
> > > negotiation while the tester rejects the configuration of a data=20
> > > channel. The IUT sends a configuration request and the=20
> > tester rejects
> > > it. The IUT should send another configuration request, but it does
> > > not.
> >=20
> > Currently the channel is closed if they reject our config
> > request, because we don't know how to proceed if they don't=20
> > like our settings. We can sent them again, but they will be=20
> > rejected again. For this case I also have to read the L2CAP=20
> in detail.
>=20
> Yeah, it seemed a bit odd to me too. But that's what the test=20
> case tests. I'll get some clarification on this one.
Here's what happens in that test:
1. The IUT sends a L2CAP_ConfigReq.
2. The tester responds with a L2CA_ConfigCfm with result=3Drejected and wit=
h
acceptable InMTU, OutFlow, and Flush TO.
3. The IUT sends an L2CAP_ConfigReq containing the acceptable values which
the tester sent in the response. The tester will be told (manually) what
values the IUT can accept and it will use those values in its response abov=
e
in step 2.
4. The tester responds with an L2CA_ConfigCfm with result=3Dsuccess and the
values that it accepted (the same values that were requested in step 3 and
in the response in step 2).
The basic idea is that the IUT asks for the channel to be configured in som=
e
way, the tester rejects it and tells the IUT what it would like to see. If
the IUT is ok with that, then it acknowledges the tester's response by
sending another config request with the values the tester wanted. If the
tester asked for settings that we can't handle then we can give up and clos=
e
the connection.
Make sense?
-Daryl.
> > 4.) TP/COS/RCO/BI-01, BI-02: These tests verify=20
> that the IUT=20
> > performs a consistency check on the data. Both tests send=20
> two packets=20
> > to the IUT. In each test, the first packet has a mistake.=20
> In BI-01 the=20
> > first packet is too short by one byte, and in BI-02 the=20
> first packet=20
> > is too long by one byte. In both cases the stack must correctly=20
> > receive the second packet, but not the first. The data should be=20
> > discarded in the case of the inconsistencies, and an error=20
> reported to=20
> > the application.
>=20
> It seems that we can't handle this case complete correctly,=20
> if the data was put only in one fragment. But in the basics=20
> this should work and the malformed packets should be dropped.=20
> Did you have a detailed log of this test which shows us byte=20
> by byte which request was sent?
It appears that things got a bit confused in the BV-01 case. In the BV-02
case, the stack tossed the extra byte and reported the error to stderror bu=
t
not to the application. To pass the test the application must be told that
there was an error reading the data (my interpretation of the test case is
that the stack can still send the application the data, but it must be
flagged as a failure). In both cases, the second packet should be correctly
received. It's not clear to me from the test case that receiving the second
packet correctly is mandatory, but it might be. It shouldn't be a problem t=
o
receive it correctly.
Below are the two scenarios:
BV-01 case:
3451624.786137 < 01 05 04 0D 71 83 1F 96 A0 00 18 CC 00 00 00 00 01=20
3451624.790905 > 04 0F 04 00 07 05 04=20
3451628.318245 > 04 03 0B 00 01 00 71 83 1F 96 A0 00 01 00=20
3451628.318729 > 04 0F 04 00 08 00 00=20
3451628.318786 < 02 01 20 0C 00 08 00 01 00 02 01 04 00 01 00 40 00=20
3451628.318851 < 01 0D 08 04 01 00 0E 00=20
3451628.352279 > 04 0E 06 08 0D 08 00 01 00=20
3451628.354970 > 04 1B 03 01 00 05=20
3451628.412420 > 04 13 05 01 01 00 01 00=20
3451629.731541 > 02 01 20 10 00 0C 00 01 00 03 01 08 00 40 00 40 00 00 00
00=20
00=20
3451629.732281 < 02 01 20 0C 00 08 00 01 00 04 02 04 00 40 00 00 00=20
3451629.772684 > 04 13 05 01 01 00 01 00=20
3451630.704342 > 02 01 20 16 00 12 00 01 00 05 02 0E 00 40 00 00 00 00 00
01=20
02 FF 00 02 02 FF FF=20
3451631.824537 > 02 01 20 14 00 10 00 01 00 04 01 0C 00 40 00 00 00 01 02
FF=20
00 02 02 FF FF=20
3451631.824697 < 02 01 20 0E 00 0A 00 01 00 05 01 06 00 40 00 00 00 00 00=20
3451631.843088 > 04 13 05 01 01 00 01 00=20
3451635.601252 > 02 01 20 33 00 30 00 40 00 31 32 33 34 35 36 37 38 39 30
3A=20
3B 3C 3D 3E 3F 31 32 33 34 35 36 37 38 39 30 3A 3B 3C 3D 3E=20
3F 31 32 33 34 35 36 37 38 39 30 3A 3B 3C 3D 3E=20
3451635.601809 > 04 FF 1B 06 19 45 72 72 6F 72 20 69 6E 20 6C 6D 5F 64 61
74=20
61 2E 63 28 31 37 31 34 29 0A=20
3451635.630626 > 02 01 20 34 00 30 00 40 00 31 32 33 34 35 36 37 38 39 30
3A=20
3B 3C 3D 3E 3F 31 32 33 34 35 36 37 38 39 30 3A 3B 3C 3D 3E=20
3F 31 32 33 34 35 36 37 38 39 30 3A 3B 3C 3D 3E 3F=20
root@jack-00000000:~>./l2test1 -u -P 1 00:a0:96:1f:83:71
l 2test[568]: Conl2cap_recv_acldata: Unexpected start frame (len 52)
l2test[568]: seq missmatch: 0 -> 875770417
l2test[568]: size missmatch: 48 -> 13877
l2test[568]: Read failed. Function not implemented(38)
DV: recv error: Function not implemented(38)
l2test[568]: Exit
Note: the line above that starts with "DV:" was just a printf I added just
to check something. You can ignore it.
BV-02 case:
3451212.377519 > 04 05 04 00 01 00 1F=20
3451217.001182 > 04 04 0A 71 83 1F 96 A0 00 00 00 00 01=20
3451217.001882 < 01 09 04 07 71 83 1F 96 A0 00 01=20
3451217.005163 > 04 0F 04 00 08 09 04=20
3451217.022390 > 04 03 0B 00 01 00 71 83 1F 96 A0 00 01 00=20
3451217.023089 < 01 0D 08 04 01 00 0E 00=20
3451217.038752 > 04 0E 06 08 0D 08 00 01 00=20
3451217.039391 < 01 0F 04 04 01 00 18 CC=20
3451217.042422 > 04 0F 04 00 07 0F 04=20
3451217.053451 > 04 1D 05 00 01 00 18 CC=20
3451217.053881 > 04 0F 04 00 08 00 00=20
3451217.054253 > 04 1B 03 01 00 05=20
3451221.347537 > 02 01 20 0C 00 08 00 01 00 02 01 04 00 01 00 40 00=20
3451221.348308 < 02 01 20 10 00 0C 00 01 00 03 01 08 00 40 00 40 00 00 00
00=20
00=20
3451221.379927 > 04 13 05 01 01 00 01 00=20
3451222.532855 > 02 01 20 14 00 10 00 01 00 04 01 0C 00 40 00 00 00 01 02
FF=20
00 02 02 FF FF=20
3451222.533633 < 02 01 20 0E 00 0A 00 01 00 05 01 06 00 40 00 00 00 00 00=20
3451222.533719 < 02 01 20 0C 00 08 00 01 00 04 01 04 00 40 00 00 00=20
3451222.568912 > 04 13 05 01 01 00 01 00=20
3451222.580161 > 04 13 05 01 01 00 01 00=20
3451223.503064 > 02 01 20 16 00 12 00 01 00 05 01 0E 00 40 00 00 00 00 00
01=20
02 FF 00 02 02 FF FF=20
3451225.027417 > 02 01 20 33 00 2F 00 40 00 31 32 33 34 35 36 37 38 39 30
3A=20
3B 3C 3D 3E 3F 31 32 33 34 35 36 37 38 39 30 3A 3B 3C 3D 3E=20
3F 31 32 33 34 35 36 37 38 39 30 3A 3B 3C 3D 3E=20
3451225.035109 > 02 01 00 01 00 3F=20
3451225.035598 > 04 FF 1B 06 19 45 72 72 6F 72 20 69 6E 20 6C 6D 5F 64 61
74=20
61 2E 63 28 31 39 30 34 29 0A=20
3451226.772904 > 02 01 20 34 00 30 00 40 00 31 32 33 34 35 36 37 38 39 30
3A=20
3B 3C 3D 3E 3F 31 32 33 34 35 36 37 38 39 30 3A 3B 3C 3D 3E=20
3F 31 32 33 34 35 36 37 38 39 30 3A 3B 3C 3D 3E 3F=20
root@jack-00000000:~>./l2test -d -P 1
l2test[586]: Waiting for connection on psm 1 ...
l2test[587]: Connect from 00:A0:96:1F:83:71 [imtu 672, omtu 255, flush_to
65535]
l2test[587]: Receiving ...
l2cap_recv_acldata: Unexpected continuation frame (len 1)
l2test[587]: Recevied 47 bytes
l2test[587]: Recevied 48 bytes
-Daryl.
Hey Marcel,
Thanks for your response!
It'll take me a bit of time to gather all of the logs. I'll send them to yo=
u
as I get them. The logs are a bit lengthy, so I'll send them directly to yo=
u
instead of the list.
My comments are inserted below.
> Can you tell us a little bit more about your product, because=20
> I can't find enough details on the website.
The product hasn't been released yet, so I can't publicly discuss too much.
We could talk a bit off-list about it if you'd like.
> The biggest problem in this test case is the=20
> bluez-kernel-2.3, because it is too much outdated. You should=20
> better use one of -mh patches or try to build a new=20
> bluez-kernel package from the kernel scripts that I have put=20
> into CVS. The bluez-libs-2.3 shouldn't make any problems, but=20
> it is a good idea to update to bluez-sdp-1.1.
Yeah, I figured. It took a bit of work, but I now have a 2.4.18 kernel up
to mh4 (the latest on your site).
> The L2CAP and RFCOMM part is kernel specific and it is a good=20
> idea to do the qualification tests with the an up-to-date=20
> kernel, because in this case it is easier to look at the=20
> problems and fix them.
Yup. From here on it will be done on an up-to-date kernel (Is 2.4.18 with
your most recent patch level considered up-to-date? Moving to 2.4.20 would
be a major hassle). I would have done that earlier, but I didn't realize ho=
w
outdated the bluez-kernel package was until it was too late.
> > L2CAP:
> > 1.) TP/COS/CED/BI-01: Verifies that the IUT rejects=20
> an unkown=20
> > signalling command. The tester sends an unkown L2CAP=20
> command. The IUT=20
> > should respond with an L2CAP_Reject with reason 0 "Command not=20
> > understood". The IUT did not.
>=20
> We have a fixme for this in the l2cap.c code, but currently=20
> no code exists. Should be easy to fix, but nobody cares about it.
Heh heh. I care! ;) Are you going to take a look at that? I could have a
look, but it might take me a while to figure it out.
> > 2.) TP/COS/CFD/BV-01: Tests that IUT is able to handle the=20
> > receiving of more than one request for configuration of=20
> data channel.=20
> > Tester sends L2CAP_Config Req with flag=3D1, IUT responds=20
> with flag=3D0.=20
> > According to section 5.4 p.290 of the version 1.1 spec,=20
> "When used in=20
> > the Configuration Response, the continuation flag must be=20
> set if the=20
> > flag is set in the Request".
>=20
> This seems to be a bug in the current code. But I have to=20
> re-read the L2CAP specification for the details.
It might also help to take a look at the test cases, which are free to
download. But, as with everything bluetooth, if you want all the details yo=
u
have to pay. ;)
> > 3.) TP/COS/CFD/BV-02: Tests that IUT is able to perform=20
> > negotiation while the tester rejects the configuration of a data=20
> > channel. The IUT sends a configuration request and the=20
> tester rejects=20
> > it. The IUT should send another configuration request, but it does=20
> > not.
>=20
> Currently the channel is closed if they reject our config=20
> request, because we don't know how to proceed if they don't=20
> like our settings. We can sent them again, but they will be=20
> rejected again. For this case I also have to read the L2CAP in detail.
Yeah, it seemed a bit odd to me too. But that's what the test case tests.
I'll get some clarification on this one.
> > 4.) TP/COS/RCO/BI-01, BI-02: These tests verify=20
> that the IUT=20
> > performs a consistency check on the data. Both tests send=20
> two packets=20
> > to the IUT. In each test, the first packet has a mistake.=20
> In BI-01 the=20
> > first packet is too short by one byte, and in BI-02 the=20
> first packet=20
> > is too long by one byte. In both cases the stack must correctly=20
> > receive the second packet, but not the first. The data should be=20
> > discarded in the case of the inconsistencies, and an error=20
> reported to=20
> > the application.
>=20
> It seems that we can't handle this case complete correctly,=20
> if the data was put only in one fragment. But in the basics=20
> this should work and the malformed packets should be dropped.=20
> Did you have a detailed log of this test which shows us byte=20
> by byte which request was sent?
Yeah. I should have an HCI dump for both cases. I'll send them to you right
after this.
> > RFCOMM:
> > Note: Some of these comments don't apply to a specific=20
> test case=20
> > (they are more general).
> > 1.) Must not modify pbits in pn (parameter negotiation)=20
> > response. The pbits are dependent on which DLC is being configured.=20
> > Apparently this is a common problem, and one that has been argued=20
> > about with the SIG because apparently nobody uses the bits=20
> - but the=20
> > SIG would not give in (refer to erratum 364). They are specified in=20
> > the TS GSM 07.10 630 spec, section 5.4.6.3.1.
>=20
> I am little bit confused, because I thought that the P/F bit=20
> in a UIH packet response on dlci 0 should always be zero. The=20
> only case where the P/F bit is set should be with credit=20
> based flow control. I will check the specification. Can you=20
> send me the erratum 364?
I should have been more clear. By pbits I meant priority bits, not the P/F
bit. I don't have a copy of the 07.10 630 spec, so I can't look up the
details. Do you have a copy? Anyway, the priority bits are set to a certain
value depending on which DLC you are using. I'm pretty sure that for DLC 0
they should be set to 0. For DLC's 1 through 7, I think they are set to 7.
Beyond that I don't remember. I'll see what I can do about getting a copy o=
f
the erratum 364... But I'm pretty sure there aren't any interesting detail=
s
in it, just people complaining that the bits are pointless. The TS GSM 07.1=
0
630 spec is where the details are.
> > 2.) TP/RFC/BV-07: Closing rfcomm doesn't appear to close=20
> > l2cap. Is this true? This isn't actually required to pass=20
> this test,=20
> > but it did confuse the tester. This may have been a mistake on my=20
> > part. I just hit ctrl-c when rctest was connected and assumed that=20
> > everything would get closed. Would calling close() have a different=20
> > effect?
>=20
> This is working fine for me. After closing the channel, we=20
> close dlci 0 and this also closes the L2CAP connection.
I can retry it with the new kernel modules.
> > 3.) TP/RFC/BV-13-C: Verifies that the IUT responds=20
> to a Remote=20
> > Line Status command from the tester. When the remote line status=20
> > command is received, the remote device must respond with a=20
> remote line=20
> > status response. We responded with NSC (not supported=20
> command) instead=20
> > of RLS response.
>=20
> I have fixed this in patch-2.4.20-mh7 and it is in the not=20
> released 2.4.21-rc2 mainstream kernel.
Great! Is that also in patch-2.4.18-mh4?
> > 4.) TP/RFC/BV-17-C: RFCOMM Parameter Negotiation: RFCOMM=20
> > doesn't respond with desired parameters in RPN response (it=20
> responds=20
> > with 0's). I took a quick look at the RFCOMM code (our=20
> older version)=20
> > and it's apparent that variables are being set with the=20
> desired values=20
> > when the tester requests values that we don't like, but those=20
> > variables are not the ones that are actually sent in the=20
> response. The=20
> > parameter mask is set correctly though.
>=20
> Please enable RFCOMM debug output and send us the request=20
> that the Tester performs.
It'll take a bit of work to accomplish that because testing is being done
remotely... But if we need to do it, we can.
As a first step I'll send you an e-mail with the snippet of code I'm talkin=
g
about and point out what I think the problem is. And when I get tester logs
I'll send them too.
> > 5.) Once an RFCOMM channel is established, the IUT must=20
> > exchange MSC's (modem status commands) before sending data.=20
> That is,=20
> > it must send an MSC, wait for a response, wait for the=20
> sender's MSC,=20
> > and respond to it before sending data. Our device sent an=20
> MSC and then=20
> > immediately started sending data when we used rctest. This=20
> applies to=20
> > many test cases.
>=20
> We send the MSC after the UA. But we also go into=20
> BT_CONNECTED state and in this state you can also start=20
> sending data. We should maybe go from BT_CONNECT -> BT_CONFIG=20
> and only switch to BT_CONNECTED after the successful exchange of MSC.
That sounds good to me. Not sure about the UA though... I'll check on it.
> > 6.) If a connecting device doesn't send a PN=20
> command with CL=20
> > bits set to 0x0f, then it means it is not a 1.1 device and=20
> we must not=20
> > use credit based flow control. In our case, when such a PN=20
> command was=20
> > received, data was sent using credit based flow control but=20
> shouldn't=20
> > have been. This applies to many test cases.
>=20
> This should not happen, because the current RFCOMM code can=20
> deal with 1.0b and 1.1 devices correctly. Please check this=20
> with latest RFCOMM code and send us the detailed log of this problem.
Ok... I'll try it out with the new kernel modules.
-Daryl.
Hi Daryl,
> We've started bluetooth qualification testing with Cetecom for our product
> (which uses the bluez stack). Most tests passed, but there were several that
> failed. Below is a summary of the testing that was performed and a list of
> failed tests. We are only testing the portions which are relevant to our
> product, so this is list is not necessarily a complete list of qualification
> related problems. I believe most of the problems will be relatively easy to
> fix. Could you guys take a look?
it looks like that the home of Cetecom is in Germany :)
Can you tell us a little bit more about your product, because I can't
find enough details on the website.
> The tests were performed on a system running a slightly out-of-date bluez
> stack, so it's possible that some of the problems have already been
> resolved. If you could point out any items that have already been resolved
> (or are probably resolved), it would be much appreciated. A qualified
> bluetooth module was not available for testing (but will be soon), so if it
> appears that any of these problems are likely due to a malfunctioning
> module, please let me know.
>
> The tests were performed on a system running the following bluez component
> versions:
> bluez-kernel-2.3
> bluez-libs-2.3
> bluez-sdp-1.0rc3
The biggest problem in this test case is the bluez-kernel-2.3, because
it is too much outdated. You should better use one of -mh patches or try
to build a new bluez-kernel package from the kernel scripts that I have
put into CVS. The bluez-libs-2.3 shouldn't make any problems, but it is
a good idea to update to bluez-sdp-1.1.
The L2CAP and RFCOMM part is kernel specific and it is a good idea to do
the qualification tests with the an up-to-date kernel, because in this
case it is easier to look at the problems and fix them.
> The portions of each of these required for SPP server and OPP client were
> tested so far: SDP, GAP, RFCOMM, L2CAP. For the most part, optional things
> were not tested. Testing wasn't 100% complete.
>
> Qualification failures/problems: (I can get tester logs for most of these
> failures if they would be helpful.)
Please send them to me. Stephen has already answered the SDP part and I
try to put some comments on L2CAP and RFCOMM.
> L2CAP:
> 1.) TP/COS/CED/BI-01: Verifies that the IUT rejects an unkown
> signalling command. The tester sends an unkown L2CAP command. The IUT should
> respond with an L2CAP_Reject with reason 0 "Command not understood". The IUT
> did not.
We have a fixme for this in the l2cap.c code, but currently no code
exists. Should be easy to fix, but nobody cares about it.
> 2.) TP/COS/CFD/BV-01: Tests that IUT is able to handle the receiving
> of more than one request for configuration of data channel. Tester sends
> L2CAP_Config Req with flag=1, IUT responds with flag=0. According to section
> 5.4 p.290 of the version 1.1 spec, "When used in the Configuration Response,
> the continuation flag must be set if the flag is set in the Request".
This seems to be a bug in the current code. But I have to re-read the
L2CAP specification for the details.
> 3.) TP/COS/CFD/BV-02: Tests that IUT is able to perform negotiation
> while the tester rejects the configuration of a data channel. The IUT sends
> a configuration request and the tester rejects it. The IUT should send
> another configuration request, but it does not.
Currently the channel is closed if they reject our config request,
because we don't know how to proceed if they don't like our settings. We
can sent them again, but they will be rejected again. For this case I
also have to read the L2CAP in detail.
> 4.) TP/COS/RCO/BI-01, BI-02: These tests verify that the IUT
> performs a consistency check on the data. Both tests send two packets to the
> IUT. In each test, the first packet has a mistake. In BI-01 the first packet
> is too short by one byte, and in BI-02 the first packet is too long by one
> byte. In both cases the stack must correctly receive the second packet, but
> not the first. The data should be discarded in the case of the
> inconsistencies, and an error reported to the application.
It seems that we can't handle this case complete correctly, if the data
was put only in one fragment. But in the basics this should work and the
malformed packets should be dropped. Did you have a detailed log of this
test which shows us byte by byte which request was sent?
> RFCOMM:
> Note: Some of these comments don't apply to a specific test case
> (they are more general).
> 1.) Must not modify pbits in pn (parameter negotiation) response.
> The pbits are dependent on which DLC is being configured. Apparently this is
> a common problem, and one that has been argued about with the SIG because
> apparently nobody uses the bits - but the SIG would not give in (refer to
> erratum 364). They are specified in the TS GSM 07.10 630 spec, section
> 5.4.6.3.1.
I am little bit confused, because I thought that the P/F bit in a UIH
packet response on dlci 0 should always be zero. The only case where the
P/F bit is set should be with credit based flow control. I will check
the specification. Can you send me the erratum 364?
> 2.) TP/RFC/BV-07: Closing rfcomm doesn't appear to close l2cap. Is
> this true? This isn't actually required to pass this test, but it did
> confuse the tester. This may have been a mistake on my part. I just hit
> ctrl-c when rctest was connected and assumed that everything would get
> closed. Would calling close() have a different effect?
This is working fine for me. After closing the channel, we close dlci 0
and this also closes the L2CAP connection.
< ACL data: handle 0x0029 flags 0x02 dlen 8
L2CAP(d): cid 0x55 len 4 [psm 3]
RFCOMM(s): DISC: cr 1 dlci 4 pf 1 ilen 0 fcs 0x77
> ACL data: handle 0x0029 flags 0x02 dlen 8
L2CAP(d): cid 0x40 len 4 [psm 3]
RFCOMM(s): UA: cr 1 dlci 4 pf 1 ilen 0 fcs 0x5d
< ACL data: handle 0x0029 flags 0x02 dlen 8
L2CAP(d): cid 0x55 len 4 [psm 3]
RFCOMM(s): DISC: cr 1 dlci 0 pf 1 ilen 0 fcs 0xfd
< ACL data: handle 0x0029 flags 0x02 dlen 12
L2CAP(s): Disconn req: dcid 0x0055 scid 0x0040
> 3.) TP/RFC/BV-13-C: Verifies that the IUT responds to a Remote Line
> Status command from the tester. When the remote line status command is
> received, the remote device must respond with a remote line status response.
> We responded with NSC (not supported command) instead of RLS response.
I have fixed this in patch-2.4.20-mh7 and it is in the not released
2.4.21-rc2 mainstream kernel.
> 4.) TP/RFC/BV-17-C: RFCOMM Parameter Negotiation: RFCOMM doesn't
> respond with desired parameters in RPN response (it responds with 0's). I
> took a quick look at the RFCOMM code (our older version) and it's apparent
> that variables are being set with the desired values when the tester
> requests values that we don't like, but those variables are not the ones
> that are actually sent in the response. The parameter mask is set correctly
> though.
Please enable RFCOMM debug output and send us the request that the
Tester performs.
> 5.) Once an RFCOMM channel is established, the IUT must exchange
> MSC's (modem status commands) before sending data. That is, it must send an
> MSC, wait for a response, wait for the sender's MSC, and respond to it
> before sending data. Our device sent an MSC and then immediately started
> sending data when we used rctest. This applies to many test cases.
We send the MSC after the UA. But we also go into BT_CONNECTED state and
in this state you can also start sending data. We should maybe go from
BT_CONNECT -> BT_CONFIG and only switch to BT_CONNECTED after the
successful exchange of MSC.
> 6.) If a connecting device doesn't send a PN command with CL bits
> set to 0x0f, then it means it is not a 1.1 device and we must not use credit
> based flow control. In our case, when such a PN command was received, data
> was sent using credit based flow control but shouldn't have been. This
> applies to many test cases.
This should not happen, because the current RFCOMM code can deal with
1.0b and 1.1 devices correctly. Please check this with latest RFCOMM
code and send us the detailed log of this problem.
Regards
Marcel
-------------------------------------------------------
Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
The only event dedicated to issues related to Linux enterprise solutions
http://www.enterpriselinuxforum.com
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hey Steve,
> > 1.) The SDP entry for the SDP server itself should have a
> > Language Base Attribute ID List (because there are text
> descriptions).
> > I'm not absolutely clear on whether or not it is mandatory, but it
> > would make the testers happy. Can an application add an
> attribute to
> > that record, or would sdpd have to be modified?
>
> Should be fixed in CVS for sdpd. (However, I can't find out
> how the ISO 639 language name, e.g., 'en', is mapped to a
> UINT_16. I assumed 'e' is more significant.)
Great, thanks. I took a quick look and it appears that other people think
the 'e' is more significant too. So the 16-bit code that other devices use
is 0x656e.
> > 2.) There appears to be a problem handling continuation
> > states. Handling continuation state is optional. We found
> that if the
> > querying device sends a maximum byte count of 100, the
> continutation
> > state worked fine. But if the querying device sent a maximum byte
> > count of 8, the continuation state doesn't work (the
> continuation flag
> > wasn't recognized in the next packet). I can dig up an
> example log if
> > it would help.
>
> Yeah it would be good to get a log. I imagine 8-bytes is
> pretty close to the minimum size.
I'll forward the logs as soon as I get them.
We stumbled across this one accidentally. We didn't intend to test
continuation states. But apparently the real test for continuation states
uses a maximum byte count less than 8.
-Daryl.
-------------------------------------------------------
Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
The only event dedicated to issues related to Linux enterprise solutions
http://www.enterpriselinuxforum.com
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Daryl,
On Tue, 2003-05-06 at 18:34, Daryl Van Vorst wrote:
> Qualification failures/problems: (I can get tester logs for most of these
> failures if they would be helpful.)
>
> SDP:
> PASS! (for our purposes), but there were a few things of note:
> 1.) The SDP entry for the SDP server itself should have a Language
> Base Attribute ID List (because there are text descriptions). I'm not
> absolutely clear on whether or not it is mandatory, but it would make the
> testers happy. Can an application add an attribute to that record, or would
> sdpd have to be modified?
Should be fixed in CVS for sdpd. (However, I can't find out how the ISO
639 language name, e.g., 'en', is mapped to a UINT_16. I assumed 'e' is
more significant.)
> 2.) There appears to be a problem handling continuation states.
> Handling continuation state is optional. We found that if the querying
> device sends a maximum byte count of 100, the continutation state worked
> fine. But if the querying device sent a maximum byte count of 8, the
> continuation state doesn't work (the continuation flag wasn't recognized in
> the next packet). I can dig up an example log if it would help.
Yeah it would be good to get a log. I imagine 8-bytes is pretty close to
the minimum size.
Steve
--
Stephen Crane, Rococo Software Ltd. http://www.rococosoft.com
[email protected] +353-1-6601315 (ext 209)
-------------------------------------------------------
Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
The only event dedicated to issues related to Linux enterprise solutions
http://www.enterpriselinuxforum.com
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
At 01:54 PM 6/12/2003, Daryl Van Vorst wrote:
>Fantastic! Thanks. :)
>
>Yeah, it should help others. Hopefully there aren't other subtleties that
>we've missed regarding this.
>
>Looks like all of the current failures now have fixes from you and Marcel.
>So far the only way that I've been updating my stack is by using Marcel's
>patches. Marcel, any chance you could make another patch once Max has put in
>this L2CAP thing?
Done. Pushed to BK 2.4.
Max
Hi Daryl,
> Looks like all of the current failures now have fixes from you and Marcel.
> So far the only way that I've been updating my stack is by using Marcel's
> patches. Marcel, any chance you could make another patch once Max has put in
> this L2CAP thing?
the next patches are planned for the end of next week, because they will
include the CMTP implementation for the Commmon ISDN Profile. But you
can use patch-2.4.18-mh6 and I sent you the incremental fixes by email.
Regards
Marcel
-------------------------------------------------------
This SF.NET email is sponsored by: eBay
Great deals on office technology -- on eBay now! Click here:
http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Max,
> -----Original Message-----
> From: [email protected]=20
> [mailto:[email protected]] On Behalf Of=20
> Max Krasnyansky
> Sent: June 12, 2003 12:12 PM
> To: Daryl Van Vorst; 'Marcel Holtmann'
> Cc: 'BlueZ Mailing List'
> Subject: RE: [Bluez-devel] Qualification Testing
>=20
>=20
> At 11:49 AM 6/12/2003, Daryl Van Vorst wrote:
> >> >Apparently, in step 3 above, if we send a config request with no
> >> >options it will also pass the test. How silly is that? (specially=20
> >> >considering that's what we send by default in the first place!)
> >> I'm pretty sure that it's just because they use some dumb
> >> tester implementation. It doesn't make sense to resend the=20
> >> same config request.
> >
> >It's actually written that way in the test case. Here's a quote from=20
> >the updated test case (errata correction ID 241):
> >
> >"Pass Verdict: The IUT sends an L2CAP_ConfigReq with=20
> acceptable values=20
> >received in the L2CAP_ConfigRsp with Result =3D Failure - unacceptable=20
> >parameters, or the L2CAP_ConfigReq contains no options."
> Consider it done then :). Sounds like this will be useful for=20
> other folks to pass qualification. I'll put it in.
Fantastic! Thanks. :)
Yeah, it should help others. Hopefully there aren't other subtleties that
we've missed regarding this.
Looks like all of the current failures now have fixes from you and Marcel.
So far the only way that I've been updating my stack is by using Marcel's
patches. Marcel, any chance you could make another patch once Max has put i=
n
this L2CAP thing?
-Daryl.
At 11:49 AM 6/12/2003, Daryl Van Vorst wrote:
>> >Apparently, in step 3 above, if we send a config request with no
>> >options it will also pass the test. How silly is that? (specially
>> >considering that's what we send by default in the first place!)
>> I'm pretty sure that it's just because they use some dumb
>> tester implementation. It doesn't make sense to resend the
>> same config request.
>
>It's actually written that way in the test case. Here's a quote from the
>updated test case (errata correction ID 241):
>
>"Pass Verdict: The IUT sends an L2CAP_ConfigReq with acceptable values
>received in the L2CAP_ConfigRsp with Result = Failure - unacceptable
>parameters, or the L2CAP_ConfigReq contains no options."
Consider it done then :). Sounds like this will be useful for other folks
to pass qualification. I'll put it in.
Max
Max,
> If an application does not explicitly tell us that it
> supports larger MTU then it does not support it. As simple as
> that :). We don't play "guess what MTU I support" games ;-).
Yup.
> Sure we can make a hack. Once we agree on how should we
> handle it I'll make
> the change. But if the hack affects general case we're not
> going to put it
> into official kernel.
Of course. :)
> >Apparently, in step 3 above, if we send a config request with no
> >options it will also pass the test. How silly is that? (specially
> >considering that's what we send by default in the first place!)
> I'm pretty sure that it's just because they use some dumb
> tester implementation. It doesn't make sense to resend the
> same config request.
It's actually written that way in the test case. Here's a quote from the
updated test case (errata correction ID 241):
"Pass Verdict: The IUT sends an L2CAP_ConfigReq with acceptable values
received in the L2CAP_ConfigRsp with Result = Failure - unacceptable
parameters, or the L2CAP_ConfigReq contains no options."
-Daryl.
At 03:51 PM 5/29/2003, Daryl Van Vorst wrote:
>Max,
>
>Here's where we're at with this one: We either need to pass this test, or
>issue an erratum. Issuing an erratum is going to be a very time-consuming
>task and we can't be certain of the outcome.
>
>About the only scenario we could come up with where this makes any sense at
>all is if the remote device wants to send data larger than the default MTU
>of 672, and the local application doesn't specifically tell the stack that
>it can handle a larger MTU before calling connect(). Is it in our interest
>to handle this?
If an application does not explicitly tell us that it supports larger MTU
then it does not support it. As simple as that :).
We don't play "guess what MTU I support" games ;-).
>Is it possible to give the app control during the CONFIG state so that it
>can do the negotiation with the remote side? Am I correct in assuming that
>as it is now the app only gets control once we enter the OPEN state?
See, the L2CAP spec defines this ""very nice"" :) API with a bunch of callbacks
which propagate config requests to the application. This means that every
single L2CAP application (even a simple one) has to have exact same code to
handle L2CAP configuration. We don't do that. If app supports MTU other than
default it explicitly sets it with setsockopt() and we send that MTU in the
very first config request.
>Perhaps we could put in a "hack" (if we're going to call it that) which
>allows us to pass the test. We could, at the same time, write up an errata
>requesting that this test be optional or changed so that we would pass the
>test without the "hack". Once the erratum is accepted, we could remove the
>hack.
>
>Is there any chance that you could make this change? Or, if not, could you
>help me determine where in the code to do it?
Sure we can make a hack. Once we agree on how should we handle it I'll make
the change. But if the hack affects general case we're not going to put it
into official kernel.
>The behaviour that would make it pass is as follows:
>
>1. We send a config request.
>2. We get a config response rejecting our request which contains the
>tester's desired values.
>3. We re-send the config request with those values (the tester will accept
>this request).
>4. At this point if the config request is not accepted we can close the link
>like we would normally.
>
>Maybe we could add a setsockopt() l2cap option like LM_FLEXIBLEINMTU to turn
>on this behaviour (not sure if making it optional will pass - I'll check).
If we don't make it optional then it will certainly affect general case because
we cannot accept whatever the other side sends us.
>Apparently, in step 3 above, if we send a config request with no options it
>will also pass the test. How silly is that? (specially considering that's
>what we send by default in the first place!)
I'm pretty sure that it's just because they use some dumb tester implementation.
It doesn't make sense to resend the same config request.
Comments ?
Max