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.
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
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:
<[email protected]> (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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
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
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
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
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.
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
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
> 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.
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
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
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.
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
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.
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
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: [email protected]
> [mailto:[email protected]] 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: [email protected]
> > [mailto:[email protected]] 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:[email protected]]
> > > 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.
> > http://www.parasoft.com/bulletproofapps1
> > _______________________________________________
> > Bluez-devel mailing list
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/b> luez-devel
> >
>
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: [email protected]
> [mailto:[email protected]] 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:[email protected]]
> > 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.
> http://www.parasoft.com/bulletproofapps1
> _______________________________________________
> Bluez-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/b> luez-devel
>
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:[email protected]]
> 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
>
>
>
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.
http://www.parasoft.com/bulletproofapps1
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
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