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.

NDK: DHCP Client 'dies' after re-newal & re-binding fails

Part Number: MSP432E401Y

Hi,

I noticed that the system (DHCP client) becomes unreachable from the network once the DCHP client's renewal and rebinding fails. I had supposed that once the re-newal of the client DHCP request msg fails, due to a problem on the DHCP's server side, it would try endless using DHCP's client discovery messages. However this is not the case. It is correct that it falls back to the D state ("DORA" Discovery, Offer, Request & Ack) once re-newal (R-state) times out. However after discovery times out as well, the system basically gets unreachable on the network and remains in that state. How can this be changed? We will have close to 100 nodes on our train based network and we are unable to turn-off power in order to force a restart on these nodes. What shall we do in order to guarantee proper network re-configuration once the DHCP server issue is being resolved after a scenario described above?

SW used: simplelink_msp432e4_sdk_3_20_00_10

  • Hi ngrkus,

    Perhaps you can switch between a static and dynamic address, but you will have to remove one before switching to the other. Here is a post with instructions on how to remove a static IP address - which you should do before enabling DHCP.

    Thanks,

    Alexis

  • Hi Alexis,

    thank you for your advice. However in our application it is a customer requirement to use DHCP. Before changing the codebase of the NDK I would like to understand why the dhcp client behaves this way. Maybe I do overlook something. That's why I am asking. Just to make it hopefully more clear I repeat the actual scenario:

    1.) dhcp is working as it should. The requesting client gets all the information that is needed.

    2.) Both dhcp servers do fail - the main and the backup dhcp server.

    3.) The client tries to re-newal its IP address due to the lease time running out

    4.) No replies from the servers, since both of them are off-line.

    5.) After a specific calculated time period the client falls back from dhcp requesting state to its discovery state. It is desperatly reaching our for a responding server. No respone from the servers. Still both of them are offline.

    6.) After another specific calculated time period the dhcp client stops sending discovery frames at all. The DHCP service on the client itself is dead from now on.

    7.) After some time one or two of the dhcp servers come back to live and are ready again for the DHCP DORA sequences.

    8.) However since the dhcp client service is dead no discovery frames are send out anymore. The dhcp client remains off the network until power cycling or until a reset condition occurrs.

    This behavior is not useful in our case. We can not easily power off the unit, and we cannot easily do a reset on it. We need to have the dhcp client's on the network remain in permanent discovery state OR switch to a self assigning IP address algorithm once the discovery time period expires.

    Q1.) What is the reason for the actual behavior? I may overlook something. I would like to understand better before changing code in the SDK network section.

    br

    Markus

  • Hello Markus,

    The NDK will only try to fallback on the discovery phase a finite amount of times. The default amount being 12. After it reaches that retry count it will close the dhcp client. 

    You could try changing the source code at ti/ndk/nettools/dhcp/dhcp.h to alter MAX_DISCOVER_TRIES to be a larger number.

    #define MAX_DISCOVER_TRIES  12          /*  Maximum attempts in INIT State */

    Alternatively you could change the code of the dhcp client state machine to ignore MAX_DISCOVER_TRIES all together by deleting the following lines in ti/ndk/nettools/dhcp/dhcpsm.c

        /* If we're out of tries, exit */
        if( ++MaxDiscover > MAX_DISCOVER_TRIES )
            goto Exit;

    Both of these options would require rebuilding the NDK libraries. Information on how to do that can be found here.

    Finally if you do not want to rebuild the NDK you can detect when the NDK is closing the dhcp client if you registered a callback function when creating the dhcp client. The callback function will be called with the integer argument set to NETTOOLS_STATE_FAULT + the current state. From here you could reboot the NDK stack by calling NC_NetStop() with an argument greater than 0. This will cause the whole NDK stack to reboot ultimately getting the dhcp client to restart.

    We have an example callback function that demonstrates detecting a failure in the dhcp client. I have modified it to call NC_NetStop() and placed it below for your reference.

    /*
     *  ======== serviceReport ========
     *  NDK service report.  Initially, just reports common system issues.
     */
    void serviceReport(uint32_t item, uint32_t status, uint32_t report, void *h)
    {
        static char *taskName[] = {"Telnet", "", "NAT", "DHCPS", "DHCPC", "DNS"};
        static char *reportStr[] = {"", "Running", "Updated", "Complete", "Fault"};
        static char *statusStr[] =
            {"Disabled", "Waiting", "IPTerm", "Failed","Enabled"};
    
        Display_printf(display, 0, 0, "Service Status: %-9s: %-9s: %-9s: %03d\n",
                taskName[item - 1], statusStr[status], reportStr[report / 256],
                report & 0xFF);
    
        /* reboot the stack as the dhcp client has been closed */
        if ((item == CFGITEM_SERVICE_DHCPCLIENT) &&
                (status == CIS_SRV_STATUS_ENABLED) &&
                (report & NETTOOLS_STAT_FAULT)) {
            NC_NetStop(1);
        }
    }

    Regards,
    Dalton




  • Hi Dalton,

    thank you for the clarification.

    br

    Markus

**Attention** This is a public forum