All of lore.kernel.org
 help / color / mirror / Atom feed
* Qualification testing - rfcomm
@ 2003-07-08 18:16 Daryl Van Vorst
  2003-07-08 21:47 ` [Bluez-devel] " James Courtier-Dutton
                   ` (3 more replies)
  0 siblings, 4 replies; 26+ messages in thread
From: Daryl Van Vorst @ 2003-07-08 18:16 UTC (permalink / raw)
  To: BlueZ Mailing List, 'Marcel Holtmann'

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

Marcel,

Finally got some results on those latest rfcomm changes for qualification.
Looks like there are a few more problems. :(  But we're close. :)

TP/RFC/BV-09-C:
"Verify that the IUT handles flow control correctly when the Tester, acting
as a device conforming to Bluetooth version 1.0B, controls the data flow
using the Modem Status Command. The IUT's device role is of no importance."

The command and console output:

root@jack-00000000:~>./rctest -s -P 1 -b 20 00:A0:96:1F:83:71
rctest[351]: Connected
rctest[351]: Sending ...
rctest[351]: Send failed. Resource temporarily unavailable(11)

The IUT sends data in 5 frames, then stops for aboue 20s, then sends 5 more,
then stops, etc. Technically, this test passed because we did stop sending
data after the tester send MSC stop to the IUT. But something's clearly not
right.

There is an hcidump of the session attached.

TP/RFC/BV-12-C:
"Verify that the IUT handles aggregate flow control correctly when the
Tester, acting as a device conforming to Bleutooth version 1.0B, controls
the data flow using the Flow Control on/off commands FCon and FCoff. The
IUT's device role is of no importance."

The command and console output:

root@jack-00000000:~>./rctest -s -P 1 -b 20 00:A0:96:1F:83:71
rctest[362]: Connected
rctest[362]: Sending ...
rfcomm_recv_mcc: Unknown control type 0x18
rfcomm_recv_mcc: Unknown control type 0x28

The IUT does not respond to FCoff with FCoff, and continues sending data. It
also does not respond to FCon with FCon. 

There is an hcidump of the session attached.

-Daryl.

[-- Attachment #2: RFC_BV_09_IUT_sends_5_frames_every_20s_hcidump --]
[-- Type: application/octet-stream, Size: 1792 bytes --]

[-- Attachment #3: RFC_BV_12_IUT_does_not_reply_with_FCoff_FCon_hcidump --]
[-- Type: application/octet-stream, Size: 4864 bytes --]

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [Bluez-devel] Qualification testing - rfcomm
  2003-07-08 18:16 Qualification testing - rfcomm Daryl Van Vorst
@ 2003-07-08 21:47 ` James Courtier-Dutton
  2003-07-08 23:23   ` Daryl Van Vorst
  2003-07-11  8:18 ` [Bluez-devel] " Marcel Holtmann
                   ` (2 subsequent siblings)
  3 siblings, 1 reply; 26+ messages in thread
From: James Courtier-Dutton @ 2003-07-08 21:47 UTC (permalink / raw)
  To: Daryl Van Vorst; +Cc: BlueZ Mailing List, 'Marcel Holtmann'

Daryl Van Vorst wrote:
> Marcel,
> 
> Finally got some results on those latest rfcomm changes for qualification.
> Looks like there are a few more problems. :(  But we're close. :)
> 
> TP/RFC/BV-09-C:
> "Verify that the IUT handles flow control correctly when the Tester, acting
> as a device conforming to Bluetooth version 1.0B, controls the data flow
> using the Modem Status Command. The IUT's device role is of no importance."
> 
> The command and console output:
> 
> root@jack-00000000:~>./rctest -s -P 1 -b 20 00:A0:96:1F:83:71
> rctest[351]: Connected
> rctest[351]: Sending ...
> rctest[351]: Send failed. Resource temporarily unavailable(11)
> 
> The IUT sends data in 5 frames, then stops for aboue 20s, then sends 5 more,
> then stops, etc. Technically, this test passed because we did stop sending
> data after the tester send MSC stop to the IUT. But something's clearly not
> right.
> 
> There is an hcidump of the session attached.
> 
> TP/RFC/BV-12-C:
> "Verify that the IUT handles aggregate flow control correctly when the
> Tester, acting as a device conforming to Bleutooth version 1.0B, controls
> the data flow using the Flow Control on/off commands FCon and FCoff. The
> IUT's device role is of no importance."
> 
> The command and console output:
> 
> root@jack-00000000:~>./rctest -s -P 1 -b 20 00:A0:96:1F:83:71
> rctest[362]: Connected
> rctest[362]: Sending ...
> rfcomm_recv_mcc: Unknown control type 0x18
> rfcomm_recv_mcc: Unknown control type 0x28
> 
> The IUT does not respond to FCoff with FCoff, and continues sending data. It
> also does not respond to FCon with FCon. 
> 
> There is an hcidump of the session attached.
> 
> -Daryl.

Any chance of doing some tests with SCO ?
It might help us with some of the currently problems there are with SCO 
and usb dongles.
Cheers
James

^ permalink raw reply	[flat|nested] 26+ messages in thread

* RE: [Bluez-devel] Qualification testing - rfcomm
  2003-07-08 21:47 ` [Bluez-devel] " James Courtier-Dutton
@ 2003-07-08 23:23   ` Daryl Van Vorst
  2003-07-18 19:35     ` James Courtier-Dutton
  0 siblings, 1 reply; 26+ messages in thread
From: Daryl Van Vorst @ 2003-07-08 23:23 UTC (permalink / raw)
  To: 'James Courtier-Dutton'
  Cc: 'BlueZ Mailing List', 'Marcel Holtmann',
	'Siegfried Lehmann', 'Benjamin Ko'

James,

Unfortunately I'm not going to be of much help with SCO testing...  We've
been doing our testing with Cetecom (they're on the CC list).

It may be possible for you to arrange something with them if you (or someon=
e
else) are making a product. Contact Ben Ko (benjamin.ko@CetecomUSA.com) if
you'd like to discuss it.

-Daryl.

> -----Original Message-----
> From: bluez-devel-admin@lists.sourceforge.net=20
> [mailto:bluez-devel-admin@lists.sourceforge.net] On Behalf Of=20
> James Courtier-Dutton
> Sent: July 8, 2003 2:47 PM
> To: Daryl Van Vorst
> Cc: BlueZ Mailing List; 'Marcel Holtmann'
> Subject: Re: [Bluez-devel] Qualification testing - rfcomm
>=20
>=20
> Daryl Van Vorst wrote:
> > Marcel,
> >=20
> > Finally got some results on those latest rfcomm changes for=20
> > qualification. Looks like there are a few more problems. :(=20
>  But we're=20
> > close. :)
> >=20
> > TP/RFC/BV-09-C:
> > "Verify that the IUT handles flow control correctly when=20
> the Tester,=20
> > acting as a device conforming to Bluetooth version 1.0B,=20
> controls the=20
> > data flow using the Modem Status Command. The IUT's device=20
> role is of=20
> > no importance."
> >=20
> > The command and console output:
> >=20
> > root@jack-00000000:~>./rctest -s -P 1 -b 20 00:A0:96:1F:83:71
> > rctest[351]: Connected
> > rctest[351]: Sending ...
> > rctest[351]: Send failed. Resource temporarily unavailable(11)
> >=20
> > The IUT sends data in 5 frames, then stops for aboue 20s,=20
> then sends 5=20
> > more, then stops, etc. Technically, this test passed because we did=20
> > stop sending data after the tester send MSC stop to the IUT. But=20
> > something's clearly not right.
> >=20
> > There is an hcidump of the session attached.
> >=20
> > TP/RFC/BV-12-C:
> > "Verify that the IUT handles aggregate flow control=20
> correctly when the=20
> > Tester, acting as a device conforming to Bleutooth version 1.0B,=20
> > controls the data flow using the Flow Control on/off=20
> commands FCon and=20
> > FCoff. The IUT's device role is of no importance."
> >=20
> > The command and console output:
> >=20
> > root@jack-00000000:~>./rctest -s -P 1 -b 20 00:A0:96:1F:83:71
> > rctest[362]: Connected
> > rctest[362]: Sending ...
> > rfcomm_recv_mcc: Unknown control type 0x18
> > rfcomm_recv_mcc: Unknown control type 0x28
> >=20
> > The IUT does not respond to FCoff with FCoff, and continues sending=20
> > data. It also does not respond to FCon with FCon.
> >=20
> > There is an hcidump of the session attached.
> >=20
> > -Daryl.
>=20
> Any chance of doing some tests with SCO ?
> It might help us with some of the currently problems there=20
> are with SCO=20
> and usb dongles.
> Cheers
> James
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email sponsored by: Parasoft
> Error proof Web apps, automate testing & more.
> Download & eval WebKing and get a free book.=20
> www.parasoft.com/bulletproofapps=20
> _______________________________________________
> Bluez-devel mailing list
> Bluez-devel@lists.sourceforge.net=20
> https://lists.sourceforge.net/lists/listinfo/b> luez-devel
>=20

^ permalink raw reply	[flat|nested] 26+ messages in thread

* [Bluez-devel] Re: Qualification testing - rfcomm
  2003-07-08 18:16 Qualification testing - rfcomm Daryl Van Vorst
  2003-07-08 21:47 ` [Bluez-devel] " James Courtier-Dutton
@ 2003-07-11  8:18 ` Marcel Holtmann
  2003-07-22 16:23   ` Max Krasnyansky
  2003-07-11  8:55 ` Marcel Holtmann
  2003-07-18 19:30 ` [Bluez-devel] " James Courtier-Dutton
  3 siblings, 1 reply; 26+ messages in thread
From: Marcel Holtmann @ 2003-07-11  8:18 UTC (permalink / raw)
  To: Daryl Van Vorst; +Cc: BlueZ Mailing List

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

Hi Daryl,

> TP/RFC/BV-12-C:
> "Verify that the IUT handles aggregate flow control correctly when the
> Tester, acting as a device conforming to Bleutooth version 1.0B, controls
> the data flow using the Flow Control on/off commands FCon and FCoff. The
> IUT's device role is of no importance."
> 
> The command and console output:
> 
> root@jack-00000000:~>./rctest -s -P 1 -b 20 00:A0:96:1F:83:71
> rctest[362]: Connected
> rctest[362]: Sending ...
> rfcomm_recv_mcc: Unknown control type 0x18
> rfcomm_recv_mcc: Unknown control type 0x28
> 
> The IUT does not respond to FCoff with FCoff, and continues sending data. It
> also does not respond to FCon with FCon. 

we don't have support for flow control on the entire RFCOMM session. But
it seems that the FCOFF and FCON should be supported. The attached patch
implements support for it, but I am not quite sure if it is the right
way to do this.

Regards

Marcel


[-- Attachment #2: patch-fcoff-fcon --]
[-- Type: text/plain, Size: 2114 bytes --]

--- bt-2.4/net/bluetooth/rfcomm/core.c	Thu Jul 10 21:16:52 2003
+++ marcel-2.4/net/bluetooth/rfcomm/core.c	Fri Jul 11 10:04:37 2003
@@ -853,6 +853,50 @@
 	return rfcomm_send_frame(s, buf, ptr - buf);
 }
 
+static int rfcomm_send_fcoff(struct rfcomm_session *s, int cr)
+{
+	struct rfcomm_hdr *hdr;
+	struct rfcomm_mcc *mcc;
+	u8 buf[16], *ptr = buf;
+
+	BT_DBG("%p cr %d", s, cr);
+
+	hdr = (void *) ptr; ptr += sizeof(*hdr);
+	hdr->addr = __addr(s->initiator, 0);
+	hdr->ctrl = __ctrl(RFCOMM_UIH, 0);
+	hdr->len  = __len8(sizeof(*mcc));
+
+	mcc = (void *) ptr; ptr += sizeof(*mcc);
+	mcc->type = __mcc_type(cr, RFCOMM_FCOFF);
+	mcc->len  = __len8(0);
+
+	*ptr = __fcs(buf); ptr++;
+
+	return rfcomm_send_frame(s, buf, ptr - buf);
+}
+
+static int rfcomm_send_fcon(struct rfcomm_session *s, int cr)
+{
+	struct rfcomm_hdr *hdr;
+	struct rfcomm_mcc *mcc;
+	u8 buf[16], *ptr = buf;
+
+	BT_DBG("%p cr %d", s, cr);
+
+	hdr = (void *) ptr; ptr += sizeof(*hdr);
+	hdr->addr = __addr(s->initiator, 0);
+	hdr->ctrl = __ctrl(RFCOMM_UIH, 0);
+	hdr->len  = __len8(sizeof(*mcc));
+
+	mcc = (void *) ptr; ptr += sizeof(*mcc);
+	mcc->type = __mcc_type(cr, RFCOMM_FCON);
+	mcc->len  = __len8(0);
+
+	*ptr = __fcs(buf); ptr++;
+
+	return rfcomm_send_frame(s, buf, ptr - buf);
+}
+
 static int rfcomm_send_test(struct rfcomm_session *s, int cr, u8 *pattern, int len)
 {
 	struct socket *sock = s->sock;
@@ -1351,6 +1395,20 @@
 		rfcomm_recv_msc(s, cr, skb);
 		break;
 
+	case RFCOMM_FCOFF:
+		if (cr) {
+			set_bit(RFCOMM_TX_THROTTLED, &s->flags);
+			rfcomm_send_fcoff(s, 0);
+		}
+		break;
+
+	case RFCOMM_FCON:
+		if (cr) {
+			clear_bit(RFCOMM_TX_THROTTLED, &s->flags);
+			rfcomm_send_fcon(s, 0);
+		}
+		break;
+
 	case RFCOMM_TEST:
 		if (cr)
 			rfcomm_send_test(s, 0, skb->data, skb->len);
@@ -1533,6 +1591,9 @@
 	struct list_head *p, *n;
 
 	BT_DBG("session %p state %ld", s, s->state);
+
+	if (test_bit(RFCOMM_TX_THROTTLED, &s->flags))
+		return;
 
 	list_for_each_safe(p, n, &s->dlcs) {
 		d = list_entry(p, struct rfcomm_dlc, list);

^ permalink raw reply	[flat|nested] 26+ messages in thread

* [Bluez-devel] Re: Qualification testing - rfcomm
  2003-07-08 18:16 Qualification testing - rfcomm Daryl Van Vorst
  2003-07-08 21:47 ` [Bluez-devel] " James Courtier-Dutton
  2003-07-11  8:18 ` [Bluez-devel] " Marcel Holtmann
@ 2003-07-11  8:55 ` Marcel Holtmann
  2003-07-11 16:43   ` Daryl Van Vorst
  2003-07-18 19:30 ` [Bluez-devel] " James Courtier-Dutton
  3 siblings, 1 reply; 26+ messages in thread
From: Marcel Holtmann @ 2003-07-11  8:55 UTC (permalink / raw)
  To: Daryl Van Vorst; +Cc: BlueZ Mailing List

Hi Daryl,

> Finally got some results on those latest rfcomm changes for qualification.
> Looks like there are a few more problems. :(  But we're close. :)
> 
> TP/RFC/BV-09-C:
> "Verify that the IUT handles flow control correctly when the Tester, acting
> as a device conforming to Bluetooth version 1.0B, controls the data flow
> using the Modem Status Command. The IUT's device role is of no importance."
> 
> The command and console output:
> 
> root@jack-00000000:~>./rctest -s -P 1 -b 20 00:A0:96:1F:83:71
> rctest[351]: Connected
> rctest[351]: Sending ...
> rctest[351]: Send failed. Resource temporarily unavailable(11)
> 
> The IUT sends data in 5 frames, then stops for aboue 20s, then sends 5 more,
> then stops, etc. Technically, this test passed because we did stop sending
> data after the tester send MSC stop to the IUT. But something's clearly not
> right.

this looks quite right, but the rctest program don't check the error
code. If it receives EAGAIN it should try again, but it aborts.

Regards

Marcel




-------------------------------------------------------
This SF.Net email sponsored by: Parasoft
Error proof Web apps, automate testing & more.
Download & eval WebKing and get a free book.
www.parasoft.com/bulletproofapps1
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

^ permalink raw reply	[flat|nested] 26+ messages in thread

* RE: Qualification testing - rfcomm
  2003-07-11  8:55 ` Marcel Holtmann
@ 2003-07-11 16:43   ` Daryl Van Vorst
  2003-07-11 19:05     ` [Bluez-devel] " Daryl Van Vorst
  2003-07-22 16:26     ` Max Krasnyansky
  0 siblings, 2 replies; 26+ messages in thread
From: Daryl Van Vorst @ 2003-07-11 16:43 UTC (permalink / raw)
  To: 'Marcel Holtmann'; +Cc: 'BlueZ Mailing List'

Marcel,

You're right that it doesn't check the error code, it just exits. But that
doesn't explain why it sends 5 frames, waits for 20 seconds, and then sends
5 more.  Shouldn't send block?

I haven't yet tried to reproduce that behaviour.  So I'm not certain that
the sequence of send 5, wait 20, send 5 repeats indefinitely.  I'll take a
look at it shortly.

Thanks for the flow control patch...  I'll wait and see if anything comes
out of the above stuff before sending it out for testing.

-Daryl.

> -----Original Message-----
> From: Marcel Holtmann [mailto:marcel@rvs.uni-bielefeld.de] 
> Sent: July 11, 2003 1:55 AM
> To: Daryl Van Vorst
> Cc: BlueZ Mailing List
> Subject: Re: Qualification testing - rfcomm
> 
> 
> Hi Daryl,
> 
> > Finally got some results on those latest rfcomm changes for 
> > qualification. Looks like there are a few more problems. :( 
>  But we're 
> > close. :)
> > 
> > TP/RFC/BV-09-C:
> > "Verify that the IUT handles flow control correctly when 
> the Tester, 
> > acting as a device conforming to Bluetooth version 1.0B, 
> controls the 
> > data flow using the Modem Status Command. The IUT's device 
> role is of 
> > no importance."
> > 
> > The command and console output:
> > 
> > root@jack-00000000:~>./rctest -s -P 1 -b 20 00:A0:96:1F:83:71
> > rctest[351]: Connected
> > rctest[351]: Sending ...
> > rctest[351]: Send failed. Resource temporarily unavailable(11)
> > 
> > The IUT sends data in 5 frames, then stops for aboue 20s, 
> then sends 5 
> > more, then stops, etc. Technically, this test passed because we did 
> > stop sending data after the tester send MSC stop to the IUT. But 
> > something's clearly not right.
> 
> this looks quite right, but the rctest program don't check 
> the error code. If it receives EAGAIN it should try again, 
> but it aborts.
> 
> Regards
> 
> Marcel
> 
> 
> 

^ permalink raw reply	[flat|nested] 26+ messages in thread

* RE: [Bluez-devel] RE: Qualification testing - rfcomm
  2003-07-11 16:43   ` Daryl Van Vorst
@ 2003-07-11 19:05     ` Daryl Van Vorst
  2003-07-18 18:53       ` Daryl Van Vorst
  2003-07-22 16:26     ` Max Krasnyansky
  1 sibling, 1 reply; 26+ messages in thread
From: Daryl Van Vorst @ 2003-07-11 19:05 UTC (permalink / raw)
  To: 'Marcel Holtmann'; +Cc: 'BlueZ Mailing List'

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

Marcel,

I just reproduced it here. Attached is an aclsession script which will do
it. First run aclsession on one machine, then run rctest on the other
machine. Also attached are the console output and hcidump from the machine
running rctest.

The pattern of send 5 packets, wait 20 seconds, send 5 more, etc appears to
continue forever. I'm told that it should just keep sending data.

-Daryl.

> -----Original Message-----
> From: bluez-devel-admin@lists.sourceforge.net 
> [mailto:bluez-devel-admin@lists.sourceforge.net] On Behalf Of 
> Daryl Van Vorst
> Sent: July 11, 2003 9:44 AM
> To: 'Marcel Holtmann'
> Cc: 'BlueZ Mailing List'
> Subject: [Bluez-devel] RE: Qualification testing - rfcomm
> 
> 
> Marcel,
> 
> You're right that it doesn't check the error code, it just 
> exits. But that doesn't explain why it sends 5 frames, waits 
> for 20 seconds, and then sends 5 more.  Shouldn't send block?
> 
> I haven't yet tried to reproduce that behaviour.  So I'm not 
> certain that the sequence of send 5, wait 20, send 5 repeats 
> indefinitely.  I'll take a look at it shortly.
> 
> Thanks for the flow control patch...  I'll wait and see if 
> anything comes out of the above stuff before sending it out 
> for testing.
> 
> -Daryl.
> 
> > -----Original Message-----
> > From: Marcel Holtmann [mailto:marcel@rvs.uni-bielefeld.de]
> > Sent: July 11, 2003 1:55 AM
> > To: Daryl Van Vorst
> > Cc: BlueZ Mailing List
> > Subject: Re: Qualification testing - rfcomm
> > 
> > 
> > Hi Daryl,
> > 
> > > Finally got some results on those latest rfcomm changes for
> > > qualification. Looks like there are a few more problems. :( 
> >  But we're
> > > close. :)
> > > 
> > > TP/RFC/BV-09-C:
> > > "Verify that the IUT handles flow control correctly when
> > the Tester,
> > > acting as a device conforming to Bluetooth version 1.0B,
> > controls the
> > > data flow using the Modem Status Command. The IUT's device
> > role is of
> > > no importance."
> > > 
> > > The command and console output:
> > > 
> > > root@jack-00000000:~>./rctest -s -P 1 -b 20 00:A0:96:1F:83:71
> > > rctest[351]: Connected
> > > rctest[351]: Sending ...
> > > rctest[351]: Send failed. Resource temporarily unavailable(11)
> > > 
> > > The IUT sends data in 5 frames, then stops for aboue 20s,
> > then sends 5
> > > more, then stops, etc. Technically, this test passed 
> because we did
> > > stop sending data after the tester send MSC stop to the IUT. But 
> > > something's clearly not right.
> > 
> > this looks quite right, but the rctest program don't check
> > the error code. If it receives EAGAIN it should try again, 
> > but it aborts.
> > 
> > Regards
> > 
> > Marcel
> > 
> > 
> > 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email sponsored by: Parasoft
> Error proof Web apps, automate testing & more.
> Download & eval WebKing and get a free book. 
> www.parasoft.com/bulletproofapps1 
> _______________________________________________
> Bluez-devel mailing list
> Bluez-devel@lists.sourceforge.net 
> https://lists.sourceforge.net/lists/listinfo/b> luez-devel
> 

[-- Attachment #2: rc_aclsession --]
[-- Type: application/octet-stream, Size: 491 bytes --]

open 00:80:37:1a:95:78
wait 10
send 0C 00 01 00 03 01 08 00 40 00 40 00 00 00 00 00
wait 10
send 0A 00 01 00 05 02 06 00 40 00 00 00 00 00
send 08 00 01 00 04 8C 04 00 40 00 00 00
wait 10
wait 10
send 04 00 40 00 03 73 01 D7
wait 10
send 0E 00 40 00 01 EF 15 81 11 02 00 07 00 00 01 00 00 AA
wait 10
send 04 00 40 00 0B 73 01 92
wait 10
send 08 00 40 00 01 EF 09 E1 05 0B 8D AA
send 08 00 40 00 01 EF 09 E3 05 0B 8D AA
wait 10
wait 10
wait 10
wait 10
wait 10
wait 10


[-- Attachment #3: rc_console --]
[-- Type: application/octet-stream, Size: 97 bytes --]

./rctest -s -P1 -b 20 00:80:37:19:BA:86
rctest[21784]: Connected
rctest[21784]: Sending ...


[-- Attachment #4: rc_hcidump --]
[-- Type: application/octet-stream, Size: 3137 bytes --]

^ permalink raw reply	[flat|nested] 26+ messages in thread

* RE: [Bluez-devel] RE: Qualification testing - rfcomm
  2003-07-11 19:05     ` [Bluez-devel] " Daryl Van Vorst
@ 2003-07-18 18:53       ` Daryl Van Vorst
  2003-07-18 18:58         ` Marcel Holtmann
  0 siblings, 1 reply; 26+ messages in thread
From: Daryl Van Vorst @ 2003-07-18 18:53 UTC (permalink / raw)
  To: 'Marcel Holtmann'; +Cc: 'BlueZ Mailing List'

Marcel,

Just wanted to make sure that you saw this (not trying to be pushy). :)

I haven't actually run into this problem with a real product yet, but the
rfcomm tester runs into it. So as far as qualification goes, it's pretty
marginal.

-Daryl.

> -----Original Message-----
> From: bluez-devel-admin@lists.sourceforge.net 
> [mailto:bluez-devel-admin@lists.sourceforge.net] On Behalf Of 
> Daryl Van Vorst
> Sent: July 11, 2003 12:05 PM
> To: 'Marcel Holtmann'
> Cc: 'BlueZ Mailing List'
> Subject: RE: [Bluez-devel] RE: Qualification testing - rfcomm
> 
> 
> Marcel,
> 
> I just reproduced it here. Attached is an aclsession script 
> which will do it. First run aclsession on one machine, then 
> run rctest on the other machine. Also attached are the 
> console output and hcidump from the machine running rctest.
> 
> The pattern of send 5 packets, wait 20 seconds, send 5 more, 
> etc appears to continue forever. I'm told that it should just 
> keep sending data.
> 
> -Daryl.
> 
> > -----Original Message-----
> > From: bluez-devel-admin@lists.sourceforge.net
> > [mailto:bluez-devel-admin@lists.sourceforge.net] On Behalf Of 
> > Daryl Van Vorst
> > Sent: July 11, 2003 9:44 AM
> > To: 'Marcel Holtmann'
> > Cc: 'BlueZ Mailing List'
> > Subject: [Bluez-devel] RE: Qualification testing - rfcomm
> > 
> > 
> > Marcel,
> > 
> > You're right that it doesn't check the error code, it just
> > exits. But that doesn't explain why it sends 5 frames, waits 
> > for 20 seconds, and then sends 5 more.  Shouldn't send block?
> > 
> > I haven't yet tried to reproduce that behaviour.  So I'm not
> > certain that the sequence of send 5, wait 20, send 5 repeats 
> > indefinitely.  I'll take a look at it shortly.
> > 
> > Thanks for the flow control patch...  I'll wait and see if
> > anything comes out of the above stuff before sending it out 
> > for testing.
> > 
> > -Daryl.
> > 
> > > -----Original Message-----
> > > From: Marcel Holtmann [mailto:marcel@rvs.uni-bielefeld.de]
> > > Sent: July 11, 2003 1:55 AM
> > > To: Daryl Van Vorst
> > > Cc: BlueZ Mailing List
> > > Subject: Re: Qualification testing - rfcomm
> > > 
> > > 
> > > Hi Daryl,
> > > 
> > > > Finally got some results on those latest rfcomm changes for 
> > > > qualification. Looks like there are a few more problems. :(
> > >  But we're
> > > > close. :)
> > > > 
> > > > TP/RFC/BV-09-C:
> > > > "Verify that the IUT handles flow control correctly when
> > > the Tester,
> > > > acting as a device conforming to Bluetooth version 1.0B,
> > > controls the
> > > > data flow using the Modem Status Command. The IUT's device
> > > role is of
> > > > no importance."
> > > > 
> > > > The command and console output:
> > > > 
> > > > root@jack-00000000:~>./rctest -s -P 1 -b 20 00:A0:96:1F:83:71
> > > > rctest[351]: Connected
> > > > rctest[351]: Sending ...
> > > > rctest[351]: Send failed. Resource temporarily unavailable(11)
> > > > 
> > > > The IUT sends data in 5 frames, then stops for aboue 20s,
> > > then sends 5
> > > > more, then stops, etc. Technically, this test passed
> > because we did
> > > > stop sending data after the tester send MSC stop to the IUT. But
> > > > something's clearly not right.
> > > 
> > > this looks quite right, but the rctest program don't 
> check the error 
> > > code. If it receives EAGAIN it should try again, but it aborts.
> > > 
> > > Regards
> > > 
> > > Marcel
> > > 
> > > 
> > > 
> > 
> > 
> > 
> > -------------------------------------------------------
> > This SF.Net email sponsored by: Parasoft
> > Error proof Web apps, automate testing & more.
> > Download & eval WebKing and get a free book.
> > www.parasoft.com/bulletproofapps1 
> > _______________________________________________
> > Bluez-devel mailing list
> > Bluez-devel@lists.sourceforge.net 
> > https://lists.sourceforge.net/lists/listinfo/b> luez-devel
> > 
> 

^ permalink raw reply	[flat|nested] 26+ messages in thread

* RE: [Bluez-devel] RE: Qualification testing - rfcomm
  2003-07-18 18:53       ` Daryl Van Vorst
@ 2003-07-18 18:58         ` Marcel Holtmann
  2003-07-18 19:07           ` Daryl Van Vorst
  0 siblings, 1 reply; 26+ messages in thread
From: Marcel Holtmann @ 2003-07-18 18:58 UTC (permalink / raw)
  To: Daryl Van Vorst; +Cc: 'BlueZ Mailing List'

Hi Daryl,

> Just wanted to make sure that you saw this (not trying to be pushy). :)
> 
> I haven't actually run into this problem with a real product yet, but the
> rfcomm tester runs into it. So as far as qualification goes, it's pretty
> marginal.

and that's the problem I don't find the part where it gets wrong :(

Did the other patch helped?

Regards

Marcel




-------------------------------------------------------
This SF.net email is sponsored by: VM Ware
With VMware you can run multiple operating systems on a single machine.
WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the
same time. Free trial click here: http://www.vmware.com/wl/offer/345/0
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

^ permalink raw reply	[flat|nested] 26+ messages in thread

* RE: [Bluez-devel] RE: Qualification testing - rfcomm
  2003-07-18 18:58         ` Marcel Holtmann
@ 2003-07-18 19:07           ` Daryl Van Vorst
  2003-07-18 19:12             ` Marcel Holtmann
  0 siblings, 1 reply; 26+ messages in thread
From: Daryl Van Vorst @ 2003-07-18 19:07 UTC (permalink / raw)
  To: 'Marcel Holtmann'; +Cc: 'BlueZ Mailing List'

Marcel,

> > Just wanted to make sure that you saw this (not trying to 
> be pushy). 
> > :)
> > 
> > I haven't actually run into this problem with a real 
> product yet, but 
> > the rfcomm tester runs into it. So as far as qualification 
> goes, it's 
> > pretty marginal.
> 
> and that's the problem I don't find the part where it gets wrong :(

Do you mean you tried the aclsession script and didn't see the same send 5
frames, wait 20 sec, send 5 more etc problem?

> Did the other patch helped?

We haven't tested it yet...  I was hoping for a resolution to the above
problem before I sent updates for evaluation.

-Daryl.

^ permalink raw reply	[flat|nested] 26+ messages in thread

* RE: [Bluez-devel] RE: Qualification testing - rfcomm
  2003-07-18 19:07           ` Daryl Van Vorst
@ 2003-07-18 19:12             ` Marcel Holtmann
  2003-07-18 19:19               ` Daryl Van Vorst
  0 siblings, 1 reply; 26+ messages in thread
From: Marcel Holtmann @ 2003-07-18 19:12 UTC (permalink / raw)
  To: Daryl Van Vorst; +Cc: 'BlueZ Mailing List'

Hi Daryl,

> > and that's the problem I don't find the part where it gets wrong :(
> 
> Do you mean you tried the aclsession script and didn't see the same send 5
> frames, wait 20 sec, send 5 more etc problem?

the aclsession scripts produces this effect, but it also left the ACL
link in some kind of buggy state. It must be some really stupid that I
always overlook. The code looks correct to me and my Bluetooth 1.0b
devices are working fine.

> > Did the other patch helped?
> 
> We haven't tested it yet...  I was hoping for a resolution to the above
> problem before I sent updates for evaluation.

It would be nice to know if the patch is enough for qualification,
because I don't plan to integrate a session wide flow control.

Regards

Marcel




-------------------------------------------------------
This SF.net email is sponsored by: VM Ware
With VMware you can run multiple operating systems on a single machine.
WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the
same time. Free trial click here: http://www.vmware.com/wl/offer/345/0
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

^ permalink raw reply	[flat|nested] 26+ messages in thread

* RE: [Bluez-devel] RE: Qualification testing - rfcomm
  2003-07-18 19:12             ` Marcel Holtmann
@ 2003-07-18 19:19               ` Daryl Van Vorst
  2003-07-22 17:09                 ` Max Krasnyansky
  0 siblings, 1 reply; 26+ messages in thread
From: Daryl Van Vorst @ 2003-07-18 19:19 UTC (permalink / raw)
  To: 'Marcel Holtmann'; +Cc: 'BlueZ Mailing List'

Marcel,

> > Do you mean you tried the aclsession script and didn't see the same 
> > send 5 frames, wait 20 sec, send 5 more etc problem?
> 
> the aclsession scripts produces this effect, but it also left 
> the ACL link in some kind of buggy state. It must be some 
> really stupid that I always overlook. The code looks correct 
> to me and my Bluetooth 1.0b devices are working fine.

Ok...  I guess we can leave it for now then. If it becomes a more serious
issue I'll let you know.

> > > Did the other patch helped?
> > 
> > We haven't tested it yet...  I was hoping for a resolution to the 
> > above problem before I sent updates for evaluation.
> 
> It would be nice to know if the patch is enough for 
> qualification, because I don't plan to integrate a session 
> wide flow control.

I'll get things ready for more testing. Will probably be able to give it a
go next week sometime.

-Daryl.

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [Bluez-devel] Qualification testing - rfcomm
  2003-07-08 18:16 Qualification testing - rfcomm Daryl Van Vorst
                   ` (2 preceding siblings ...)
  2003-07-11  8:55 ` Marcel Holtmann
@ 2003-07-18 19:30 ` James Courtier-Dutton
  2003-07-18 20:25   ` Daryl Van Vorst
  3 siblings, 1 reply; 26+ messages in thread
From: James Courtier-Dutton @ 2003-07-18 19:30 UTC (permalink / raw)
  To: Daryl Van Vorst; +Cc: BlueZ Mailing List, 'Marcel Holtmann'

Daryl Van Vorst wrote:
> Marcel,
> 
> Finally got some results on those latest rfcomm changes for qualification.
> Looks like there are a few more problems. :(  But we're close. :)
> 
Can you outline what hardware you are using to do the test.
Is it:
1) USB bluetooth adapters
2) PCI bluetooth adapters
3) PCMCIA bluetooth adapters
4) Serial bluetooth adapters.

Cheers
James

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [Bluez-devel] Qualification testing - rfcomm
  2003-07-08 23:23   ` Daryl Van Vorst
@ 2003-07-18 19:35     ` James Courtier-Dutton
  0 siblings, 0 replies; 26+ messages in thread
From: James Courtier-Dutton @ 2003-07-18 19:35 UTC (permalink / raw)
  To: Daryl Van Vorst
  Cc: 'BlueZ Mailing List', 'Marcel Holtmann',
	'Siegfried Lehmann', 'Benjamin Ko'

Daryl Van Vorst wrote:
> James,
> 
> Unfortunately I'm not going to be of much help with SCO testing...  We've
> been doing our testing with Cetecom (they're on the CC list).
> 
> It may be possible for you to arrange something with them if you (or someone
> else) are making a product. Contact Ben Ko (benjamin.ko@CetecomUSA.com) if
> you'd like to discuss it.
> 
> -Daryl.
>


I am just an open source developer. I am not making any products or 
otherwise profiting from what I am doing.
So, unless CetecomUSA.com do testing for free, I don't think your 
suggestion will help me much.

Cheers
James

^ permalink raw reply	[flat|nested] 26+ messages in thread

* RE: [Bluez-devel] Qualification testing - rfcomm
  2003-07-18 19:30 ` [Bluez-devel] " James Courtier-Dutton
@ 2003-07-18 20:25   ` Daryl Van Vorst
  0 siblings, 0 replies; 26+ messages in thread
From: Daryl Van Vorst @ 2003-07-18 20:25 UTC (permalink / raw)
  To: 'James Courtier-Dutton'
  Cc: 'BlueZ Mailing List', 'Marcel Holtmann'

James,

> > Finally got some results on those latest rfcomm changes for=20
> > qualification. Looks like there are a few more problems. :(=20
>  But we're=20
> > close. :)
> >=20
> Can you outline what hardware you are using to do the test.
> Is it:
> 1) USB bluetooth adapters
> 2) PCI bluetooth adapters
> 3) PCMCIA bluetooth adapters
> 4) Serial bluetooth adapters.

