CC3220SF-LAUNCHXL: DHCP ceases to assign IPs after multiple connect/disconnects

Sarah Pelosi said:

Hi Andrew,

We haven't seen this issue before, but I can test the demo and try to recreate it.

1. How long does it take for the DHCP to disappear?
2. Are you using a custom board or a LaunchPad?
3. Are you connecting multiple devices every so often, or connecting and reconnecting one? Please explain the use case/setup where you are seeing this issue. Are you in an especially noisy environment?
4. Any other relevant details?

Best regards,
Sarah

1. It seems to vary.  Sometimes a couple days and then sometimes it seems like the same day.  Its been difficult to pinpoint and I have to power cycle to get it out of that state.

2. It is on a custom board using a CC3220SMOD and pretty much copies the Launchpad otherwise.

3. Only one device gets connected to it off and on just to check the status, mainly just me seeing if it is still running.  It's basically sitting in a metal box outside, antenna sticks out the box.  There is a small motor that can run sometimes, but I'm just not sure how noise or some environmental condition would stop just the DHCP from running.  Web server still works fine and device never shows a sign of reset because the system up-time never resets

4. It appears the code is continuing to run and it does let a device connect because I get the "device connected message" along with the MAC address, it just doesn't assign it an IP address and so the device that attempts to connect starts assigning itself a link local address.  Everything else works fine if I give the device a static IP.

capture2.zip

I've attached a wireshark capture that began just before I connected to the simplelink wifi network while it is in the state of not acting like a DHCP

Hi Andrew,

I have a setup for this, but I haven't replicated the issue yet. I'll take another look at it today and get a response to you tomorrow or Wednesday.

To clarify, are you using the latest CC3220 SDK v1.50.00.06 and service pack?

Best regards,

Sarah

Hi Sarah,

Any more news on this?  I did power cycle the setup and after the weekend, the dhcp stopped responding again.  Is there any way to test whether it is running or not with a simplelink API call?  I'm thinking of having my code poll it to check and see if it is still running and maybe record the time it happened.  If there is any other information your team could share on the system architecture that might point to why this is happening, it would be greatly appreciated.

Sarah Pelosi said:

Hi Andrew,

Unfortunately, I have not been able to replicate this issue.

1. Are you using SDK v1.50.00.06 and the latest service pack?
2. Are you configuring the DHCP in your application code?
3. Are you able to capture NWP logs from your setup? processors.wiki.ti.com/.../CC3120_&_CC3220_Capture_NWP_Logs

There is no way to check the current state of the DHCP server, just the parameters (sl_NetAppGet). The other option is to try what Jan suggested earlier and restart the DHCP to check for error codes.

Best regards,
Sarah

1.  SDK is 1_30_01_03

2.  Yes, it is getting set, I believe, in the provisioning task function ConfigureSimpleLinkToDefaultState(void).  I set it to AP mode at power on by the following:

        RetVal = sl_WlanSetMode(ROLE_AP);

        if (RetVal == 0)
        {
            UART_PRINT("Signal AP mode --> provisioning task (normally done by SW2 handler)\n\r");

            // indicate AP role on OCP register
            uint32_t ocpRegVal = MAP_PRCMOCRRegisterRead(OCP_REGISTER_INDEX);
            ocpRegVal |= (1<<OCP_REGISTER_OFFSET);
            MAP_PRCMOCRRegisterWrite(OCP_REGISTER_INDEX, ocpRegVal);

            //mcuReboot();
         }

3.  I'll have to work on this since it is remotely located currently.

Sarah,

I've been still working on this issue. I've found out what appears to be causing it. If I do enough rapid connects and disconnects from the simplelink AP I eventually get a different message from the DHCP.  Sorry, it sounds a bit crazy, but this has been the only way to get it to occur in any repeatable manner, otherwise it is completely random.  It also appears that doing a webpage refresh of 10.123.45.1/demo.html immediately after hitting the connect button on a phone helps things along... not sure why?

It appears once this "Peer released" message occurs, the DHCP no longer continues to function and any device that tries to connect after that occurs resorts to using link local addressing. I'm not sure what to do because I feel it is beyond my control.

[WLAN EVENT] External Station disconnected from SimpleLink AP
[NETAPP EVENT] IPv4 released 10.123.45.2 for device xx:xx:xx:xx:xx:xx
Reason: Peer released

I've now confirmed the issue on CC3220Launchpad-XL hardware and custom hardware, running Out of Box Demo and also my modified version using the 1.3SDK.

UPDATE:

I then briefly tested Out of Box using the 1.5SDK and it appears that it does a better job and leases an IP after a peer release.  I'm having issues getting my custom out of box demo to build under the latest SDK so it will take me some time to port it over it appears...

Sarah,

I just moved my code over to the latest SDK, the DHCP issue still continues to occur. Maybe I was having good luck yesterday with the lastest SDK and the OOB demo and somehow managed to avoid the issue. I still see the following when it occurs:

[NETAPP EVENT] IPv4 released 10.123.45.2 for device xx:xx:xx:xx:xx:xx
Reason: Peer released

This appears to be somewhere in the DHCP code on the network processor and I'm assuming there is some sort of race condition occurring.  It seems to be much easier to reproduce when there is a webpage refresh immediately following an initiation of a station connection to the simplelink AP.  I also find it strange that when you disconnect a station from the AP, you get an IPV4 release, reason: peer released, and then a lease event again, but not always.  It appears that this "dhcp lockup" occurs when the dhcp fails to do the "lease" step after the "release"

Can you get someone to look into this issue further?  This is show stopper at this point.

Thanks

TI, any response to this?  This appears to be a bug with the network processor that is outside my control.  Please advise.

Sarah,

I have attached a NWP file that captures the DHCP issue using the latest SDK.  I connected and disconnected 3-4 times and then the issue occurred.  Again, I can't stress enough how big of an issue this is and pretty much makes this part unreliable from an end use standpoint.  

Thanks

nwp_log_1_50_0_06_DHCP_Lockup.log

Hello Andrew,

The sniffer capture as you say is only after the problem occurs.

Might be useful to capture some time earlier but I have also looked at the NWP logger  and I do see getting the DHCP DISCOVER and sending back DHCP OFFER (which doesn't get response).

Can you elaborate regarding what you do on the client side when IP is released? Are you originating it from the client (this is what I see at least)?

Lastly, you are using servicepack 3.3.0.0 and there is a newer 3.5.0.0 with some fixes. Can you try it out just to align on the latest? it does not involve any porting/migrating of any kind. This is the NWP set of patches.

Regards,

Shlomi