Re: [tor-relays] inet_csk_bind_conflict

[David Fifield <david@xxxxxxxxxxxxxxx>]

On Mon, Dec 12, 2022 at 10:18:53PM +0100, Anders Trier Olesen wrote:
> > It is surprising, isn't it? It certainly feels like calling connect
> > without first binding to an address should have the same effect as
> > manually binding to an address and then calling connect, especially if
> > the address you bind to is the same as the kernel would have chosen
> > automatically. It seems like it might be a bug, but I'm not qualified to
> > judge that.
>
> Yes, I'm starting to think so too. And strange that Cloudflare doesn't mention
> stumbling upon this problem in their blogpost on running out of ephemeral
> ports. [1]
> [1]https://blog.cloudflare.com/how-to-stop-running-out-of-ephemeral-ports-and-start-to-love-long-lived-connections
> If I find the time, I'll make an attempt at understanding exactly what is going
> on in the kernel.

Cloudflare has another blog post today that gets into this topic.

https://blog.cloudflare.com/the-quantum-state-of-a-tcp-port/

It investigates the difference in behavior between
inet_csk_bind_conflict and __inet_hash_connect that I commented on at
https://forum.torproject.net/t/tor-relays-inet-csk-bind-conflict/5757/13 and
https://bugs.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/40201#note_2839472.
Setting the IP_BIND_ADDRESS_NO_PORT option leads to __inet_hash_connect;
not setting it leads to inet_csk_bind_conflict.

The author attributes the difference in behavior to the fastreuse field
in the bind hash bucket:

> The bucket might already exist or we might have to create it first.
> But once it exists, its fastreuse field is in one of three possible
> states: -1, 0, or +1.
>
> …
>
> …inet_csk_get_port() skips conflict check for fastreuse == 1 buckets.
> …__inet_hash_connect() skips buckets with fastreuse != -1.
_______________________________________________
tor-relays mailing list
tor-relays@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays