Connectivity check in an IPv6-only network

I recently changed my home-network to IPv6 only with NAT64 and DNS64 at the edge (why? because I can...)

Now: Looks like the "Host IP" field in Octoprint Connectivity check only accepts IPv4 addresses. "Test name resolution" works fine, but when I (for example) enter 2620:fe::fe and port 53 in "Host IP" and click "Test host & port" it says "server is not reachable". Using "host octoprint.org 2620:fe::fe" from the commandline shows it is reachable...

Solution of course is to switch off connectivity check...

This might be a bug, in which case please open a bug report on GitHub.

The python docs have this section below in them:


  • A pair (host, port) is used for the AF_INET address family, where host is a string representing either a hostname in internet domain notation like 'daring.cwi.nl' or an IPv4 address like '100.50.200.5', and port is an integer.

    • For IPv4 addresses, two special forms are accepted instead of a host address: '' represents INADDR_ANY, which is used to bind to all interfaces, and the string '' represents INADDR_BROADCAST. This behavior is not compatible with IPv6, therefore, you may want to avoid these if you intend to support IPv6 with your Python programs.
  • For AF_INET6 address family, a four-tuple (host, port, flowinfo, scope_id) is used, where flowinfo and scope_id represent the sin6_flowinfo and sin6_scope_id members in struct sockaddr_in6 in C. For socket module methods, flowinfo and scope_id can be omitted just for backward compatibility. Note, however, omission of scope_id can cause problems in manipulating scoped IPv6 addresses.

    Changed in version 3.7: For multicast addresses (with scope_id meaningful) address may not contain %scope_id (or zone id) part. This information is superfluous and may be safely omitted (recommended).


OctoPrint uses the first section for its connectivity check, so maybe it doesn't work for IPv4 addresses.

Beware, raspberry Pi's do not play well with IPV6. I have quite a few around the house, and even with the latest bullseye, there are still issues. I disable IPV6 on them

Sorry, thats rubbish. My 5 RasPis do all fine in an IPv6 only network. But thats not the topic here. This is only about OctoPrint and if the connectivity check entry field can also take an IPv6 address.

As @Charlie_Powell pointed out, "this might be a bug". I think this is a bug and the best way to get bugs fixed is to open a bug report at https://github.com/OctoPrint/OctoPrint/issues.

Either its a simple bug and the input field validation doesn't accept IPv6 addresses or its a more complicated bug because the underlying code doesn't know what to do with the IPv6 address.

You will need a GitHub account (they are free) and do the best you can with the bug report template. You are in the best position to test any fix that gets created so you should author the bug report.

Will do - I thought I ask here first if I am just to stupid to configure this. I do know about networks but have no clue about Python....

Bug report here: Connectivity check does not take IPv6 addresses Β· Issue #4380 Β· OctoPrint/OctoPrint Β· GitHub

Do you realy need an external server to find your External IP?
I get that info directly from my own router.

Stop thinking IPv4 please. On IPv6 you can get your external IP (well, ONE of your possible multiple external IPs) directly from your interface.

IF you do not NAT. There are so many possibilities to construct a network....

A nice two-liner of PHP can get you your IP (and this works for IPv6 and also for legacy-IP):

<?php
  $ip = getenv("REMOTE_ADDR");
  echo $ip;
?>

Indeed. When I ssh into my raspi it greets me like this:

Access OctoPrint from a web browser on your network by navigating to any of:

    http://kiwi.local
    http://192.168.23.48
    http://[2001:db8:2319:0:5f2a:19ee:e9c8:2b4]
    http://[2001:db8:2319:0:e414:751e:9b0e:175]
    http://[2001:db8:2319:0:fb31:64b2:e3c1:a3a]
    http://[2001:db8:2319:0:cb09:93cf:6172:56b]
    http://[2001:db8:2319:0:af94:17a2:74c7:61]
    http://[2001:db8:2319:0:f522:8472:a3d1:92b]
    http://[2001:db8:2319:0:dd5f:5799:5311:c18]
    http://[2001:db8:2319:0:300e:6a96:e04:b77]
    http://[2001:db8:2319:0:f4c7:84ec:e73:758]
    http://[2001:db8:2319:0:6a82:87cd:8bc1:13f]
    http://[2001:db8:2319:0:3752:5fdd:5cc4:381]
    http://[2001:db8:2319:0:298e:a23c:fa63:132]
    http://[2001:db8:2319:0:ca69:9edd:7b18:5d8]
    http://[2001:db8:2319:0:651e:a545:eae9:4cf]
    http://[2001:db8:2319:0:42a7:2be:efd6:eab]
    http://[2001:db8:2319:0:eefd:ea48:1568:422]
    http://[2001:db8:2319::b00b:c1f1]
    http://[fdec::cafe:48]
    http://[fdec::23:48]
    http://[2001:db8:2319:0:ba27:ebff:fe3e:67a0]

https is also available, with a self-signed certificate.

You know that 2001:db8::/32 is the network reserved for documentation purposes?

Looks like this will be fixed in 1.8.0.

1 Like

Exactly, so that's what you pick when for some reason you hesitate posting a dozen global ip to your print host