Re: connect(2) reassociation regression

[William Ahern <william@25thandclement.com>]

On Sat, Mar 16, 2013 at 07:51:07AM -0700, Eric Dumazet wrote:
> On Fri, 2013-03-15 at 22:56 -0700, William Ahern wrote:
> > I've stumbled upon what may be a regression in connect(2) behavior.
<snip>
> > At some point in the 3.x cycle (maybe after 3.2.0) something was changed.
> > Whereas previously any reassociation worked, regardless of destination
> > network, now if the _first_ association is to the loopback, any subsequent
> > association to non-loopback fails with EINVAL. However, if the loopback is
> > the second or later association then everything continues to work. In other
> > words, the sequence
> > 
<snip>
> 
> There is an issue as the connect() call sets both local address:port and
> remote address, in the case the local address was not already set by a
> prior bind().
> 
> And once bound to a local address, its not really clear if we are
> allowed to bind to a different one, and fall in the possible traps of
> SO_REUSEADDR and find another socket bound to the same local addr:port.
> 
> So if the second connect() also change the source port, I am pretty sure
> some applications will badly break.
> 
> I would just avoid the problem of handling this mess, and let the
> application close the socket and allocate a new one.

This is for UDP, not TCP. The alternative is sendto/recvfrom. For a
non-blocking, recursive DNS library reopening sockets all of the time is
really messy.

> Changing the kernel behavior on these kind of unspecified stuff might
> break some other applications.

Indeed. The behavior _was_ changed, and my application broke, and
potentially many other applications.

> Clearly the BSD API was bad, as the connect() is a 'super operation',
> not only setting the remote address:port, but also the local
> address:port given the current routing table.

Well, AFAICT Linux implemented this behavior for years. FWIW, Solaris also
implements this behavior. It's been universal until recently.