【转】FTS抓包看蓝牙的SDP整个过程

原文网址：http://blog.sina.com.cn/s/blog_69b5d2a50101f23c.html

1.概述

SDP是蓝牙的Service Discovery Protocol，用来发现远程设备能够提供的Service。它只负责发现对方支持的Service，不负责Service的具体实现。

2.背景概念

SDP中的每一个Service用ServiceRecord来表示（具有唯一的32bit的Handle)，每一个ServiceRecord由若干ServiceAttribute组成，ServiceAttribute由Attribute ID和Attribute Valuel两个部分。

通过SDP request可以访问这些record，以此来获取设备的服务信息。

Data Element是SDP中使用的一种数据结构，如下：


具体的Type和Size Index可以查询Spec p1580和p1581。Data element可以用来表示attribute ID,Attribute range,Attribute value。

每一个Service record至少包含两种attribute：

1.ServiceRecordHandle (Attribute ID = 0x0000)

2.ServiceClassIDList (Attribute ID = 0x0001)

ServiceRecordHandle是一个32位整型，唯一标识某一SDP中的Service record

ServiceClassIDList表示该Service record所属的Service Classes

传输的request/resposne有如下的结构：

3.关于SDP的一些Frame---本地hsot进行request，远端slave进行resposne

首先是本地的Host进行一系列的SDP_ServiceSearchAttributeRequest，远端Slave进行resposne。这个request的说明如下：


ServiceSearchPattern指定了要寻找的Service record

AttributeIDList表明了要寻找的Service record中的某些Attributes

下面我们可以通过一些Frame来具体看看这个request。

Frame91：SDP_ServiceSearchAttributeRequest

00001001 00000000 00010100 00000000 00010100 00000000 01000100 00000000 00000110 00000000 00000000 00000000 00001111 00110101 00000011 00011001 00000001 00000000 00000011 11111000 00110101 00000101 00001010 00000000 00000000 11111111 11111111 00000000

最前面四个字节是HCI层的包装

Connection Handle: 00001001 00000000 = 0x9 = 9

Total Length: 00010100 00000000 = 0x0014 = 20

下面两个字节是L2CAP层的包装

PDU Length: 00010100 00000000 = 0x0014 = 20

Channel ID: 01000100 00000000 = 0x0044

下面是SDP的部分：

PDU ID: 是SDP_ServiceSearchAttributeRequest

Transaction ID: 0x0000

Parameter Length: 0x000f = 15  //这里需要注意的是，SDP是MSB！！！

后面是SDP request的parameter部分

ServiceSearchPattern:这部分是一系列的Data Element，参考Data element解释如下：

00110101：00110 = 6 表示数据部分是Data element sequence  101 = 5表示下面的一个字节表示该Data Element的大小

00000011 = 3表示该Data Element大小为3个字节

00011001（Data element sequence中的第一个Data element）： 00011 = 3 表示是UUID  001 = 1表示2 bytes

00000001 00000000 = 0x0100 表示实际的UUID：查询UUDI值，表示L2CAP

Max Amount of Attribute Data to Return:0x03f8 =  1016

List of Requested Attributes: 这又是一个Data element sequence，分析如下：

00110101： 00110 = 6表示数据部分是Data element sequence 101 = 5表示下面的一个字节表示该Data Element的大小

00000101 = 5表示该Data Element大小为5个字节

00001010: 00001 = 1表示Unsigned Integer 010 = 2表示4 bytes

这样表示的就是一个attribute ID range

00000000 00000000 11111111 11111111：表示的就是从0x0000到0xffff的attribute ID

Bytes for continuation length: 0

注:这个request的目的应该是搜索L2CAP Service的所有Attributes。PS：不知道哪个2B搞的协议，需要弄得这么复杂吗？？

Frame92:SDP_ServiceSearchAttributeResponse 

远端slave的resposne,携带参数如下:

AttributeListsByteCount,

AttributeLists,

ContinuationState

L2CAP显示的PDU的长度是256，数据茫茫。。。还是挑一些重点看看吧。

PDU ID: 00000111 = 0x07 SDP_ServiceSearchAttributeResponse

Transaction ID: 0x0000

Attribute List Byte Count: 246  //PS：靠，attributeLists有这么多字节

