public inbox for linux-bluetooth@vger.kernel.org
 help / color / mirror / Atom feed
* [Bluez-devel] Qualification Testing
@ 2003-05-06 17:34 Daryl Van Vorst
  2003-05-07 10:56 ` Stephen Crane
  2003-05-08 13:43 ` Marcel Holtmann
  0 siblings, 2 replies; 81+ messages in thread
From: Daryl Van Vorst @ 2003-05-06 17:34 UTC (permalink / raw)
  To: BlueZ Mailing List

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
www.enterpriselinuxforum.com

_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

^ permalink raw reply	[flat|nested] 81+ messages in thread
* [Bluez-devel] Qualification testing.
@ 2004-12-01  0:32 Daryl Van Vorst
  2004-12-01  6:42 ` Marcel Holtmann
  0 siblings, 1 reply; 81+ messages in thread
From: Daryl Van Vorst @ 2004-12-01  0:32 UTC (permalink / raw)
  To: 'BlueZ Mailing List'

[-- Attachment #1: Type: text/plain, Size: 1419 bytes --]

Marcel,

Another round of qualification testing has begun. The results so far seem
much less painful this time. :)

So far there is one definite failure. There are a couple others which are
being debated. All of these have appeared because the tests have changed
slightly since (or weren't required) the last time we tested.

Test COS/CFD/BV-12 fails because the IUT does not send result=3 in an l2cap
config response upon reception of an unknown option. Apparently we didn't
have to do this test last time. And it's clear in the code why it fails:
l2cap.c: /* FIXME: Reject unknown option */

I noticed in the spec that the response must contain the offending options:

"On an unknown option failure (Result=0x0003), the option types not
understood
by the recipient of the Request must be included in the Response.
Note that hints (defined in Section 6 on page 297), those options in the
Request that are skipped if not understood, must not be included in the
Response and must not be the sole cause for rejecting the Request."

I've been staring at the code pondering how to fix this cleanly. I've
attached an attempt at fixing it. The fix is not quite complete because I
believe it has a buffer overflow vulnerability. It is not fully tested
either. But I figured it was best to run it by you before going too far
because more than likely you'll want to change something. ;)

BTW - We're using 2.4.21-mh10.

-Daryl.

[-- Attachment #2: l2cap_diff --]
[-- Type: application/octet-stream, Size: 3712 bytes --]

--- linux-2.4.21/net/bluetooth/l2cap.c	2004-10-19 11:14:43.000000000 -0700
+++ linux-2.4.21_mods/net/bluetooth/l2cap.c	2004-11-30 16:28:37.000000000 -0800
@@ -81,6 +81,8 @@
 static int l2cap_send_req(struct l2cap_conn *conn, __u8 code, __u16 len, void *data);
 static int l2cap_send_rsp(struct l2cap_conn *conn, __u8 ident, __u8 code, __u16 len, void *data);
 
+static void l2cap_add_conf_opt(void **ptr, __u8 type, __u8 len, unsigned long val);
+
 /* ----- L2CAP timers ------ */
 static void l2cap_sock_timeout(unsigned long arg)
 {
@@ -1235,11 +1237,12 @@
 	return len;
 }
 
-static inline void l2cap_parse_conf_req(struct sock *sk, void *data, int len)
+static inline int l2cap_parse_conf_req(struct sock *sk, void *data, int len, void **rsp_ptr)
 {
 	int type, hint, olen; 
 	unsigned long val;
 	void *ptr = data;
+	int result = 0;
 
 	BT_DBG("sk %p len %d", sk, len);
 
@@ -1265,10 +1268,13 @@
 			if (hint)
 				break;
 
-			/* FIXME: Reject unknown option */
+			/* Reject unknown option */
+			l2cap_add_conf_opt(rsp_ptr, type, olen, val);
+			result = L2CAP_CONF_UNKNOWN_OPT;
 			break;
 		};
 	}
+	return result;
 }
 
 static void l2cap_add_conf_opt(void **ptr, __u8 type, __u8 len, unsigned long val)
@@ -1341,16 +1347,16 @@
 	return result;
 }
 
-static int l2cap_build_conf_rsp(struct sock *sk, void *data, int *result)
+static int l2cap_build_conf_rsp(struct sock *sk, void *data, void **ptr, int *result, int conf_output)
 {
-	l2cap_conf_rsp *rsp = (l2cap_conf_rsp *) data;
-	void *ptr = rsp->data;
+  	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);
+	if (result && conf_output)
+		*result = l2cap_conf_output(sk, ptr);
 	else	
 		flags |= 0x0001;
 
@@ -1358,7 +1364,7 @@
 	rsp->result = __cpu_to_le16(result ? *result : 0);
 	rsp->flags  = __cpu_to_le16(flags);
 
-	return ptr - data;
+	return *ptr - data;
 }
 
 static inline int l2cap_connect_req(struct l2cap_conn *conn, l2cap_cmd_hdr *cmd, __u8 *data)
@@ -1493,6 +1499,7 @@
 	__u8 rsp[64];
 	struct sock *sk;
 	int result;
+	void *ptr = ((l2cap_conf_rsp *)rsp)->data;
 
 	dcid  = __le16_to_cpu(req->dcid);
 	flags = __le16_to_cpu(req->flags);
@@ -1502,16 +1509,22 @@
 	if (!(sk = l2cap_get_chan_by_scid(&conn->chan_list, dcid)))
 		return -ENOENT;
 
-	l2cap_parse_conf_req(sk, req->data, cmd->len - L2CAP_CONF_REQ_SIZE);
+	result = l2cap_parse_conf_req(sk, req->data, cmd->len - L2CAP_CONF_REQ_SIZE, &ptr);
+
+	if (result) {
+		/* Unknown option */
+		l2cap_send_rsp(conn, cmd->ident, L2CAP_CONF_RSP, l2cap_build_conf_rsp(sk, rsp, &ptr, &result, 0), rsp);
+		goto unlock;
+	}
 
 	if (flags & 0x0001) {
 		/* Incomplete config. Send empty response. */
-		l2cap_send_rsp(conn, cmd->ident, L2CAP_CONF_RSP, l2cap_build_conf_rsp(sk, rsp, NULL), rsp);
+		l2cap_send_rsp(conn, cmd->ident, L2CAP_CONF_RSP, l2cap_build_conf_rsp(sk, rsp, &ptr, NULL, 0), rsp);
 		goto unlock;
 	}
 
 	/* Complete config. */
-	l2cap_send_rsp(conn, cmd->ident, L2CAP_CONF_RSP, l2cap_build_conf_rsp(sk, rsp, &result), rsp);
+	l2cap_send_rsp(conn, cmd->ident, L2CAP_CONF_RSP, l2cap_build_conf_rsp(sk, rsp, &ptr, &result, 1), rsp);
 
 	if (result)
 		goto unlock;
--- linux-2.4.21/include/net/bluetooth/l2cap.h	2004-08-26 11:39:27.000000000 -0700
+++ linux-2.4.21_mods/include/net/bluetooth/l2cap.h	2004-11-30 15:43:17.000000000 -0800
@@ -151,6 +151,7 @@
 
 #define L2CAP_CONF_SUCCESS	0x00
 #define L2CAP_CONF_UNACCEPT	0x01
+#define L2CAP_CONF_UNKNOWN_OPT  0x03
 
 typedef struct {
 	__u8       type;

^ permalink raw reply	[flat|nested] 81+ messages in thread
end of thread, other threads:[~2004-12-02 17:56 UTC | newest]

Thread overview: 81+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2003-05-06 17:34 [Bluez-devel] Qualification Testing Daryl Van Vorst
2003-05-07 10:56 ` Stephen Crane
2003-05-07 16:44   ` Daryl Van Vorst
2003-05-08  2:18   ` Daryl Van Vorst
2003-05-12 16:37     ` Stephen Crane
2003-05-12 19:38       ` Daryl Van Vorst
2003-05-08 13:43 ` Marcel Holtmann
2003-05-08 18:11   ` Daryl Van Vorst
2003-05-08 19:53     ` Marcel Holtmann
2003-05-08 21:04     ` Daryl Van Vorst
2003-05-08 21:55     ` Daryl Van Vorst
2003-05-09  0:10       ` Marcel Holtmann
2003-05-08 22:06     ` Daryl Van Vorst
2003-05-08 18:33   ` Daryl Van Vorst
2003-05-09  0:51   ` Max Krasnyansky
2003-05-09  1:14     ` Marcel Holtmann
2003-05-09 18:11       ` Daryl Van Vorst
2003-05-09 18:36         ` Marcel Holtmann
2003-05-09 21:15         ` Max Krasnyansky
2003-05-09 21:52           ` Daryl Van Vorst
2003-05-09 22:51             ` Max Krasnyansky
2003-05-09 23:16               ` Daryl Van Vorst
2003-05-09 23:40               ` Daryl Van Vorst
2003-05-10  0:26                 ` Marcel Holtmann
2003-05-10  2:33                   ` Daryl Van Vorst
2003-05-10  6:17                   ` Max Krasnyansky
2003-05-10 11:25                     ` Marcel Holtmann
2003-05-11  3:57                       ` Daryl Van Vorst
2003-05-12 22:51                         ` Daryl Van Vorst
2003-05-12 23:05                           ` Marcel Holtmann
2003-05-13 17:37                           ` Max Krasnyansky
2003-05-13 17:55                             ` Daryl Van Vorst
2003-05-13 22:31                             ` Marcel Holtmann
2003-05-13 23:02                               ` Max Krasnyansky
2003-05-13 23:19                                 ` Marcel Holtmann
2003-05-14  0:05                                   ` Max Krasnyansky
2003-05-14  0:30                                     ` Marcel Holtmann
2003-05-14 16:02                                       ` Daryl Van Vorst
2003-05-14 16:34                                         ` Max Krasnyansky
2003-05-14 21:12                                           ` Daryl Van Vorst
2003-05-14 22:24                                             ` Daryl Van Vorst
2003-05-14 22:27                                               ` Marcel Holtmann
2003-05-14 22:35                                                 ` Daryl Van Vorst
2003-05-16  0:43                                                   ` Max Krasnyansky
2003-05-16 14:43                                                     ` Daryl Van Vorst
2003-05-16 17:38                                                       ` Max Krasnyansky
2003-05-16 17:54                                                         ` Daryl Van Vorst
2003-05-16  7:17                                                   ` Marcel Holtmann
2003-05-10  6:16       ` Max Krasnyansky
2003-05-10 16:30         ` Marcel Holtmann
2003-05-11  7:19           ` Max Krasnyansky
2003-05-11  7:44             ` Marcel Holtmann
2003-05-12 23:37           ` Daryl Van Vorst
2003-05-13  0:04             ` Marcel Holtmann
2003-05-13  0:43               ` Daryl Van Vorst
2003-05-13 17:49               ` Max Krasnyansky
2003-05-13 17:44             ` Max Krasnyansky
2003-05-13 18:36               ` Daryl Van Vorst
2003-05-15 21:25                 ` Daryl Van Vorst
2003-05-16 17:35                   ` Max Krasnyansky
2003-05-16 18:01                     ` Daryl Van Vorst
2003-05-16 18:23                       ` Marcel Holtmann
2003-05-19 21:17                       ` Max Krasnyansky
2003-05-19 21:19                       ` Max Krasnyansky
2003-05-20 16:40                         ` Daryl Van Vorst
2003-05-29 22:51                         ` Daryl Van Vorst
2003-06-12 18:08                           ` Max Krasnyansky
2003-06-12 18:49                             ` Daryl Van Vorst
2003-06-12 19:11                               ` Max Krasnyansky
2003-06-12 20:54                                 ` Daryl Van Vorst
2003-06-12 21:28                                   ` Marcel Holtmann
2003-06-13  1:22                                   ` Max Krasnyansky
2003-05-13 13:30           ` Daryl Van Vorst
2003-05-13 14:02             ` Marcel Holtmann
  -- strict thread matches above, loose matches on Subject: below --
2004-12-01  0:32 [Bluez-devel] Qualification testing Daryl Van Vorst
2004-12-01  6:42 ` Marcel Holtmann
2004-12-01 19:09   ` Daryl Van Vorst
2004-12-01 19:32     ` Marcel Holtmann
2004-12-01 23:02       ` Daryl Van Vorst
2004-12-02  7:35         ` Marcel Holtmann
2004-12-02 17:56           ` Daryl Van Vorst

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox