[lwip-users] RE: lwIP 1.3.x and tcp socket disconnects in the ESTABLISHED State

[Dustin Stahlback]

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: address@hidden [mailto:address@hidden On Behalf Of address@hidden
Sent: Friday, January 23, 2009 11:00 AM
To: address@hidden
Subject: lwip-users Digest, Vol 65, Issue 20


Send lwip-users mailing list submissions to
        address@hidden

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
        address@hidden

You can reach the person managing the list at
        address@hidden

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
      (address@hidden)
   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: "address@hidden" <address@hidden>
Subject: Re: [lwip-users] netconn_write throughput stuck at 1024 bytes
To: Mailing list for lwIP users <address@hidden>
Message-ID: <address@hidden>
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" <address@hidden>
Subject: [lwip-users] lwIP 1.3.x and tcp socket disconnects in the
        ESTABLISHED state
To: <address@hidden>
Message-ID:
        <address@hidden>
        
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 <address@hidden>
Subject: Re: [lwip-users] lwIP 1.3.x and tcp socket disconnects in the
        ESTABLISHED state
To: Mailing list for lwIP users <address@hidden>
Message-ID:
        <address@hidden>
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 <address@hidden
> 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
> address@hidden
> 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" <address@hidden>
Subject: Re: [lwip-users] lwIP 1.3.x and tcp socket disconnects in the
        ESTABLISHED state
To: Mailing list for lwIP users <address@hidden>
Message-ID: <address@hidden>
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
> address@hidden
> 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
address@hidden
http://lists.nongnu.org/mailman/listinfo/lwip-users

End of lwip-users Digest, Vol 65, Issue 20
******************************************