lwip-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lwip-users] Packets stop sending after a while when MEMP_OVERFLOW_C


From: Sebastian Gniazdowski
Subject: Re: [lwip-users] Packets stop sending after a while when MEMP_OVERFLOW_CHECK isn't 2
Date: Thu, 26 Apr 2018 13:25:19 +0200


I've tried to use *_OVERFLOW_CHECK == 0 and simulate the slowdown it causes by sys_msleep(1). It does help, i.e. program behaves like when *_OVERFLOW_CHECK == 2, sends 200k packets without hang. The sleep is placed after the sending of each ping packet (how they are being send is described below). Can sending 254 packets through RAW socket in a loop – without sys_msleep(), i.e. tight, fast – cause problems? One person suggested to me that I might starve TCPIP thread, also by problematic thread priorities (didn't check that yet).

I send 254 packets (pings), wait 5 seconds, repeat. It is this thread that basically hangs when the sending loop isn't slowed down. The hang is: instead of pings, I see (wireshark) ARP query (for HWADDR of gateway) every second. LWIP_STATS reveal that the response for this ARP request (sent by the gateway) is ignored:

ETHARP
        xmit: 3
        recv: 2

ETHARP
        xmit: 4
        recv: 2

ETHARP
        xmit: 5
        recv: 2

ETHARP
        xmit: 6
        recv: 2

etc. Basically, ETHARP sees that it sends ARP request (because "xmit: ..." increases), and it really does send it, but the response to the request is ignored – "recv: 2" doesn't increase.

A basic conclusion that can be done: the gateway at some point disappears from ARPTABLE and this triggers second ARP request to reestablish it in this cache. Constant "recv: 2" suggests that ARPTABLE isn't fixed, gateway isn't placed there again, so no ping packets are being send, only repeating ARP requests.

I verified this with wireshark and serial debug messages. The gateway really disappears from ARPTABLE. The code used to check its existence there:

    ip4_addr_t * ip = NULL;
    struct netif * I = NULL;
    struct eth_addr * mac = NULL;
    LOCK_TCPIP_CORE();
    int ret = etharp_get_entry( 0, &ip, &I, &mac );
    int last = get_ip4_addr_4( ip );
    UNLOCK_TCPIP_CORE();
    if ( ret ) {
      dlog_msgn("ARP: %d", last);
    } else {
      dlog_msgn("No ARP table element zero!");
    }

get_ip4_addr_4 returns fourth number from IP address. I attach 2 screenshots, 1st when everything is OK, "ARP: 11" is printed (gateway is at 192.168.3.11), ping packets are being send. 2nd one when the gateway suddenly disappears from ARPTABLE, immediatelly causing ping packets to not being send.


Do I starve TCPIP thread? Should this starving result in disappearing of gateway from ARPTABLE? Why subsequent ARP requests don't reestablish the gateway in ARPTABLE?
--
Best regards,
Sebastian Gniazdowski

Attachment: hanged.png
Description: PNG image

Attachment: normal.png
Description: PNG image


reply via email to

[Prev in Thread] Current Thread [Next in Thread]