netdev - Re: [Feature Request] IP_BIND_ADDRESS_NO

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Fri, 19 Aug 2016 15:33:53 -0700
From:   Eric Dumazet <eric.dumazet@...il.com>
To:     Cristian Morales Vega <christian.morales.vega@...il.com>
Cc:     netdev@...r.kernel.org
Subject: Re: [Feature Request] IP_BIND_ADDRESS_NO_PORT with port

On Fri, 2016-08-19 at 23:41 +0300, Cristian Morales Vega wrote:
> I would like a socket option that let's me share a source port as long
> as the 4-tuples are unique in a UDP socket *and* specify which source
> port that is.
> It would be similar to IP_BIND_ADDRESS_NO_PORT. It would do exactly
> the same when you bind to port 0, but when you bind to a different
> port it would say "don't do anything with this port yet, but when I
> connect() please use the port as source port instead of a random
> ephemeral port".
> 
> The reason is the following. I would like to have a server receiving
> and sending UDP datagrams from multiple clients using a single port. I
> would like to use multiple sockets for sending, so I can use different
> SO_MAX_PACING_RATEs for each one. One socket per client/session.
> So there is a single "main socket" bind to the relevant port
> (equivalent to the one that accept()s in TCP), and when it receives a
> new session request it creates a new socket specific for that season
> (as accept() does). When creating that new socket I first need to
> bind() it to select the port, and then connect() it to make it receive
> only datagrams from the relevant session.
> The problem is that between the bind() and the connect() there is a
> small time in which the new socket can receive data that should go to
> the "main socket". It's not an unsolvable problem but makes the server
> code more complicated than it needs to be.

Yes, this is something I had on my plate for a while. This is indeed
something we can solve easily.