CCS/CC3220MOD: What is value of DHCP Lease Time, Where set in Network Terminal Example, Could Not Find With CCS8

IIRC, at the start of the test, I connected my Galaxy 7 phone to the DUT and was probably assigned 10.123.45.2 and then the MAC PC would have been assigned 10.123.45.3. So perhaps after a DHCP lease expired for the MAC on 10.123.45.3 it was reassigned to 10.123.45.2 and now the socket connection was broken.

Jan,

Thanks for the clues to the lease time setup.  In SWRU455 programers guide I found some example code I worked into the ConfigureSimpleLinkToDefaultState() function right before the WAN policy set. 

     /*Set DHCP lease time. */
     SlNetAppDhcpServerBasicOpt_t dhcpParams;
     _u8 outLen = sizeof(SlNetAppDhcpServerBasicOpt_t);
//     dhcpParams.lease_time      = 4096;                         // lease time (in seconds) of the IP Address
     dhcpParams.lease_time      = 300;                          // 5 minute lease time (in seconds) of the IP Address
     dhcpParams.ipv4_addr_start =  SL_IPV4_VAL(10,123,45,2);   // first IP Address for allocation. IP Address should be set as Hex number - i.e. 0A0B0C01 for (10.11.12.1)
     dhcpParams.ipv4_addr_last  =  SL_IPV4_VAL(10,123,45,5);   // last IP Address for allocation. IP Address should be set as Hex number - i.e. 0A0B0C01 for (10.11.12.1)
     sl_NetAppStop(SL_NETAPP_DHCP_SERVER_ID);                   // Stop DHCP server before settings
     RetVal = sl_NetAppSet(SL_NETAPP_DHCP_SERVER_ID, SL_NETAPP_DHCP_SRV_BASIC_OPT, outLen, (_u8* )&dhcpParams);  // set parameters
     sl_NetAppStart(SL_NETAPP_DHCP_SERVER_ID);                  // Start DHCP server with new settings

     if( RetVal )
     {
         // error
         UART_PRINT("sl_NetAppSet: Failed to configure device DHCP Lease Time");
     }

I have built this and put it into a unit. I set the lease time to a short value in hopes of duplicateing the failure with out waiting 12 hours.

I ran the code from the CCS8 debugger. I connected the Galaxy 7 phone to get 10.123.45.2. I disconnected the phone and connected to the unit under test with a Windows lap top as a station (10.123.45.3) running our control software. I used IPCONFIG to check the lease and waited for the time out to see if the communication failure would occur on a Windows PC. It did not. The IP address lease got extended by 5 minuets when ever the time got with in less than 3 minuets of the lease time out.

We then disconnected the Windows PC, and then connected the Galaxy phone which again got 10.123.45.2. I disconnected the phone. Then we connected the MAC PC which got address 10.123.45.4 and we ran the control software. The MAC control PC has run several time the 5 minuet lease with out loss of communication. So I was not able to duplicate the problem.  We will let it continue to run and capture the Debug UART output.

<edited>

Hi,

I not understand your use case. I am not sure what side is a server and what side is client and whether UDP or TCP sockets are used. But common way how to dealt with changing IP addresses is to use some kind of discovery protocol. In similar case I use own discovery protocol based on UDP broadcast.

Information what you provided at your last answer looks pretty normal.

Jan

Regarding, "I am not sure what side is a server and what side is client"   My bad. I will give better details. We are using a TCP socket.  Our product (the ST365 with the CC3220 in it) is the AP and running the socket server.  The MAC PC is connecting as the STA with socket client.

Regarding the changing IP address, we had not thought about this case before and our MAC PC desk top application has no countermeasures for what happens if the IP address changes. (FYI our desk top software can also control the product through a wired LAN connection and has been extensively tested this way. However the wired LAN IP addresses rarely change.) We have only just begun to do long (over night) tests with the WiFi LAN and had this problem the first over night run. Two other over night runs have not duplicated the problem.

Regarding "...dealt with changing IP addresses is to use some kind of discovery protocol"  I would like to get smarter. Can you outline the steps?

I was thinking that the MAC PC control program would need to try to find the instrument again even though it is now on another IP address of the AP to which the MAC PC is still connected. This is a case we had not anticipated.

<edited>

Hi,

In such use case you don't need implement discovery protocol. Because your client (PC, cell phone) always know IP address of opposite side (CC3220). This address will be always same as IP address of gateway (obtained via DHCP protocol).

Yes when IP address of your client (PC, cell phone) is renewed and changed your opened socket is not valid  never more. I expect that exception will be fired at your PC or cell phone app. Your code need dealt with this and reconnect. But there may to be hidden a trap. Your TCP socket may not be closed properly by four way handshake. And your socket may to be occupied at CC3220 TCP server till keep-alive time expire. Easiest solution of this issue is to use TCP server for multiple clients.

Jan

Hello Jan,

Regarding, "In such use case you don't need implement discovery protocol. Because your client (PC, cell phone) always know IP address of opposite side (CC3220). This address will be always same as IP address of gateway (obtained via DHCP protocol)."
Thanks for confirming my understanding.

