[<prev] [next>] [day] [month] [year] [list]
Message-ID: <1416465189.8629.11.camel@edumazet-glaptop2.roam.corp.google.com>
Date: Wed, 19 Nov 2014 22:33:09 -0800
From: Eric Dumazet <eric.dumazet@...il.com>
To: Jonathan Maxwell <jmaxwell37@...il.com>
Cc: davem@...emloft.net, kuznet <kuznet@....inr.ac.ru>,
jmorris <jmorris@...ei.org>, yoshfuji <yoshfuji@...ux-ipv6.org>,
kaber <kaber@...sh.net>, netdev@...r.kernel.org,
linux-kernel@...r.kernel.org, Jon Maxwell <jmaxwell@...hat.com>
Subject: Re: [PATCH net] tcp: fix connect() invalid -EADDRNOTAVAIL error
On Thu, 2014-11-20 at 14:44 +1100, Jonathan Maxwell wrote:
> > > Prerequisites for this to happen:
> > > 1) The local tcp port range must be exhausted.
> > > 2) A process must have called bind() followed by connect() for all
> > > local ports.
> >
> > How the bind() is done exactly ? How SO_REUSEADDR is used ?
>
> It fails regardless. I tried both with and without for the client and
> server programs.
>
This is the missing part from the programs.
By not using SO_REUSEADDR, programs basically do not allow another
programs to use same port.
> But removing the bind() and just calling connect() from the initial
> program
> then a subsequent connect() from a separate program succeeds. It seems
> that
> this is inconsistent behaviour. The proposed fix makes it behave the
> same for
>
> both cases.
This not consistent behavior is well known and somehow expected by some
applications.
bind() requests the kernel that this socket has a reserved port.
It means the socket can later disconnect from the target, and reconnect
to another, using _same_ source port, or chose to listen() on this port.
That is why kernel is so picky, otherwise the listen() might fail
later...
This is part of BSD socket semantic.
You have to use SO_REUSEADDR on both programs to relax these
constraints.
Your change might break existing programs, really expecting kernel
to behave as requested.
--
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