客户平台的网卡从一家厂商的芯片更换为另一家的芯片，结果出现WiFi Miracast无法连接成功的情况。

初步信息调查：

1. 客户平台内核版本为： 3.1.10
2. 实测发现，当平台作GC时，连接没有问题。
3. 分析手机端和平台端的 wpa_supplicant.log ，有如下一些发现：
   • 平台端如下Log异常： Associaite Request中没有包含RSN IE等相关信息，这是P2P连接过程 中，所必须。
   • 手机端有如下Log异常：

      03-03 16:06:08.252 I/wpa_supplicant(  864): p2p0: WPS-M2D dev_password_id=0 config_error=12
      03-03 16:06:08.255 D/wpa_supplicant(  864): EAPOL: txSuppRsp
     03-03 16:06:08.255 D/wpa_supplicant(  864): TX EAPOL: dst=06:3d:98:a6:29:34
     03-03 16:06:08.255 D/wpa_supplicant(  864): TX EAPOL - hexdump(len=78): 01 00 00 4a 02 4d 00 4a fe 00 37 2a 00 00 00 01 02 00 10 4a 00 01 10 10 22 00 01 0d 10 1a 00 10 ...
     03-03 16:06:08.256 D/wpa_supplicant(  864): EAPOL: SUPP_BE entering state RECEIVE
     03-03 16:06:08.256 D/wpa_supplicant(  864): P2P: Terminate connection due to WPS PBC session overlap
     03-03 16:06:08.256 D/wpa_supplicant(  864): P2P: Group Formation failed with 06:3d:98:a6:29:34
     03-03 16:06:08.256 D/wpa_supplicant(  864): P2P: Clear timeout (state=PROVISIONING)
     03-03 16:06:08.256 D/wpa_supplicant(  864): P2P: State PROVISIONING -> IDLE
     03-03 16:06:08.256 I/wpa_supplicant(  864): P2P-GROUP-FORMATION-FAILURE
     

   config_error 的值为 12， 其意义为：　 WPS_CFG_MULTIPLE_PBC_DETECTED ，这个是GO在处理M1信息时，带上的。

4. 根据双方的Log， GO在处理GC发送过来的M1消息后，回复了M2D信息给GC， 从而中断了WPS的交互过程。从如下代码入手分析：

   

   函数 wps_registrar_p2p_dev_addr_match 中进行地址过滤时，发现了 线索：

   

   正常情况下， reg->p2p_dev_addr 的值应该与 wps->p2p_dev_addr 的值一致，但是从出错Log中发现 wps->p2p_dev_addr 的值为0。 而 wps 相关的初始化是在 eap_wsc_init 在调用了 wps_init 来进 行初始化的。 如下图所示 ：

   

   有个条件引起来我们的注意： sm->assoc_p2p_ie 是否因为这个为NULL，导致 wps_init 初始化时， p2p_dev_addr 没有 得到赋值？

5. 分析 wpa_supplicant 处理Associate Request的函数代码： 在函数 hostapd_notif_assoc 里面，会解析 Associate Request 携带 的IE信息， 代码如下：

   

   可以发现，并结合之前的Log发现， WPS， RSN， WPA等 IE信息都为空。 所以有理由 怀疑Driver送上来的Associate Request中就没有包含这些IE 信息， IE信息为空！！！

6. Driver层确认 在Driver处理Association Request的地方， 加一些打印Log确认收到的 IE是否为空，结果发现，Driver有收到这些IE信息的。 Driver在处理完 Associate Request后，如果OK，会送回一个Associate Response给对方 ，并调用 cfg80211_new_sta 将Associate Request事件通知到上层。 应该在这个地方可能将IE信息漏掉了。

由于定位到问题的原因是：驱动在调用 cfg80211_new_sta 时，没有将 如 下标记设置：

struct station_info sinfo;
struct ieee80211_mgmt *mgmt;

NdisZeroMemory(&sinfo, sizeof(sinfo));

//因为这个标记没有置上，导致nl80211模块处理IE信息时，
//将assoc_req IE给过滤掉了, 正解就是要让这句执行。
 sinfo.filled = STATION_INFO_ASSOC_REQ_IES;

 mgmt = (struct ieee80211_mgmt *) assoc_frame;
 sinfo.assoc_req_ies_len = assoc_len - 24 - 4;
