Summary: Slow / incomplete HTTP responses.
Project: lwIP - A Lightweight TCP/IP stack
Submitted by: None
Submitted on: Monday 02/05/2007 at 05:30 UTC
Severity: 3 - Normal
Item Group: None
Assigned to: None
Discussion Lock: Any
Sounds like you have a software race, which in turn is probably caused by
locking problems, and this results in (perhaps) the TCP timers not
functioning correctly. By adding the printf you have changed the timing, and
so made one problem go away.
Can you check that you have ensured there is never more than one thread
active in the lwIP code at any one time?
Could you also supply your lwipopts configuration, and giove some details of
the hardware and lwIP APIs that you are using?
Yes there does seem to be some kind of timing issue going on ....
it seems that sometimes the address of pcb->remote_port resolves to an
illegal address and causes gdb to dump out. If I printf the address of
pcb->remote_port the problem is not evident.
I have played with some of the MSS size settings and timing in lwipopts but
everything else is as it comes.
Note my printf is directed to a custom crt console output on the gdb
connected serial port.
and utilises the 'easymac' module ( also from Niktech ). The code is compiled
with GCC 3.4.4 single thread model crosscompiler for the Manik on an FC6
Niktech provides all the VHDL sources, and GPL tools to build the platform.
I am using the LWIP 'easymac' API demo from the Niktech site. I am not
entirely sure which version of LWIP the Niktech demo is based on however no
changes to LWIP are required to compile. I am using 1.2
Other than this problem ( pointer and erratic web ) LWIP is excellent. I can
ping -f , do a http request and ARP and it seems to work well.
Have you tried contacting Niktech for support? From the sound of it they
have ported it to their platform, and without details of how they have ported
it it will be very hard to us to get to the bottom of your problem.