sobby does not appear to use socket reuse flags

[Chris Jones]

Binary package hint: sobby

Restarting sobby can produce the following (from strace output):

bind(4, {sa_family=AF_INET, sin_port=htons(6522), sin_addr=inet_addr("0.0.0.0")}, 16) = -1 EADDRINUSE (Address already in use)

The server is not running, but the socket will be in TIME_WAIT or similar, so sobby should specify the appropriate REUSE option when it creates its listening socket, allowing for instant restarts.

[Philipp Kern (pkern)]

In theory that's a security measure and it should not happen if sobby is SIGTERM'ed (i.e. if the socket is closed cleanly), or does it?

[Chris Jones (cmsj)]

I ran into this with a wedged sobby that I had to kill and was then unable to restart for a few minutes. AIUI SO_REUSEADDR is widespread in network daemons because the security risk is minimal.

[Philipp Kern (pkern)]

There is a slight risk that some invalid data is floating into the application (see http://www.unixguide.net/network/socketfaq/4.5.shtml), but I don't know how common it is. I don't consider this anymore a security measure at all anymore as those daemons actively try to get rid of it and they have to agree upon it being deactivated. And it really slows down restarting on busy machines if you still have lots of connections up.

Actually this is only possible directly at the net6 level if we want to prevent an API change here, at least if you're dealing with a IPv6 socket and bindv6only set to 0 (so it is actually in use to listen on both IPv4 and IPv6). I wonder if get_socket should return the IPv6 socket in this case, but it looks very unclean to me somehow to have access only to one of the two sockets through get_socket.

Armin, do you have any objection to just set that for every server socket in net6?

[Armin Burgmeier (arbu)]

> Armin, do you have any objection to just set that for every server socket in net6?

I'd suggest to add a tcp_server_socket::tcp_server_socket(const address& bind_addr, bool reuse_addr) overload. We can then let net6::server always set the reuse_addr flag to true.

[Martin Pitt (pitti)]

I see a net6 upload for this bug in the hardy SRU queue. Please fix this in Karmic first, and add SRU description/subscription.

[Philipp Kern (pkern)]

On Tue, Jun 02, 2009 at 07:20:07AM -0000, Martin Pitt wrote:
> I see a net6 upload for this bug in the hardy SRU queue. Please fix this
> in Karmic first, and add SRU description/subscription.

It's already fixed in karmic in 1.3.9-1ubuntu1.

Kind regards,
Philipp Kern
--
 .''`. Philipp Kern Debian Developer
: :' : http://philkern.de Stable Release Manager
`. `' xmpp:[e-mail] Wanna-Build Admin
  `- finger <email address hidden>

[Martin Pitt (pitti)]

SRU description/impact/regression potential/test case, please?

[Martin Pitt (pitti)]

> SRU description/impact/regression potential/test case, please?

This is still outstanding.

[Nick Moffitt (nick-moffitt)]

This bug has manifested itself in the "infinote" package as well, now. Infinote looks like the future sobby server, and it's possible it just needs the fix ported across.

In the meantime the only way to work around this seems to be with /proc/sys/net/ipv4/tcp_tw_reuse

[Nick Moffitt (nick-moffitt)]

On lucid, here are the affected packages:

ii infinoted 0.4.1-1 dedicated server for infinote-based collabor
ii infinoted-0.4 0.4.1-1 dedicated server for infinote-based collabor
ii libinfinity-0.4-0 0.4.1-1 infinote-based collaborative editing

I'm noting it here because it looks like a regression triggered by a package name change.

[Kees Cook (kees)]

This (untested) patch should add SO_REUSEADDR to the gobby server.

[Armin Burgmeier (arbu)]

This has been fixed upstream in infinoted 0.5, with this patch: http://git.0x539.de/?p=infinote.git;a=commitdiff;h=3593a6816d9065be6d1137b4f4f8048ab8b0db8d

[Philipp Kern (pkern)]

Fixed in libinfinity 0.5, which is in oneiric.

[Rolf Leggewie (r0lf)]

Karmic has long since stopped to receive any updates. Marking the Karmic task for this ticket as "Won't Fix".

[Rolf Leggewie (r0lf)]

Hardy has seen the end of its life and is no longer receiving any updates. Marking the Hardy task for this ticket as "Won't Fix".