[Bug 1308200] Re: apt-get not RFC6555 (Happy Eyeballs) compliant

Julian Andres Klode 1308200 at bugs.launchpad.net
Tue Jan 2 22:01:57 UTC 2018


Spent the day implementing a subset of Happy Eyeballs Version 2 (RFC
8305, https://tools.ietf.org/html/rfc8305) for APT. I initially started
implementing a subset of its predecessor (RFC 6555,
https://tools.ietf.org/html/rfc6555) half a year ago and reworked that
today, but then I noticed the new RFC and switched to that.

The branch pu/happy-eyeballs2a
(https://github.com/Debian/apt/compare/master...julian-klode:pu/happy-
eyeballs2a?expand=1) implements it as following:

1. All addresses returned by getaddrinfo() are ordered so that preferred and non-prefered address families alternate (for example, IPv6, IPv4, IPv6, IPv4).
2. For each address, we attempt a connection and wait 250 ms for it and all previous attempts, storing all attempts in a list (vector currently). If one connection succeeds it is used.
3. If no connection succeeded, we wait another TimeOut for all attempts and use the result of that wait as the final result.

This means we easily fall back in cases of broken IPv6 routing, and also
in situations where some hosts just refuse connections.

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to apt in Ubuntu.
https://bugs.launchpad.net/bugs/1308200

Title:
  apt-get not RFC6555 (Happy Eyeballs) compliant

Status in apt package in Ubuntu:
  In Progress
Status in apt package in Debian:
  New

Bug description:
  Disclaimer: I'm not sure if this is a bug, or a feature. If it is not
  a bug, I think reporting this issue is useful anyway because it causes
  long delays in apt-get install / apt-get update.

  On dual-stack setups (IPv4 and IPv6), if one of the two paths is slow
  or non-functional at all, the overall application experience can be
  slow.

  An application that uses a Happy Eyeballs (RFC 6555) algorithm checks
  both IPv4 and IPv6 connectivity (with a preference for IPv6) and uses
  the first connection that is returned. This has been implemented in,
  for example, Chrome and Firefox.

  apt / apt-get does not have this functionality. Due to this lack, a
  apt-get run can be very slow: a "sudo apt-get update" can take up to
  15 minutes on a system with a non-functional IPv6 connection, even if
  the system is already uptodate, which normally only takes 15 seconds
  or so.

  "man apt.conf" shows this info:

         ForceIPv4
             When downloading, force to use only the IPv4 protocol.

         ForceIPv6
             When downloading, force to use only the IPv6 protocol.

  So no feature "RFC6555" or "HappyEyeballs".

  An ugly work-around is this: Create a file
  /etc/apt/apt.conf.d/99timeout with these contents

  Acquire::http::Timeout "2";
  Acquire::ftp::Timeout "2";

  That way, after 2 seconds the other path is chosen.

  $ lsb_release -rd
  Description:	Ubuntu 14.04 LTS
  Release:	14.04

  ProblemType: Bug
  DistroRelease: Ubuntu 14.04
  Package: apt 1.0.1ubuntu2
  ProcVersionSignature: Ubuntu 3.13.0-24.46-generic 3.13.9
  Uname: Linux 3.13.0-24-generic x86_64
  ApportVersion: 2.14.1-0ubuntu2
  Architecture: amd64
  CurrentDesktop: Unity
  Date: Tue Apr 15 20:26:25 2014
  InstallationDate: Installed on 2014-04-10 (4 days ago)
  InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Daily amd64 (20140410)
  SourcePackage: apt
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1308200/+subscriptions



More information about the foundations-bugs mailing list