[lwip-users] TCP segment of a reassembled PDU

[Bernhard 'Gustl' Bauer]

Hi,

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?

TIA

Gustl

[David Empson]

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.

_______________________________________________
lwip-users mailing list
lwip-...@nongnu.org
http://lists.nongnu.org/mailman/listinfo/lwip-users

[Bernhard 'Gustl' Bauer]

David Empson schrieb:

> 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.

Hi David,

now it works.

Thanks a lot

Gustl