Bug#684407: apt: connection to Debian mirror with both A and AAAA records fails if client has no routable IPv6 address
On Wed, Jul 19, 2017 at 05:57:09PM +0200, Vincent Lefevre wrote:
> On 2017-07-19 17:01:27 +0200, Julian Andres Klode wrote:
> > On Wed, Jul 19, 2017 at 04:53:37PM +0200, Vincent Lefevre wrote:
> > > On 2017-07-19 14:03:01 +0200, Julian Andres Klode wrote:
> > > > I can't reproduce this, but you just marked it as found in 1.5~beta1. All
> > > > my networks are IPv4-only (either just gw -> internet or entirely) and I
> > > > never had any issue with that, nor does the majority - otherwise we'd
> > > > be swimming in bug mails, so it must be some niche setup.
> > >
> > > I suspect that most users have a working IPv6 address or no global
> > > IPv6 address at all. Actually, that's the normal set-up. What happens
> > > here is either IPv6 is partly down or there's a SLAAC attack.
> >
> > As someone else wrote before, the issue is more likely that the IPv4
> > server does not work, and you only see the IPv6 error message, as previous
> > ones are dropped.
>
> IPv6 is tried *first* (unless things have changed since 2015).
> So, this would mean that I would have got the IPv4 failures, not
> the IPv6 ones.
We simply iterate the getaddrinfo() results, we don't prefer one
protocol version over the other - not sure if getaddrinfo() does
that.
>
> > According to ip, I have
> > inet6 fda1:c6c7:dd63:0:a64e:31ff:fe0b:588c prefixlen 64 scopeid 0x0<global>
> > but I don't actually have any reachable IPv6 stuff outside the
> > network.
> >
> > So I'm still not sure when this happens.
>
> What happens for unreachable IPv6 stuff? Is the connection refused
> immediately or does it hang? The problem is visible only with the
> latter.
I don't know. It probably depends on your gateways to respond
with an error message if the given address is routed via some
gateway. Unfortunately, we can't control gateways and if they
drop or not.
>
> > > > I suggest you take a look at methods/connect.cc and see if you can
> > > > come up with a fix. The code specifically iterates over all results
> > > > it gets from getaddrinfo(). Alternatively, try to figure out when this
> > > > bug happens.
> > >
> > > Indeed, it finally manages to connect, but it appears that there
> > > is something like up to an 8-minute timeout. This is too much!
> >
> > That's a contradiction to your previous results.
>
> The previous results were in 2015. Different context.
Well, different "bug" then, and this one is fixed?
>
> > > Here I got:
> > >
> > > Fetched 88.4 kB in 8min 0s (183 B/s)
> > >
> > > This should be shortened, or an option should be added.
> >
> > If the connect times out due to unreachable next hop, that
> > should happen immediately, otherwise it waits 120 seconds
> > for connect() to succeed (and any other operation, read,
> > write, etc.).
> >
> > You can set the acquire::http::TimeOut option to reduce that.
>
> OK, but the apt.conf(5) man page says:
>
> The option timeout sets the timeout timer used by the method; this
> value applies to the connection as well as the data timeout.
>
> This means that if I reduce the timeout with this option, this
> will also affect the data timeout, and e.g. 10 seconds may be
> too short for it.
I don't think 10 seconds timeout for *any* data (one TCP packet)
is too low, really.
--
Debian Developer - deb.li/jak | jak-linux.org - free software dev
| Ubuntu Core Developer |
When replying, only quote what is necessary, and write each reply
directly below the part(s) it pertains to ('inline'). Thank you.
Reply to: