RTOS/TMS320C6657: NDK change IP address at runtime

I forget to add a link for a firther bugfix:
e2e.ti.com/.../498342

Hi Bernhard,

The SW team is notified. They will post their feedback directly here.

BR
Tsvetolin Shulev

Dear Tsvetolin,

thanks for the fast feedback!

I was able to do a first --successful-- test with all the bugfixes merged.

KR
Bernhard

Hi,

Are you still use the NDK 2.26.00.08 with all the bug fix merged yourself? And succeeded for the test? The latest NDK we tested on C6657 is 2.26.00.08. We used to publish NDK download here: software-dl.ti.com/.../index.html. But now we bundle the NDK with any Processor SDK RTOS release, like C6657, release them quarterly. So we don't have a new NDK with all of them fixed publicly.

Regards, Eric

Eric,

yes, we are using NDK 2.26.0.8 and I have merge the bugs by myself.

Yes the first tests were successfull.

Honestly, I think it is really bad to not share any NDK updates/bugfixes to the officially NDK downloads site. Is it intended to search all possible SDK download sites to get a critical bugfix?

If you do not plan to update the official NDK download site is it possible to post a link to all official SDK downloads? This enalbes me from checking from time to time whether a bugfix was made withing an other processors SDK?

By the way a small change is necessary in the original bugfix from Steven Connell. To avoid the SockClose() to be called twice:

/**
 *  @b Description
 *  @n
 *      The goal of this function is to allow a clean
 *      reboot/shutdown or IP address change, without leaving any dangling
 *      sockets. Additionally, control must be given back to an application
 *      thread that's using an affected socket, so that it can handle such a
 *      change appropriately. NOTE: This function should never block!
 *
 *      The function cycles through all the socket entries for the
 *      specified protocol family and closes any socket which matches the
 *      IP Address specified. The function was added to ensure that when
 *      an IP address is modified OR when the stack is shut down or rebooted,
 *      then any sockets matching the IP Address provided are closed.
 *
 *      There are 3 special cases - linger sockets, lingering sockets and
 *      listen queue sockets.
 *
 *      1. Linger sockets are sockets that will linger for a time period prior
 *      to closing down. Since a close on a linger socket that's initiated from
 *      this function would result in lingering, the linger option is disabled
 *      for such sockets prior to closing.
 *
 *      2. Lingering sockets are currently in the process of being shut down by
 *      their owning thread. No lingering sockets should be killed here, as
 *      this results in the owning thread having the 'rug pulled out' from under
 *      it and will crash as a result. This function forces lingering sockets
 *      to stop lingering and allows the owning thread to finish the job it
 *      already started.
 *
 *      3. Listen Q sockets are the queued up incoming connections that are
 *      chained to a socket that is currently accepting connections (i.e.
 *      blocked on a call to accept()). Listen Q sockets must be closed in a
 *      special way, otherwise a crash may result (similar to the reasons given
 *      for lingering sockets).
 *      In all cases, the socket is set to have an error and signaled so that
 *      the owning thread can handle this change (e.g. so a call blocked on
 *      recv() will return with error, or the next socket operation attempted
 *      will fail).
 *
 *      This is for *internal* NDK Stack Usage.
 *
 *  @note You must call llEnter() prior to calling this function, and
 *      llExit() upon returning from this function.
 *
 *  @param[in]  SockProt
 *      Socket Family
 *  @param[in]  IPAddress
 *      OLD IP Address to which a socket might be bound to and which needs
 *      to be cleaned.
 *
 *  @retval
 *      Not Applicable
 */