We are using an Ericsson ROK 104001 bluetooth module. It's connected to a
high-speed UART. The stack is running on an ARM processor.

Once qualification testing is complete I'll put together a list of all test=
s
that were performed, and what kind of software tools or programs needed to
be used for each test.

-Daryl.

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [Bluez-devel] Re: Qualification testing - rfcomm
  2003-07-11  8:18 ` [Bluez-devel] " Marcel Holtmann
@ 2003-07-22 16:23   ` Max Krasnyansky
  2003-07-22 16:46     ` Marcel Holtmann
  2003-07-22 16:48     ` Daryl Van Vorst
  0 siblings, 2 replies; 26+ messages in thread
From: Max Krasnyansky @ 2003-07-22 16:23 UTC (permalink / raw)
  To: Marcel Holtmann; +Cc: Daryl Van Vorst, BlueZ Mailing List

On Fri, 2003-07-11 at 01:18, Marcel Holtmann wrote:
> Hi Daryl,
> 
> > TP/RFC/BV-12-C:
> > "Verify that the IUT handles aggregate flow control correctly when the
> > Tester, acting as a device conforming to Bleutooth version 1.0B, controls
> > the data flow using the Flow Control on/off commands FCon and FCoff. The
> > IUT's device role is of no importance."
> > 
> > The command and console output:
> > 
> > root@jack-00000000:~>./rctest -s -P 1 -b 20 00:A0:96:1F:83:71
> > rctest[362]: Connected
> > rctest[362]: Sending ...
> > rfcomm_recv_mcc: Unknown control type 0x18
> > rfcomm_recv_mcc: Unknown control type 0x28
> > 
> > The IUT does not respond to FCoff with FCoff, and continues sending data. It
> > also does not respond to FCon with FCon. 
> 
> we don't have support for flow control on the entire RFCOMM session. But
> it seems that the FCOFF and FCON should be supported. The attached patch
> implements support for it, but I am not quite sure if it is the right
> way to do this.
Is it mandatory ? I always thought it's optional.

