[Top][All Lists]
[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)