This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Why wlan_cu and not wpa_cli?

Other Parts Discussed in Thread: AM3715

I have been working with the TI WLAN drivers included with the AM3715 EVM SDK  4.0.0.0, and it seems that the suggested ./wlan_cu command connects to wpa_supplicant with success (though I have not tried actually connecting to a network). However when I try to use one of the wpa_supplicant utilities directly such as wpa_cli or wpa_gui they fail to connect to wpa_supplicant. This being said I was wondering why wlan_cu is used instead of the wpa_cli?

Additionally any feedback as to the feasibility of using the wpa_supplicant interfaces with the TI WLAN stack would be greatly appreciated, in the end I would like to see wpa_gui talking to wpa_supplicant (wpa_gui builds and runs fine, it just does not detect wpa_supplicant and thus will not do anything).

  • The configuration utility (wlan_cu) provided by TI is used to configure the TI WLAN driver and FW, to perform
    most WLAN operations, such as scanning, connecting and to perform TX, RX and calibration procedures.

     

  • sinoj issac said:
    The configuration utility (wlan_cu) provided by TI is used to configure the TI WLAN driver and FW, to perform
    most WLAN operations, such as scanning, connecting and to perform TX, RX and calibration procedures.

    I get that part, and it does work, but I am trying to figure out why the wpa_supplicant interfaces (wpa_cli, wpa_gui) are not working directly, as it looks like wpa_supplicant is being used underneath wlan_cu. Was wpa_supplicant modified to work with wlan_cu or is there some run time option that allows only wlan_cu to work?

    In the end I want to have a working graphical configuration interface for the wifi, so if I can get wpa_gui to work with the wpa_supplicant being used by wlan_cu that seems to be the fastest route. I suppose the alternative would be to write a new graphical utility, or modify wpa_gui to work like wlan_cu, but I want to be sure there is no way that wpa_gui will ever work out of the box before creating a TI specific configuration utility. In general if we can get the default wpa_supplicant interfaces working properly it opens up the TI WLAN driver to a much wider open source community audience.

  • I tried wpa_cli with parameters and got this:

    root@dm3730-am3715-evm/# wpa_cli -i tiwlan0 -p /var/volatile/ru
    n status
    ioctl[SIOCGIFADDR]: Cannot assign requested address
    wpa_state=ASSOCIATING
    Supplicant PAE state=DISCONNECTED
    suppPortStatus=Unauthorized
    EAP state=DISABLED
    root@dm3730-am3715-evm:/#

    I'm not sure if it worked or not.

    Steve K.

  • Steve Kipisz said:
    I'm not sure if it worked or not.

    I think this is actually a positive response, I should have done more digging into the options you pass into wpa_cli and wpa_gui (I assumed they would 'just work' like wlan_cu), when I use your options with wpa_gui (which unfortunately does not have a --help response) I get a connection with the supplicant, and I can at least perform a scan and get a couple of networks back. I need to get a better setup for testing this with a more typical access point, perhaps at home, to really verify it is working, but this is a big step forward. Thanks for the help, I owe you one.