sinfo.assoc_req_ies = mgmt->u.assoc_req.variable;

return cfg80211_new_sta(pNetDev, mac_addr, &sinfo, GFP_KERNEL);

设备当GO时， p2p virtual interface 启动时，有时会出现Device or Resource is busy

p2p 协商成功后，会创建一个virtual interface, 即 调用 wpa_driver_nl80211_if_add ， 在该函数中，会调用 linux_set_iface_flags 将虚拟接口设置为UP状态， 查看该函数的代码如 下：

在下这个命令时，出现上述错误。 kernel中处理该命令的函数为： devinet_ioctl 进一步追下去，在该函数中： __dev_change_flags 有如下代码：

UP会对应 __dev_open 函数。 这个函数会调用driver注册的打开网络接口 的回调函数。如下代码所示 ：

从上述代码也可以看到，在打开设备之前，会发送一个 NETDEV_PRE_UP 通 知链消息。 在 cfg80211_netdev_notifier_call 函数中，会处理该消息： 这个逻辑主要是一些Sanity Check，即此时能不能打开该网络接口。

最重要的处理函数是 cfg80211_can_use_iftype_chan ，在这个函数中会 分析当前打开网络接口是否有问题。

通过对上述代码的分析，结合driver的Log，做出了如下的修改：

客户报怨仓库某个指定的区域WiFi性能很差，WiFi速率很慢。如下是抓包过程 中，某个数据帧的情况：

从上述抓包的信息来看，有两个信息值得注意：

1. 信号干扰
2. 重传

上述数据包是一个重传的数据包。 在Channel 6上重传概率大于30%。

从WiSpy工具查看信号干扰情况，发现Channel 1～6 干扰很严重。

有发现周围有一个老旧的摄像机在周围，然而没有使用，但是通电着。这个摄 像机对Channel 1～6之间的信号干扰很大，导致出现较高的数据重传率。

固件升级后，一些手机出现奇怪的现象。 它们会连接到网络，然后断开并显 示定位网络服务的信息。这个过程是可重复的。

数据包抓取结果如下：

如上图红色标记，Duration的值太大，有点异常，一般情况下，应该只有几十 毫秒。

这个问题最后查出是手机Firmware代码的Bug，导致在处理与802.11n的AP交互时， 出现Duration值异常的情况。这会影响周围所有的WiFi设备，而不仅仅是这个 手机。

客户抱怨WiFi网络性能差，且有时甚至连接不上WiFi网络。

抓包信息如下：

可以看到出现了CRC错误， 这表明我的抓包工具不能正确地读取帧信息。当靠 近发送数据的设备时，CRC错误率会降低。

当通信双方的距离大于一定值后，会出现CRC错误率变高的情况，尝试靠近一 下，看CRC错误率是否会降低。

客户报怨他们新的网卡传输高分辨率的图片时，速率非常慢。然而，在上星期 的售前演示时，却没有这样的问题。

抓取数据包如下：

发现上述情况不断重复，即不停地进行Off-Channel扫描，然而网卡没有动， 且非常靠近AP。

一个设备在off-channel或休眠状态下是不会传输数据的。 NULL数据帧使用 power management位来通知AP为其缓存数据帧。 通常有如下两种原因：

1. 节省电力
2. 执行off-channel扫描来建立一个neighbor列表,以方便未来可能进行的漫 游动作。

在这个案例中，STA不停地尝试建立一个neighbor列表，可以看到它在正执行 off-channel扫描（在信息1,6,11之间不停地切换）。这表明STA正在尝试寻找 一个更好的AP去关联，有如下可能的原因会导致这种行为发生：

1. driver有错误。
2. STA错误地配置了高概率的漫游。
3. RF差，没有接收到数据。
4. 天线坏了或者是没有接好。
5. 干涉。

基于上述的分析以及可能的原因，发现USB接口的网卡插在显示器的背部，周 围几乎被金属包围。这样会导致USB性能很差，很能保持连接，会导致不停地 漫游到新的AP上。

