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.

Exosite internet client high count TCP/UDP receive packet drops at various times.

Guru 56398 points

Has anyone else been seeing similar issue, monitored via LWIP debug stats, high counts of TCP receive packet drops? 

The Exosite TCP client eventually uses up all available HEAP memory on the XL-TM4C1294XL launch pad in trying to re connect to the server. No amount of Tweaks to (lwipopts.h) can augment high counts of (bad) packets coming from the internet, server or server network.

During morning and afternoon hours the Exosite client has a typical & very low count of receive packet drops. Client often runs for hours without interruption or (PCB) memory leaks. Our internet provider states packet loss is coming from an up stream source.

Do not believe the ISP is being completely honest. Believe TCP traffic shaping is causing packet delay frame corruption that only effects the Exosite http client SYNC ability when UDP has a bind to TCP stack. The Ethernet client with a UDP bind other than a DNS Broadcast has heap memory leak issues that escalate with packet loss. Oddly DNS is using UDP whether enable in LWIP or not.

LWIP 1.4.1 appears to default into a UDP broadcast schema when no UDP bind is configured.

  • * Interesting how LWIP host can receive UDP packets without LWIP_UDP enabled in (lwipopts.h), so required by LWIP doc notes for DNS. Receive packet drops seemingly bomb the UDP (pcb) and at times quickly corrupt the memory pool Heap. LWIP IP debug shows DNS packets are received and transmitted on UDP port 53.

    LWIP web Wiki states the definitions for (lwipopt.h) #defines are listed in (opt.h),  Clearly is not the case as some defines cause compiler errors if or when a value is set as the text states. One example is the time outs define. You can't make this stuff up, it was here all along. Seemingly many Ethernet configuration parameters are being enabled from (opt.h) when (#ifndef) in (lwipopt.h) making it impossible to trouble shoot heap memory issues. 

    http://lwip.wikia.com/wiki/LwIP_Wiki

    Update high count packet drops:

    2.24.2015: https://e2e.ti.com/support/microcontrollers/tiva_arm/f/908/t/417592

    The Sys_Timeout list of argument value total is not asserted here if {NO_SYS == 1} in (lwipopts.h) 

    /**
     * MEMP_NUM_SYS_TIMEOUT: the number of simultaneously active timeouts.
     * (requires NO_SYS==0)
     * The default number of timeouts is calculated here for all enabled modules.
     * The formula expects (argument list values) to be either '0' or '1'.
     */
    #ifndef MEMP_NUM_SYS_TIMEOUT
    #define MEMP_NUM_SYS_TIMEOUT     (LWIP_TCP + IP_REASSEMBLY + LWIP_ARP + (2*LWIP_DHCP) + LWIP_AUTOIP + LWIP_IGMP + LWIP_DNS + PPP_SUPPORT)
    #endif

     
  • The reported time window mysteriously changed after posting to an all hour event.

    Seemingly it is Not necessary to set DNS server LWIP options unless a DNS server will be running locally in the TCP stack. Exosite connect to server function has the host server IP address embedded in software and the (m2.exoiste.com) domain name is only placed in the http header per RFC packet transfer rules. The open socket function does not need to name resolve and likely only uses an outside DNS query to check for an internet connection to mark the socket ok.

  • No need for DNS timer in order to use (dns.c) symbols only for host name resolve function (dns_gethostbyname). Then (LWIP_DNS == 1) enable does not require LWIP_UDP== 1 to be enabled.

    4.23.2015 Sneaky LWIP v.1.4.11 have most all NETIF setting configured in (opt.h). TI programmer only added a few overrides in (lwipopts.h). Many over rides do not function in (lwipopts.h) we must add {#include "lwip/opt.h"} then things get better in LWIP stack.

    Notes:

    Client DNS (per RFC) 1st broadcast query connectionless UDP53, if fails then connects to TCP 53 to get Host name to IP resolve.

    Possible UDP memory leak LWIP issue and how UDP protocol even work when disabled in (lwipopts.h) makes for an interesting coffee break discussions at the water cooler.  LWIP services these two timers no matter if enable or disable here has no effect the timers still assert as shown below during host client timer asserting.

    void
    lwIPHostTimerHandler(void)
    {
        uint32_t ui32IPAddr;
        err_t eError;
    
    #if NO_SYS
        //if(HWREGBITW(&g_sEnet.ui32Flags, FLAG_TIMER_DNS_EN))
        //{
         //   dns_tmr();
        //}
    
        //if(HWREGBITW(&g_sEnet.ui32Flags, FLAG_TIMER_TCP_EN))
        //{
           // tcp_tmr();
       //}
    #endif // #if NO_SYS

  • LWIP internal timer services both DNS/TCP timers. The two calls above post seem to be redundant. Auto IP DHCP should assign two Name servers IP addresses for (dns.c) name resolves.

    //*****************************************************************************
    //
    // This function services all of the lwIP periodic timers, including TCP and
    // Host timers.  This should be called from the lwIP context, which may be
    // the Ethernet interrupt (in the case of a non-RTOS system) or the lwIP
    // thread, in the event that an RTOS is used.
    //
    //*****************************************************************************
    #if NO_SYS
    static void
    lwIPServiceTimers(void)
    {
    ~~~~~~~~~~~~~~
    
        //
        // Service the DNS Timer
        //
    #if LWIP_DNS
        if((g_ui32LocalTimer - g_ui32DNSTimer) >= DNS_TMR_INTERVAL)
        {
            g_ui32DNSTimer = g_ui32LocalTimer;
            dns_tmr();
        }
    #endif
    
        //
        // Service the link timer.
        //
    #if LWIP_AUTOIP || LWIP_DHCP
        if((g_ui32LocalTimer - g_ui32LinkTimer) >= LINK_TMR_INTERVAL)
        {
            g_ui32LinkTimer = g_ui32LocalTimer;
            lwIPLinkDetect();
        }
    #endif
    }
    #endif
  • Settings made to #defines in (lwipopts.h) do not always Sanity check against settings in (opt.h) and confuse anyone making changes only in (lwipopts.h) may lead to Sanity conflicts.

    Placing include (lwipopts.h) atop (opt.h) appears not to preform a backwards Sanity check (bool) for any (true) settings in (opt.h) then made (false) in (lwipopts.h). The opposite is then true when actually false in ones mind after enabling the feature to be true.

    4.23.2015:

    (Memp_std.c) reverses the if (!) flag asking to build (MEMP_OVERFLOW_CHECK==1) adding space to each PBUF even though being enabled in (lwipopts.h) if not enabled in (opt.h). The Boolean appears to invoke only from (opt.h) unless the (!) is removed then it invokes from (lwipopts.h). 

    https://e2e.ti.com/support/microcontrollers/tiva_arm/f/908/t/412465