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

[Chen]

Sorry, but I take back "It even seems to run a little
faster" since there is no fair comparison due to code changes

>>>>>>>>>>>>>>..

Just to close my inquiry.

After upgrading to 1.3.2, all problems are gone! (It even seems to run a
little faster!)

Thanks to lwip gurus!

Message: 5
Date: Tue, 09 Feb 2010 14:24:28 +0100
From: "Simon Goldschmidt" <address@hidden>
Subject: Re: [lwip-users] Re: lwip-users Digest, Vol 78, Issue 19
To: Mailing list for lwIP users <address@hidden>
Message-ID: <address@hidden>
Content-Type: text/plain; charset="iso-8859-1"


Chen wrote:
> Where can I find the bug fix log between my lwIP and the latest rev?

In the file "CHANGELOG" in the top directory of the ZIP file or CVS checkout. The current version can be found here:

http://cvs.savannah.gnu.org/viewvc/lwip/CHANGELOG?root=lwip&view=markup

However, there have really been a lot of changes since 1.3.0, you might want to upgrade to 1.3.2!

Simon
--
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01




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

Message: 6
Date: Tue, 09 Feb 2010 15:10:02 +0100
From: St?phane Lesage <address@hidden>
Subject: Re: [lwip-users] Re: lwip-users Digest, Vol 78, Issue 19
To: address@hidden
Message-ID: <address@hidden>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

 
 > Chen wrote:
 > > Where can I find the bug fix log between my lwIP and the latest rev?
 >
 > In the file "CHANGELOG" in the top directory of the ZIP file
 > or CVS checkout. The current version can be found here:
 >
 > http://cvs.savannah.gnu.org/viewvc/lwip/CHANGELOG?root=lwip&vi
ew=markup
 >
 > However, there have really been a lot of changes since 1.3.0,
 > you might want to upgrade to 1.3.2!

There is a bug fix after 1.3.2 for mem_stats
https://savannah.nongnu.org/bugs/index.php?28679

http://cvs.savannah.gnu.org/viewvc/lwip/src/core/mem.c?root=lwip&r1=1.67&r2=1.68






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

Message: 7
Date: Tue, 9 Feb 2010 09:22:29 -0500
From: "Bill Auerbach" <address@hidden>
Subject: RE: [lwip-users] Duplicated ACK and retransmitted packets
To: "'Mailing list for lwIP users'" <address@hidden>
Message-ID: <address@hidden>
Content-Type: text/plain;       charset="us-ascii"

Lou,

When I fought a Dup Acks problem a long time ago and was sure it was caused
by lwIP, I was surprised to find that it was caused by a subtle problem in
my Ethernet driver.  Be sure your driver is rock solid.

Bill

>-----Original Message-----
>From: address@hidden
>[mailto:address@hidden] On
>Behalf Of Lou Cypher
>Sent: Monday, February 08, 2010 1:47 PM
>To: Mailing list for lwIP users
>Subject: [lwip-users] Duplicated ACK and retransmitted packets
>
>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





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

Message: 8
Date: Tue, 09 Feb 2010 13:06:35 -0200
From: Alain Mouette <address@hidden>
Subject: Re: [lwip-users] Unifficial relesae?
To: Mailing list for lwIP users <address@hidden>
Message-ID: <address@hidden>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed


Kieran Mansley escreveu:
>>
>> What I am trying to find is someone else that could keep track of actual
>> bugfixes (preferably with yout help) and release a set of minimal
>> changes to 1.3.2.
>
> If you did want to do something like this, it might make sense to
> instead simply keep a set of changes that are necessary (and I think the
> number of changes is very small - it would only be critical bug fixes)
> documented on the lwIP wiki.

Yes, that was the original idea. The problem is that someone with enough
internal knowledge of LWIP should document those "critical bug fixes"
and if possible prepare a patch...

Alain




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

Message: 9
Date: Tue, 09 Feb 2010 16:11:17 +0100
From: Lou Cypher <address@hidden>
Subject: Re: [lwip-users] Duplicated ACK and retransmitted packets
To: address@hidden
Message-ID: <address@hidden>
Content-Type: text/plain; charset=ISO-8859-1

> When I fought a Dup Acks problem a long time ago and was sure it was caused
> by lwIP, I was surprised to find that it was caused by a subtle problem in
> my Ethernet driver.  Be sure your driver is rock solid.

The eth driver comes from a silicon vendor, providing usage examples that are
both not working and poorly written as C code. Go figure, jelly solid.

Anyway, I'm not sure about who's responsible for dup ACKs.
I just see them happening all the time, when I transfer data that's larger than
an MTU, say more than 2-3 MTU.

~ Lou





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

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

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