Your message dated Thu, 24 Jul 2025 22:40:25 +0200
with message-id <[email protected]>
and subject line Re: Bug#1109457: apt-listbugs: Does not fall back to IPv4 on
IPv6 failure
has caused the Debian Bug report #1109457,
regarding apt-listbugs: Does not fall back to IPv4 on IPv6 failure
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
1109457: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1109457
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: apt-listbugs
Version: 0.1.47
Severity: normal
Tags: ipv6
Dear Maintainer,
* Verified in Debian 12 as well as Deb 13 testing.
If apt-listbugs is installed in a system then, when there are problems
with IPv6, "apt install/update" can appear to hang at
"Retrieving bug reports...0%"
Requires ctrl-C, and after saying do not try to retrieve bugs again
apt asks if it should continue installation.
When I select "yes" it then fails to continue installation.
Also "apt-listbugs -d list apt-listbugs" initally reports:
Exception `LoadError' at
<internal:/usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_require.rb>:136 -
cannot load such file -- soap/rpc/driver
Exception `LoadError' at
<internal:/usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_require.rb>:136 -
cannot load such file -- xml/encoding-ja
Exception `LoadError' at
<internal:/usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_require.rb>:144 -
cannot load such file -- xml/encoding-ja
Set XSD::XMLParser::XMLParser as XML processor.
Exception `LoadError' at
<internal:/usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_require.rb>:136 -
cannot load such file -- httpclient
Exception `LoadError' at
<internal:/usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_require.rb>:136 -
cannot load such file -- addressable/uri
Exception `LoadError' at
<internal:/usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_require.rb>:144 -
cannot load such file -- addressable/uri
Exception `KeyError' at
/usr/lib/ruby/vendor_ruby/http/cookie_jar/abstract_store.rb:15 - key not found:
:hash
and then gets to...
"! CONNECT TO bugs.debian.org 80" (Debian 12)
at which point it seems to hang. But if I wait for
over 6 MINUTES then it does seem to fall back to IPv4 to get the details.
So perhaps my subject line is wrong, but the timeouts are obviously too
long and, coupled with the multiple redirects, means nobody is going to wait
that
long unless they've gone off for a coffee.
The cause of the problem is that my ISP broke routing for my IPv6 address a
week ago, but it was not immediately obvious and is still not fixed.
workaround: is to either uninstall apt-listbugs, or temporarily disable
IPv6 (if convenient). In either case apt then works quickly.
-- System Information:
Debian Release: 13.0
APT prefers testing-security
APT policy: (500, 'testing-security'), (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 6.12.33+deb13-amd64 (SMP w/1 CPU thread; PREEMPT)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages apt-listbugs depends on:
ii apt 3.0.3
ii distro-info 1.13
ii ruby 1:3.3+b1
ii ruby-debian 0.3.10+b13
ii ruby-gettext 3.4.9-1
ii ruby-soap4r 2.0.5-9
ii ruby-unicode 0.4.4.5-1+b2
ii ruby-xmlparser 0.7.3-6+b1
Versions of packages apt-listbugs recommends:
ii ruby-httpclient 2.8.3+git20211122.4658227-1
ii ruby-sys-proctable 1.3.0-1
Versions of packages apt-listbugs suggests:
ii reportbug 13.2.0
ii sensible-utils 0.0.25
pn w3m | www-browser <none>
pn xdg-utils <none>
-- no debconf information
--- End Message ---
--- Begin Message ---
On Thu, 24 Jul 2025 17:49:52 +1000 Cameron Davidson wrote:
> On 2025-07-19 06:47, Francesco Poli wrote:
[...]
> > On Fri, 18 Jul 2025 18:23:29 +1000 Cameron Davidson wrote:
[...]
> >> Dear Maintainer,
> > Hello Cameron,
> > thanks for your bug report.
>
> Thanks for the detailed response
I am glad you appreciated it, although it must be said that I haven't
figured out the mystery of the 360 s timeout...
[...]
> >> and then gets to...
> >> "! CONNECT TO bugs.debian.org 80" (Debian 12)
> >> at which point it seems to hang. But if I wait for
> >> over 6 MINUTES then it does seem to fall back to IPv4 to get the details.
> > Over 6 min, you say?
> > How much more than 6 min?
>
> Using the "time ..." command it reported as 6min 45 seconds for Debian
> 13, and 6min plus somewhere between 20 and 30 s for Debian 12.
OK, so it's not 999 s ...
>
>
> >
> > Could it be almost 17 min, by chance?
> >
> > The only [timeout] set by apt-listbugs itself is 999 s long (which
> > corresponds to almost 17 min), for the SOAP connection.
> >
> > [timeout]:<https://salsa.debian.org/frx-guest/apt-listbugs/-/blob/f9053c84c6cd3ab30556bea10a44ca64a929d3b0/lib/aptlistbugs/debian/btssoap.rb#L38>
But it's not the timeout that kicks in, judging from the time measured
by you.
[...]
> > And the default timeout for [ruby-httpclient] seems to be 60 s, if I
> > understand correctly...
> >
> > [ruby-httpclient]:<https://salsa.debian.org/ruby-team/ruby-httpclient/-/blob/d35b14cda69bbce6ab7e63ab7199c98d4d060a51/lib/httpclient/session.rb#L145>
> >
> >
> > I am really puzzled...
> >
> >> So perhaps my subject line is wrong, but the timeouts are obviously too
> >> long and, coupled with the multiple redirects, means nobody is going to
> >> wait that
> >> long unless they've gone off for a coffee.
> > You have to admit that the main purpose of the connection timeout is
> > not to fall back to IPv4, when IPv6 fails.
> >
> > Moreover, it looks unfortunate that your IPv6 network makes the clients
> > wait indefinitely (until some timeout kicks in, I mean), rather than
> > failing with some immediate error...
>
>
> IPv6 is fine on my system, even to the ISP's internal network, so I have
> no way to know that the packets get lost on the way back.
Ah, I see.
In other words, IPv6 packets were silently dropped or got lost, without
any clear error coming back to your system... as if IPv6 packets fell
into some sort of black hole...
[...]
> > I think that you could try to set another timeout
> > in /usr/lib/ruby/vendor_ruby/aptlistbugs/debian/btssoap.rb (lines 38,
> > 39, and 40) and see whether your wait changes.
> > This way, we could perhaps check whether this is indeed the timeout
> > that kicks in. And whether reducing it helps your use case.
> >
> > Please let me know, if you perform this test.
> > Thanks for your time and patience.
> >
> Sorry about the delay - I was just sitting down to run those checks for
> you when the routing problem got fixed (a mere 8 days after reporting
> it to my ISP).
That is good for you! Now you can enjoy a fully working IPv6 network
again! :-)
>
> It is probably a rare enough event that I don't feel inclined to
> artificially adjust my firewall to simulate the situation again.
I can agree on that: after all, it was a (temporary) misbehavior on
your ISP side, not something that could happen on a (properly
configured) network, where IPv6 is either available or not...
>
> My guess about the delay is that maybe it is the accumulation of 60
> second delays in each of 6 requests.
Sounds plausible.
Did you count 6 requests, or are you only guessing that there were 6
requests, just because the delay was about 6 times the (60 s) timeout?
>
> Thanks again,
You're welcome! :-)
I don't think the silent-IPv6-packet-black-hole scenario is common
enough to warrant an ad-hoc option in apt-listbugs to tweak the
ruby-httpclient timeout.
I am therefore closing this bug report.
Of course, now that I have said this, hundreds of users will raise
their voice and yell "me too!", reopening the bug report... ;-)
Have a nice day!
--
http://www.inventati.org/frx/
There's not a second to spare! To the laboratory!
..................................................... Francesco Poli .
GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE
pgpkRjXT__sIe.pgp
Description: PGP signature
--- End Message ---
