Plugin: check_port fails if machine has both IPv6/IPv4

[dylansama]

Please complete the following tasks.

• Web browser cache cleared
• Link provided to install script if applicable
• Web browser, ruTorrent, PHP and OS version provided

Tell us about your environment

Web Browser: N/A
ruTorrent: Master: 1c80a6d
PHP: PHP 7.4.3
OS: Ubuntu 20.04.5 LTS

Tell us how you installed ruTorrent

Manually

Describe the bug

Machine with both an IPv6 and IPv4 address bound to a single interface. The system is deciding to send calls over the IPv6 address in the http request for port checking, but the default port checking site (www.yougetsignal.com) does not support IPv6 at all when checking open ports.

At least from what I can tell it doesn't. It returns Invalid remote address. whenever you input an IPv6 address in the port checking field (https://www.yougetsignal.com/tools/open-ports/). Tried both the compressed/uncompressed IPv6 notations, nothing seems to work. Fairly certain it simply does not support IPv6.

Steps to reproduce

1. Try to insert an IPv6 address into www.yougetsignal.com with a known open port.
2. It will never work

Expected behavior

Detect if port is open or not.

Additional context

www.yougetsignal.com
Has both an A record (ipv4) and an AAAA record (ipv6).

IPv6 DNS lookup

$ dig www.yougetsignal.com AAAA

; <<>> DiG 9.16.1-Ubuntu <<>> www.yougetsignal.com AAAA
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41731
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;www.yougetsignal.com.		IN	AAAA

;; ANSWER SECTION:
www.yougetsignal.com.	300	IN	AAAA	2606:4700:3033::6815:2462
www.yougetsignal.com.	300	IN	AAAA	2606:4700:3033::ac43:c04e

;; Query time: 28 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Tue Nov 01 20:26:37 PDT 2022
;; MSG SIZE  rcvd: 105

This is likely very system dependent, but most linux systems follow the same logic on DNS lookups I've found. It will attempt both an AAAA and A lookup. If the domain has an AAAA record it will be preferred, which when the call finally gets back to curl it will be made over IPv6 then.

The check_port plugin works in a 2-step manner: first getting the caller's external address, and second submitting the port and ip_address in a form. Because www.yougetsignal.com has an AAAA record and is actively listening to all IPv6 queries on its webserver, its fulfilling the initial call to find the caller's external address. Which is fairly basic, and makes sense as to why the IP address lookup supports IPv6. It's port checking functionality was not built to handle testing IPv6 addresses though I'm guessing.

portchecker.co
Is only listening on IPv4, so actually works great. However the check_plugin has a different bug in that it is not submitting to the correct url for this site (filed separately). Otherwise this would work for machines with both IPv6/IPv4, as the DNS lookup will only find an A record for portchecker.co, thus making the calls naturally go over IPv4 as expected and everything works fine.

The solution as it were would be to simply ensure the requests are made ONLY over IPv4. Looking into the SnoopyClient in PHP it makes all https calls by using curl under the hood. Curl thankfully has a very simple parameter to ensure the interface used for the query is done only using IPv4, --ipv4. With that 1 simple parameter addded, we can ensure check_port calls always work (since none of the sites support IPv6 anyways) for all users.

Already made a PR so that the underlying curl request will only use ipv4 (only enabled within the check_port plugin), thus sidestepping the issue with www.yougetsignal.com entirely.
#2396

[stickz]

Issue resolved with #2396 by setting --ipv4 as a curl parameter. Please comment here for any further issues.