Does any one recognise this protocol? is it RF_COMM

Does any one recognise this protocol? is it RF_COMM

[Alan]

I am trying to write an OS driver for some propeitary hardware.
I have hit brick wall and need to go back and check what I know so far and 
turn over the rocks on the bits I hoped I could ignore. 


I am wondering if I made faulty guess early on.  hence this question.



What protocol is this?   Can it be RF_COMM ?

below is an edited extract of SnoppyPro logs from the windows software talking 
to the real physical device.

My question is what protocol are all the wrappers.
 I beleieve I identified HCI-ACL / L2CAp/ UNK / Proprietary.

The Unk one is probably something standard. As I can feed the proprietary part 
into an RF_COMM socket under linux and the device responds as if I am the 
windows machine. I thook that to mean Windows was talking RF_COMM.

Howver when I have unix software pretend  be the device and listen( ) the 
accept( ) never returns if it is the winodw software talking to me, but does 
when it is my linux software talking to my enulated on linux device.
I can post full hcidump of the failure to connect if you indicate what 
settings are intelligible to you, Im finding raw the most informative  as i 
can compare it to Snopypro logs....  
But expect people who knows things would understand the gobbledegooked
output modes better. 

The snoopy pro logs are at the USB level(?), and contain one extra (internal) 
layer of protocol data I do not undertsand. I think it is RF_COMM

Typical packets
Physical devices packet sent to Windows
113     in      up      0x82    28.093  28.093  00
TransferBuffer: 0x0000002b (43) length
pre  0000: 2b 20 27 00    23 00 41 00    09 ef 3f 
wrap 0000: 7e[1f 00](61)  24:ac:18:25:80:00 => 00:00:00:00:00:00
cmnd 0000: 02 00 00 04  70 00 01 00  00 00 00 01  00 00 00 40

Windows PC Packet sent to Device
122     out     down    0x02    28.140  28.140  00
TransferBuffer: 0x00000024 (36) length
pre  0000: 2b 20 20 00    1c 00 8c 00    0b ff 2f 00    
wrap 0000: 7e[17 00](69)  00:00:00:00:00:00 => 01:00:00:00:00:00
cmnd 0000: 01 02 76 65  72 0d 0a 86  

wrap and cmnd lines are the Device specific protocol burried in what look like 
lower layers. My LinuxSoftware emulates the Windows software by injecting the 
packets starting at 7E up the second last byte, into an RF_COMM socket.

What I think I know
Im pretty sure the   2b 20 20 00  is
Protocol: “Core_V4.0.pdf” Figure 5.2: HCI ACL Data Packet   p429
and 1c 00 8c 00
is L2CAP  [size and channel ID].

Does anyone recognise a protocol runnign on L2CAP that looks like this

09 ef 3f       Data        40   for inbound packets and
0b ff 2f 00    Data       86  for outbound packets

Here are the same packets dumped RAW for Linux Software talking
physical devices.  
(I cant get packets for windw softwware talking emulated device as the conect 
fails. Thats the problem)

Note there are binary differences in both the L2CAP and RFCOMM parts.
Most worrying to me is the missing 0.
> 02 2B 20 27 00 23 00 40 00 09 EF 3F 7E 1F 00 61 24 AC 18 25 
  80 00 00 00 00 00 00 00 02 00 00 04 70 00 01 00 00 00 00 01 
  00 00 00 40 
Linux RFComm packet.
< 02 2B 20 1F 00 1B 00 4D 00 0B EF 2F 7E 17 00 69 00 00 00 00 
  00 00 01 00 00 00 00 00 01 02 76 65 72 0D 0A 9A 

Any idea why the differences or where there is a reasonable document on what 
those RF_COMM bytes mean.
Im probably goign to have to go deep enough to understand the connect process.


          Alan

Re: Does any one recognise this protocol? is it RF_COMM

[James Steele]

On 17 May 2011 12:45, Alan <alanbluetooth@aiaware.com> wrote:
>
> What protocol is this?   Can it be RF_COMM ?

It looks like it is RFCOMM yes (at least it looks sane from my mental parser).

> Im pretty sure the   2b 20 20 00  is
> Protocol: “Core_V4.0.pdf” Figure 5.2: HCI ACL Data Packet   p429
> and 1c 00 8c 00
> is L2CAP  [size and channel ID].

Yes

> Does anyone recognise a protocol runnign on L2CAP that looks like this
>
> 09 ef 3f       Data        40   for inbound packets and
> 0b ff 2f 00    Data       86  for outbound packets

Yes - it's RFCOMM

