refactor: deactivate IPv6 in nginx per default

[meteyou]

Signed-off-by: Stefan Dej meteyou@gmail.com

[miklschmidt]

Curious, what's the motivation for this? Are there any additional measures to force mDNS to not use IPv6?

Without

[server]
use-ipv6=no

In /etc/avahi/avahi-daemon.conf, won't this break for many users?

[meteyou]

I think this could also be a good solution. Maybe a better solution than my change.

[miklschmidt]

I think this could also be a good solution. Maybe a better solution than my change.

I suppose this PR was to fix the fact that some people experience problems connecting to moonraker because mDNS resolves to the local IPv6 address which is not whitelisted in the moonraker authentication section. If you remove the IPv6 listener from nginx, they'll just fail to connect completely. Most routers use a subnet generated from the public IPv6 address given by the ISP, so it's literally impossible to whitelist on build time without whitelisting everything, and then we might as well just remove the authentication section altogether. The only feasible way i see to "fix" the issue is to force IPv4, even though it feels wrong.

[meteyou]

no, thats not the case. if you disable ipv6 in nginx, the client will use ipv4. its like a fallback...

[miklschmidt]

@meteyou interesting. I might have misdiagnosed the situation but some of my users just couldn't connect unless it listened for ipv6. Enabling IPv6 in nginx just moved the problem to moonraker.

[miklschmidt]

@meteyou Maybe we do both? I'll try to remember to test this, RatOS 2.0 is right around the corner.

[meteyou]

@meteyou interesting. I might have misdiagnosed the situation but some of my users just couldn't connect unless it listened for ipv6. Enabling IPv6 in nginx just moved the problem to moonraker.

Yeah... this issue was the reason for this commit. The problem is that mDNS only checks if port 80 is listening for ipv6, but this is no check for moonraker if the address is allowed. By removing it from nginx, the user will not have this issue because it will connect every time with ipv4.

But I think your solution is better because it fixes the issue at the beginning (avahi). Suppose a user has an ipv6-only network (i don't think this exists for private networks, only for company networks). In that case, the local DNS server will provide ipv6, and nginx can send mainsail via ipv6, and this user has to allow his ipv6 network in his moonraker.conf...

[miklschmidt]

The problem is that mDNS only checks if port 80 is listening for ipv6, but this is no check for moonraker if the address is allowed. By removing it from nginx, the user will not have this issue because it will connect every time with ipv4.

This is news to me, but i'm not an mDNS expert. I can't find anything about port 80 being a prerequisite for mDNS to respond with both IPv4 and IPv6. If this was indeed the case, i can't understand why some people couldn't connect to nginx at all via the .local address until it was configured to listen for IPv6. Do you mean the browser falls back to IPv4 if IPV6 doesn't respond? Because that is definitely a thing, but it's a configurable thing, and i'm not sure that the defaults are consistent.

Suppose a user has an ipv6-only network (i don't think this exists for private networks, only for company networks). In that case, the local DNS server will provide ipv6, and nginx can send mainsail via ipv6, and this user has to allow his ipv6 network in his moonraker.conf...

I had quite a few users with IPv6 connection issues before the nginx change, i can't say for sure if any of them were on private networks, but i would assume so.

I'll have to send some users to https://ipv6-test.com/. Chrome on my machine defaults to IPv4 regardless of whether IPv6 is available or not.

[meteyou]

I don't know if mDNS or the browser redirects to ipv4 when ipv6 is disabled in nginx...

I recommend users disable ipv6 in nginx or add the network to their moonraker.conf if they have issues with connecting to moonraker. Both methods work...

[miklschmidt]

Will start trying the nginx change! Usually we've been telling people to use the IPv4 address of the pi instead of the .local address which works too.