在WiFi直连(WiFi Direct,也称为peer-to-peer,P2P)中,设备可以不通过AP(Access Point)进行连接。在P2P group中,称为GO(Group Owner)的设备具有像AP一样的功能,其他被称为GC(Group Client)的设备就去连接GO。支持WiFi Direct功能的设备都可以称为GO或GC。在Group Formation阶段,设备会被确定称为GO还是GC。笔者将会后面的博客讨论Group Formation过程。在P2P group中,只会存在一个GO,其他许多的GC去连接这个GO,然后进行通信。
P2P体系结构由支持设备间通信的交互组件组成。
P2P设备
P2P GO角色:
P2P GC角色:
P2P拓扑是1:n策略,多个GC可以连接同一个GO。这些连接的设备被称为一个P2P Group。
在DMG之外的运行每个client可能是P2P GC或传统的不具有P2P功能的Client。在DMG之内运行的每个client必须是具备P2P功能的GC。
图1 在DMG之外的P2P组成和拓扑
图2 在DMG中的P2P组成和拓扑
一个P2P Group有唯一的SSID,图3表示1:1的拓扑。
图3 P2P Group 拓扑为1:1
支持P2P功能的设备可以并发模式运行,也就是STA(Station)模式和P2P模式共存。在并发模式中,P2P设备可以连接一个AP。因此,P2P设备可以GO+STA或GC+STA模式运行。在并发模式中,设备存在两个interface接口,并且这两个interface大概率处于同一个channel信道,也有可能处于不同的channel和band。
在下图中可以看到,P2P设备处于并发模式。
图4 P2P Concurrent Device
图4显示了P2P设备有一个MAC实体作为了WLAN-STA,另外一个MAC实体作为了P2P Device。双MAC功能可以通过两个独立的物理MAC实体提供,每个实体与自己的PHY实体关联,或者两个虚拟MAC实体与一个PHY实体关联。
一个P2P group可以与一个并发操作的WLAN BSS处于相同或者不同的信道中。比如,WLAN BSS可能处于5.2GHz的channel 36,而P2P group在2.4GHz的channel 6。
在DMG之外运行的P2P,规范是假设以下STA功能和服务在设备中已经实现:
在DMG之内运行的P2P,规范是假设以下STA功能和服务在设备中已经实现:
P2P技术一个主要的应用场景就是Miracast,设备之间共享媒体数据,所以P2P还必须支持WMM(WiFi Multimedia),WMM是一种源自802.11e的Qos服务,主要是针对实时音视频数据的传输。
P2P设备还支持以下特殊功能:
P2P discovery阶段让P2P设备快速查找周围的其他P2P设备,并建立连接。P2P discovery主要由以下几个部分组成:
基本原理:P2P设备进行主动扫描从而发现附近的其他设备,设备使用probe request和probe response帧去发现彼此。P2P Group形成之后,GO会发送beacon帧去发现设备。
P2P Device不会回复probe request帧,除非它是GO或者处于Listen State。
P2P Device不会发送beacon帧,除非它是GO。
下面这张图展示了Discovery的过程:
Scan阶段:扫描阶段使用IEEE Std 802.11-2012
中定义的扫描过程。P2P设备可以在这个阶段查找其他的P2P设备或者P2P Group,并选择最佳的信道去建立P2P Group。在Scan阶段,设备扫描自己支持的所有信道(可以是Channel 1,6,11,也可以是全新到扫描)去寻找周围的其他设备。在Scan阶段的P2P设备不会回复Probe Request帧。
Listen状态:不属于P2P Group中的设备如果处于Listen状态可以被其他的设备发现。Listen状态会给定一个信道,叫Listen Channel监听信道。这是从Social Channels中选择的一个信道,2.4GHz频段中Channel 1,6,11被作为Social Channels。
Listen Channel应在设备Discovery之初选择,并应保持不变,直到P2P Discovery阶段完成。
处于Listen状态的P2P设备只能对Probe Request探测请求帧进行应答,探测请求帧包含P2P IE、P2P通配符SSID元素、一个通配符BSSID和一个目的地址(广播地址或其P2P设备地址)。
每个P2P 设备都会选择一个随机数,随机数的上限和下限分别是maxDiscoverableInterval和minDiscoverableInterval,默认情况分别为3和1。如果随机数为1,那么设备会处于Listen状态的时间为100TU,如果随机数为3,那么设备处于Listen状态的时间为3*100TU。随机数的机制主要是为了避免两个设备Listen和Search的时间同步,导致互相搜索不到彼此。
Search状态:P2P device会在social channel上发送一个或多个Probe Request帧。这些Probe Request帧包含以下信息。
总结:一个P2P device处于Scan阶段,它有可能会发现另外一个处于Search状态 Listen状态的P2P device。Find阶段主要用于保证两个P2P device能够处于相同的channel相互发现,并交换设备信息。一个P2P device进行connect可能会出现下面三种情况:
这里主要有三种方式可以进行Group Formation。它们分别是:
可以通过下图看出P2P GO Negotiation的过程包含几个阶段。
图中所示,device1发送GO Negotiation给device2,帧交换的主要目的是进行GO intent值的交换,intent值决定了谁作GO。intent值的范围是0到15。谁的intent值越大,谁就作GO。如果intent值相同,则通过tie breaker来判断,tie breaker为0或1,1表示作GO,tie breaker的值是0或1随机选择的。
比如,device1的intent为5,在GO Negotiation Request中tie breaker随机设置为0。不巧的是,device2的intent也设置为5,但是device2通过GO Negotiation Request得知device1的tie breaker为0,那么将自己tie breaker切换为1并发送GO Negoation Repsonse。如果device1的tie breaker随机设置为1,那么device2的tie breaker就会相应切换为0。这样从而能保证在intent相同的情况下GO协商也能成功。
通过抓包工具抓到的GO协商的帧交互如下:
Device2发出Negotiation confirmation ,status code为0,表示成功
决定GO的流程图如下所示:
下图是Negotiation Response codes。常见的就是status code: success (0)
。
当status code为9时,即当两个device的intent值都为15时,会GO协商失败。
当status code为7时,表示两个device不在相同的channel。
当status code为11时,表示对端设备拒绝连接。
一旦GO协商成功之后,GO就会发送beacon帧。beacon帧中包含了P2P Group的属性信息。
阶段3——Phase1 and Phase 2 of WPS Provisioning
下图清晰地展示了WPS Provisioning中Phase1和Phase 2过程的帧交换。
我们通过wireshark工具抓取了Group Formation的Phase 1和Phase 2过程的数据包,截图如下:
这里采用的方法是PBC(Push ButtonConfiguration)方式。Group Formation过程有一个叫Provisioning的阶段,Provisioning采用的WSC(WiFi Simple configuration)。因为需要等待用户输入,所以WSC大概会花费2min左右的时间。由于Group Formation阶段可能会执行多次,因此用户无法接受2min的延迟。在P2P Group形成之前,P2P Device应该获取所需的相关信息,相关信息包括从用户处获取的PIN等。P2P Device应该在15s内完成P2P Group的创建(完成Group Formation)。
下图详细地展示了P2P Group Formation过程:
part-1
part-1阶段是authentication request和authentication response帧的交互。在WiFi association的过程中,我们也能看到association request和association response这些帧的交互。
part-2
在part-2中,我们看到EAP authentication过程,主要有以下阶段:
supplicant(GC)将发送EAPOL-Start帧给AP(GO)。抓的数据包中不存在这一帧,应该是GO直接初始化好了这一过程。下图是该帧的具体细节:
GC发送response identity给GO。response identity内容为“WFA-SimpleConfig-Enrollee-1-0”。同时,GO是registrar。
part-3
part-3是WSC的过程。
4. 在M1 Message之前,AP将发送WSC Start (1)给supplicant。这一帧由GO发出,如下图所示:
在WSC-START之后,我们会看到M1-M8 message帧的交互过程。在M1-M2中,diffie-helmen密钥交换将生成共享密钥。supplicant和GO都将交换公钥以生成公共共享密钥。GO和supplicant不会共享私钥,它们将使用Diffie-Helmen密钥交换算法计算共享密钥。
在PBC方式中,用户不会输入PIN。默认的PIN码被设置为00000000
。
9. M5 Message帧是Enrollee发给Registrar。通过Registrar,Enrollee (supplicant)证明了拥有PIN的前半部分。PIN的前半部分相互认证通过该帧结束。
10. M6 Message是Registar(GO)发给Enrollee。通过Enrollee,Registar(GO)验证后半部分PIN的正确性。如果输入了错误的后半部分PIN,在M6之后就不会有任何消息了。
下图是抓包工具抓到的M6:
11. M7 Message是Enrollee (supplicant)发给Registrar (GO)。Enrollee证明了后半部分PIN的正确性,后半部分PIN的相互认证到此结束了。
下图是抓包工具抓的M7:
12. M8 Message是Registrar发给Enrollee。在M8消息中,Security configuration、New Credentials都会分发给Enrollee。现在,Enrollee必须使用新的凭据重新连接到GO。
下图是抓包工具抓的M8:
13. Enrollee发送WSC_DONE给Registrar。WSC(Wifi Simple Configuration)将在WSC_DONE帧后结束。下图可以看到WSC_DONE的具体细节。
14. Registrar将返回EAP-Fail message给Enrollee。然后,Enrollee将断开连接disassociate,再通过M8中获取的凭据credential进行重连reconnect,之前旧的连接不再有效。Registrar (GO)发送的EAP-Fail message如下所示:
15. supplicant(Enrollee)发起断开连接的动作,即发送disassociation frame给GO(Registrar)。disassociation frame如下:
16. GO(Registrar)将发送Deauthentication frame,然后Supplicant通过新的凭据进行重新连接,如下图所示:
到此,Group Formation的PHASE-1结束了。
Phase-2
接下来,介绍下Group formation过程中的Phase-2阶段。Phase-2阶段主要进行4-way handshake,这和正常association的4-way handshake一样。唯一的区别是Phase-2阶段用户不需要输入密码。在PBC方法中,M8 Message会携带凭据信息。4-way handshake会根据M8中凭据信息生成PTK、GTK和其他密钥。这里将使用AES方法完成数据的加密。下图展示了4-way handshake相关的数据包:
在4-way handshake之后,Group formation的Phase-2过程就结束了。
Phase-2之后
在4-way handshake之后,GO会发出beacon帧,beacon帧会携带P2P capability Attribute,并且group formation bit设置为0。在GO Negotiation Procedure之后,group formation bit会设置为1,在 4-way Handshake之后,该位又会置为0。
4-way handshake之后,beacon帧会从GO端立即发出,如下所示:
从下面的beacon帧中看出,group formation设置为0x0。
接下来,会进行DHCP握手阶段,GO会为GC分配IP地址,之后将进行数据通信。观察下图可以看到在Phase-2之后,立即进行了DHCP的握手。但是在wireshark抓包工具中没有看到DHCP握手情况,因为在4-way handshake之后DHCP相关消息被加密了。
在这之后,GO和GC之间将进行数据传输。下图展示了wireshark工具中DHCP的过程,这必须先抓到4-way handshake的数据包,然后在wireshark中输入PSK或PASSWORD:SSID进行解密数据流量。
在DHCP过程之后,将完成数据传输,并且P2P默认使用AES-CCMP加密。
在2.3.1节中,我们了解到通过Negotiation Method方法形成P2P Group。在这一节,我们将了解通过Autonomous GO Method形成P2P Group。同时,我们将了解这两种方法的不同。
在AUTO GO Method中,一个设备将声明自己作为GO,我们将不会看到Negotiation Phase协商阶段。
下图是通过Negotiation Method方法形成P2P Group的帧交互过程。
在上图中,用红色方框标记的就是GO negotiation过程。这个过程将决定哪个设备作为GO。在Autonomous GO (AUTO GO) 方法中,我们将看不到协商过程,因为其中一个设备已经声明它作为GO。
下图展示了P2P Auto GO的过程。
在P2P Auto GO方法中,设备声明自己作为GO,该设备就变成了GO,并选择一个channel开始发送beacon帧。
在discovery阶段,discovery是基于GO发送的beacon帧或active discovery过程。在AUTO GO方法中,GO将会发送beacon帧让passive scan的设备能够被发现。这个阶段同时也有可选服务发现optional service discovery。
一个P2P设备加入autonomous group,我们可以观察supplicant的log与设备发出的beacon帧。
IFNAME=p2p-wlan-0 <3>CTRL-EVENT-STATE-CHANGE id=0 state=9 BSSID=xx:xx:xx:74:40:a0 SSID=DIRECT-pF
<3>P2P-GROUP-STARTED p2p-wlan0-0 GO ssid=”DIRECT-Ww” freq=2437 passphrase=”6NmClTZ8″ go_dev_addr=xx:xx:xx:74:c0:a0
在discovery阶段,可以观察到Beacon、Probe request和probe response帧的交互,如下面抓的包所示:
当任意一个设备想加入一个已经存在的P2P group时,我们能够看到P2P Provisional Discovery Request和Response帧的交互过程。Provision Discovery Request帧会在Config Methods属性中配置发送方设备想让接收方设备使用的方法。当设备接收到Provision Discovery Request帧时,会向对端设备响应Provision Discovery Response帧。Provision Discovery Response帧如果在Config Methods属性配置了相同的方法,这表示成功,如果配置为NULL,则表示失败。
观察下图中Provision Discovery Request帧的结构,config method配置为**“Push Button”,因为我们采用了Push button method连接。
观察下图Provision Discovery Response的帧结构,也是采用的“Push Button”**方法。
在这之后,将进行Group Formation中的Phase 1 and Phase 2阶段。下图展示了Phase 1 and Phase 2阶段的帧交互过程。
下图展示了Group Formation中的Phase 1 and Phase 2阶段,和使用Negotiation Method方法的Phase 1 and Phase 2一样。
一旦Group Formation成功,GO的supplicant logs会打印以下event。
IFNAME=p2p-wlan0-0 <3>AP-STA-CONNECTED xx:xx:xx:74:43:dc p2p_dev_addr=xx:xx:xx:7
4:c3:dc
<3>AP-STA-CONNECTED xx:xx:xx:74:43:dc p2p_dev_addr=xx:xx:xx:74:c3:dc
在Phase-1和Phase-2成功之后,进行DHCP,之后GO和GC之间采用AES加密进行数据传输。
2.3.1节和2.3.2节分别介绍了Negotiation Method和Autonomous Method两种Group Formation方法。本节主要介绍使用Persistent Method方法去形成P2P Group Formation。在Persistent method方法中,设备会保存M8 Message中的凭据credentials,GO或GC将使用这些凭据credentials去邀请P2P device去形成P2P Group。
现在我们将了解P2P Persistent Group Formation方法。我们将了解到该方法与Negotiation和Autonomous Group方法的不同之处。
在Group Formation的开始阶段,我们将看到Phase-1和Phase-2阶段。Phase-1阶段主要用于GO分发credentials凭据给GC。P2P Persistent Group Formation没有Phase-1阶段,因为在形成Group的时候,凭据credentials已经保存起来了。任何设备想要连接到之前连接过的设备,它将使用存储起来的凭据进行连接,因此不会有Phase-1阶段,Group Formation过程进行得更快,因为在GO和GC之间少了许多帧交换。
在Persistent Method方法中,我们也不会看到Negotiation Phase协商阶段,因为GO已经在Group形成的时候就确定了。当一个P2P device获取到Persistent Group的凭据时,P2P device应该将该凭据保存起来。这样能够让GO重新创建P2P Group。甚至P2P GC也可以保存凭据,并用这些凭据邀请GO来形成P2P Group。
persistent group形成有两种方式:
在P2P Persistent Group中,Device Discovery采用Active Scanning主动扫描。Device Discovery也可以采用passive scanning,这种主要发生在Autonomous GO中,GO已经开始主动广播beacon帧。上图中的discovery主要是通过Probe Request和Probe Response帧进行的。
如果GO具有persistent Group Formation的能力,那么在P2P Capability attribute的Group Capability Bitmap field中Persistent P2P Group bit会被置为1。这里的置位主要发生在GO传输的beacon帧、Probe Response帧。
下图中Persistent Reconnect设置为0,表示GO不支持Persistent Reconnect。
P2P GO可以将Persistent Reconnect位设置为1,从而表示P2P GC可以重新连接,而无需用户干预Persistent P2P Group。我们可以从probe response中看到详细信息。
在第一次Group Formation的时候,我们可以看到Phase-1和Phase-2阶段。在Persistent P2P Group形成之后再次连接,我们只会看到Phase-2阶段,不会看到Phase-1阶段。
下面是supplicant关于Persistent Group被创建相关的log。
<3>P2P-GROUP-STARTED p2p-wlan0-13 GO ssid=”DIRECT-X7″ freq=2462 passphrase=”11W0
ozWN” go_dev_addr=xx:xx:xx:74:c0:a0 [PERSISTENT]
在persistent reconnect方法中,我们不会看到Phase-1阶段,如下所示:
P2P Invitation过程
在Invitation的过程中,GO邀请GC或GC邀请GO形成一个P2P Group。P2P Invitation是一个可选的过程,主要有以下几种场景:
P2P Group Formation Procedures – Negotiation Method – PART 1
P2P Group Formation Procedures – Negotiation Method – PART 2
P2P Group Formation Procedure – Autonomous Group Formation Method
P2P Group Formation Procedure – Persistent Method