Regarding, "...when IP address of your client (PC, cell phone) is renewed and changed your opened socket is not valid  never more...."
Unfortunatlly I cannot find a way to duplicate the problem. With the lease time set for 300 seconds and a MAC PC running our instrument control desk top firmware connected to 10.123.45.4 we left it run overnight (>12 hours) and the socket connection was still working this morning when I started work.

I am wondering if some brief interuption of the RF path might trigger the event but I have dreamed up a way to do so. I tried wraping aluminum foil around our instrument which reduced the signal a lot but the MAC PC never lost connection. Neither the instrument, connected into my work bench development environment nor the MAC PC is very portable for experiments involving increasing RF path length.

If it is not a loss of the RF link what else might have triggered the IP acquisition from the event I reported?

Hi,

Hard to say what may to be wrong. But I don't believe that your issue is RF related. In case issue at RF side, you will disconnected from AP likely. In your log is not disconnect event shown.

You should implement reconnect algorithm into your PC app definitely. In case your TCP connection is terminated by some reason, you application need to repeat connection attempt. To determine reason of issue you should capture network log by sniffer (e.g. Wireshark) as well.

Jan

Hello Lee,

Are you also monitoring the net app event handler for DHCP events? I you're getting IP release or IP collision event that might explain some things. That aside, you should still have a reconnect algorithm in place like Jan suggested.

Information on events in section 5.7 here.

Jesu

Jesu,

Regarding, "Are you also monitoring the net app event handler for DHCP events?"  I did not know so I went into the SWRU455 section 5.7 and read a bit. That lead me to a project search for "slcb_NetAppEvtHdlr" with out success.

Our code is based on the network_terminal example and there is the "SimpleLinkNetAppEventHandler" in the network_terminal.c file. So I think this is the event handlere of which you asked.

I just added "UART_PRINT("\n\r[NETAPP EVENT] IPV4 IP Acquired");" to the only case that had no UART messages, the "SL_NETAPP_EVENT_IPV4_ACQUIRED" case.

There is no case for SL_NETAPP_EVENT_IP_COLLISION in the code. I will try to add one that at least reports the collision out the UART PRINT. (Looks like SL_NETAPP_EVENT_IPV4_LOST,  SL_NETAPP_EVENT_DHCP_IPV4_ACQUIRE_TIMEOUT, and SL_NETAPP_EVENT_IPV6_LOST are all events which currently do not have a case in the code.)

Thanks for the question.  As I said, our code is based on the network_terminal example and I am the third person to be working with it. (I am a physicist who pretends to be a EE hardware designer who some times struggles with code.)

Thanks,

Jan,
Jesu,

More information. We have again run another afternoon and night with the MAC PC controlling our instrument and no connection failures. And I have set the lease time to 5 minuets.

Regarding, "You should implement reconnect algorithm into your PC app definitely."  I am reluctant to ask a co-worker to make changes with out a way to reproduce the original failure so that we could test such changes.

The total clue we have is that the Net App event handler reported the lease of 10.123.45.2 and then control was lost and the Socket was closed..

If not the lease time, what else might trigger the reassignment of IP address?

Further experiments.
Our AP is set up to lease only one IP address. Our terminal set up is: "wlan_ap_start -s "ST365SN3" -t OPEN -c 6 -txp 10 -l 1"

While the MAC PC was connected and controlling the instrument on address 10.123.45.4 through the socket server, I tried connecting my Galaxy 7. The Galaxy 7 was refused the WiFi connection with no report out the Debug UART, and no loss of control by the MAC PC.  This is what I would expect with the AP set to lease only one IP address.

So I conclude the original error was not caused by another wireless client device interfering by trying to connect to our instrument.

Hi,

DHCP request comes from client (your computer) side. Hard to say how works DHCP management at your computer side. Wireshark log may to give you a clue what is going on.

If you want simulate this issue with normal AP, you can use this way(s):

1. Using infrastructure Wifi router (requires CC3220 code changes)

• use STA mode with CC3220 and connect your Wifi router
• set static IP address lease (set specific IP to specific MAC address)
• set short DHCP lease time
• connect your computer to Wifi router, connect your app and communicate with server inside CC3220
• change static lease IP for your computer at Wifi router
• wait till leas expires and new IP is assigned

2. Using router with with AP and client mode (no CC3220 code changes required, need to use router with AP and STA capability - OpenWRT device recommanded)

• connect your router to AP inside CC3220
• create new Wifi network at your router with new subnet
• set port forwarding between two subnets
• set DHCP server inside your router (to 2nd network)
• use same way as at point 1

Jan

Hello Jan,

I have read and understand your suggestions. Thanks. I had not thought of how introducing a third party, the WiFi router, might give me additional methods to probe and force the behavior.

Hi Lee,

You are correct, these events are invoked in the SimpleLinkNetAppEventHandler. I think the events that would concern you would be when the IP gets released and if there's a collision. These additional checks will give you insight whether or not the AP releases the IP and if there's an IP collision. These can be easily added like below in the switch case of the SimpleLinkNetAppEventHandler. 

case SL_NETAPP_EVENT_DHCPV4_RELEASED:
        // insert code here
        break;

case SL_NETAPP_EVENT_IP_COLLISION:
        // insert code here
        break;

Jesu,

Thanks for getting back to me.

I have updated the event handler case statement to report out the UART PRINT the missing cases and we have set the MAC PC again running it for an endurance test.