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.
> 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 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.
> > 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.
--
Vincent Lefèvre <vinc...@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
