Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.bugs.dist > #1253139 > unrolled thread

Bug#1109457: apt-listbugs: Does not fall back to IPv4 on IPv6 failure

Back to article view | Back to linux.debian.bugs.dist

Contents

  Bug#1109457: apt-listbugs: Does not fall back to IPv4 on IPv6 failure Cameron Davidson <bugs@davidsoncj.id.au> - 2025-07-18 11:50 +0200
    Bug#1109457: apt-listbugs: Does not fall back to IPv4 on IPv6 failure Francesco Poli <invernomuto@paranoici.org> - 2025-07-18 23:00 +0200
      Bug#1109457: apt-listbugs: Does not fall back to IPv4 on IPv6 failure Cameron Davidson <bugs@davidsoncj.id.au> - 2025-07-24 10:20 +0200

#1253139 — Bug#1109457: apt-listbugs: Does not fall back to IPv4 on IPv6 failure

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

[toc] | [next] | [standalone]

#1253205

[Multipart message — attachments visible in raw view] — view raw

Control: tags -1 moreinfo


On Fri, 18 Jul 2025 18:23:29 +1000 Cameron Davidson wrote:

> Package: apt-listbugs
> Version: 0.1.47
> Severity: normal
> Tags: ipv6
> 
> Dear Maintainer,

Hello Cameron,
thanks for your bug report.

> 
> * 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.

This looks like a [known issue] with the dash shell, which, as far as I
can tell, is still used by libapt to invoke hooks. I have [repeatedly]
[asked] the APT Development Team for a status update on this issue, but I
haven't yet received any reply...

[known issue]: <https://bugs.debian.org/832593#80>
[repeatedly]: <https://bugs.debian.org/960442#15>
[asked]: <https://bugs.debian.org/960442#37>

> 
> 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

Well, this is debug output coming from the Ruby library (I think).
You cannot expect a perfectly clean and beautiful output, when you pass
the debug option...    ;-)

> 
> 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?

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>

This was changed almost [19 years ago], before I began to maintain and
develop apt-listbugs. And it seems it was done in response to a bug
report...

[19 years ago]: <https://salsa.debian.org/frx-guest/apt-listbugs/-/commit/481b5e6e7adc3d557d17d3ed471c4f78e126c0e0>

If there's another timeout that kicks in before 999 s at about 360 s or
so, I cannot understand where it is coming from, to be honest.
I haven't found any default timeout set by [ruby-soap4r], apart from
the ones that apt-listbugs sets to 999 s ...

[ruby-soap4r]: <https://salsa.debian.org/ruby-team/ruby-soap4r/-/tree/f60e60bbfaf557b1c7a2a42285d3d4349d0a6eef>

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...

> 
> 
> 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.

Well, if you remove apt-listbugs, you won't enjoy its services, of
course!   ;-)

On the other hand, if you temporarily disable IPv6, you have to do
something inconvenient, whenever you want to use apt or aptitude...


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.


-- 
 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

[toc] | [prev] | [next] | [standalone]

#1253764

[Multipart message — attachments visible in raw view] — view raw

On 2025-07-19 06:47, Francesco Poli wrote:
> Control: tags -1 moreinfo
>
>
> On Fri, 18 Jul 2025 18:23:29 +1000 Cameron Davidson wrote:
>
>> Package: apt-listbugs
>> Version: 0.1.47
>> Severity: normal
>> Tags: ipv6
>>
>> Dear Maintainer,
> Hello Cameron,
> thanks for your bug report.

Thanks for the detailed response

>> * 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.
> This looks like a [known issue] with the dash shell, which, as far as I
> can tell, is still used by libapt to invoke hooks. I have [repeatedly]
> [asked] the APT Development Team for a status update on this issue, but I
> haven't yet received any reply...
>
> [known issue]:<https://bugs.debian.org/832593#80>
> [repeatedly]:<https://bugs.debian.org/960442#15>
> [asked]:<https://bugs.debian.org/960442#37>
>
>> 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
> Well, this is debug output coming from the Ruby library (I think).
> You cannot expect a perfectly clean and beautiful output, when you pass
> the debug option...    ;-)

I did not know what to expect, not having ruby installed until apt-listbugs.

I was just following instructions that had been given in other bug reports.


>> 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.


>
> 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>
>
> This was changed almost [19 years ago], before I began to maintain and
> develop apt-listbugs. And it seems it was done in response to a bug
> report...
>
> [19 years ago]:<https://salsa.debian.org/frx-guest/apt-listbugs/-/commit/481b5e6e7adc3d557d17d3ed471c4f78e126c0e0>
>
> If there's another timeout that kicks in before 999 s at about 360 s or
> so, I cannot understand where it is coming from, to be honest.
> I haven't found any default timeout set by [ruby-soap4r], apart from
> the ones that apt-listbugs sets to 999 s ...
>
> [ruby-soap4r]:<https://salsa.debian.org/ruby-team/ruby-soap4r/-/tree/f60e60bbfaf557b1c7a2a42285d3d4349d0a6eef>
>
> 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.

Waiting for a timeout is my only option short of disabling IPv6 completely

>> 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.
> Well, if you remove apt-listbugs, you won't enjoy its services, of
> course!   ;-)
>
> On the other hand, if you temporarily disable IPv6, you have to do
> something inconvenient, whenever you want to use apt or aptitude...
>
>
> 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).

It is probably a rare enough event that I don't feel inclined to 
artificially adjust my firewall to simulate the situation again.

My guess about the delay is that maybe it is the accumulation of 60 
second delays in each of 6 requests.

Thanks again,

Cameron.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.bugs.dist

csiph-web