From 517764a7ac0cc7d3f576a662fd65aa2b6d1a8018 Mon Sep 17 00:00:00 2001 From: YueGuobin Date: Sat, 25 Apr 2026 01:48:45 +0800 Subject: [PATCH 1/5] fix: include error details in LLM model config failure response Co-Authored-By: Claude Opus 4.6 --- gns3server/api/routes/controller/llm_model_configs.py | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/gns3server/api/routes/controller/llm_model_configs.py b/gns3server/api/routes/controller/llm_model_configs.py index 75a5472da..a567bd1ef 100644 --- a/gns3server/api/routes/controller/llm_model_configs.py +++ b/gns3server/api/routes/controller/llm_model_configs.py @@ -242,7 +242,7 @@ async def create_user_llm_model_config( log.error(f"Failed to create LLM model config: {e}") raise HTTPException( status_code=status.HTTP_500_INTERNAL_SERVER_ERROR, - detail="Failed to create LLM model configuration" + detail=f"Failed to create LLM model configuration: {e}" ) @@ -564,7 +564,7 @@ async def create_group_llm_model_config( log.error(f"Failed to create LLM model config: {e}") raise HTTPException( status_code=status.HTTP_500_INTERNAL_SERVER_ERROR, - detail="Failed to create LLM model configuration" + detail=f"Failed to create LLM model configuration: {e}" ) From f9d1ccc7019f26e0b4849bc8f6aea799847d62ac Mon Sep 17 00:00:00 2001 From: YueGuobin Date: Sat, 25 Apr 2026 15:44:20 +0800 Subject: [PATCH 2/5] docs: add troubleshooting for controller hostname unreachable Add documentation for the "No common subnet" error when the controller's hostname in /etc/hosts resolves to an unreachable or stale IP address. Co-Authored-By: Claude Opus 4.6 --- docs/features/compute-controller-setup.md | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) diff --git a/docs/features/compute-controller-setup.md b/docs/features/compute-controller-setup.md index 6c4215f44..8b70eb0fd 100644 --- a/docs/features/compute-controller-setup.md +++ b/docs/features/compute-controller-setup.md @@ -102,3 +102,23 @@ POST /v3/computes 1. Verify Controller's `host` is set to its actual IP, not `0.0.0.0` 2. Ensure both machines are on the same network 3. Check firewall rules allow UDP communication + +### Controller Hostname Unreachable + +If the controller machine uses a hostname defined in `/etc/hosts` (e.g., `guobin.localhost`), and the compute node reports: + +``` +Cannot get an IP address on same subnet: No common subnet for compute X (controller) and Y +``` + +1. **Symptom**: The controller's hostname resolves to an IP that is unreachable from the compute node +2. **Root Cause**: The `/etc/hosts` entry for the controller's hostname points to a stale or unreachable IP address +3. **Solution**: + - Ensure the controller's hostname in `/etc/hosts` resolves to the correct, reachable IP address + - Example (correct): + ``` + 192.168.1.104 guobin.localhost + ``` + - If the machine's IP is dynamic (DHCP), consider: + - Setting a DHCP static lease on the router for a fixed IP + - Using mDNS (`.local` domain) if supported by the compute node From e88b12086a1c2082585df14d204e8b25fd9a7628 Mon Sep 17 00:00:00 2001 From: YueGuobin Date: Sat, 25 Apr 2026 15:54:12 +0800 Subject: [PATCH 3/5] docs: clarify host=0.0.0.0 causes controller to register as 127.0.0.1 Add details about the "No common subnet" error when Controller's host is set to 0.0.0.0, and how to verify via /v3/version endpoint. Co-Authored-By: Claude Opus 4.6 --- docs/features/compute-controller-setup.md | 19 ++++++++++++++----- 1 file changed, 14 insertions(+), 5 deletions(-) diff --git a/docs/features/compute-controller-setup.md b/docs/features/compute-controller-setup.md index 8b70eb0fd..d5049fb00 100644 --- a/docs/features/compute-controller-setup.md +++ b/docs/features/compute-controller-setup.md @@ -71,8 +71,10 @@ POST /v3/computes ### Host Configuration -- **Controller `host`**: If set to `0.0.0.0`, it will be changed to `127.0.0.1`, which breaks cross-subnet link creation -- **Solution**: Always use the actual IP address for Controller's `host` field +- **Controller `host`**: If set to `0.0.0.0`, the controller will register itself as `127.0.0.1`, which breaks remote compute connections +- **Symptom**: Compute nodes report "No common subnet for compute X (controller) and Y" even when on the same network +- **Solution**: Always use the actual LAN IP address for the Controller's `host` field (e.g., `host = 192.168.1.104`) +- **Dynamic IP**: If the controller machine uses DHCP, set a static lease on the router or use mDNS (`.local` domain) ### Password Configuration @@ -99,9 +101,16 @@ POST /v3/computes ### No Common Subnet Error -1. Verify Controller's `host` is set to its actual IP, not `0.0.0.0` -2. Ensure both machines are on the same network -3. Check firewall rules allow UDP communication +If compute nodes report: +``` +Cannot get an IP address on same subnet: No common subnet for compute X (controller) and Y +``` + +1. **Primary cause**: Controller's `host` is set to `0.0.0.0` - it registers as `127.0.0.1` which is unreachable from compute nodes +2. Check the controller's `/v3/version` endpoint - if `controller_host` shows `127.0.0.1`, this is the issue +3. Set the Controller's `host` to its actual LAN IP address (e.g., `192.168.1.104`) +4. Verify both machines are on the same network and can ping each other +5. Check firewall rules allow TCP/UDP communication on required ports ### Controller Hostname Unreachable From d81a7410e21a5b540aceb41e34554ee3bc14312d Mon Sep 17 00:00:00 2001 From: YueGuobin Date: Sat, 25 Apr 2026 15:55:37 +0800 Subject: [PATCH 4/5] docs: remove misleading Controller Hostname Unreachable section This section was misleading - the actual root cause is host=0.0.0.0 causing controller to register as 127.0.0.1, not hostname resolution. Co-Authored-By: Claude Opus 4.6 --- docs/features/compute-controller-setup.md | 19 ------------------- 1 file changed, 19 deletions(-) diff --git a/docs/features/compute-controller-setup.md b/docs/features/compute-controller-setup.md index d5049fb00..75f4a66c8 100644 --- a/docs/features/compute-controller-setup.md +++ b/docs/features/compute-controller-setup.md @@ -112,22 +112,3 @@ Cannot get an IP address on same subnet: No common subnet for compute X (control 4. Verify both machines are on the same network and can ping each other 5. Check firewall rules allow TCP/UDP communication on required ports -### Controller Hostname Unreachable - -If the controller machine uses a hostname defined in `/etc/hosts` (e.g., `guobin.localhost`), and the compute node reports: - -``` -Cannot get an IP address on same subnet: No common subnet for compute X (controller) and Y -``` - -1. **Symptom**: The controller's hostname resolves to an IP that is unreachable from the compute node -2. **Root Cause**: The `/etc/hosts` entry for the controller's hostname points to a stale or unreachable IP address -3. **Solution**: - - Ensure the controller's hostname in `/etc/hosts` resolves to the correct, reachable IP address - - Example (correct): - ``` - 192.168.1.104 guobin.localhost - ``` - - If the machine's IP is dynamic (DHCP), consider: - - Setting a DHCP static lease on the router for a fixed IP - - Using mDNS (`.local` domain) if supported by the compute node From c688223e1b2ba66f185f600a87bd79e1d3408069 Mon Sep 17 00:00:00 2001 From: YueGuobin Date: Sat, 25 Apr 2026 16:08:53 +0800 Subject: [PATCH 5/5] docs: add troubleshooting guide for WebSocket console authentication failure Add documentation explaining the common issue where WebSocket console connections to remote compute nodes fail due to credential mismatch. The guide describes the error symptoms, root cause (Controller forwarding its own credentials to Compute), and solution (ensuring matching compute_username and compute_password in Compute's configuration). --- docs/features/compute-controller-setup.md | 32 +++++++++++++++++++++++ 1 file changed, 32 insertions(+) diff --git a/docs/features/compute-controller-setup.md b/docs/features/compute-controller-setup.md index 75f4a66c8..fdcd14286 100644 --- a/docs/features/compute-controller-setup.md +++ b/docs/features/compute-controller-setup.md @@ -112,3 +112,35 @@ Cannot get an IP address on same subnet: No common subnet for compute X (control 4. Verify both machines are on the same network and can ping each other 5. Check firewall rules allow TCP/UDP communication on required ports +### WebSocket Console Authentication Failed + +When connecting to a remote compute node's console via WebSocket, the connection may fail with errors in the logs: + +**Controller log:** +``` +New client 192.168.1.104:33268 has connected to controller console WebSocket +Forwarding console WebSocket to 'ws://192.168.1.3:3080/v3/compute/projects/.../console/ws' +Client 192.168.1.104:33268 has disconnected from controller console WebSocket +``` + +**Compute log:** +``` +WebSocket /v3/compute/projects/.../console/ws" [accepted] +ERROR gns3server.api.routes.compute.dependencies.authentication:103 Could not authenticate while connecting to compute WebSocket: Could not validate credentials +``` + +**Cause**: The Controller forwards its own `compute_username` and `compute_password` credentials when connecting to the Compute's WebSocket endpoint. If the Compute node does not have matching credentials configured, authentication fails. + +**Solution**: Ensure the Compute node's configuration file has matching credentials: + +```ini +[Server] +enable_http_auth = True +compute_username = gns3 +compute_password = your_password +``` + +The Controller automatically uses its configured `compute_username` and `compute_password` when establishing WebSocket connections to remote computes (see `gns3server/api/routes/controller/nodes.py` lines 627-628). + +**Note**: If `compute_password` is not explicitly set in the Compute's config, a random 16-character password is auto-generated at startup, making authentication impossible for any external Controller. +