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.
>
> I may or may not need or want to implement, a credit based flow control
> RFComm connection. I had hoped the easiest way was to try it and see if
> that fixed the problem.
>
>
> I've hunted through the bluez Source and I cant see how I might use
>
> flow control on an RF_COMM socket.? (in c)
Ok assuming thats a stupid question because (I think) under later standards
(1.1?) the flow is always on if it can be negotiated. Thus its not matter of
how I turn it on because it was by default and the other end must have ....?
I appear to have a nasty problem.
When the proprietary windows code opens an "RFcomm socket" is sends a credits
based flow a control byte. When my unix code opens a vanilla RFCOMM socket to
the device it does not. Note only the packets going one way (windows->device)
have the flow control byte. Is that normal? permissable? a standard windows
FUBAR of RFComm?
I now have observed behaviour exceedingly consistent with the device blocking
halfway through sending me a sequence of proprietary packet fagments. The
question cant be the problem as I only get half an answer. Its still
conceivable my codes too slow and they missing fragments got got dropped, but
i dont think so as there several bazzilion fragments to go when the packets
just stop.
If theres any confusion because RFCOM or somethings a stream. My proprietary
protcol constains size fields etc in its payload and treats it as discrete
packets.
I have wireshark etal, I eat hex, bit fields encodings, etal, for breakfast.
Any advice on which packets are the negotiation of credit based flow control
so I can inspect whats happening and work it out for myself?
Currently I feel like Im trying reverse Engineer RFCOMM.
Alan
(feel free to answer the question you think I should have asked instead.)
--
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