> Note there are binary differences in both the L2CAP and RFCOMM parts.
> Most worrying to me is the missing 0.

I assume you mean the "extra" 00 in the "outbound packet" you
mentioned above?  If so then don't worry, that is the "credits" field
when RFCOMM is operating with credit based flow control - it's present
when the poll bit (0x10) is set in the control field for a UIH
(control field = 0xef).

> Any idea why the differences or where there is a reasonable document on what
> those RF_COMM bytes mean.

The RFCOMM specification gives a basic introduction, but the headers
can be quite gnarly since they are quite "packed" and there are quite
a few extension bits (with their frame structure changing properties.)
 The RFCOMM specification does have the simple frame structure
overview for the regular frames (Figure 5.1) and credit based flow
control frames (Figure 6.1) though .
Otherwise TS 07.10 - you can find it on 3GPP.

James

Re: Does any one recognise this protocol? is it RF_COMM

[Alan]

Status my problems are solved for now...
>From here on down the turtles appear to be all mine. Weeee.... 

On Wednesday 18 May 2011 03:30:53 you wrote:
> On 17 May 2011 12:45, Alan <alanbluetooth@aiaware.com> wrote:
> > What protocol is this?   Can it be RF_COMM ?
> 
> It looks like it is RFCOMM yes (at least it looks sane from my mental
> parser).
> 
> > Im pretty sure the   2b 20 20 00  is is L2CAP  [size and channel ID].
> Yes
> 
> > Does anyone recognise a protocol runnign on L2CAP that looks like this
> Yes - it's RFCOMM

You got no idea how good it is to be sure of at least one or two things.
Those few bytes were always a gulf between what I was coding against and the 
last thing I new for sure. I had a fundamental problem with attempting to 
interperet any protocol when a few of the preceding bytes meant? and changed 
from time to time. 

Armed with that certainty I have determiend that my actual sticking point
was that the connect sequence from windows was examining via SDP what servies 
were offered and that I had to emulate to some degree the proprietary service 
as advertised.... I guessed and tried a plain old serial service, which was 
superficially similar to thers and it works fine (so far).  

Im beginning to like my physical device manufacturer more and more as so far 
I've not run into anything that was seemingly utterly borked as was situatiion 
normal at the last telco I worked for, and in the OS that shall not be named.
Even this SDP requirement appears to only test "does it advertsie the protocol 
I want to talk?" (yeah Im new to bt Id never seen an advertisement or sdptool 
browse) (it took me awhile to find "hciconfig hci0 class" as well.)



> I assume you mean the "extra" 00 in the "outbound packet" you
> mentioned above?  
yes extra in the windows packet which is what Im trying to emulate so its 
missing in my packets when I try to send the same data from linux.
 (sorry if my befuddlement was leaking)
> If so then don't worry, that is the "credits" field
> when RFCOMM is operating with credit based flow control - it's present
> when the poll bit (0x10) is set in the control field for a UIH
> (control field = 0xef).
Now that sounds gnarly.

Ta. I will check that out. 
A quick google (now that i have the right keywords) seemed to say that "credit 
based flow control" is negotiated. Ive looked at  the HCI dump of that connect 
negotiation.  ouch. gnarly in hex. In my observation the extra byte is only 
sent one way which seems odd but then again the data coming back from the 
device is much larger than the questions. The device appears to never sends 
any "credits" field back to the windows software.

Its either credits or weird ignored extra leading bytes in the proprietary 
protocol. I have tested and I can stuff extra bytes into the front of the 
packets (before 7E) that I send to the Physical device. It appears to ignore 
them up to the leading 7E. Its plausible that older versions of the device 
used an extra byte to route packets to internal susbsystems, ... but Im 
guessing pretty hard here.

If I really am about to today get my (facade based) emulation of the device 
going I can test and be certain which it is, as I will either get the zeros 
delivered by RFCOMM as data or they will be eaten as part of the header.
 
> The RFCOMM specification gives a basic introduction, but the headers
> can be quite gnarly since they are quite "packed"
I've worked with snmp, SS7 signalling protocol and worse..., the RFCOMM 
packing isnt tooo gnarly, but I admit storing an extension flag in the lsb and 
length*2 in the higher bits tricked me for bit. Im sure it makes sense in a 
circuit. I had stared at those 3 bytes for ages looking a length and missed it 
entirely.

> overview for the regular frames (Figure 5.1) and credit based flow
> control frames (Figure 6.1) though 
More good key words for google. Yummy.
> Otherwise TS 07.10 - you can find it on 3GPP.

	Alan