12 Replies Latest reply on Jul 12, 2016 2:04 PM by venkats_16

    Issue with P2P on i.MX6SL EVK with 1DX module



      we are facing an issue with the P2P mode of the 1DX module on when running on i.MX6SL EVK with 1DX dev kit and Linux Kernel 3.14.52 (from Freescale's git repository).


      This problem is related to the re-establishment of a P2P GO using bcmdhd, controlled by wpa_supplicant.  After boot, a persistent P2P GO is enabled successfully.  Stations can connect and disconnect with no problems.  The P2P GO is then removed and a new P2P GO is enabled using the wpa_supplicant P2P_GROUP_ADD and P2P_GROUP_REMOVE commands.  The MAC correctly starts beaconing in its role as a P2P GO but any attempt to associate fails.  Although WLC_E_ASSOC_IND events are sent to bcmdhd, they are ignored with the error:


      (CFG80211-ERROR) wl_notify_connect_status : Invalid ndev status -1


      This occurs because wl_get_mode_by_netdev() fails to match the ndev to an ndev in the net_list for the driver.  This condition is caused by a failure to deallocate the net_info corresponding to the previously removed P2P GO. Because the deallocation failed, at the point the P2P GO is re-enabled, the net_list already holds the maximum number of net_info structures for the following interfaces:



      p2p-wlan0-0   (this should have been removed)


      During the call to wl_cfg80211_add_virtual_iface() to add the re-enabled P2P GO, wl_alloc_netinfo() is called to allocate a netinfo for the new interface.  This is the allocation that fails.  The failure return value is however ignored by wl_cfg80211_add_virtual_iface() which ploughs ahead with the setup.


      The cause of the allocation failure is actually the failure of the deallocation that occurred when the previous P2P GO was removed. Although wl_dealloc_netinfo() is called as a result of a call to wl_cfg80211_del_virtual_iface(), the ndev parameter never matches any of the devices in the net_list so nothing actually gets removed.  When wl_cfg80211_handle_ifdel() is called during the P2P GO removal, wl_cfg80211_remove_if() is called that leads to the failed call to wl_dealloc_netinfo().


      As a work-around, calling wl_dealloc_netinfo(cfg, ndev) directly after the call to wl_cfg80211_remove_if(cfg, if_event_info->ifidx, ndev) makes the problem go away.  This is almost certainly not the correct fix but I’ve included it to help illustrate the problem.


      static s32 wl_cfg80211_handle_ifdel(struct bcm_cfg80211 *cfg, wl_if_event_info *if_event_info,

      struct net_device* ndev)



      . . . .



      #if defined(BCMSDIO)

      dhd_wlfc_get_enable(dhd, &enabled);

      if (enabled && cfg->wlfc_on && dhd->op_mode != DHD_FLAG_HOSTAP_MODE &&

      dhd->op_mode != DHD_FLAG_IBSS_MODE) {


      cfg->wlfc_on = false;



      #endif /* PROP_TXSTATUS_VSDB */



      printk("wl_cfg80211_handle_ifdel if_event_info->ifidx: %d ndev->ifindex %d name: %s\n", if_event_info->ifidx, ndev->ifindex, ndev->name);

      wl_cfg80211_remove_if(cfg, if_event_info->ifidx, ndev);


      // *** work-around successfully removes correct netinfo

      wl_dealloc_netinfo(cfg, ndev);


      return BCME_OK;



      Does anybody have any insight on this ? Can somebody confirm/deny the issue ?



      Raul Benet

        • 2. Re: Issue with P2P on i.MX6SL EVK with 1DX module

          hi Raul,


          What version of firmware are you using? 


          Can you provide a logcat when you are running unmodified software while it fails?





          • 3. Re: Issue with P2P on i.MX6SL EVK with 1DX module


            we are running on linux, so I guess "logcat" doesn't apply. (do correct me if I am wrong)


            We've captured a kernel log with dhd_msg_level set to 0x5. See attached.


            Let me know if you need a different dhd_msg_level.


            if you still can't see it, we could try to come up with a wpa_cli scripts that reproduces the problem.


            Firmware version. Here is the string I see in fw_bcmdhd.bin

            Version: CRC: 3451af24 Date: Tue 2015-12-29 15:58:03 PST Ucode Ver: 1043.2060 FWID: 01-4e412465


            The linux kernel is 3.14.52 from Freescale's git repository.




            • 4. Re: Issue with P2P on i.MX6SL EVK with 1DX module

              hi Raul


              Sorry for the delay. Hopefully your current patch allows you to move forward. We are trying to fix this problem with Broadcom.





              • 5. Re: Issue with P2P on i.MX6SL EVK with 1DX module

                Hi Raul,


                The wpa_cli scripts would be useful. Could  you please send those across.





                • 6. Re: Issue with P2P on i.MX6SL EVK with 1DX module

                  Hi Raul,


                  Could you please send me your wpa_cli scripts.




                  • 7. Re: Issue with P2P on i.MX6SL EVK with 1DX module


                    See below procedure for reproducing the problem using wpa_cli:



                    Start wpa_cli and select the interface using (only do this once):


                    >> interface wlan0


                    This command sequence sets-up and starts the persistent P2P group owner.


                    >> add_network (return netId (0 in this case))


                    >> set_network 0 ssid "DIRECT-XXX-KAPTIVO"

                    >> set_network 0 psk "8ormorechars"

                    >> set_network 0 proto WPA

                    >> set_network 0 key_mgmt WPA-PSK

                    >> set_network 0 pairwise CCMP

                    >> set_network 0 mode 3

                    >> set_network 0 disabled 2


                    >> p2p_group_add persistent=0


                    Event reported:

                    <3>P2P-GROUP-STARTED p2p-wlan0-0 GO ssid="DIRECT-XXX-KAPTIVO" freq=2412 passphrase="8ormorechars" go_dev_addr=fe:db:b3:89:44:fe [PERSISTENT]


                    P2P Group Owner is now active and devices can detect and connect. The network interface p2p-wlan0-0 has been created.

                    We then tear-down the GO with the following command:


                    >> p2p_group_remove p2p-wlan0-0


                    Event reported:

                    <3>P2P-GROUP-REMOVED p2p-wlan0-0 GO reason=REQUESTED


                    Now repeat the command sequence from add_network.  Note that the second time around, the netId will be different.  Also, the created network interface will be p2p-wlan0-1.  After the P2P GO is started for the second time, any attempt by a device to perform a mac auth or associate fails as we described in the original bug report.






                    • 8. Re: Issue with P2P on i.MX6SL EVK with 1DX module

                      Hi Raul,


                      Is your issue consistently reproducible?


                      Here is the wpa_cli sequence of commands on GO & GC that I used. It seems to work and was able to repeat this 3 times. Please see attached logs from supplicant.


                      GO> p2p_group_add

                      GC> p2p_find

                      GO> p2p_find


                      GO> IFNAME=p2p-wlan0-X wps_pbc


                      In below go_mac is the mac address of the GO interface.

                      GC> p2p_connect <go_mac> pbc join go_intent=0


                      GO> p2p_stop_find


                      After that I assign IP addresses to interfaces using below commands from shell.


                      On GO:

                      ifconfig p2p-wlan0-X

                      On GC:

                      ifconfig p2p-wlan0-X


                      After this do a ping test from GO to GC


                      Then from wpal_cli remove the interface from GO. And this seems to automatically remove it on the GC too.


                      GO> p2p_group_remove p2p-wlan0-X






                      • 9. Re: Issue with P2P on i.MX6SL EVK with 1DX module

                        Hi venkats_16


                        This isn’t the scenario that is failing for us.   The scenario is:


                        1. Start persistent GO as explained previously.
                        2. Connect with a normal 802.11 STA (not a P2P device) – this will work correctly.
                        3. Stop the GO.
                        4. Start a new persistent GO (as before)
                        5. Attempt to connect with the same STA – associate_ind and any other events related to the new interface are dropped by bcmdhd.


                        All subsequent stopping and starting of the persistent GO lead to the same problem.  The connecting device is always a normal 802.11 STA operating in infrastructure mode.  The STA sees the GO as a legacy AP.  The Broadcom device is always acting as a persistent P2P GO i.e. no P2P negotiation was performed to establish the role of GO.  The problem is consistently reproducible.



                        • 10. Re: Issue with P2P on i.MX6SL EVK with 1DX module

                          Hi Raul,


                          For the use case that you are describing, the usual procedure would be to use hostapd on the AP side(and setup infrastructure AP) and wpa_supplicant on the STA side.


                          Would that procedure not work for you?




                          • 11. Re: Issue with P2P on i.MX6SL EVK with 1DX module


                            Our requirement is to support connections from both Wi-Fi P2P capable devices and legacy 802.11 stations.  To support P2P discovery, it is my understanding that we need to use wpa_supplicant.  I thought that hostap is restricted to operation as a traditional infrastructure mode AP.  Because our device is a fixed powered device, it’s appropriate for us to establish a persistent P2P GO during the device configuration mode.  Our use-case is very similar to the approach used by devices such as Wi-Fi printers where a concurrent connection to an infrastructure network is maintained along with a persistent P2P GO to allow for direct connection.




                            • 12. Re: Issue with P2P on i.MX6SL EVK with 1DX module

                              Hi Raul,


                              This is a scenario, which we currently don't support. Will look into whether this could be added to our next release. 


                              Most devices that support P2P also support being regular infrastructure mode station.  To make a case for adding this to the next release could you let us know what kind of devices support P2P , but don't support regular infrastructure mode station.