lwip-users
[Top][All Lists]
Advanced

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

[lwip-users] Re: [lwip] lwIP (current) : large data transfers seem to b


From: Paul Sheer
Subject: [lwip-users] Re: [lwip] lwIP (current) : large data transfers seem to break lwIP
Date: Thu, 09 Jan 2003 01:07:16 -0000

to find this bug is laborious, but straight forward

do the following:

create a loooong printf statement that dumps the
state of the tcp pcb structure at every packet.
you should print the decimal/hex value of every
structure member

dump the whole thing to a log file, and see
what happens just before the stack dies

most probably, there is a tell-tail sign like
a wrapping parameter

i have found a bug this way before, but it may
not be the same bug.

you can also see what members i have changed to
be 32-bit at paulos.2038bug.com

-paul

On 2002.10.17 01:35 Chris Borrelli wrote:
> Probing for help...
> 
> I am seeing an interesting problem when sending large chunks of data 
> from lwIP.  After about 2 1/2 MB of data gets sent to the remote host, 
> lwip just stops sending data...
> 
> I have a callback setup (sent) that gets called every time new tx buffer 
> space becomes available.  I think this happens whenever lwIP receives an 
> ACK for previously transmitted data.  Inside the callback I call 
> tcp_write with remaining data to send.  After ~2.5 MB of data is sent 
> out, the callback doesn't get called ever again.  I suspect this number 
> is related to my lwipopts.h settings.
> 
> Ethereal shows that all the data that is sent from lwIP is ACK'd by the 
> remote host, and still the stack seems to just die.
> 
> Has anyone run into this or anything similar before?  
> 
> Setup:
> cvs version of lwIP running on a PPC405 (300MHz).
> tcp_fasttmr called every 2 mS
> tcp_slowmr called every 5 ms
> Ethernet uses interrupts on rx side.
> 
>  -Chris
> 
> my lwipopts.h:
> - - - - - - - - - - - - - - - - - - - - -
> #ifndef __LWIPOPTS_H__
> #define __LWIPOPTS_H__
> 
> #define NO_SYS 1
> #define LWIP_CALLBACK_API 1
> 
> #define MEM_ALIGNMENT           4
> #define MEM_SIZE                8 * 1024 * 1024
> #define MEMP_NUM_PBUF           64
> #define MEMP_NUM_UDP_PCB        1
> #define MEMP_NUM_TCP_PCB        8
> #define MEMP_NUM_TCP_PCB_LISTEN 16
> #define MEMP_NUM_TCP_SEG        255
> 
> #define MEMP_NUM_NETBUF         0
> #define MEMP_NUM_NETCONN        0
> #define MEMP_NUM_API_MSG        0
> #define MEMP_NUM_TCPIP_MSG      0
> #define MEMP_NUM_SYS_TIMEOUT    0
> 
> #define PBUF_POOL_SIZE          512
> #define PBUF_POOL_BUFSIZE       1536
> 
> #define PBUF_LINK_HLEN          16
> 
> #define LWIP_TCP                1
> #define TCP_TTL                 255
> #define TCP_QUEUE_OOSEQ         1
> #define TCP_MSS                 1476
> #define TCP_SND_BUF             512 * 1024
> #define TCP_SND_QUEUELEN        2 * TCP_SND_BUF/TCP_MSS
> #define TCP_WND                 16 * 1024
> #define TCP_MAXRTX              12
> 
> #define ARP_TABLE_SIZE 4
> 
> #define IP_FORWARD              0
> #define IP_OPTIONS              1
> #define ICMP_TTL                255
> 
> #define LWIP_DHCP               0
> #define DHCP_DOES_ARP_CHECK     1
> 
> #define LWIP_UDP                0
> #define UDP_TTL                 255
> 
> #endif /* __LWIPOPTS_H__ */
> 
> 
> [This message was sent through the lwip discussion list.]
> 
Paul Sheer Consulting IT Services . . Tel . . . +27 (0)21 6869634
Email . . . . . . . . . . . . . . . . . . . . . address@hidden
Linux development, cryptography, recruitment,  support,  training
http://www.icon.co.za/~psheer . . . . . . http://rute.2038bug.com
L I N U X . . . . . . . . . . . .  The Choice of a GNU Generation

[This message was sent through the lwip discussion list.]




reply via email to

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