wifi direct扫描不到原因分析

1 wlan0 mac地址与p2p0 mac地址

p2p0 mac地址和wlan0 mac地址不是相同的,p2p0 mac地址是将wlan0 mac地址第一个字节bit1(bit0--bit7)位由0改为1,表明这是一个local address,而不是Universal administered. 相关log只有在打开wifi wpa_supplicant初始化的时候才打印。

 08-03 15:03:01.136 D/wpa_supplicant( 4357): p2p0: Own MAC address: 16:00:00:00:00:00
 08-03 15:03:01.274 D/wpa_supplicant( 4357): P2P: Own listen channel: 81:6
 08-03 15:03:01.367 D/wpa_supplicant( 4357): wlan0: Own MAC address: 14:00:00:00:00:00

2 wlan0 scan的Probe Request与p2p0 scan的Probe Request

SSID
  Length: [0-11]32 [25]
  SSID: [0-4]................................ [26-57]

SSID
  Length: [0-11]7 [25]
  SSID: [0-4]DIRECT- [26-32]
WPA [0-2]
WPS [0-2]
Wi-Fi Direct [0-11]
  P2P Attribute [0-12]

3 合法wlan0 mac地址

合法Mac地址的第一位的bit0和bit1必须都为0,bit0表示是单播/多播Mac地址,bit1表示是local/universal Mac地址。

即第一个字节对应的十六进制数的最后一个数字只能为:0,4,8,C。

最终发现不合法的Mac地址都是导致DUT搜索不到其他p2p设备,其他p2p设备也搜索不到它。

版权声明:本文为博主原创文章,未经博主允许不得转载。

时间: 2024-10-03 22:29:03

wifi direct扫描不到原因分析的相关文章

安全漏洞扫描,风险原因分析及解决方案

1 会话标识未更新 1.1 原因 在用户进入登录页面,但还未登录时,就已经产生了一个session,用户输入信息,登录以后,session的id不会改变,也就是说还是以前的那个session(事实上session也确实不会改变,因为没有建立新session,原来的session也没有被销毁). 很多人只是让会话invalidate没有用(request.getSession().invalidate();),是因为invalidate方法不是真正的将session销毁,只是将session中的内

android wifi Direct Audio TX/RX延迟分析

1 Direct Audio TX代码流程 1.1 从Host到FW -> htc.c::HifLayerRecvCallback -> htc.c::_HTCPipeIndicateRecvMgs//HTC_SERVICE.ProcessRecvMsgMultiple = htt_tgt_hif_svc_h2t_input -> htt_tgt_hif_svc.c::_htt_tgt_hif_svc_h2t_input//发送HTT_H2T_MSG_TYPE_TX_FRM ->

Android 4.2 Wifi Display 之 Settings 源码分析(一)

一.简单背景 简单背景:随着无线互联的深入,不管是蓝牙.WIFI或者各种基于此的规范不管是UPNP还是DLNA都随着用户的需求得到了很大的发展,google 自从android 4.0引入wifi direct后,又在11月份公布的android 4.2中引入了Miracast无线显示共享,其协议在此可以下载.具体的协议部分内容比较多,本人由于水平有限,就不在这里罗列协议的内容了,只附上一份架构图供大家对其有个大致的印象. 英文缩写对应如下: HIDC: Human Interface Devi

马上搞定Android平台的Wi-Fi Direct开发

导语 移动互联网时代,很多用户趋向于将大量的资料保存在移动设备上.但在给用户带来便利的同时引发了一个新的问题——保存在移动设备上的资料该怎样共享出去?到了思考时间,普通青年这样想:折腾什么劲啊,直接用数据线不就行了:而文艺青年可能这样想:咱们建个群吧,大家有好的东西都可以共享:二逼青年不高兴了,都特么互联网时代了,来点新意,好么?直接上网盘啊,大家互相研究研究,你懂的,嘿嘿.然而我是这样想的:都特么别BB,技术要以时俱进,来个新潮点的不行么?直接上Wi-Fi Direct.好用简单不解释.那么我

Windows变慢原因分析及解决方法

<p>Windows变慢原因分析及解决方法  <br/> <br/> <br/> <br/> 谁都希望计算机一开机就可以立即进入Windows 系统而不用等待,或者是系统在使用的时候不会越来越慢,但由于种种原因常常使这些愿望不能实现,甚至一开机就死机或者用着用着就越来越慢的情况也经常发生.其实有些时候Windows 启动速度缓慢并不是它本身的问题,而是一些设备或软件造成的.本文就是软件.硬件和病毒三大方面来分析系统速度变慢的原因,并且提供了针对系

SELECT TOP 1 比不加TOP 1 慢的原因分析以及SELECT TOP 1语句执行计划预估原理

现实中遇到过到这么一种情况: 在某些特殊场景下:进行查询的时候,加了TOP 1比不加TOP 1要慢(而且是慢很多)的情况, 也就是说对于符合条件的某种的数据,查询1条(符合该条件)数据比查询所有(符合该条件)数据慢的情况, 这种情况往往只有在某些特殊条件下会出现,那么,就有两个问题:为什么加了TOP 1 会比不加TOP 1慢?这种“特殊条件”是什么条件? 本文将对此情况进行演示和原理分析,以及针对此种情况采用什么方法来解决. 按照一贯风格,先造一个测试环境:1000W+的数据 数据的特点为: 1

Android WiFi 通信 -- WiFi 和 Wifi Direct 简介

WiFi简介 Wi-Fi可分为五代:第一代802.11,1997年制定,只运行于2.4GHz,最快2Mbit/s 第二代802.11b,只运行于2.4GHz,最快11Mbit/s,正逐渐淘汰 第三代802.11g/a,分别运行于2.4GHz和5GHz,最快54Mbit/s 第四代802.11n,可运行于2.4GHz或5GHz,20和40MHz带宽下最快72和150Mbit/s 第五代802.11ac,只运行于5GHz 由于ISM频段中的2.4GHz频段被广泛使用,例如微波炉.蓝牙,它们会干扰Wi

SQL Server扩展事件的使用ring_buffer target时“丢失”事件的原因分析以及ring_buffer target潜在的问题

事情起因: 排查SQL Server上的死锁问题,一开始想到的就是扩展事件, 第一种方案,开profile守株待兔吧,显得太low了,至于profile的变种trace吧,垂垂老矣,也一直没怎么用过. 第二种方案是开启TRACEON(DBCC TRACEON (3605,1204,1222,-1))将死锁写入error log,也是个不错的选择. 不过想到系统默认的扩展事件sysem_health已经捕获了死锁信息(sqlserver.xml_deadlock_report), 就没必要再重新往

Inotify数达到限制或文件空间不足的不同表现同一本质原因分析

操作系统环境: LSB Version:    :base-4.0-amd64:base-4.0-noarch:core-4.0-amd64:core-4.0-noarch:graphics-4.0-amd64:graphics-4.0-noarch:printing-4.0-amd64:printing-4.0-noarch Distributor ID: RedHatEnterpriseServer Description:    Red Hat Enterprise Linux Serve