> Yeah, that's one of the reasons it is marked as "example application for the
> lwIP raw api", not as httpd to be used in production environments! However,
> I'm still planning to change this and it's not the only thing missing ;-)
Well, there is value in simple examples. They demonstrate main
co
Lou Cypher wrote:
As well: the example httpd.c in contrib is similarly vulnerable, should be
annotated, just not to forget...
Yeah, that's one of the reasons it is marked as "example application for
the lwIP raw api", not as httpd to be used in production environments!
However, I'm still pla
Oh, you're darn right, thanks!
Already used/planned something like that, somewhere else in my code, while in
that part is missing.
As well: the example httpd.c in contrib is similarly vulnerable, should be
annotated, just not to forget...
Lou
>> So, in the case of the HTTP capture you provided, t
> So, in the case of the HTTP capture you provided, there is a request
> header telling you "Content-Length: 36". This tells you that after
> the end of the headers (i.e. after the blank line), you should expect
> another 36 bytes of data. You need to wait for those bytes to come in
> before cons
This isn't a case of *IP fragmentation* so there won't be any IP
reassembly. It's just that the TCP data is being sent in two
messages. This is perfectly valid TCP behavior.
Strictly speaking, there's nothing in TCP that prevents the client
from sending you the entire request in 1-byte pieces if
I have an HTTPD implementation, derived from the raw one in contrib/, that
showed a strange behavior receiving fragmented packets.
Note: In the attached Wireshark capture there's a fragment of communication that
exhibits such problem. In the capture file .130 is the host/web-client, and .199
is the
