[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [lwip-users] Duplicated ACK and retransmitted packets
From: |
Bill Auerbach |
Subject: |
RE: [lwip-users] Duplicated ACK and retransmitted packets |
Date: |
Tue, 9 Feb 2010 09:22:29 -0500 |
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
- [lwip-users] Duplicated ACK and retransmitted packets, Lou Cypher, 2010/02/08
- RE: [lwip-users] Duplicated ACK and retransmitted packets,
Bill Auerbach <=
- Re: [lwip-users] Duplicated ACK and retransmitted packets, Kieran Mansley, 2010/02/09
- Re: [lwip-users] Duplicated ACK and retransmitted packets, Lou Cypher, 2010/02/09
- Re: [lwip-users] Duplicated ACK and retransmitted packets - some news, Lou Cypher, 2010/02/09
- Re: [lwip-users] Duplicated ACK and retransmitted packets - some news, Kieran Mansley, 2010/02/11
- Re: [lwip-users] Duplicated ACK and retransmitted packets - some news, Lou Cypher, 2010/02/11
- Re: [lwip-users] Duplicated ACK and retransmitted packets - some news, address@hidden, 2010/02/11
- Re: [lwip-users] Duplicated ACK and retransmitted packets - some news, Lou Cypher, 2010/02/11