search

sebka4 / avr-uip

Automatically exported from code.google.com/p/avr-uip
0 stars 0 forks source link

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

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago 
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 commented 8 years ago

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

GoogleCodeExporter commented 8 years ago 
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 commented 8 years ago 
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