On Friday 24 Jun 2011 16:14:12 Alan wrote:
> On Thursday 23 Jun 2011 20:52:45 Alan wrote:
> > On Saturday 21 May 2011 03:36:47 James Steele wrote:
> > > Hi,
> > >
> > > On 19 May 2011 08:43, Alan <alanbluetooth@xxxxxxxxxxx> wrote:
> > > > Status my problems are solved for now...
> > >
> > > Great! I always like it when that happens.
> > >
> > > > From here on down the turtles appear to be all mine. Weeee....
> >
> > There just had to be a splat.
What shame it was a public one.
Me a culpa:
Rule 0: never ever underestimate your own ability to bork up multithreaded IO
code.
Rule 1: Always assume you just broke rule 0:
My problem went away a bit in that I found my code deadlocks for
some reason more specific than I am an idiot.
===========
This however flow control issue still haunts me, but is not an immediate
roadblock but i want it gone. aka
still help please.
> > I may or may not need or want to implement, a credit based flow control
> > RFComm connection.
but I want to emulate the windows code as best I can....
As previously reported,
The protocol I am emulating only sends credit based flow control one way
Windows->Device my current unix emulation of that doesnt.
Is one way RFCOMM credit based flow control bytes reasonable? possible or
borked?
Are these the packets negotiating this on my emulated connection with the
result of no flow control bytes either way?
Linux to device
27 0.667880 RFCOMM Sent UIH DLCI=0 MPX_CTRL DLC parameter
negotiation (PN) Parameter Negotiation
E/A =1 C/R=1 DLCI 0
PF Flag 0
The actual hex.
0000 02 2a 20 12 00 0e 00 90 00 03 ef 15 83 11 02 f0 .* ..... ........
0010 07 00 70 00 00 07 70 ..p...p
Near as I can tell
(excerpt from an implementation of a kernel)
pn->flow_ctrl = cr ? 0xf0 : 0xe0;
implies cr==true is flagged by f0
So my linux stack offered flow control but as shown below there is not flow
control? How come?
Device to Linux
29 0.684828 RFCOMM Rcvd UIH DLCI=0 MPX_CTRL DLC parameter
negotiation (PN) Parameter Negotiation
E/A = 1 C/R = 0 DLCI = 0
The actual hex.
0000 02 2a 20 12 00 0e 00 40 00 01 ef 15 81 11 02 e0 .* ....@ ........
0010 07 00 70 00 00 03 aa ..p....
0xe0 => The device refused ? or did the device say no I dont want flow control
the other way?
and hence is the bluez stack is now supposed to(but doesnt?) send credits and
the device not send them? or is my observed windows behaviour where credits
only go one way borked ?
============ Two example, (first two), RFCOMM payload packets
AFAIK, there is no flow control bytes.... Why not?
T=3 sec, heartbeat From Device to Linux. aka "Hello"
0000 02 2a 20 27 00 23 00 40 00 09 ef 3f 7e 1f 00 61 .* '.#.@ ...?~..a
0010 24 ac 18 25 80 00 00 00 00 00 00 00 02 00 00 04 $..%.... ........
0020 70 00 01 00 00 00 00 01 00 00 00 40 p....... ...@
Linux to Device.
0000 02 2a 20 1f 00 1b 00 90 00 0b ef 2f 7e 17 00 69 .* ..... .../~..i
0010 00 00 00 00 00 00 01 00 00 00 00 00 01 02 76 65 ........ ......ve
0020 72 0d 0a 9a r...
means boom. aka "ver". lets start again.
"hertbeats" stop now that we said boom.
... what comes after here I have now mainly decoded...
blah ... blah...
Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
