lwip-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lwip-devel] A pcb stall in the FIN_WAIT_1


From: narke
Subject: Re: [lwip-devel] A pcb stall in the FIN_WAIT_1
Date: Wed, 14 Mar 2012 00:40:30 +0800

On 13 March 2012 17:11, Simon Goldschmidt <address@hidden> wrote:
> narke <address@hidden> wrote:
>> In my system, I closed a passive connected PCB and before that the
>> network cable was plugged out.  Then FIN_WAIT_1 pcb continuously to
>> send FIN segments.  Because this pcb stays in active_pcb list, I
>> cannot bind another pcb on the same port.  (I've already waited for
>> more than 2*MSL time)
>>
>> My question is, in this state, how long time the FIN_WAIT_1 pcb can be
>> released?
>
> In any state (except for SYN_SENT), the maximum number of retransmissions is 
> configured by TCP_MAXRTX (which is 12 by default). As there is an exponential 
> backoff (see tcp_backoff[] values), 2*MSL is of course not enough to just 
> abort a connection, as the default values of TCP are very fault-tolerant.

Understand.  Thanks for your great support!

>
>> And, in this case, does the tcp_abort() helpful?
>
> You can of course abort the previous connection manually, but letting the 
> listening pcb always be bound (so you don't have to rebind) would be a better 
> idea, I guess.
>

This method I have interesting.  But what confused is, tcp_abort()
will also deallocate the aborting pcb.  So, anyway I have to renew
another pcb and do the rebind.  So, how do I archive the what you
suggested result?



> Simon
> --
> Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
> belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de
>
> _______________________________________________
> lwip-devel mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/lwip-devel



-- 
Life is the only flaw in an otherwise perfect nonexistence
    -- Schopenhauer

narke
public key at http://subkeys.pgp.net:11371 (address@hidden)



reply via email to

[Prev in Thread] Current Thread [Next in Thread]