Re: [lwip-users] TCP segment of a reassembled PDU

[David Empson]

"Bernhard 'Gustl' Bauer" wrote:
> I try to run a http server with LWIP. Every time a POST request to a
> certain filename is received an answer is generated. Head and body of
> this answer have a length of 184 bytes. LWIP is configured that it can
> send out over 1000 bytes in one packet.
>
> Wireshark marks this packet with the info 'TCP segment of a reassembled
> PDU' and another packet is sent out with six '\0'! How can I avoid this?

The packet you mention with that message (e.g. number 6 in the capture) 
contains all of the data for the response. For some reason, Wireshark 
displays the data as if it was part of the next packet (number 8), which is 
actually a FIN from LWIP with no data at all.

The six zero bytes you are seeing (e.g. in packet 8) are just Ethernet frame 
padding to reach the minimum length of 60 bytes. The TCP header in frame 8 
says there are no data bytes included.

Aha - I think I see the problem. There is a syntax error in the HTTP header. 
It has a "Content Length" header, which should be "Content-Length" (with a 
hyphen instead of a space). Wireshark doesn't recognise it, so it doesn't 
know how long the content is. It therefore delays the display of the content 
until the arrival next packet, which (being a FIN) is clearly the end of the 
content.

In its entirety, the exchange goes like this

1 <-- SYN
2 --> SYN, ACK
3 <-- ACK
4 <-- HTTP POST
5 --> ACK of 4
6 --> HTTP respose to POST
7 <-- ACK of 6
8 --> FIN
9 <-- ACK
10 <-- FIN
11 --> ACK

Apart from a few extra ACKs (probably due to timing), the packet flow looks 
fine to me, so this isn't an LWIP problem.