[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4A059E75.7060008@cosmosbay.com>
Date: Sat, 09 May 2009 17:17:09 +0200
From: Eric Dumazet <dada1@...mosbay.com>
To: Octavian Purdila <opurdila@...acom.com>
CC: netdev@...r.kernel.org
Subject: Re: ports beeing reused too fast
Octavian Purdila a écrit :
> On Saturday 09 May 2009 09:58:25 Eric Dumazet wrote:
>
>>> I've looked over the code and it looks right, so maybe net_random() is
>>> not random enough? Or maybe there are side effects because of the %
>>> port_range?
>> Random is random :)
>> Probability a port can be reused pretty fast is not nul.
>>
>
> Thinking again about it... you are right :)
>
>> So yes, behavior you discovered is expected, when we switched port
>> selection from a sequential one (not very secure btw) to a random one.
>>
>> Any strong reason why a firewall would drop a SYN because ports were used
>> in a previous session ?
>
> We don't know why the firewall (Cisco FWSM) is dropping the packets, may be a
> bug, limitation or miss-configuration. We are trying to track this down with
> the firewall vendor.
Normally, the client machine should not reuse a port during the TIME_WAIT duration
(TCP_TIMEWAIT_LEN being 60 seconds on linux). Port selection being random or sequential,
it should avoid all ports recently used.
Maybe this firewall has a longer TIME_WAIT enforcement (something like 2 minutes)
>
>> Previous mode can be restored by application itself, using a bind() before
>> connect(), if this application knows it has a very high rate of connections
>> from a particular host to a particular host. (source ports range being
>> small anyway, so your firewall could complain again)
>
> Do you mean bind() with port != 0 ? Because I am already using bind() before
> connect().
>
Yes, but its obviously complex to handle at application side...
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists