|
»
»
http post and connection not closed problem
|
View:
New views
5 Messages
—
Rating Filter:
Alert me
|
 |
http post and connection not closed problem
by Stephane Lesage
::
Rate this Message:
Hi, I wrote an http server in my embedded device (using sockets) and sometimes I have a problem when uploading a big file (new firmware). The web browser hangs (IE or FF on WinXP). Looking at the IE capture, I can see: - my device sends a HTTP 400 Bad Request response (packets 193, 194) (which is certainly a bug from me) - closes the connection (packet 196) - the web browser has not yet finished sending the POST data and tries to continue - infinite loop with ZeroWindowProbe / ZeroWindow In the FF capture: - I don't see my device response - infinite loop with RST,ACK from my device and TCP retransmission from the PC I think the connection should be closed and the browser should display an error message. Am I right ? Can this be related to bug 26672 ? Or is it the close/shutdown problem ? Capture files are here: http://www.ateis-international.com/downloads/temp/ -- Stéphane LESAGE ATEIS International _______________________________________________ lwip-devel mailing list lwip-devel@... http://lists.nongnu.org/mailman/listinfo/lwip-devel |
|
|
Re: http post and connection not closed problem
by goldsimon@gmx.de
::
Rate this Message:
Hi Stephane,
from looking at your capture, it seems that neither bug #26672 nor the close/shutdown is your problem but rather a simple bug in tcp.h (which is fixed in CVS head, but for which I unfortunately didn't create an own bug entry). If you can't update to CVS head from october 26th, make sure the definition of TCP_EVENT_RECV() in tcp.h, around line 486 looks like this: #define TCP_EVENT_RECV(pcb,p,err,ret) \ do { \ if((pcb)->recv != NULL) { \ (ret) = (pcb)->recv((pcb)->callback_arg,(pcb),(p),(err)); \ } else { \ (ret) = ERR_OK; \ if (p != NULL) { \ tcp_recved((pcb), ((struct pbuf*)(p))->tot_len); \ pbuf_free(p); \ } \ } \ } while (0) The call to tcp_recved was missing. This leads to closing and failing to reopen the window when pcb->recv is set to NULL (i.e. when calling tcp_recv(pcb, NULL)) and the client is still sending data. Hope that helps, Simon Stephane Lesage wrote: > Hi, > > I wrote an http server in my embedded device (using sockets) > and sometimes I have a problem when uploading a big file (new firmware). > The web browser hangs (IE or FF on WinXP). > > Looking at the IE capture, I can see: > - my device sends a HTTP 400 Bad Request response (packets 193, 194) (which is certainly a bug from me) > - closes the connection (packet 196) > - the web browser has not yet finished sending the POST data and tries to continue > - infinite loop with ZeroWindowProbe / ZeroWindow > > In the FF capture: > - I don't see my device response > - infinite loop with RST,ACK from my device and TCP retransmission from the PC > > > I think the connection should be closed and the browser should display an error message. > Am I right ? > > Can this be related to bug 26672 ? > Or is it the close/shutdown problem ? > > Capture files are here: > http://www.ateis-international.com/downloads/temp/ > > > -- > Stéphane LESAGE > ATEIS International > > > _______________________________________________ > lwip-devel mailing list > lwip-devel@... > http://lists.nongnu.org/mailman/listinfo/lwip-devel > > _______________________________________________ lwip-devel mailing list lwip-devel@... http://lists.nongnu.org/mailman/listinfo/lwip-devel |
|
|
|
|
|
|
|
|
Re: http post and connection not closed problem
by goldsimon@gmx.de
::
Rate this Message:
Since you are using sockets (sorry, I seem to have missed that in your
first mail), this really might be bug #26672. The change in tcp.h makes sure all newly received data doesn't influence the window, but it can happen that data in the socket's recvmbox closes the window. And the patch I posted to bug #26672 makes sure that when closing, tcp_recved() is called for this data, which makes sure the window reopens. Could you try to apply this patch and see if it's better? This explains the situation in packets 0-56 amd 960+. Reading your traces, I noticed you seem to run out of buffers somewhere, resulting in retransmissions (only few, but still...). You might want to get to the source of that, too. Simon Stephane Lesage wrote: >> I'll try to reproduce my bug and see how lwip behaves with the fix. >> > > Well I met the bug again, > And the situation is now better but not perfect. > > Here is a capture with 3 attempts: > http://www.ateis-international.com/downloads/temp/upload%20bug%20IE%203.pcap > > 1. packets 0-56 > same situation as before, but I could not reproduce it. > 2. packets 57-932 > Here we can see the lwip device acks and announces a full-size window of 8192 bytes > after closing the connection. > 3. packets 960+ > Lwip acks with 250ms delay and window has not been reset > > >> From preliminary investigation, it seems that read() returns >> a value <= 0 before the end of the http POST content, so I >> consider the connection closed. >> I added more debug info in the response. >> It may be an lwip bug or misconfiguration (recvmbox size ?) >> > > Now I can see that I abort the download because read() returns 0. > > Normally 0 means the connection is closed, right ? > Or should I use another way ? > > Anyway, read() should not return 0 as the web browser keeps sending data. > > > When looking just before my http server sends the error 400 response, > In packet 183, length=1132 > http://www.ateis-international.com/downloads/temp/upload%20bug%20IE.pcap > > And here before lwip sends RST, in packet 213, length = 892 > http://www.ateis-international.com/downloads/temp/upload%20bug%20FF.pcap > > I can see that we arrive in the situation where window = 0. > Could it be a bug ? > > _______________________________________________ lwip-devel mailing list lwip-devel@... http://lists.nongnu.org/mailman/listinfo/lwip-devel |
| Free embeddable forum powered by Nabble | Forum Help |
