40 replies

AI LLM Not connecting, ports getting blocked

✅Solved

Read, inspect, understand this doc for context: https://hasteb.in/w7YqOvkx44GBjNL
1) System architecture (3 ways)
A) “Boxes + arrows” view
Windows host runs Ollama on port 11434.
WSL2 (Ubuntu-24.04) runs OpenClaw Gateway (systemd user service).
OpenClaw primary model is Ollama; fallback is NVIDIA NIM.
B) Network-path view (the actual bug)
In default WSL NAT mode, Linux must reach Windows services via the host gateway IP (yours: 172.29.64.1).
Your failure is: WSL → 172.29.64.1:11434 = TCP connect timeout (packets don’t get through).
We’re now switching to WSL mirrored networking mode, where (per Microsoft) host + WSL can connect via localhost, avoiding the 172.29.* path.
C) Model/timeout view
NVIDIA NIM fallback works but can take ~91s to respond.
You set:
agents.defaults.timeoutSeconds = 600
Discord eventQueue.listenerTimeout = 240000

so slow fallback replies don’t get dropped. ---

Solution

Original blocker (root cause), stated precisely

OpenClaw in WSL could not reach the Windows-hosted Ollama service over the default WSL2 NAT “host gateway IP” path:

- In WSL2 NAT mode, the Windows host is typically reachable from Linux via the vEthernet (WSL) gateway IP (yours: 172.29.64.1
172.29.64.1
).
- Your repeated symptom was: WSL →
172.29.64.1:11434
172.29.64.1:11434
timed out, even though Windows itself could
curl 127.0.0.1:11434
curl 127.0.0.1:11434
and
curl 172.29.64.1:11434
curl 172.29.64.1:11434
successfully.
- Windows Firewall / Hyper‑V firewall rule experiments did not change the WSL→host timeout on that NAT path.
- The fix was to avoid the broken NAT/gateway path and use a path that WSL can reliably reach: WSL mirrored networking →
127.0.0.1:11434
127.0.0.1:11434
(proven by your WSL