On 2019-10-13 12:11:51, Eduard Bloch wrote:
> Hallo,
> * Antoine Beaupre [Thu, Oct 10 2019, 12:36:21PM]:
>> Package: apt-cacher-ng
>> Version: 3.2-2
>> Severity: normal
>> Tags: ipv6
>>
>> apt-cacher-ng does not deal well with dual-stack failures. At home I
>> regularly have trouble with my IPv6 connexions, which just hang. Most
>> applications are able to recover from this and fallback to IPv4, which
>> just works. This is therefore mostly transparent to users, at worst
>> there's a slight delay during the switchover.
>
> Okay, I agree. I also experience such situations, rarely, when the
> crap modem from my provider gets upset and fails to route IPv6 (but
> still reports full IPv6 connectivity in its diagnostics).
>
>> The way to deal with this is documented in RFC 8305 and is generally
>> refered to as "happy eyeballs":
>>
>> https://en.wikipedia.org/wiki/Happy_Eyeballs
>
> Not sure this is feasible exactly the way they describe there. This RFC
> is apparently mostly by DNS timing behavior but ACNG currently uses
> getaddrinfo which delivers all collected DNS data at once.
>
> What I intend to implement instead is a similar scheme:
>
> a) get all DNS records like ATM
> b) filter to IPv4 or IPv6 or both (depending on user preference in
> <ConnectProto> setting)
> c) auto-sort the list so that the first entry is v4 or v6 (depending on
> <ConnectProto> preference) and the following ones are alternativing
> d) start connecting on the first entry
> e) when nothing happened after N seconds, start a second connection attempt
> in parallel (using the second address, which is of different family then)
> f) if the second background connect attmpt fails after N, abort it, try the
> next DNS entry in the sequence, etc. etc. (while the first connect attempt is
> still ongoing, until <NetworkTimeout> seconds is reached)
>
> Questions:
>
> a) do you consider this reasonable enough?
That seems reasonable, and actually pretty close to RFC8305.
> b) would you like to become a tester for this, in case you can reproduce
> this regularly? (I can fake the test case but nothing beats the real
> thing)
I can try! it can take up to a month for this situation to occur and I
haven't tried reproducing it manually, but I'm definitely happy to help.
> c) any good name proposal for N? I think about "FastTimeout"
> (vs. NetworkTimeout)
The RFC calls this a "Connection Attempt Delay".
> d) good default value for N? I'd consider 5s (while NetworkTimeout: 60s
> currently)
"N" is 250ms in the rfc, fwiw, which seems more reasonable than (say)
something large than 1s, let alone one *minute*. :)
It also says that connexion attempts should be spaced out by at least
10ms, preferably 100ms. This is all in section 5.
A.
--
You are absolutely deluded, if not stupid, if you think that a
worldwide collection of software engineers who can't write operating
systems or applications without security holes, can then turn around
and suddenly write virtualization layers without security holes.
- Theo de Raadt
