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

[Enrico Murador - Research & Development - CET]

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