Hi everyone,
I’ve been trying to set up my AltaRoute10 with a Docker-based controller on my Mac, and I’ve hit a roadblock. I’ve tried everything I can think of, and this forum is my last resort. Here’s the situation:
Docker Command
Here’s the exact command I’m using to run the Docker container:
The AltaRoute10 device doesn’t appear in the controller interface.
When I access 192.168.1.1 (AltaRoute10’s management page), it asks for the controller URL. After entering the URL, nothing happens.
What I’ve Tried
Verified the container’s IP (192.168.1.11) and ensured the ports (80 and 443) are open and accessible.
Configured the controller to listen on all network interfaces (0.0.0.0).
Tested connectivity between the container, the host, and the AltaRoute10.
The container can ping the router (192.168.1.1) and vice versa.
Verified that the DDNS and controller pages load without errors.
Checked the logs from both the controller and the AltaRoute10 for hints, but nothing conclusive.
Problem
Despite the setup:
The AltaRoute10 does not register with the controller.
Entering the controller URL on 192.168.1.1 does not take effect or show any errors. But after some time the Route10 starts blinking red.
At this point, I feel I’ve done everything I could, but I must be missing something. If anyone has experience with AltaRoute10 and Docker-based setups, your advice would be greatly appreciated.
Do you use any kind of dns filters like adguard/pihole in your network or using something like nextdns? They usually offer some option called rebinding protection, that needs to be turned off. Every dns request that resolves to some private address will be blocked if it’s on.
dig A local.xxxxxxx.ddns.manage.alta.inc@1.1.1.1 should resolve to 192.168.1.11.
You can also create a macvlan network, and attach the alta controller to it, so the controller is able to discover the R10, since they are in the same broadcast domain.
I turned off Adguard and do not have any other services/tools to keep it simple. also yes the local…ddns resolves to 192.168.1.11.
but if I dont use local. and directly go to xxx.ddns.manage.alta.inc it directs to my Public IP and then to 192.168.1.1 where router page is hosted … I assume that is expected
you have created a new docker network of type bridge. Did you add the physical nic of your docker host to that bridge?
creating a new bridge with the same subnet as your physical nic doesn’t automatically add the nic as a bridge port.
Please share the output of brctl show and ip a.
The bridge driver, which is the default Docker network type, allows multiple containers to be added to the same broadcast domain. However, communication between this network and the Docker host is still handled through NAT. This is why you need to use ‘publish’ (-p) which simply adds a destination NAT to the container’s internal IP address.
Multiple 400 Bad Request responses are observed for POST /api/device/boot. This indicates an issue with the request payload or the endpoint not handling the request properly.
HTTP 200 Responses:
Successful requests to POST /api/sites/stats with 200 OK indicate that some endpoints are working as expected.
MQTT Handshake:
The GET /mqtt requests return 101 Switching Protocols, indicating successful WebSocket upgrades.
High Network Activity:
Continuous traffic on port 443 suggests secure communication between server and multiple clients or upstream services like CloudFront.
Dynamic DNS:
Requests to local.kmc04sprrnv.ddns.manage.alta.inc imply dynamic DNS configuration is actively resolving, but the payloads seem inconsistent.
The traffic between 192.168.1.1' and the container (192.168.1.11`) is clearly visible.
Requests and responses are being exchanged over HTTPS (https port).
HTTP 400 (Bad Request):
There are no visible signs of dropped packets or missing responses in the TCP stream. This indicates that the 400 errors are application-layer (server-side), not network-layer issues.
A 400 Bad Request typically means the server received the request but found something invalid in its headers, body, or structure.
Bridge and Interface:
container (eth0) is functioning properly, and packets are flowing through without issues.
Router Role:
The router (192.168.1.1) is initiating connections properly, which rules out issues with routing or NAT.
lastly I got this email notification with error, not sure if it is related to this situation:
POST /fe/oops
SyntaxError: Unexpected token u in JSON at position 0
at JSON.parse ()
at /usr/share/access/be/access.js:2:1959910
at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
at async /usr/share/access/be/access.js:2:1947417
at async y.pgPool (/usr/share/access/be/access.js:2:2017501)
at async t.handler (/usr/share/access/be/access.js:2:1947399
What version of Control are you running? If you access the container via shell you can sudo apt update && sudo apt upgrade -y to upgrade Control. The default version at time of creating the container is 1.0d, so if you haven’t upgraded via apt, then it’s likely running a version that doesn’t yet support Route10.
The issue is resolved—I updated the Docker image from inside the container, and it worked. However, I wasn’t aware that updates were needed even after pulling the latest image. It might be helpful to host the fully updated image or provide documentation clarifying this process. I didn’t see this information anywhere, so I wanted to bring it to your attention.
As far as I know, the plan is to update or replace the image down the road, but in the interim, we absolutely should have that in the documentation—thank you for bringing it to our attention. It should be updated by tomorrow.
