[Top][All Lists]
[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.]
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [lwip-users] Re: [lwip] lwIP (current) : large data transfers seem to break lwIP,
Paul Sheer <=