AttributeListsByteCount = 00000000 11110110 = 0x00f6 = 246

看一下AttributeLists的开头3个字节:00110110 00000011 00111101

00110110：00110表示是Data element sequence 110 = 6表示下面两个字节表示该Data Element的大小

00000011 00111101 = 0x33d = 829 //这么多字节是必须用到ContinuationState了

随便看几个Attribute吧：

第一个AttributeList：

前三个字节是00110110 00000000 01001110 解析如下（PS:写解析软件的公司真牛逼）：

00110110: 00110表示是Data element sequence 110 = 6表示下面两个字节表示该Data Element的大小

00000000 01001110 = 0x004e = 78  //第一个AttributeList有78个字节

第一个Attribute：00001001 00000000 00000000

00001表示Unsigned Integer 001表示2个字节 （Attribute ID是16位的）

Attribute ID为00000000 00000000，表示ServiceRecordHandle

Attribute value为0x00010000

再看一个Attribute：

00001001 00000000 00000001 00110101 00000110 00011001 00010001 00010010 00011001 00010010 00000011 

00001001:无符号整数，2个字节

00000000 00000001 = 0x01：Attribute ID = 0x01：是ServiceClassIDList属性

00110101 00000110:UUID，6个字节

00011001 00010001 00010010:UUID,2个字节，Attribute value为0x1112

00011001 00010010 00000011:UUID,2个字节,Atribute value为0x1203

其余的attribute不看了，太多了，哪个Sb制定的协议！！

最后的ContinuationState：00000000 11110110 = 0x00f6  //这次response不足以把所有的attribute传回，0x00f6会用在下一次的SDP_ServiceSearchAttributerequest中。如果足以传回所有的attribute，则ContinuationState为1个字节=0.

注：以上是一个SDP_ServiceSearchAttributeRequest和一个SDP_ServiceSearchAttributeResponse。下面又是一组request和resposne。

Frame100：SDP_ServiceSearchAttributeRequest

相比于上一个SDP_ServiceSearchAttributeRequest不同的是，transaction ID为0x0001， Continuation length bytes为0x00f6，是上次的resposne返回的，说明这次的request是要求对方继续发送上次没有发送完的response。

直到frame128才完成所有的response，在这个过程中，远端的slave也开始向本地的Host发送SDP request。

3.远端slave向本地的Host发送requsst，本地的Host进行resposne

Frame110：SDP_ServiceSearchAttributeRequest

远端的slave在Frame110时就已经向本地Host发送SDP request，可以看出，双方的SDP request和resposne是穿插的，并不是一定要等一方完成后另一方才能进行SDP request。

Frame110是关于pnp Information的requset，本地的Host也在Frame121向远端slave发送了这个SDP requset。

4.总结：

SDP用于发现对方能够提供的服务，通信方式为SDP requset和SDP resposne。从抓取的包来看，两端的SDP Service 都会向对方发送SDP requset。需要注意在SDP中是MSB的字节顺序，与L2CAP和HCI不同，另外，需要注意Data Element，每个Attribute的ID和Value都是由它来表示的。

PS：我只想说，制定这种协议的人可以去死了。

时间： 2024-09-29 09:35:50

【转】FTS抓包看蓝牙的SDP整个过程的相关文章

charles抓包看性能数据

1.优化某个接口或加载速度(H5加载速度慢) 抓包看Overview ①看Duration,就是接口的加载时间 ②看Latency,就是延时一端传播到另一端所花费的时间:一般和网络有关:可以综合Duration和Latency看是否是接口慢还是网络慢 ③接口返回数据大小 Response 优化前端显示速度综合考虑: 接口加载时间.前端渲染时间webview加载时间 H5优化:从单独拉取H5渲染接口  到  接口在字段中给出html样式加载 原文地址:https://www.cnblogs.com

WinpCap 使用线程发数，明明发了，返回值0是OK的啊，怎么抓包看不到，难道不支持多线程。。。

