large http packets are split into multiple and are not being re-assembled properly on the avr-uip side

[GoogleCodeExporter]

What steps will reproduce the problem?
1. build the firmware 
2. start wireshark
3. load a http page lots of times and check the logs.  After a while you will 
see

1801    924.830456  192.168.2.110   192.168.2.107   TCP http > 59410 [ACK] Seq=1 
Ack=394 Win=546 Len=0

1802    924.830480  192.168.2.107   192.168.2.110   TCP [TCP Dup ACK 1800#1] 59410 > 
http [ACK] Seq=394 Ack=547 Win=6552 Len=0

1803    925.035373  192.168.2.107   192.168.2.110   HTTP    [TCP Retransmission] 
Continuation or non-HTTP traffic

1804    925.036834  192.168.2.110   192.168.2.107   TCP [TCP Dup ACK 1801#1] http > 
59410 [ACK] Seq=547 Ack=394 Win=546 Len=0

>>>>>>
Note the "Continuation or non-HTTP traffic" this is because the amount of data 
being sent is larger than one http packet size as I learned from:
http://www.gossamer-threads.com/lists/ethereal/users/68274

When this error occurs the UIP stack dies for a few moments while it figures 
out what to do... :-p  Well I think it's waiting on a timeout and performs a 
cleanup.

Original issue reported on code.google.com by qarc...@gmail.com on 30 Apr 2011 at 5:33

[GoogleCodeExporter]

Original comment by qarc...@gmail.com on 30 Apr 2011 at 5:33

• Added labels: Priority-Critical
• Removed labels: Priority-Medium

[GoogleCodeExporter]

Fix by turning on UIP_REASSEMBLY
#define UIP_REASSEMBLY 1

Add code to warn if this var is not set to anything.
default to OFF, i.e. 0

Original comment by qarc...@gmail.com on 26 May 2011 at 3:18

[GoogleCodeExporter]

fixed in rev 87.  It did work it turns out.  The CGI was crashing.

Original comment by qarc...@gmail.com on 26 May 2011 at 3:19

• Changed state: Fixed