My Windows client and ZimaOS are on the same LAN, but the auto-discovery fails completely. What’s worse is that I can’t even manually enter the local IPv4 address. Are you really forcing me to use a Network ID and go through a ZeroTier virtual NIC just to connect locally? This design logic feels way too aggressive.
You shouldn’t need ZeroTier for a same-LAN connection. Let’s first prove whether this is networking or just broken discovery.
On your Windows machine (PowerShell), run:
ipconfig
ping 10.0.0.xxx
tracert 10.0.0.xxx
Replace with your ZimaOS IP.
If ping fails > this is subnet/VLAN/network.
If ping works > test the service ports:
Test-NetConnection 10.0.0.xxx -Port 80
Test-NetConnection 10.0.0.xxx -Port 443
Test-NetConnection 10.0.0.xxx -Port 9999
(Replace 9999 with the actual client port.)
If ping works but port test fails > firewall issue.
If ports are open > discovery layer is failing, not LAN connectivity.
On ZimaOS (via SSH), run:
ip addr
ip route
ss -tulnp
This confirms the IP, subnet, and whether the service is actually listening.
If all of that checks out, then the issue isn’t networking, it’s the client not allowing direct LAN IP entry or the discovery mechanism not functioning properly.
Let’s verify first, then we escalate properly.
To follow up and provide some hard evidence—I’ve performed a full-stack diagnostic to prove this isn’t a “network issue,” but a “discovery logic” failure. Here is what I’ve verified:
-
Service Layer: Ran
ss -tulnp | grep -E '80|443|9527'on ZimaOS. All core services are listening on0.0.0.0, NOT just localhost. -
Routing Layer:
ip addrandip routeconfirm the device is sitting exactly where it should be on the local subnet. -
Access Layer: From my Windows host,
Test-NetConnection 10.0.0.109 -Port 9527(as well as 80 and 443) returns TcpTestSucceeded: True.
The “pipe” is wide open. I can reach the ports and see the services, yet the client remains blind.
Are you guys relying on Windows NLA (Network Location Awareness) or specific mDNS/Avahi broadcasts that struggle with multi-homed environments? If NLA is misidentifying the network profile, it might be blocking the discovery layer entirely.
Log:
root@ZimaOS:/root ➜ # netstat -tulnp | grep -E '80|443|9527'
tcp 0 0 0.0.0.0:8096 0.0.0.0:* LISTEN 2903/docker-proxy
tcp6 0 0 :::80 :::* LISTEN 1177/zimaos-gateway
tcp6 0 0 :::443 :::* LISTEN 1177/zimaos-gateway
tcp6 0 0 :::9527 :::* LISTEN 1845/zimaos
tcp6 0 0 :::8096 :::* LISTEN 2911/docker-proxy
udp 0 0 0.0.0.0:48066 0.0.0.0:* 1332/rpc.mountd
udp 0 0 0.0.0.0:58350 0.0.0.0:* 800/avahi-daemon: r
udp 0 0 0.0.0.0:5353 0.0.0.0:* 800/avahi-daemon: r
udp6 0 0 :::443 :::* 1177/zimaos-gateway
udp6 0 0 fe80::fb39:c26d:9e5:546 :::* 1152/NetworkManager
udp6 0 0 :::5353 :::* 800/avahi-daemon: r
udp6 0 0 :::9527 :::* 1845/zimaos
udp6 0 0 :::35170 :::* 800/avahi-daemon: r
root@ZimaOS:/root ➜ # ip addr | grep eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
inet 10.0.0.109/24 brd 10.0.0.255 scope global dynamic noprefixroute eth0
root@ZimaOS:/root ➜ # ip route | grep eth0
default via 10.0.0.1 dev eth0 proto dhcp src 10.0.0.109 metric 100
10.0.0.0/24 dev eth0 proto kernel scope link src 10.0.0.109 metric 100
root@ZimaOS:/root ➜ # ^C
root@ZimaOS:/root ➜ #
PS C:\Windows\system32> Test-NetConnection 10.0.0.109 -Port 443
ComputerName : 10.0.0.109
RemoteAddress : 10.0.0.109
RemotePort : 443
InterfaceAlias : Ethernet0
SourceAddress : 10.0.0.218
TcpTestSucceeded : True
PS C:\Windows\system32> Test-NetConnection 10.0.0.109 -Port 9527
ComputerName : 10.0.0.109
RemoteAddress : 10.0.0.109
RemotePort : 9527
InterfaceAlias : Ethernet0
SourceAddress : 10.0.0.218
TcpTestSucceeded : True
PS C:\Windows\system32> Test-NetConnection 10.0.0.109 -Port 80
ComputerName : 10.0.0.109
RemoteAddress : 10.0.0.109
RemotePort : 80
InterfaceAlias : Ethernet0
SourceAddress : 10.0.0.218
TcpTestSucceeded : True
You’re asking two valid things:
• Why can’t I manually enter the LAN IPv4?
• Am I being forced to use ZeroTier even on the same subnet?
Based on your diagnostics, this is not a network failure.
Your ports are reachable.
Routing is correct.
Services are listening on 0.0.0.0.
TcpTestSucceeded: True.
The transport layer is healthy.
Technically, ZimaOS discovery on Windows relies on mDNS (Avahi) and Windows multicast handling. If Windows Network Location Awareness (NLA) classifies the network as Public, multicast discovery can silently fail even though direct TCP works.
So yes — this points to a discovery-layer dependency (mDNS/NLA), not a connectivity issue.
Now the design question:
You should not be forced to use ZeroTier when:
• Both devices are on 10.0.0.0/24
• Ports are reachable
• Services are listening
ZeroTier is meant for cross-network access, not same-LAN fallback.
If manual IPv4 entry is not allowed when discovery fails, that’s a client UX limitation — not a networking requirement.
Your diagnostics prove the pipe is open.
The client simply isn’t using it.
So what’s the solution?
There are three realistic paths:
1 Fix Windows network profile (most common cause)
Run PowerShell as Admin:
Get-NetConnectionProfile
If it shows Public:
Set-NetConnectionProfile -InterfaceAlias "Ethernet0" -NetworkCategory Private
Restart the client.
2 Test mDNS resolution
ping zimaos.local
If that fails but direct IP works, Windows mDNS resolution is failing.
That confirms discovery-layer issue.
3 Bypass discovery
Open directly in browser:
https://10.0.0.109
or
https://10.0.0.109:9527
If that loads, the device is reachable without ZeroTier.
Bottom line:
You do NOT need ZeroTier on the same subnet.
Your logs prove connectivity works.
Either:
• Correct the Windows network profile
• Or the client needs manual LAN IP fallback
Everything else is discovery logic, not networking.