Both A and AAAA tracker lookups are done regardless of IPv6-status

[tofurky]

I was looking into some intermittent errors thrown by dnsmasq on my network - Maximum number of concurrent DNS queries reached (max: 150) - and so ran a packet capture to investigate the traffic. I did and can tweak dnsmasq to increase concurrent upstream requests; but, if I can reduce the number of queries generated, it seems it'd be better.

I noticed that for each tracker lookup, separate A and AAAA queries are being sent. In my case, this is pointless since the server, while it has IPv6 kernel support, is IPv4 only.

So, it's effectively doubling the amount of DNS queries made, which can push dnsmasq over the threshold waiting for upstream responses. They come in pretty quick succession with udns support, too.

It appears to be due to the default use of AF_UNSPEC sockets per UdnsResolver::resolve(). Commenting out the AF_INET6 + AF_UNSPEC case there leads to the behavior I wanted (A-only).

I did try restricting address families per systemd (e.g. RestrictAddressFamilies=AF_INET AF_UNIX) and while the listener in ss output shows it becomes AF_INET, the AAAA queries persisted.

Sorry in advance if there's some simple way to change this behavior that I missed. It seems while --enable-ipv6 existed in rtorrent as recently as https://github.com/rakshasa/rtorrent/commit/8d562d53fc1ed7107087e11effd4de2fc74ffde2 and still exists here, it doesn't do anything per e14dd067efe9f29cf11f8e72e69c74e30c4adca1. is_block_ipv6() and set_block_ipv6() as controlled by network.block.ipv6.set don't appear to do anything, either.

Honestly not sure if this is a bug or a feature request; perhaps the vestigial flags are a "bug", but the AAAA+A for every lookup may be intentional.

[rakshasa]

Setting network.block.ipv6.set should be fixed to also apply to dns lookups.

[tofurky]

I finally rebased on master - network.block.ipv6.set = 1 in .rtorrent.rc isn't blocking AAAA lookups :/ tcpdump is showing the same behavior as before. Maybe I'm doing it wrong?

# xmlrpc_rtorrent network.block.ipv6 
Result:

64-bit integer: 1

[rakshasa]

Are those AAAA lookups UDP tracker requests?

fix/tracker-error branch should now avoid DNS requests for those if blocked.

Note that http requests for torrent files (not tracker requests) are not affected by the block setting above.

[tofurky]

Yep, tracker requests. I'll check out that branch and report back, thanks.

[tofurky]

Seemed to prevent the lookups per tcpdump, but pretty quickly died with the following:

rtorrent: caught torrent::internal_error: CurlGet::set_initial_resolve(...) called on a stacked or started object.
/lib/x86_64-linux-gnu/libtorrent.so.30(_ZN7torrent14internal_error10initializeERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE+0x90) [0x7b61e53c9820]
/usr/bin/rtorrent(_ZN7torrent14internal_errorC1EPKc+0xaa) [0x5a5dd826d30a]
/lib/x86_64-linux-gnu/libtorrent.so.30(+0x48945) [0x7b61e537e945]
/lib/x86_64-linux-gnu/libtorrent.so.30(_ZN7torrent3net7HttpGet8use_ipv4Ev+0x15) [0x7b61e53a2735]
/lib/x86_64-linux-gnu/libtorrent.so.30(+0xf51b8) [0x7b61e542b1b8]
/lib/x86_64-linux-gnu/libtorrent.so.30(+0xef51f) [0x7b61e542551f]
/lib/x86_64-linux-gnu/libtorrent.so.30(_ZN7torrent5utils9Scheduler7performENSt6chrono8durationIlSt5ratioILl1ELl1000000EEEE+0x56) [0x7b61e53c3c46]
/lib/x86_64-linux-gnu/libtorrent.so.30(_ZN7torrent5utils6Thread10event_loopEv+0x78) [0x7b61e53c5188]
/usr/bin/rtorrent(+0x58b09) [0x5a5dd825bb09]
/lib/x86_64-linux-gnu/libc.so.6(+0x29ca8) [0x7b61e4e33ca8]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0x85) [0x7b61e4e33d65]
/usr/bin/rtorrent(+0x59a71) [0x5a5dd825ca71]

[rakshasa]

Do you get that error on current master?

[rakshasa]

Updated the branch with some possible fixes.

Edit: Fixed, found the bug.

[tofurky]

Nope, was just seeing it on fix/tracker-error. Tip of master seems fine now with regards to both the AAAA and crash, thanks.