连接一台比较旧的AP时，连接失败，被AP拒绝。对比其他平台，可以正常连接。

这个问题看上去应该是AP兼容性问题，需要一份正常连接的Log和失败的Log进 行对比，以判断问题点。

1. 首先看AP回的Probe Response的信息

   

   从图中，可以看到几个信息：

   • 此AP不包含HT Capability，说明是不支持11n的（注：在解决问题前， 是不清楚AP是很老旧的AP这个信息的。）
   • 第二，就是AP的一些Capability信息。
2. 其次看下连接失败时，发送给AP的Association Request的包的信息

   

3. 其他平台能正常连接到此AP时，发送给AP的Associaiton Request的包的信 息

   

通过对比，可以发现有如下两个疑点：

1. Association Request中的immediate Bloack Ack Allowed这个位没有设置。
2. 在发送给AP的Association Request中的信息中包含有Extended Capabilities信息。

针对上述两个疑点，发现连接不上的主要原因是在Association Request中携 带了Extended Capabilities IE信息。针对这种情况， wpa_supplicant 已 经有了一个修改的思路：

/*
 * Workaround: Add Extended Capabilities element only if the AP
 * included this element in Beacon/Probe Response frames. Some older
 * APs seem to have interoperability issues if this element is
 * included, so while the standard may require us to include the
 * element in all cases, it is justifiable to skip it to avoid
 * interoperability issues.
 */
if (!bss || wpa_bss_get_ie(bss, WLAN_EID_EXT_CAPAB)) {
        u8 ext_capab[18];
        int ext_capab_len;
        ext_capab_len = wpas_build_ext_capab(wpa_s, ext_capab,
                                             sizeof(ext_capab));
        if (ext_capab_len > 0) {
                u8 *pos = wpa_ie;
                if (wpa_ie_len > 0 && pos[0] == WLAN_EID_RSN)
                        pos += 2 + pos[1];
                os_memmove(pos + ext_capab_len, pos,
                           wpa_ie_len - (pos - wpa_ie));
                wpa_ie_len += ext_capab_len;
                os_memcpy(pos, ext_capab, ext_capab_len);
        }
}

客户 有报在A模下吞吐量偏低的问题， 标准要求在20MBit/s, 但是测试到的结果低于10Mbit/s.

当在A模式下，设置AP在某些channel, driver会识别成其他的 Channel，这时吞吐量会偏低。

在Side Band Channel听到比较弱的AP Beacon

过滤到非Ajacent信道上侦听到的Beacon。

When we are doing concurrent p2p connection (STA + P2P-GO) using dynamic interface, after some trails the GO-NEG fails which is causing the STA connection to be deauthenticated.

1. NEG_FAIL 失败的原因 the reason for failing the add_iface is because we have exceeded the maximum number of VIF's. So we are ok with p2p GO-NEG failing, but the problem is it disconnects the STA interface.
2. 问题初步分析
   • It looks like some of the calls in at least one of the error paths end up getting going through both p2p-wlan0-# and wlan0 interface when handling this type of failure case. The pending p2p-wlan0-# instance gets removed properly, but wlan0 instance should not have tried to remove the pending P2P group since it was not on that instance in the first place.
   • The reason for GO-NEG fail is that "add_iface" is failing, so "p2p_group_interface" is not set, but in wpas_p2p_group_delete based on the below condition we are deleting the STA managed interface. wpas_p2p_group_delete() should not be called on the non-P2P station interface..

     else if (wpa_s->p2p_group_interface == P2P_GROUP_INTERFACE_CLIENT ||
                       (ssid && ssid->mode == WPAS_MODE_INFRA)) {
                      wpa_s->reassociate = 0;
                      wpa_s->disconnected = 1;
                      gtype = "client";
     

     Is there any reason for checking INFRA mode in p2p module? Yes, WPAS_MODE_INFRA is used for P2P Client as well as non-P2P station.

It was possible for a P2P group formation failure to result in a concurrent station mode operation getting disconnected in the specific error case where group interface addition fails after a successful GO Negotiation. Fix this by skipping the wpas_p2p_group_delete() call in this specific case since the group interface does not exists anymore at the point wpas_group_formation_completed() gets called.