I know the reason the debug can't printout fast enough but that is not the issue (My debug UART is not irq driven and I use a debug printout that blocks). Thanks for the suggestion on #define TCP_FIN_WAIT_TIMEOUT 20000 /* milliseconds */ #define TCP_SYN_RCVD_TIMEOUT 20000 /* milliseconds */
-----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of [email protected] Sent: Friday, January 23, 2009 11:00 AM To: [email protected] Subject: lwip-users Digest, Vol 65, Issue 20 Send lwip-users mailing list submissions to [email protected] To subscribe or unsubscribe via the World Wide Web, visit http://lists.nongnu.org/mailman/listinfo/lwip-users or, via email, send a message with subject or body 'help' to [email protected] You can reach the person managing the list at [email protected] When replying, please edit your Subject line so it is more specific than "Re: Contents of lwip-users digest..." Today's Topics: 1. Re: netconn_write throughput stuck at 1024 bytes ([email protected]) 2. lwIP 1.3.x and tcp socket disconnects in the ESTABLISHED state (Dustin Stahlback) 3. Re: lwIP 1.3.x and tcp socket disconnects in the ESTABLISHED state (yueyue papa) 4. Re: lwIP 1.3.x and tcp socket disconnects in the ESTABLISHED state (Simon Goldschmidt) ---------------------------------------------------------------------- Message: 1 Date: Fri, 23 Jan 2009 14:29:57 +0100 From: "[email protected]" <[email protected]> Subject: Re: [lwip-users] netconn_write throughput stuck at 1024 bytes To: Mailing list for lwIP users <[email protected]> Message-ID: <[email protected]> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Forgot one: DownyTif wrote: > Is TCP_WND only for receiving data? If I only receive small frames in my > lwip, do I have to still make it big? > TCP_WND is the receive window announced to the other side with a SYN, but it is also used as a maximum limitation on a transmit window received from the other side. This is to limit memory allocation in the lwIP application. So you still have to set it high when only receiving a little data but sending much. Simon ------------------------------ Message: 2 Date: Fri, 23 Jan 2009 08:39:30 -0600 From: "Dustin Stahlback" <[email protected]> Subject: [lwip-users] lwIP 1.3.x and tcp socket disconnects in the ESTABLISHED state To: <[email protected]> Message-ID: <1cd05b980c94ac408b37c82bbabaa3e60fa60...@mtsexchange.dc.multitech.prv> Content-Type: text/plain; charset="us-ascii" Gentleman, I have the following setup: lwIP 1.3.0.x (latest CVS), freeRTOS 5.0.0, AT91SAM7X256 I use the PPP driver to interface to analog and wireless modems. I am looking for some advice an trying to track down an issue while recieving data from a TCP socket using the netconn api. I have a specific file (random data padded with 230K+ bytes of 0xFF). Sometimes, this file transfer causes the TCP socket to close and send the FIN packet even though the file has not finished being received. The state the TCP socket is in is ESTABLISHED when the socket closes, whereas on a proper functioning file transfer, the socket closes in the state CLOSE_WAIT. This was determined from the tcp_debug_print_state() mechanism. The stats_display() indicates that I have allocated enough resources for this specific task so I believe I have a decent lwipopts.h setup. I can decrease the failure rate by enabling a debug statement (2ms to printout) in the function tcp_process() under the ESTABLISHED case. I cannot turn on all TCP debug as this will cause the stack not to work at all. If you have any ideas I would appreciate them. Thanks, Dustin ------------------------------ Message: 3 Date: Fri, 23 Jan 2009 22:52:36 +0800 From: yueyue papa <[email protected]> Subject: Re: [lwip-users] lwIP 1.3.x and tcp socket disconnects in the ESTABLISHED state To: Mailing list for lwIP users <[email protected]> Message-ID: <[email protected]> Content-Type: text/plain; charset="iso-8859-1" i think i meet the similar problem you meet. I do not make deep debug as you did. (Due to project time.) I make such change: in tcp.h #define TCP_FIN_WAIT_TIMEOUT 20000 /* milliseconds */ #define TCP_SYN_RCVD_TIMEOUT 20000 /* milliseconds */ ==> #define TCP_FIN_WAIT_TIMEOUT 10000 /* milliseconds */ #define TCP_SYN_RCVD_TIMEOUT 10000 /* milliseconds */ the problem becomes better. In fact I donot know the deep reason. I guest such change make quick resent, and some other problems are avoid. I also hope to get the answer too. I test the problem only happened in the GPRS environement, the same code in the modem channel is working very stable. On Fri, Jan 23, 2009 at 10:39 PM, Dustin Stahlback <[email protected] > wrote: > Gentleman, > > I have the following setup: > > lwIP 1.3.0.x (latest CVS), freeRTOS 5.0.0, AT91SAM7X256 > > I use the PPP driver to interface to analog and wireless modems. > > > I am looking for some advice an trying to track down an issue while > recieving data from a TCP socket using the netconn api. > > > I have a specific file (random data padded with 230K+ bytes of 0xFF). > Sometimes, this file transfer causes the TCP socket to close and send > the FIN packet even though the file has not finished being received. > The state the TCP socket is in is ESTABLISHED when the socket closes, > whereas on a proper functioning file transfer, the socket closes in the > state CLOSE_WAIT. This was determined from the tcp_debug_print_state() > mechanism. The stats_display() indicates that I have allocated enough > resources for this specific task so I believe I have a decent lwipopts.h > setup. I can decrease the failure rate by enabling a debug statement > (2ms to printout) in the function tcp_process() under the ESTABLISHED > case. I cannot turn on all TCP debug as this will cause the stack not > to work at all. > > If you have any ideas I would appreciate them. > > Thanks, > > Dustin > > > _______________________________________________ > lwip-users mailing list > [email protected] > http://lists.nongnu.org/mailman/listinfo/lwip-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.gnu.org/pipermail/lwip-users/attachments/20090123/c58979ef/attachment.html ------------------------------ Message: 4 Date: Fri, 23 Jan 2009 17:45:21 +0100 From: "Simon Goldschmidt" <[email protected]> Subject: Re: [lwip-users] lwIP 1.3.x and tcp socket disconnects in the ESTABLISHED state To: Mailing list for lwIP users <[email protected]> Message-ID: <[email protected]> Content-Type: text/plain; charset="iso-8859-1" In the past, such things as errors depending on timing (which also could be why full debug doesn't work) mostly were errors in the port or driver like more than one thread working in the lwIP core at the same time. You should check your port and driver for correctness first. Of course it could also be a bug in lwIP, but things like "I cannot turn on all TCP debug as this will cause the stack not to work at all" are highly suspicious of threading problems! Simon Dustin Stahlback wrote: > Gentleman, > > I have the following setup: > > lwIP 1.3.0.x (latest CVS), freeRTOS 5.0.0, AT91SAM7X256 > > I use the PPP driver to interface to analog and wireless modems. > > > I am looking for some advice an trying to track down an issue while > recieving data from a TCP socket using the netconn api. > > > I have a specific file (random data padded with 230K+ bytes of 0xFF). > Sometimes, this file transfer causes the TCP socket to close and send > the FIN packet even though the file has not finished being received. > The state the TCP socket is in is ESTABLISHED when the socket closes, > whereas on a proper functioning file transfer, the socket closes in the > state CLOSE_WAIT. This was determined from the tcp_debug_print_state() > mechanism. The stats_display() indicates that I have allocated enough > resources for this specific task so I believe I have a decent lwipopts.h > setup. I can decrease the failure rate by enabling a debug statement > (2ms to printout) in the function tcp_process() under the ESTABLISHED > case. I cannot turn on all TCP debug as this will cause the stack not > to work at all. > > If you have any ideas I would appreciate them. > > Thanks, > > Dustin > > > _______________________________________________ > lwip-users mailing list > [email protected] > http://lists.nongnu.org/mailman/listinfo/lwip-users -- NUR NOCH BIS 31.01.! GMX FreeDSL - Telefonanschluss + DSL für nur 16,37 EURO/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K11308T4569a ------------------------------ _______________________________________________ lwip-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/lwip-users End of lwip-users Digest, Vol 65, Issue 20 ****************************************** _______________________________________________ lwip-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/lwip-users
