Fix upload failure on Windows caused by IPv6 link-local resolution #1245

New Issue

MrUnknownDE · 2026-04-05T17:05:23+02:00

MrUnknownDE commented

2026-04-05 17:05:23 +02:00

Originally created by @sezgynus on 12/28/2025

Description

This PR fixes a hostname-based upload failure on Windows when using .local addresses.

When a printer is configured using a hostname, Orca Slicer resolves the address via mDNS (Bonjour).
On Windows, mDNS resolution often returns only IPv6 link-local addresses (fe80::/10).
These addresses are valid for local discovery but are not suitable targets for HTTP-based uploads, as Moonraker/Nginx typically does not listen on IPv6 link-local interfaces.

As a result, G-code uploads could fail deterministically with connection refused, while UI access and connection tests continued to work due to browser-level IPv4 fallback.

This change filters out IPv6 link-local addresses during mDNS resolution.
If no usable addresses remain, the existing system resolver fallback is preserved.

No new features are introduced, and there are no breaking changes.
The fix only affects the upload path and improves consistency with browser behavior.

Screenshots/Recordings/Graphs

https://github.com/user-attachments/assets/13fb7718-9575-4e6d-8439-8a5b7cd5ea0c

Tests

Windows 10 / Windows 11
Printer configured using hostname (*.local)
Moonraker/Nginx listening on IPv4 only
Verified that:
- G-code upload fails before the change when mDNS resolves to IPv6 link-local
- G-code upload succeeds after the change using IPv4
- UI access and connection test behavior remains unchanged
- System resolver fallback still works when mDNS does not return a usable address

*Originally created by @sezgynus on 12/28/2025* # Description This PR fixes a hostname-based upload failure on Windows when using `.local` addresses. When a printer is configured using a hostname, Orca Slicer resolves the address via mDNS (Bonjour). On Windows, mDNS resolution often returns only IPv6 link-local addresses (`fe80::/10`). These addresses are valid for local discovery but are not suitable targets for HTTP-based uploads, as Moonraker/Nginx typically does not listen on IPv6 link-local interfaces. As a result, G-code uploads could fail deterministically with `connection refused`, while UI access and connection tests continued to work due to browser-level IPv4 fallback. This change filters out IPv6 link-local addresses during mDNS resolution. If no usable addresses remain, the existing system resolver fallback is preserved. No new features are introduced, and there are no breaking changes. The fix only affects the upload path and improves consistency with browser behavior. # Screenshots/Recordings/Graphs ![file_00000000468471f4acdbc60ff75505ec.png](https://github.com/user-attachments/assets/d994bf8f-b128-44bf-9817-d6df489510b6) ![Video Project 2](https://github.com/user-attachments/assets/969cd5fd-8f1b-47d5-b35e-9c35cbb83ab2) https://github.com/user-attachments/assets/13fb7718-9575-4e6d-8439-8a5b7cd5ea0c ## Tests - Windows 10 / Windows 11 - Printer configured using hostname (`*.local`) - Moonraker/Nginx listening on IPv4 only - Verified that: - G-code upload fails before the change when mDNS resolves to IPv6 link-local - G-code upload succeeds after the change using IPv4 - UI access and connection test behavior remains unchanged - System resolver fallback still works when mDNS does not return a usable address

Sign in to join this conversation.

No Label

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github/OrcaSlicer#1245