if (!m_adapterHandle){    return false;}int rst = pcap_sendpacket((pcap_t*)m_adapterHandle,data ,dataLen);if(rst != 0){    return true;}return false; 看我标黑的就知道了吧,datalen如果为0,发不出去. 而且data如果内容全为'\0',那么也会被屏蔽掉. 这一点官方文档并没有确切的描述,请注意(当然,正常情况下你的报文应该有protocol

tcpdump 抓包 通过 Wireshark分析抓包文件

1. tcpdump的基本原理 1.1  tcpdump starce 的区别 在本机中的进程的系统行为调用跟踪,starce   是一个很好的工具:但是在网络问题的调试中,tcpdump 应该是一个必不可少的工具:能清晰分析网络通信的信息. 默认情况下,tcpdump 不会抓取本机内部通讯的报文   :根据网络协议栈的规定,对于报文,即使是目的地是本机(自己和自己通信),也需要经过本机的网络协议层,所以本机通讯肯定是通过API进入内核,并且完成路由选择.[比如本机的TCP通信,也必须要sock

Chaeles抓包工具

一.工具概述 Charles是跨平台的,windows或者Mac下都可以运行Fiddler支持windows 二.工具用途 1.看发出去的请求 在没有接口文档的情况下,可以通过抓包来看到请求类型.参数等信息. 2.定位问题 通过抓包分析是Server端的问题,还是客户端的问题 例如点击页面按钮没有反应,可以抓包看有没有响应 https的网站抓包后看到的是乱码,有加密 举两个简单的例子   (1) 抓包查看账号密码是不是明文 在Request的test中可以看到账号密码,这样对于网站用户来说是不安

【转】蓝牙ble app开发(三) －－ 抓包

原文网址:http://blog.csdn.net/lckj686/article/details/43156617 关于android 蓝牙app开发抓包的重要性在 android 蓝牙ble app开发(二) -- 关键概念,连接参数,连接请求 中已经详细描述就不再熬述了固件基于cc2540  cc2541 1.环境 需要一个抓包器几十块钱, USBdongle 装Packet Sniffer软件进行抓包. 环境搭建可以参考:http://blog.csdn.net/mzy202/artic

蓝牙4.0BLE抓包(二) – 广播包解析

本文转自:http://www.cnblogs.com/aikm/p/5022502.html 感谢原创作者! SleepingBug评论:这篇文档写的相当好,受教了,多谢了!   作者:强光手电[艾克姆科技-无线事业部] 在使用EN-Dongle捕获和解析广播包之前,我们先了解一下BLE报文的结构,之后,再对捕获的广播包进行分析.在学习BLE的时候,下面两个文档是极其重要的,这是SIG发布的蓝牙的核心协议和核心协议增补. 核心协议Core_v4.2. 核心协议增补CSS v6. 虽然这两个文档

Fiddler抓包3-查看get与post请求

前言 前面两篇关于Fiddler抓包的一些基本配置,配置完之后就可以抓到我们想要的数据了,接下来就是如何去分析这些数据. 本篇以博客园的请求为例,简单分析get与post数据有何不一样,以后也能分辨出哪些是get,哪些是post了. 一.get请求 1.打开fiddler工具,然后浏览器输入博客首页地址:http://www.cnblogs.com/yoyoketang/ 2.点开右侧Inspectors下的Headers区域,查看Request Headers 3.Request Header

BLE广播数据的抓包解析

前言: 报文由数据字节组成同时是按比特传输的,这就免不了牵涉到字节序的问题. 对于各个字节的传输,总是从最低位开始传输.如0x80是按00000001发送的,0x01是按10000000发送的. 同时大多数字节域又是从低字节开始发送的.如0x010203发送序列为110000000100000010000000 之所以说大多数,是因为并不是所有的数据都会从低字节发送从后面的抓取的广播报文中也能看不来. 另外由于抓包软件可能并不一定能完全知道哪些数据时从低字节开始发的,抓取的广播数据可能有一些需要

10.6 监控io性能 - 10.7 free命令 - 10.8 ps命令 - 10.9 查看网络状态 - 10.10 linux下抓包

- 10.6 监控io性能 - 10.7 free命令 - 10.8 ps命令 - 10.9 查看网络状态 - 10.10 linux下抓包 - 扩展tcp三次握手四次挥手 http://www.doc88.com/p-9913773324388.html  - tshark几个用法:http://www.aminglinux.com/bbs/thread-995-1-1.html  # 10.6 监控io性能 ![mark](http://oqxf7c508.bkt.clouddn.com/b