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.

CC3235SF: CC3235 STA failed to get IP address

Part Number: CC3235SF

Hi team,

These is from the customer:

The current use environment is 2 APs with 4 STAs, repeatedly switching into the network, AP to TCP Server, STA to TCP Client. When four STAs are connected to AP 1 at the same time, connect to the TCP server of AP 1, then disconnect all STA connections and connect to the TCP server of AP 2. This repeated operation results in a time when the STA cannot obtain an IP address from the AP, and a restart of the STA still cannot obtain an IP address, but the host does not have a status print. Don't know which link is wrong, how do I get this exception from the AP side and handle it 。

And debugMsg is open, no exception information is printed on the AP side, client can not connect on the STA side: -114 or sl disconnect reason 200, and then pass through the pair

void SimpleLinkNetAppEventHandler(SlNetAppEvent_t *pNetAppEvent) switch (pNetAppEvent->Id) enters default. The IP address is then also obtained through the pointer pNetAppEvent->Data.IpAcquiredV4 

Thanks & Best regards,

Yolande

  • Hello Yolande,

    I have assigned this thread to the relevant expert.

    Thanks,

    Rogelio

  • Hi,

    So the connect and disconnect for all 4 stations work most of the time and at some point fails?

    Basically, you should get two events for each station when connecting, the SL_WLAN_EVENT_CONNECT followed by SL_NETAPP_EVENT_IPV4_ACQUIRED. When disconnecting from the AP, you should get SL_WLAN_EVENT_DISCONNECT.

    Can you show the events you get for each station? the -114 is just when you try to connect to a server in non-blocking mode and you need to try again and the 200 reason is for WLAN disconnection.

    You can also actively probe for the WLAN status using the sl_WlanGet() API with option SL_WLAN_CONNECTION_INFO.

    Another option is to get logs from the internal NWP and see what is happening under the hood.

    Shlomi

  • Hi,

    Just a comment. I think issue may to be related to exhausting DHCP pool at AP side. As far I know DHCP server at CC32xx does not properly release address even after lease time expiration at some cases. Maximum size of DHCP pool is 32 as far I know.

    I think he should try:

    • At STA side use Address release option SL_NETCFG_IPV4_STA_ADDR_MODE -> SL_NETCFG_IF_ENABLE_DHCP_RELEASE
    • At AP side decrease lease time and check size of DHCP pool range

    Jan

  • Oh, I did not understand that the AP are also SimpleLink devices. If this is the case (please verify), then it is best to also check it.

    Thanks Jan

  • Hi team,

    This is from the customer:

    Sometimes it fails, printing via status, after this issue the SL_NETAPP_EVENT_IP_COLLISION event appears, indicating an IP collision. As for the SL_WLAN_EVENT_CONNECT and SL_NETAPP_EVENT_IPV4_ACQUIRED events that you said, status printing is done, but in exceptional cases, they are not printed.

    Then yesterday discovered the situation, the phone can still connect when there was a previous IP unassignment, but now after the problem, The mobile phone cannot connect to the WIFI. Print only SL_NETAPP_EVENT_IP_COLLISION and SL_WLAN_EVENT_STA_REMOVED events

    The main thing is now there is an IP collision event, or if the IP is used up, whether there are interfaces to clear these IPs, or restart the WIFI. The behavior of the AP active detection exception is reached, but all of this requires the AP to meet some condition, that is, if no IP is acquired, through printing on the AP side. The event that occurred when the exception occurred was not found .

    Thanks & Best regards,

    Yolande

  • Hi,

    It would help if you can provide a high level diagram of all components. Is CC3235 a station? AP? both? 

    how do you set the IP address? DHCP? static?

    Regards,

    Shlomi

  • Hi,

    This is AP Set

    And,The state of the anomaly last night

    The module does not have any other print except this print information, and the restart of STA cannot be solved, only the restart of AP can continue to use, but I have checked the relevant API interface, there is no way to delete the port STA according to the MAC address

  • Hi,

    Can you try to set at STA device this?

    Fullscreen
    1
    2
    3
    Status = sl_NetCfgSet(SL_NETCFG_IPV4_STA_ADDR_MODE, SL_NETCFG_ADDR_DISABLE_FAST_RENEW,0,0);
    Status = sl_NetCfgSet(SL_NETCFG_IPV4_STA_ADDR_MODE,SL_NETCFG_IF_ENABLE_DHCP_RELEASE,0,0);
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    I think this may to decrease failure rate.

    Jan

  • Hi,I try to set NETCFG_IF_ENABLE_DHCP_RELEASE,but return me error  

  • Hi,

    I am not sure why this API is not working at your case and error SL_ERROR_INVALID_PARAM is returned.According SWRU455 it should work.

    What SDK is used? What ServicePack is uploaded inside device?

    Jan

  • SDK Version is 4.10.0.07,and Service Pack is sp_4.6.0.1_3.1.0.5_3.1.0.25

  • Hi,

    This is pretty old SDK and ServicePack. It is almost four years old SDK. It is not best idea to use such old ServicePack because your device may to be affected by some security vulnerabilities.

    Are you able test with latest SDK or at least update ServicePack?

    Jan

  • So if an exception occurs, such as a SL_NETAPP_EVENT_IP_COLLISION event, there is no way to recover? Now in the case of continuous printing of this event, I am directly resetting the AP device. Because this is a very old project, there is not enough time to port the SDK

  • Hi,

    I am not sure why this event (SL_NETAPP_EVENT_IP_COLLISION) is continuously called. But I think NWP reset (sl_Stop() / sl_Start()) should be enough for recovery.

    I think you should to try update ServicePack at AP side at least, if you don't want to update SDK.

    Jan

  • Hi,

    I ported some of the code to the SDK version simplelink_cc32xx_sdk_7_10_00_13, but this problem still occurs. Moreover, on the old SDK, I found that serial port printing SL_NETAPP_EVENT_IP_COLLISION is not continuous printing, sometimes 7-8 tasks will be printed at one time. I suspect that tasks with high priority have been processed, thus affecting serial port printing

  • Hi,

    Has you update Service Pack together with SDK?

    I am not able to say what is going on without debugging real code. Maybe if you capture NWP log from your AP and STAs at same moment, maybe there can be some clue. How to capture NWP log you can find at SWRU455 chapter 20.

    Jan