test: Log IP of download server in get_previous_releases.py #34045

1. 
   achow101 commented at 7:10 pm on December 10, 2025: member

   In order to help debug issues with previous release downloads from our web server, we need to know which IP the downloader connected to.
2. DrahtBot added the label Tests on Dec 10, 2025
3. 
   DrahtBot commented at 7:10 pm on December 10, 2025: contributor

   The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

   Code Coverage & Benchmarks

   For details see: https://corecheck.dev/bitcoin/bitcoin/pulls/34045.

   Reviews

   See the guideline for information on the review process.

   Type	Reviewers
   ACK	l0rinc, janb84, rkrux, fjahr, glozow

   If your review is incorrectly listed, please copy-paste <!–meta-tag:bot-skip–> into the comment that the bot should ignore.

4. in test/get_previous_releases.py:126 in 552d780403

   122@@ -122,6 +123,9 @@ def progress_hook(progress_bytes, total_size):
   123         if response.status != 200:
   124             raise RuntimeError(f"HTTP request failed with status code: {response.status}")
   125 
   126+        sock_info = socket.fromfd(response.fileno(), socket.AF_INET, socket.SOCK_STREAM).getpeername()
   

   ---

   ---

   

   janb84 commented at 7:37 pm on December 10, 2025:

   Are the server IP addresses always IPv4 ? Socket.AF_INET is ipv4 only

   Yes it works but give wrong ipv6 address :

   0Connected to 2620:6e:a004:1:30b4:de03:100:0
   1
   2Connected to 2620:6e:a004:1::b1c:c05e
   3
   4dig AAAA bitcoincore.org
   5bitcoincore.org.        3063    IN      AAAA    2620:6e:a004:1::b1c:c05e
   

   0        sock_info = response.fp.raw._sock .getpeername()
   1        print(f"Connected to {sock_info[0]}")
   

   This works (second answer) but is not the highest of quality code.

   ---

   

   achow101 commented at 8:14 pm on December 10, 2025:

   No, it can be IPv6. But since we aren’t ever going to actually use this socket, AF_INET doesn’t matter. The logging still works correctly with IPv6.

   ---

   

   janb84 commented at 8:16 pm on December 10, 2025:

   oke, thanks, please validate that it returns the correct ipv6 addresses, see my edit :) happy to be wrong

   ---

   

   achow101 commented at 8:26 pm on December 10, 2025:

   Using your suggestion, I think it will work more reliably.
5. achow101 force-pushed on Dec 10, 2025
6. DrahtBot added the label CI failed on Dec 10, 2025
7. test: Log IP of download server in get_previous_releases.py cdaf25f9c3
8. in test/get_previous_releases.py:21 in 0a06309cb8

   17@@ -18,6 +18,7 @@
   18 import re
   19 import shutil
   20 import subprocess
   21+import socket
   

   ---

   ---

   

   l0rinc commented at 9:44 pm on December 10, 2025:

   new import seems unnecessary now

   ---

   

   achow101 commented at 9:49 pm on December 10, 2025:

   Removed
9. achow101 force-pushed on Dec 10, 2025
10. in test/get_previous_releases.py:126 in cdaf25f9c3

    121@@ -122,6 +122,9 @@ def progress_hook(progress_bytes, total_size):
    122         if response.status != 200:
    123             raise RuntimeError(f"HTTP request failed with status code: {response.status}")
    124 
    125+        sock_info = response.fp.raw._sock.getpeername()
    126+        print(f"Connected to {sock_info[0]}")
    

    ---

    ---

    

    l0rinc commented at 10:05 pm on December 10, 2025:

    I’m fine with this as well, alternatively to document what we’re connecting to, we could unpack the ip from the (host, port)/(host, port, flowinfo, scope_id) tuples with something like:

    0        ip, *_ = response.fp.raw._sock.getpeername()
    1        print(f"Connected to {ip}")
    

    or

    0        ip = response.fp.raw._sock.getpeername()[0]
    1        print(f"Connected to {ip}")
    

11. l0rinc approved
12. 
    l0rinc commented at 10:06 pm on December 10, 2025: contributor

    untested ACK cdaf25f9c3e56b4e80b90a471bdc0a175160534c
13. DrahtBot removed the label CI failed on Dec 10, 2025
14. 
    janb84 commented at 10:09 am on December 11, 2025: contributor

    ACK cdaf25f9c3e56b4e80b90a471bdc0a175160534c

    Thanks for incorporating my suggestion.

15. rkrux approved
16. 
    rkrux commented at 10:51 am on December 11, 2025: contributor

    tACK cdaf25f9c3e56b4e80b90a471bdc0a175160534c
17. 
    fjahr commented at 2:55 pm on December 11, 2025: contributor

    utACK cdaf25f9c3e56b4e80b90a471bdc0a175160534c
18. 
    glozow commented at 4:35 pm on December 11, 2025: member

    ACK cdaf25f9c3e56b4e80b90a471bdc0a175160534c
19. glozow merged this on Dec 11, 2025
20. glozow closed this on Dec 11, 2025

    ---

Contributors
achow101 DrahtBot janb84 l0rinc rkrux fjahr glozow

Labels
Tests