[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[lwip-users] Duplicated ACK and retransmitted packets
From: |
Lou Cypher |
Subject: |
[lwip-users] Duplicated ACK and retransmitted packets |
Date: |
Mon, 08 Feb 2010 19:46:39 +0100 |
User-agent: |
Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.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
ftpup-part.pcap
Description: Binary data
- [lwip-users] Duplicated ACK and retransmitted packets,
Lou Cypher <=
- RE: [lwip-users] Duplicated ACK and retransmitted packets, Bill Auerbach, 2010/02/09
- 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