Qualification testing - rfcomm

Qualification testing - rfcomm

[Daryl Van Vorst]

[-- 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 --]

Re: [Bluez-devel] Qualification testing - rfcomm

[James Courtier-Dutton]

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

RE: [Bluez-devel] Qualification testing - rfcomm

[Daryl Van Vorst]

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

Re: [Bluez-devel] Qualification testing - rfcomm

[James Courtier-Dutton]

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

[Bluez-devel] Re: Qualification testing - rfcomm

[Marcel Holtmann]

[-- 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);

Re: [Bluez-devel] Re: Qualification testing - rfcomm

[Max Krasnyansky]

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 

Re: [Bluez-devel] Re: Qualification testing - rfcomm

[Marcel Holtmann]

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

Re: [Bluez-devel] Re: Qualification testing - rfcomm

[Max Krasnyansky]

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

Re: [Bluez-devel] Re: Qualification testing - rfcomm

[Marcel Holtmann]

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

RE: [Bluez-devel] Re: Qualification testing - rfcomm

[Daryl Van Vorst]

> 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.

RE: [Bluez-devel] Re: Qualification testing - rfcomm

[Marcel Holtmann]

[-- 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)

RE: [Bluez-devel] Re: Qualification testing - rfcomm

[Daryl Van Vorst]

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.

[Bluez-devel] Re: Qualification testing - rfcomm

[Marcel Holtmann]

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

RE: Qualification testing - rfcomm

[Daryl Van Vorst]

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
> 
> 
> 

RE: [Bluez-devel] RE: Qualification testing - rfcomm

[Daryl Van Vorst]

[-- 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 --]

RE: [Bluez-devel] RE: Qualification testing - rfcomm

[Daryl Van Vorst]

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
> > 
> 

RE: [Bluez-devel] RE: Qualification testing - rfcomm

[Marcel Holtmann]

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

RE: [Bluez-devel] RE: Qualification testing - rfcomm

[Daryl Van Vorst]

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.

RE: [Bluez-devel] RE: Qualification testing - rfcomm

[Marcel Holtmann]

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

RE: [Bluez-devel] RE: Qualification testing - rfcomm

[Daryl Van Vorst]

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.

RE: [Bluez-devel] RE: Qualification testing - rfcomm

[Max Krasnyansky]

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

RE: [Bluez-devel] RE: Qualification testing - rfcomm

[David Woodhouse]

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

RE: [Bluez-devel] RE: Qualification testing - rfcomm

[Max Krasnyansky]

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

Re: [Bluez-devel] RE: Qualification testing - rfcomm

[Max Krasnyansky]

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

Re: [Bluez-devel] Qualification testing - rfcomm

[James Courtier-Dutton]

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

RE: [Bluez-devel] Qualification testing - rfcomm

[Daryl Van Vorst]

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.