> @@ -1533,6 +1591,9 @@
>  	struct list_head *p, *n;
> 
>  	BT_DBG("session %p state %ld", s, s->state);
> +
> +	if (test_bit(RFCOMM_TX_THROTTLED, &s->flags))
> +		return;
> 
>  	list_for_each_safe(p, n, &s->dlcs) {
>  		d = list_entry(p, struct rfcomm_dlc, list);
This part is not ok. We still have to check for timeout. Rest of patch is fine.

Max 

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [Bluez-devel] RE: Qualification testing - rfcomm
  2003-07-11 16:43   ` Daryl Van Vorst
  2003-07-11 19:05     ` [Bluez-devel] " Daryl Van Vorst
@ 2003-07-22 16:26     ` Max Krasnyansky
  1 sibling, 0 replies; 26+ messages in thread
From: Max Krasnyansky @ 2003-07-22 16:26 UTC (permalink / raw)
  To: Daryl Van Vorst, 'Marcel Holtmann'; +Cc: 'BlueZ Mailing List'

At 09:43 AM 7/11/2003, Daryl Van Vorst wrote:
>Marcel,
>
>You're right that it doesn't check the error code, it just exits. But that
>doesn't explain why it sends 5 frames, waits for 20 seconds, and then sends
>5 more.  Shouldn't send block?
Yes it should. But only for SO_SNDTIMEO, which is set to 30 sec by default.

Max

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [Bluez-devel] Re: Qualification testing - rfcomm
  2003-07-22 16:23   ` Max Krasnyansky
@ 2003-07-22 16:46     ` Marcel Holtmann
  2003-07-22 17:40       ` Max Krasnyansky
  2003-07-22 16:48     ` Daryl Van Vorst
  1 sibling, 1 reply; 26+ messages in thread
From: Marcel Holtmann @ 2003-07-22 16:46 UTC (permalink / raw)
  To: Max Krasnyansky; +Cc: Daryl Van Vorst, BlueZ Mailing List

Hi Max,

> > > TP/RFC/BV-12-C:
> > > "Verify that the IUT handles aggregate flow control correctly when the
> > > Tester, acting as a device conforming to Bleutooth version 1.0B, controls
> > > the data flow using the Flow Control on/off commands FCon and FCoff. The
> > > IUT's device role is of no importance."
> > > 
> > > The command and console output:
> > > 
> > > root@jack-00000000:~>./rctest -s -P 1 -b 20 00:A0:96:1F:83:71
> > > rctest[362]: Connected
> > > rctest[362]: Sending ...
> > > rfcomm_recv_mcc: Unknown control type 0x18
> > > rfcomm_recv_mcc: Unknown control type 0x28
> > > 
> > > The IUT does not respond to FCoff with FCoff, and continues sending data. It
> > > also does not respond to FCon with FCon. 
> > 
> > we don't have support for flow control on the entire RFCOMM session. But
> > it seems that the FCOFF and FCON should be supported. The attached patch
> > implements support for it, but I am not quite sure if it is the right
> > way to do this.
> Is it mandatory ? I always thought it's optional.

and I stopped asking this questions ;)

> > @@ -1533,6 +1591,9 @@
> >  	struct list_head *p, *n;
> > 
> >  	BT_DBG("session %p state %ld", s, s->state);
> > +
> > +	if (test_bit(RFCOMM_TX_THROTTLED, &s->flags))
> > +		return;
> > 
> >  	list_for_each_safe(p, n, &s->dlcs) {
> >  		d = list_entry(p, struct rfcomm_dlc, list);
> This part is not ok. We still have to check for timeout. Rest of patch is fine.

good point.

diff -urN linux-2.4.22-pre7/net/bluetooth/rfcomm/core.c linux-2.4.22-pre7-mh/net/bluetooth/rfcomm/core.c
--- linux-2.4.22-pre7/net/bluetooth/rfcomm/core.c       Tue Jul 22 18:33:43 2003
+++ linux-2.4.22-pre7-mh/net/bluetooth/rfcomm/core.c    Tue Jul 22 18:37:59 2003
@@ -1540,6 +1598,9 @@
                        __rfcomm_dlc_close(d, ETIMEDOUT);
                        continue;
                }
+
+               if (test_bit(RFCOMM_TX_THROTTLED, &s->flags))
+                       continue;
 
                if ((d->state == BT_CONNECTED || d->state == BT_DISCONN) &&
                                d->mscex == RFCOMM_MSCEX_OK)

I think that should do the job. If you agree I will push this change.

Regards

Marcel




-------------------------------------------------------
This SF.net email is sponsored by: VM Ware
With VMware you can run multiple operating systems on a single machine.
WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the
same time. Free trial click here: http://www.vmware.com/wl/offer/345/0
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

^ permalink raw reply	[flat|nested] 26+ messages in thread

* RE: [Bluez-devel] Re: Qualification testing - rfcomm
  2003-07-22 16:23   ` Max Krasnyansky
  2003-07-22 16:46     ` Marcel Holtmann
@ 2003-07-22 16:48     ` Daryl Van Vorst
  2003-07-22 16:53       ` Marcel Holtmann
  1 sibling, 1 reply; 26+ messages in thread
From: Daryl Van Vorst @ 2003-07-22 16:48 UTC (permalink / raw)
  To: 'Max Krasnyansky', 'Marcel Holtmann'
  Cc: 'BlueZ Mailing List'

> On Fri, 2003-07-11 at 01:18, Marcel Holtmann wrote:
> > Hi Daryl,
> > 
> > > TP/RFC/BV-12-C:
> > > "Verify that the IUT handles aggregate flow control 
> correctly when 
> > > the Tester, acting as a device conforming to Bleutooth 
> version 1.0B, 
> > > controls the data flow using the Flow Control on/off 
> commands FCon 
> > > and FCoff. The IUT's device role is of no importance."
> > > 
> > > The command and console output:
> > > 
> > > root@jack-00000000:~>./rctest -s -P 1 -b 20 00:A0:96:1F:83:71
> > > rctest[362]: Connected
> > > rctest[362]: Sending ...
> > > rfcomm_recv_mcc: Unknown control type 0x18
> > > rfcomm_recv_mcc: Unknown control type 0x28
> > > 
> > > The IUT does not respond to FCoff with FCoff, and 
> continues sending 
> > > data. It also does not respond to FCon with FCon.
> > 
> > we don't have support for flow control on the entire RFCOMM 
> session. 
> > But it seems that the FCOFF and FCON should be supported. 
> The attached 
> > patch implements support for it, but I am not quite sure if 
> it is the 
> > right way to do this.
> Is it mandatory ? I always thought it's optional.

I asked the same question. Yes, apparently it is mandatory.

> 
> > @@ -1533,6 +1591,9 @@
> >  	struct list_head *p, *n;
> > 
> >  	BT_DBG("session %p state %ld", s, s->state);
> > +
> > +	if (test_bit(RFCOMM_TX_THROTTLED, &s->flags))
> > +		return;
> > 
> >  	list_for_each_safe(p, n, &s->dlcs) {
> >  		d = list_entry(p, struct rfcomm_dlc, list);
> This part is not ok. We still have to check for timeout. Rest 
> of patch is fine.
> 
> Max 

Ok. I'll see if it's not too late to stop testing it. :)

-Daryl.

^ permalink raw reply	[flat|nested] 26+ messages in thread

* RE: [Bluez-devel] Re: Qualification testing - rfcomm
  2003-07-22 16:48     ` Daryl Van Vorst
@ 2003-07-22 16:53       ` Marcel Holtmann
  2003-07-22 17:01         ` Daryl Van Vorst
  0 siblings, 1 reply; 26+ messages in thread
From: Marcel Holtmann @ 2003-07-22 16:53 UTC (permalink / raw)
  To: Daryl Van Vorst; +Cc: 'Max Krasnyansky', 'BlueZ Mailing List'

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

Hi Daryl,

> > > @@ -1533,6 +1591,9 @@
> > >  	struct list_head *p, *n;
> > > 
> > >  	BT_DBG("session %p state %ld", s, s->state);
> > > +
> > > +	if (test_bit(RFCOMM_TX_THROTTLED, &s->flags))
> > > +		return;
> > > 
> > >  	list_for_each_safe(p, n, &s->dlcs) {
> > >  		d = list_entry(p, struct rfcomm_dlc, list);
> > This part is not ok. We still have to check for timeout. Rest 
> > of patch is fine.
> 
> Ok. I'll see if it's not too late to stop testing it. :)

it should not make any difference for the test case, but here is the
complete version of the new patch.

Regards

Marcel


[-- Attachment #2: patch-fcoff-fcon-2 --]
[-- Type: text/x-patch, Size: 2237 bytes --]

diff -urN linux-2.4.22-pre7/net/bluetooth/rfcomm/core.c linux-2.4.22-pre7-mh/net/bluetooth/rfcomm/core.c
--- linux-2.4.22-pre7/net/bluetooth/rfcomm/core.c	Tue Jul 22 18:33:43 2003
+++ linux-2.4.22-pre7-mh/net/bluetooth/rfcomm/core.c	Tue Jul 22 18:37:59 2003
@@ -853,6 +853,50 @@
 	return rfcomm_send_frame(s, buf, ptr - buf);
 }
 
+static int rfcomm_send_fcoff(struct rfcomm_session *s, int cr)
+{
+	struct rfcomm_hdr *hdr;
+	struct rfcomm_mcc *mcc;
+	u8 buf[16], *ptr = buf;
+
+	BT_DBG("%p cr %d", s, cr);
+
+	hdr = (void *) ptr; ptr += sizeof(*hdr);
+	hdr->addr = __addr(s->initiator, 0);
+	hdr->ctrl = __ctrl(RFCOMM_UIH, 0);
+	hdr->len  = __len8(sizeof(*mcc));
+
+	mcc = (void *) ptr; ptr += sizeof(*mcc);
+	mcc->type = __mcc_type(cr, RFCOMM_FCOFF);
+	mcc->len  = __len8(0);
+
+	*ptr = __fcs(buf); ptr++;
+
+	return rfcomm_send_frame(s, buf, ptr - buf);
+}
+
+static int rfcomm_send_fcon(struct rfcomm_session *s, int cr)
+{
+	struct rfcomm_hdr *hdr;
+	struct rfcomm_mcc *mcc;
+	u8 buf[16], *ptr = buf;
+
+	BT_DBG("%p cr %d", s, cr);
+
+	hdr = (void *) ptr; ptr += sizeof(*hdr);
+	hdr->addr = __addr(s->initiator, 0);
+	hdr->ctrl = __ctrl(RFCOMM_UIH, 0);
+	hdr->len  = __len8(sizeof(*mcc));
+
+	mcc = (void *) ptr; ptr += sizeof(*mcc);
+	mcc->type = __mcc_type(cr, RFCOMM_FCON);
+	mcc->len  = __len8(0);
+
+	*ptr = __fcs(buf); ptr++;
+
+	return rfcomm_send_frame(s, buf, ptr - buf);
+}
+
 static int rfcomm_send_test(struct rfcomm_session *s, int cr, u8 *pattern, int len)
 {
 	struct socket *sock = s->sock;
@@ -1351,6 +1395,20 @@
 		rfcomm_recv_msc(s, cr, skb);
 		break;
 
+	case RFCOMM_FCOFF:
+		if (cr) {
+			set_bit(RFCOMM_TX_THROTTLED, &s->flags);
+			rfcomm_send_fcoff(s, 0);
+		}
+		break;
+
+	case RFCOMM_FCON:
+		if (cr) {
+			clear_bit(RFCOMM_TX_THROTTLED, &s->flags);
+			rfcomm_send_fcon(s, 0);
+		}
+		break;
+
 	case RFCOMM_TEST:
 		if (cr)
 			rfcomm_send_test(s, 0, skb->data, skb->len);
@@ -1540,6 +1598,9 @@
 			__rfcomm_dlc_close(d, ETIMEDOUT);
 			continue;
 		}
+
+		if (test_bit(RFCOMM_TX_THROTTLED, &s->flags))
+			continue;
 
 		if ((d->state == BT_CONNECTED || d->state == BT_DISCONN) &&
 				d->mscex == RFCOMM_MSCEX_OK)

^ permalink raw reply	[flat|nested] 26+ messages in thread

* RE: [Bluez-devel] Re: Qualification testing - rfcomm
  2003-07-22 16:53       ` Marcel Holtmann
@ 2003-07-22 17:01         ` Daryl Van Vorst
  0 siblings, 0 replies; 26+ messages in thread
From: Daryl Van Vorst @ 2003-07-22 17:01 UTC (permalink / raw)
  To: 'Marcel Holtmann'
  Cc: 'Max Krasnyansky', 'BlueZ Mailing List'

Marcel,

> Hi Daryl,
> 
> > > > @@ -1533,6 +1591,9 @@
> > > >  	struct list_head *p, *n;
> > > > 
> > > >  	BT_DBG("session %p state %ld", s, s->state);
> > > > +
> > > > +	if (test_bit(RFCOMM_TX_THROTTLED, &s->flags))
> > > > +		return;
> > > > 
> > > >  	list_for_each_safe(p, n, &s->dlcs) {
> > > >  		d = list_entry(p, struct rfcomm_dlc, list);
> > > This part is not ok. We still have to check for timeout. Rest
> > > of patch is fine.
> > 
> > Ok. I'll see if it's not too late to stop testing it. :)
> 
> it should not make any difference for the test case, but here 
> is the complete version of the new patch.

Great. Thanks.

Turns out they haven't started testing yet. I'll put this in for testing
instead of the old stuff.

-Daryl.

^ permalink raw reply	[flat|nested] 26+ messages in thread

* RE: [Bluez-devel] RE: Qualification testing - rfcomm
  2003-07-18 19:19               ` Daryl Van Vorst
@ 2003-07-22 17:09                 ` Max Krasnyansky
  2003-07-22 18:13                   ` David Woodhouse
  0 siblings, 1 reply; 26+ messages in thread
From: Max Krasnyansky @ 2003-07-22 17:09 UTC (permalink / raw)
  To: Daryl Van Vorst, 'Marcel Holtmann'
  Cc: 'BlueZ Mailing List', David Woodhouse

At 12:19 PM 7/18/2003, Daryl Van Vorst wrote:
>Marcel,
>
>> > Do you mean you tried the aclsession script and didn't see the same 
>> > send 5 frames, wait 20 sec, send 5 more etc problem?
>> 
>> the aclsession scripts produces this effect, but it also left 
>> the ACL link in some kind of buggy state. It must be some 
>> really stupid that I always overlook. The code looks correct 
>> to me and my Bluetooth 1.0b devices are working fine.
>
>Ok...  I guess we can leave it for now then. If it becomes a more serious
>issue I'll let you know.
Ok. I know what's the problem is. Basically what happens is that we fill up socket 
tx buffer before MSC exchange completes (aclsession script does wait 10) and app goes to 
sleep in sendmsg(). Then we receive MSC and send 5 frames from tx buffer (we only 
send 5 frames at a time when credit flow ctl is not enabled). App is still sleeping 
at this point because sock_def_write_space() will not wakeup the process unless there
is a lot of room in the tx buffer. Eventually (after 30 secs) sendmsg() times out but
it doesn't return an error because it did manage to send a little bit. So the app will 
call sendmsg() again and send some more data, which will trigger tx queue processing 
and we will send 5 more frames, app goes to sleep again because buffer is still full 
and the cycle repeats. 
So it's should be obvious where the bug is :), it is in rfcomm_process_tx(). It's supposed
to reschedule DLC after it sends 5 packets. The reason it works for real world apps is 
because there is always some activity on the link which kicks tx processing.

Also the problem was somewhat hard to trigger before this patch from David went in
> >+++ core.c      Thu Apr  3 14:05:20 2003
> >@@ -1430,7 +1430,7 @@
> >        } else {
> >                /* CFC disabled.
> >                 * Give ourselves some credits */
> >-               d->tx_credits = RFCOMM_MAX_CREDITS;
> >+               d->tx_credits = 5;
> >        }
> >  
> >        if (test_bit(RFCOMM_TX_THROTTLED, &d->flags))

ie We used to send more frames and therefor managed free more tx buffer space and wake up application.

The fix is simple we just need to reschedule DLC when credit based flow control is not enabled. But I'm
not sure how often we need to do that. If we do it too often we'll essentially restore old behavior, too
seldom and performance will suffer. David, any suggestion ?

Max

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [Bluez-devel] Re: Qualification testing - rfcomm
  2003-07-22 16:46     ` Marcel Holtmann
@ 2003-07-22 17:40       ` Max Krasnyansky
  2003-07-22 19:13         ` Marcel Holtmann
  0 siblings, 1 reply; 26+ messages in thread
From: Max Krasnyansky @ 2003-07-22 17:40 UTC (permalink / raw)
  To: Marcel Holtmann; +Cc: Daryl Van Vorst, BlueZ Mailing List

At 09:46 AM 7/22/2003, Marcel Holtmann wrote:
>> > @@ -1533,6 +1591,9 @@
>> >     struct list_head *p, *n;
>> > 
>> >     BT_DBG("session %p state %ld", s, s->state);
>> > +
>> > +   if (test_bit(RFCOMM_TX_THROTTLED, &s->flags))
>> > +           return;
>> > 
>> >     list_for_each_safe(p, n, &s->dlcs) {
>> >             d = list_entry(p, struct rfcomm_dlc, list);
>> This part is not ok. We still have to check for timeout. Rest of patch is fine.
>
>good point.
>
>diff -urN linux-2.4.22-pre7/net/bluetooth/rfcomm/core.c linux-2.4.22-pre7-mh/net/bluetooth/rfcomm/core.c
>--- linux-2.4.22-pre7/net/bluetooth/rfcomm/core.c       Tue Jul 22 18:33:43 2003
>+++ linux-2.4.22-pre7-mh/net/bluetooth/rfcomm/core.c    Tue Jul 22 18:37:59 2003
>@@ -1540,6 +1598,9 @@
>                        __rfcomm_dlc_close(d, ETIMEDOUT);
>                        continue;
>                }
>+
>+               if (test_bit(RFCOMM_TX_THROTTLED, &s->flags))
>+                       continue;
> 
>                if ((d->state == BT_CONNECTED || d->state == BT_DISCONN) &&
>                                d->mscex == RFCOMM_MSCEX_OK)
>
>I think that should do the job. If you agree I will push this change.

Yep. This one is ok.

Max

^ permalink raw reply	[flat|nested] 26+ messages in thread

* RE: [Bluez-devel] RE: Qualification testing - rfcomm
  2003-07-22 17:09                 ` Max Krasnyansky
@ 2003-07-22 18:13                   ` David Woodhouse
  2003-07-22 19:43                     ` Max Krasnyansky
  0 siblings, 1 reply; 26+ messages in thread
From: David Woodhouse @ 2003-07-22 18:13 UTC (permalink / raw)
  To: Max Krasnyansky
  Cc: Daryl Van Vorst, 'Marcel Holtmann', 'BlueZ Mailing List'

On Tue, 2003-07-22 at 13:09, Max Krasnyansky wrote:

> Ok. I know what's the problem is. Basically what happens is that we fill up socket 
> tx buffer before MSC exchange completes (aclsession script does wait 10) and app goes to 
> sleep in sendmsg(). Then we receive MSC and send 5 frames from tx buffer (we only 
> send 5 frames at a time when credit flow ctl is not enabled). App is still sleeping 
> at this point because sock_def_write_space() will not wakeup the process unless there
> is a lot of room in the tx buffer. 

I think this is your problem. You should wake the writer as soon as
there's any space in the buffer for it to write. If you want to throttle
tx over the wire, do it by other means, not by letting the writers sleep
indefinitely. 

> The fix is simple we just need to reschedule DLC when credit based flow control is not enabled. But I'm
> not sure how often we need to do that. 

Why only when flow control is disabled? Surely we have the same problem
in the case where flow control is enabled too? You want to keep your
buffers full (but not too _large_ for latency reasons) or you might as
well not have them, surely?

> If we do it too often we'll essentially restore old behavior, too
> seldom and performance will suffer. David, any suggestion ?

The old behaviour which I fix wouldn't be restored by waking on dequeue,
surely? What I did was limit the tx buffers, and that would still have
the desired effect.

-- 
dwmw2

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: [Bluez-devel] Re: Qualification testing - rfcomm
  2003-07-22 17:40       ` Max Krasnyansky
@ 2003-07-22 19:13         ` Marcel Holtmann
  0 siblings, 0 replies; 26+ messages in thread
From: Marcel Holtmann @ 2003-07-22 19:13 UTC (permalink / raw)
  To: Max Krasnyansky; +Cc: Daryl Van Vorst, BlueZ Mailing List

Hi Max,

> >diff -urN linux-2.4.22-pre7/net/bluetooth/rfcomm/core.c linux-2.4.22-pre7-mh/net/bluetooth/rfcomm/core.c
> >--- linux-2.4.22-pre7/net/bluetooth/rfcomm/core.c       Tue Jul 22 18:33:43 2003
> >+++ linux-2.4.22-pre7-mh/net/bluetooth/rfcomm/core.c    Tue Jul 22 18:37:59 2003
> >@@ -1540,6 +1598,9 @@
> >                        __rfcomm_dlc_close(d, ETIMEDOUT);
> >                        continue;
> >                }
> >+
> >+               if (test_bit(RFCOMM_TX_THROTTLED, &s->flags))
> >+                       continue;
> > 
> >                if ((d->state == BT_CONNECTED || d->state == BT_DISCONN) &&
> >                                d->mscex == RFCOMM_MSCEX_OK)
> >
> >I think that should do the job. If you agree I will push this change.
> 
> Yep. This one is ok.

you can pull it for 2.4 and 2.5

 net/bluetooth/rfcomm/core.c |   61 ++++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 61 insertions(+)

through these ChangeSets:

<marcel@holtmann.org> (03/07/22 1.1083)
   [Bluetooth] Add support for FCon and FCoff flow control commands
   
   This patch adds flow control support using FCon and FCoff commands
   to fulfil the requirements of the Bluetooth specification.





-------------------------------------------------------
This SF.net email is sponsored by: VM Ware
With VMware you can run multiple operating systems on a single machine.
WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the
same time. Free trial click here: http://www.vmware.com/wl/offer/345/0
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

^ permalink raw reply	[flat|nested] 26+ messages in thread

* RE: [Bluez-devel] RE: Qualification testing - rfcomm
  2003-07-22 18:13                   ` David Woodhouse
@ 2003-07-22 19:43                     ` Max Krasnyansky
  0 siblings, 0 replies; 26+ messages in thread
From: Max Krasnyansky @ 2003-07-22 19:43 UTC (permalink / raw)
  To: David Woodhouse
  Cc: Daryl Van Vorst, 'Marcel Holtmann', 'BlueZ Mailing List'

At 11:13 AM 7/22/2003, David Woodhouse wrote:
>On Tue, 2003-07-22 at 13:09, Max Krasnyansky wrote:
>
>> Ok. I know what's the problem is. Basically what happens is that we fill up socket 
>> tx buffer before MSC exchange completes (aclsession script does wait 10) and app goes to 
>> sleep in sendmsg(). Then we receive MSC and send 5 frames from tx buffer (we only 
>> send 5 frames at a time when credit flow ctl is not enabled). App is still sleeping 
>> at this point because sock_def_write_space() will not wakeup the process unless there
>> is a lot of room in the tx buffer. 
>
>I think this is your problem. You should wake the writer as soon as
>there's any space in the buffer for it to write. If you want to throttle
>tx over the wire, do it by other means, not by letting the writers sleep
>indefinitely. 
May be I didn't explain it clearly. The problem is not in the buffering. It's in the TX processing.
Read below.

>> The fix is simple we just need to reschedule DLC when credit based flow control is not enabled. But I'm
>> not sure how often we need to do that. 
>
>Why only when flow control is disabled? Surely we have the same problem
>in the case where flow control is enabled too? You want to keep your
>buffers full (but not too _large_ for latency reasons) or you might as
>well not have them, surely?
Again buffering is not the problem here.
If credit based flow control (CFC) is enabled rfcomm_process_tx() will use all available credits 
(assuming tx buffer has enough stuff to send) and then wait for more credits. As soon as we get more 
credits we send more frames from tx buffer. 
Now when CFC is disabled we send 5 frames and do not send more until app wakes up again. That is
the problem.

Here is an example. RFCOMM app sends 1KB of data and waits for response.
Lets say MTU of this channel is 100 bytes.
CFC case:
        - They grant us 5 credits
        - We send 5 frames. 
        - They grant us 5 credits
        - We send 5 frames.
        <1KB transfer is complete at this point>

Non-CFC case:
        - We send 5 frames.
        <that's it. we're stuck here>
Waking the app here won't help, it already sent what I had to send.

So what should happen instead is
Non-CFC case:
        - We send 5 frames.
        - We reschedule DLC.
        - We send 5 frames.
        - We reschedule DLC
        <1KB transfer is complete at this point>

See. Buffering is not the problem. The problem is that we have to restart tx processing.
I guess we could solve it by making socket send buffer == MTU * 5. In which case the problem 
is kind of related to buffering. But I don't want to change socket buffering just for non CFC
case.

>> If we do it too often we'll essentially restore old behavior, too
>> seldom and performance will suffer. David, any suggestion ?
>
>The old behaviour which I fix wouldn't be restored by waking on dequeue,
>surely? What I did was limit the tx buffers, and that would still have
>the desired effect.
Now you should see what I was talking about. If we reschedule DLC immediately
after sending 5 frames we'll end up sending too fast (ie exactly the same as before).

btw We're talking about RFCOMM sockets here. But it might affect TTYs as well. 

Max

^ permalink raw reply	[flat|nested] 26+ messages in thread

end of thread, other threads:[~2003-07-22 19:43 UTC | newest]

Thread overview: 26+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-07-08 18:16 Qualification testing - rfcomm Daryl Van Vorst
2003-07-08 21:47 ` [Bluez-devel] " James Courtier-Dutton
2003-07-08 23:23   ` Daryl Van Vorst
2003-07-18 19:35     ` James Courtier-Dutton
2003-07-11  8:18 ` [Bluez-devel] " Marcel Holtmann
2003-07-22 16:23   ` Max Krasnyansky
2003-07-22 16:46     ` Marcel Holtmann
2003-07-22 17:40       ` Max Krasnyansky
2003-07-22 19:13         ` Marcel Holtmann
2003-07-22 16:48     ` Daryl Van Vorst
2003-07-22 16:53       ` Marcel Holtmann
2003-07-22 17:01         ` Daryl Van Vorst
2003-07-11  8:55 ` Marcel Holtmann
2003-07-11 16:43   ` Daryl Van Vorst
2003-07-11 19:05     ` [Bluez-devel] " Daryl Van Vorst
2003-07-18 18:53       ` Daryl Van Vorst
2003-07-18 18:58         ` Marcel Holtmann
2003-07-18 19:07           ` Daryl Van Vorst
2003-07-18 19:12             ` Marcel Holtmann
2003-07-18 19:19               ` Daryl Van Vorst
2003-07-22 17:09                 ` Max Krasnyansky
2003-07-22 18:13                   ` David Woodhouse
2003-07-22 19:43                     ` Max Krasnyansky
2003-07-22 16:26     ` Max Krasnyansky
2003-07-18 19:30 ` [Bluez-devel] " James Courtier-Dutton
2003-07-18 20:25   ` Daryl Van Vorst

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.