[lwip-users] Re: lwip-users Digest, Vol 78, Issue 19

[Chen]

Mike, I really appreciate your help

I never use LWIP_STATS before, so taking your
suggestion, I search the AVR port of lwip, and I didn't find
LWIP_STATS macro, but I did find other files like
stats.c,opts.h, etc

I assume you suggest me to monitor the memory leak with
stats_display_mem? 

I call it periodicallly, and it displays:

MEM
        avail: 17 (keep growing)
        used: 0
        max: 41 (keep growing)
        err: 0 

I couldn't figure out the meaning of it (I expect avail will shrink and
max should stay the same)

Or, maybe I am on a wrong track?

Again, thank you for your time! 

Chen

Message: 3
Date: Mon, 8 Feb 2010 22:53:17 +0300
From: Mike Kleshov <address@hidden>
Subject: Re: [lwip-users] Re: lwip-users Digest, Vol 78, Issue 18
To: Mailing list for lwIP users <address@hidden>
Message-ID:
        <address@hidden>
Content-Type: text/plain; charset=ISO-8859-1

On 8 February 2010 22:35, Chen <address@hidden> wrote:
> Could you show me how to turn on stat? Thanks!

Statistics collection is enabled in lwipopts.h just like all the other
features of lwip. Consult the file opt.h for more information. Hint:
look for the LWIP_STATS macro.

Regards,
- mike




------------------------------

Message: 4
Date: Mon, 08 Feb 2010 19:46:39 +0100
From: Lou Cypher <address@hidden>
Subject: [lwip-users] Duplicated ACK and retransmitted packets
To: Mailing list for lwIP users <address@hidden>
Message-ID: <address@hidden>
Content-Type: text/plain; charset="iso-8859-1"

I've already read of someone having problems with duplicated ACKs, and I've got
a similar issue.
Note that I'm debugging part of an application that could be bugged, though I
think that the part giving the dup ACKs is quite simple.

I'm attaching (part of) a Wireshark capture as an example, where the (FTP)
client is my embedded system running lwIP 1.3.2, and the (FTP) server is a PC
running FileZilla Server.

The problem arises in the FTP file transfer, on the data connection; I tried
separating the most of it, so now I have a couple of functions handling file
reception, after I send the RETR command to server:

 - the first one sets a buffer, with length, then calls tcp_recv() with the
second; an extract follows

        uint8_t         * pd, * pmax;

        pd   = (uint8_t *)p;
        pmax = p + size;

        pf->file_buf = pd;
        pf->file_put = pd;
        pf->file_len = size;

        tcp_recv( pcb, ftplw_file_recved );

        while( pf->file_put < pmax )
        {
             ... // lwIP TCP processing
        }

        tcp_recv( pcb, 0 );


 - the second one acts as the callback, and looks like the following:

static err_t    ftplw_file_recved( void *arg,
                                   struct tcp_pcb *pcb,
                                   struct pbuf *p,
                                   err_t err )
{
    struct sFTPc        * pf = (struct sFTPc *)arg;

    if( err == ERR_OK  &&  p == 0 )
    {
        tcp_close( (struct tcp_pcb *)pf->data_desc );
        pf->data_desc = 0;
        pf->data_conn = 0;
    }
    else
    if( err == ERR_OK  &&  p != 0 )
    {
        uint16_t        size;
        uint8_t         * pd, * pp, * pmax;
        struct pbuf     * pb;

        if( pf->data_desc )
        {
            //  Enqueues received data
            pp   = pf->file_put;
            pmax = pf->file_buf + pf->file_len;
            pb   = p;

            //  Processes all linked pbufs
            do {
                size = pb->len;
                pd   = pb->payload;

                while( size  &&  pp < pmax )
                {
                    *pp++ = *pd++ ;
                    size-- ;
                }

                pb = pb->next;

            } while( pb );

            pf->file_put = pp;
        }

        tcp_recved( pcb, p->tot_len );

        pbuf_free( p );
    }

    return  ERR_OK;
}

I think that the code above is quite straightforward, besides the fact that
*most* of the time it receives all the data correctly.
While sometimes I see data corruption happening, as well.

I'm using options as in the following, and checking stats I see no buffer
reaching any limit (resources usage is very low).
-----------------------------------------------------------------------
#define  NO_SYS                         1
#define  SYS_LIGHTWEIGHT_PROT           1

#define  MEM_ALIGNMENT                  4
#define  MEM_SIZE                       (128 * 1024)

#define  MEMP_NUM_RAW_PCB               16      // 8
#define  MEMP_NUM_UDP_PCB               8       // 4
#define  MEMP_NUM_PBUF                  32      // default 16
#define  MEMP_NUM_TCP_PCB               128     // 32   // default 5
#define  MEMP_NUM_TCP_PCB_LISTEN        8
#define  MEMP_NUM_TCP_SEG               256     // default 16
#define  PBUF_POOL_SIZE                 128     // default 16

#define  LWIP_DHCP                      1       // default 0
#define  DHCP_DOES_ARP_CHECK            1

#define  LWIP_AUTOIP                    1
#define  LWIP_DHCP_AUTOIP_COOP          1

#define  TCP_WND                        4096    // default 2048
#define  TCP_MSS                        1460
#define  TCP_SND_BUF                    (8 * TCP_MSS)

#define  PBUF_LINK_HLEN                 16      // default 14

#define  LWIP_NETCONN                   0       // default 1
#define  LWIP_SOCKET                    0       // default 1
#define LWIP_COMPAT_SOCKETS             0

#define  LWIP_NETIF_HOSTNAME            1

#define  LWIP_DNS                       1


#define  LWIP_STATS                     1
#define  LWIP_STATS_DISPLAY             1

#define  LWIP_DEBUG                     1
#define  DBG_TYPES_ON           DBG_LEVEL_WARNING
#define  MEMP_DEBUG             (LWIP_DBG_LEVEL_WARNING | LWIP_DBG_ON)
-----------------------------------------------------------------------

I hope I enclosed everything here, since I'm writing this in a short time! :)
Any suggestion?

~ Lou
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ftpup-part.pcap
Type: application/octet-stream
Size: 27902 bytes
Desc: not available
Url : http://lists.gnu.org/pipermail/lwip-users/attachments/20100208/282c046b/ftpup-part.obj

------------------------------

_______________________________________________
lwip-users mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/lwip-users

End of lwip-users Digest, Vol 78, Issue 19
******************************************