Re: [Bluez-devel] Qualification Testing

Hi Max,

quoted

quoted

quoted

quoted

        5.) Once an RFCOMM channel is established, the IUT must exchange
MSC's (modem status commands) before sending data. That is, it must send an
MSC, wait for a response, wait for the sender's MSC, and respond to it
before sending data. Our device sent an MSC and then immediately started
sending data when we used rctest. This applies to many test cases.

We send the MSC after the UA. But we also go into BT_CONNECTED state and
in this state you can also start sending data. We should maybe go from
BT_CONNECT -> BT_CONFIG and only switch to BT_CONNECTED after the
successful exchange of MSC.

I remember thinking about that. But they way I interpreted spec was that we
don't have to wait for MSC response. 
This should be easy to fix.

I leave this up to you to fix.

quoted

btw When CFC is not enabled we will have to wait for MSC from the other side. Notice that we set
THROTTLED flag in that case. Which is cleared by the MSC or more credits.
So I guess we can just always set that flag and clear it when we get MSC which will fix the MSC 
test case without messing with the state machine.

Sounds reasonable to me.

Ok. I've fixed that (and pushed changes to BK). My idea about 
with TX_THROTTLED flag didn't work. Well, it worked but only in 
one direction :). Changing state machine would've been fairly big
change and could've affected compatibility.
So I added a simple logic to track MSC exchange state. Works beautifully

I like to see this logic in the state machine, but I agree with with you
that it is not the right time for changing it. Your patch works also
fine for me and I have a new 2.4.20 with all patches up and running.

Daryl, so it is now up to you to do your tests with Cetecom again and
see what we pass and what we fail. The RFCOMM layer should now perform
perfect, but the L2CAP config stuff will still fail. You can use
2.4.18-mh4 and apply these 5 patches from the bt-2.4 repository to it:

ChangeSet@1.1162, 2003-05-09 21:11:49-07:00
  [Bluetooth] RFCOMM must wait for MSC exchange to complete before sending the data.

ChangeSet@1.1161, 2003-05-09 16:41:45-07:00
  [Bluetooth] Detect and log error condition when first L2CAP fragment is too long.

ChangeSet@1.1160, 2003-05-09 11:55:22-07:00
  [Bluetooth] L2CAP config req/rsp handling fixes. 

ChangeSet@1.1126.3.2, 2003-05-09 03:22:06+02:00
  [Bluetooth] Handle priority bits in parameter negotiation

ChangeSet@1.1126.3.1, 2003-05-09 02:07:07+02:00
  [Bluetooth] Send the correct values in RPN response

Max, please go ahead and forward them to Marcelo and Linus. If you have
some extra time, please update my repositories with the new stuff.

I will make some new -mh patches on monday or tuesday.

Regards

Marcel




-------------------------------------------------------
Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
The only event dedicated to issues related to Linux enterprise solutions
www.enterpriselinuxforum.com

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