Re: [lwip-users] Bug on lwIP TCP section (or HTTP client from contrib)?

[Enrico Murador - Research & Development - CET]

An update (please read previous post for details):

The issue seems to be only in TCP part.

From Wireshark log, we can see that the client asks for a page and the first message in reply is not malformed as I thought, but simply the header part of the HTTP 401 "Unauthorized" page I've put on filesystem. At that point, the client replies with FIN+ACK without waiting the 401 message body.
I thought this behavior was caused by the server not sending a "Content-Length" field in the header, so I've modified the server to add it, but my client (Firefox 41.0.2) sometimes still sends FIN+ACK without waiting for the message body.
So the behavior of the HTTP server looks good to me, apart maybe for the lack of the "Content-Length" field in the header.

Dear Sergio and Simon,

Well, first of all, in my opinion it would be great if the HTTP server from contrib and the Sergio's fork could "re-converge" into one. Sergio added some useful features, and on the other hand community code gets debug, test and improvements from a lot of people. Still my opinion, of course.

Now to the issue: as I wrote to Sergio I'm using RAW API and RAW HTTP server from contrib HEAD, with some changes:

- I included a basic HTTP authentication (very basic - my access control is on whole website, not for single pages);
- I modified http_find_error page() function because I had to include a "401 Unauthorized" reply.

PLEASE NOTE: if I'm not wrong, function http_find_error page() has a bug: It returns "page not found" regardless of input, because it calls http_init_file() with NULL as uri (@Sergio: from a quick look seems that http_find_error page() function on your code is bugged too, but only if you set LWIP_HTTPD_SUPPORT_EXTSTATUS to zero).

On 02/11/2015 19:46, Sergio R. Caprile wrote:

yes, you are right.
I don't remember seeing the RSTs last time I checked, I switched to my
own fork long ago, and as I don't have the time to look at it in detail,
I am not able to test for a "maybe" a bug.
Since Simon signals this one as a possible bug, I'll try to see how I
can help, as it probably affects my code also.

TCP "off-by-one window" issue seems to happen when a client send a FIN+ACK message to acknowledge some sent data.

This is probably related with the malformed (isn't it?) 401 error reply that my server sends out, that causes the FIN ACK reply from the client (and brings to the original issue). This maybe is due to my fault; BTW my implementation is not so different from the "stock" one, and the TCP sequence seems to confirm that there should be no problems on the link layer side. I am now investigating on why the http_send() function calls http_eof() at this point of code...

if((hs->left == 0) && (fs_bytes_left(hs->handle) <= 0)) {
    /* We reached the end of the file so this request is done.
     * This adds the FIN flag right into the last data segment. */
    LWIP_DEBUGF(HTTPD_DEBUG, ("End of file.\n"));
    http_eof(pcb, hs);
    return 0;
}

...but the input message that fires a call to http_sent() callback is a (FIN, ACK) message in reply to the data sent by server; so we should already have reached this "end of file" code point on a previous call to http_send(), when server sent the 401 error reply.

Please describe your API and NO_SYS when you open your bug (you didn't
tell, yet).

RAW API, see top of post; NO_SYS is 1 (not relevant in this case, I think).

P.S.: regarding of the meaning of that "weird" numbers on rcv_nxt and rcv_ann_right_edge... I was simply not aware they were the "absolute" values of the TCP sequence numbers.

Thanks
Enrico

--
Enrico Murador
R&D

CET Electronics snc via E. Fermi, 1 31050 Zenson di Piave (TV) Italy Phone: +39 0421 344100 Fax: +39 0421 464042 PI/VAT IT01780330260 Web: http://www.cet-electronics.com/