void SockCleanPcb (uint SockProt, IPN IPAddress)
{
    SOCK *ps;
    SOCK *psNext;
    int   error;

    /* Validate the socket protocol family. */
    if ((SockProt < SOCKPROT_TCP) || (SockProt > SOCKPROT_RAW)) {
        return;
    }

    /* Cycle through all the entries in the socket table. */
    ps = pSockList[SockProt];
    while (ps != NULL)
    {
        /* Save next entry before SockClose() sets it to 0 (fixes mem leak) */
        psNext = ps->pProtNext;

        /* Clean the entry only if we have a match */
        if (ps->LIP == IPAddress) {

            /*
             * Invalidate the socket. This causes any further socket API
             * calls on it to fail
             */
            fdint_setinvalid((FILEDESC *)ps);

            /* Set an error on the socket */
            error = ENETDOWN;
            SockSet((void *)ps, SOL_SOCKET, SO_ERROR, &error, sizeof(error));

            /*
             *  Signal the socket, allowing owning thread to handle the error
             *  and return
             */
            FdSignalEvent(ps, FD_EVENT_READ | FD_EVENT_WRITE | FD_EVENT_EXCEPT);

            /* Don't close lingering sockets here */
            if (ps->StateFlags & SS_LINGERING) {
                /*
                 * Unset the SS_LINGERING flag
                 *
                 * Lingering sockets are currently in the process of being
                 * closed by their owning thread, and are blocked awaiting a
                 * linger timeout. However, if the IP address is being removed,
                 * or the stack is shutting down, lingering no longer makes
                 * sense. Therefore, we unset the SS_LINGERING flag, which will
                 * (in combination with signaling the socket) allow the owning
                 * thread to break out of the while loop in SockClose() and
                 * finish closing the socket.
                 */
                ps->StateFlags ^= SS_LINGERING;

                /* Move on to the next socket */
                ps = psNext;
                continue;
            }

            /*
             * Kill the socket
             *
             * Listen Q sockets are special case; for all others, pass
             * to SockClose() directly
             */
            if (ps->StateFlags & (SS_READYQ | SS_PENDINGQ)) {
                /*
                 * If this socket is in a listening socket's ready or pend Q,
                 * then it must be removed from that parent socket's Q.
                 * Otherwise, a double free of the socket is possible as well
                 * as crash due to NULL pointer dereference of the hTP field.
                 */
                SockSpawnAbort(ps);
            }
            else {
                /*
                 * Unset the SO_LINGER option
                 *
                 * Do not linger when closing a socket from this function.
                 * For any linger socket, disable linger before closing.
                 * Lingering from this function results in race condition
                 * crashes due to the exit from kernel mode before sleeping for
                 * linger time.
                 */
                if (ps->OptionFlags & SO_LINGER) {
                    ps->OptionFlags ^= SO_LINGER;
                }

                SockClose(ps);

                /* Move on to the next socket */
                ps = psNext;
                continue;
            }

            SockClose(ps);
        }

        /* Get the next entry. */
        ps = psNext;
    }
    return;
}

Hi,

All the Processor SDK RTOS package (containing a NDK) is available here: software-dl.ti.com/.../index_FDS.html. The release schedule is the end of every quarter. The Q2 release is delayed to end of July.

For your question about NDK update/bugfix and comment to the above code, I asked my colleague in NDK team to comment.

Regards, Eric

Dear Ramsey,

alright! I will change as suggested. Thank you!

Would it be possible that you confirm that all these bugfixes to be contained within the next processor SDK end of September or even in the one end of this month??

Thank you very much for you prompt support and feedback!

Bernhard

Bernhard,

Unfortunately, the sum of the bug fixes discussed above are not available in a release. I looks like the current Processor SDK RTOS 4.03.00.05 release contains NDK 2.26.00.08, which you already have.

My guess is that the next Processor SDK will not have these fixes either. To explain, the NDK development has continued with new internal releases. By the time these bugs came to light, the NDK code base had moved on. These fixes have been applied on the latest NDK development base, but it will not be available until a future Processor SDK release. By then, so much will have changed, that it will not be compatible with your current NDK release.

The best I could do is back port the fixes to the NDK 2.26.00.08 release and give you a patch file which you could apply to your release. I should mention that the latest fixes are more comprehensive. They fix additional race conditions which have not been addresses in the bug fixes above. 

Would you be interested in this? It would take me a couple of days to work up the patches.

~Ramsey

Dear Ramsey,

I really appreciate that you are willing to provide a patch with the bugs I listed fixed. I am interested in it.

If I understand you right you will also add bugfixes that have already been fixed in the actual TI internal NDK state. Is this correct?

I have some questions regarding the latest TI internal NDK state. Is there chance I elect you some details? :-)
- The "Legacy Configuration Manager API", will it be removed or replaced? I am currently using it for changing IP parameters at runtime.
- Is there a chance to get a inofficial changelog?
- Could you give a cautious release date/quarter/year for it?

Bernhard