I recently updated the ip address of the hardware controller and it seems that the local ddns address is still pointing to the old ip so I can’t seem to access the control interface via the web browser or the app. Is there anyway to force the ddns address to update? Thanks in advance for any help!
It should automatically update after a few minutes. If it doesn’t, you can restart the controller as root with “service access restart”, which should force the DDNS registration to rerun.
@Alta-Jeff It’s been a while and i have tried to reboot all my network hardware including the route 10, hardware controller, and isp modem. I did not setup ssh access on the route 10 or hardware controller so I’m not really sure how I can proceed.
If I do a dns lookup on my dns ip it still returns the old local ip. If i drop the local prefix I can get through but I only see the “Welcome! Thank you for using our WiFi network!” page.
Older versions of the controller did not update automatically. Do you know what version you are currently running, and can you update if you are not on the latest?
I think it was on the latest version when I checked a few days ago. I have the automatic updates available so I think it has updated automatically in the past. Is there anyway I can check the version of the controller software without access to the web interface or ssh? Also i can ping the new ip of the controller but nothing comes up when i try to hit that ip in a browser. Is there a way to setup the web interface so I don’t have to use the ddns url and can just specify the local ip myself?
For security reasons, use of the DDNS hostname is required. However, you can manually override the IP address that it resolves to in your hosts file (C:\windows\system32\drivers\etc\hosts or /etc/hosts). If you can ssh to the controller, you can “cat /usr/share/access/version.txt” to get the version/
I added the new ip to my hosts file under the ddns hostname used in the app and web interface. I can ping that host name and it resolves correctly to the new ip. I don’t think chrome is using the hosts file though because the web interface still fails to resolve for me.
Is there a default account I can use for ssh to the controller? I did not setup ssh access to any of my devices yet and I don’t know if I can do it now that I can’t access the web interface or app.
Yes, just add an ssh key in System Settings, and make sure it’s an admin key, and you can ssh as the root user.
How can I access system settings without access to the web interface or app?
Are you currently using Alta’s Control for local management?
@Beaker Hey, I believe so? I have the Alta labs hardware controller device wired into my alta labs route 10 router and I specified the ddns address I got when setting up the hardware controller as the controller for the route 10. This all worked fairly well (I could access the Alta control web interface by hitting that local.xxxxx.ddns hostname and the iPhone app worked as well) up until a few days ago when I assigned a new static ip to the controller through the control web interface.
When I ping that local.xxxxx.ddns hostname I would see the old ip assigned to the hardware controller even after rebooting everything multiple times and giving it plenty of time so I figured the ddns address is not updating. After adding an entry for that host name in my hosts file when I ping it the new correct ip is used but my browser (chrome) doesn’t seem to use my hosts file and just resolves the ddns hostname to the wrong ip anyway.
Unfortunately I neglected to set up ssh access to either device before I broke things so I can’t just ssh in unless there’s some default account I can use.
I’m not really sure why using the ddns hostname is a requirement for the on premises installs with the hardware controller but if I can get around that to use a manually specified ip that would probably let me fix things? What security feature does requiring the ddns hostname provide and can it be done with manually specified ips instead of resolving that hostname? Also what are the steps to access the control web interface if the internet went down and we could not resolve that hostname? Thank you everyone for your help!
I went through this yesterday during my initial setup. I lost access to the controller after adjusting the default block, which was expected, but my ddns changed entirely. If I’m reading this right, it looks like you were able to hit the AP IP.
This might be a shot in the dark, but I’d try the following:
- Open a browser other than chrome, attempt to connect to the IP where you successfully accessed the splash page for the “Welcome! Thank you for using our WiFi network!”. The browser should resolve you the device IP along with your hostname ddns as such below.
This is just an example of what the URL/hostname for the device could look like after attempting to access that IP.
https://xxx-xxx-xx-xx.abcde123456.fghij78910.ddns.manage.alta.inc/hotspot.html
"fghij78910.ddns.manage.alta.inc" section would be your controller ddns. Copy and paste that into your browser. Don’t forget to add the local and see if you can access your route10.
example: local.fghij78910.ddns.manage.alta.inc
I apologize in advance if this gets you no where.
Best,
Your device has a Let’s Encrypt-certified SSL certificate installed with that Alta DDNS hostname, which gives you the secure lock status in your browser, ensuring that you are communicating with the Alta controller, and not via something else. SSL certificates are generally not allowed for IP addresses, and obviously they would need to change any time the device changes IP addresses. As long as you can get local…ddns.manage.alta.inc to resolve to your controller’s IP address, you should be able to log in with a web browser.
@Beaker I actually dont have any alta labs ap on the network. I get that wifi page when I try to hit the xxxxxx.ddns.manage.alta.inc address. I actually get a certificate warning but I don’t remember if I had the same error before I changed the hardware controller ip. When I add the local prefix to that hostname, I get nothing. I tried Safari with the same results.
Since the /etc/hosts entry did not seem to work, I added a dns rewrite in my adguard configuration for the local.xxxxxx.ddns.manage.alta.inc hostname. Once again, pinging that hostname from terminal resolves to the correct ip but trying to access the web interface from either chrome or safari still fails.
@Alta-Jeff I thought with the on premises hardware controller we would be able to access the web interface without internet access and therefore without the ability to resolve that hostname. I think the on premises hardware controller should allow web interface access via ip. The route 10 is still running a webserver because i get a webpage saying “This device has already been configured on an Alta Labs controller.” At this point I have managed to get the local.xxxxxx.ddns.manage.alta.inc hostname to resolve in my terminal using two different approaches but the web interface still fails to come up when using either chrome or safari.
At this point i think it might be easiest to just reset both the router and the hardware controller and start from scratch (I will set ssh access up immediately this time 
) Is there a recommended order/process for this since I no longer have another router besides the route 10? If I reset the hardware controller first, I suspect I will get a different ddns address assigned that I will need to provide to the router during its initial setup, but will everything break again if i reset the router and the ip of the hardware controller changes again?
After resetting the hardware controller it now boots up to a state where it is blinking red in sets of three. Doesn’t matter if i have it connected to the route 10 or not. Is this thing totally dead at this point?
It’s most likely fine, but the three red LED blinks indicates that it was unable to download recovery firmware from the Internet. If you hold down the reset while powering it on, it will need to be on a network that has internet access in order to recover itself.
As far as the hostname not resolving, on a Mac, it should be as simple as editing the /etc/hosts file as root:
sudo nano /etc/hosts
If you still cannot ping your hostname using the updated hostname, you can “cat /etc/hosts” to make sure that you saved the file properly. Make sure that the IP address is first, and the hostname is second.
There are couple more steps you need to follow in order to access the controller with Internet disconnected for long periods of time, including a local NTP server with a real-time clock (most any desktop or laptop will do), and making sure that your router resolves 0.openwrt.pool.ntp.org to that NTP server, and local…ddns.manage.alta.inc to your controller even when the Internet is disconnected (this can be done with Route10 via static IP assignments and setting the name of the wired connected clients). Also you’ll need to make sure that the controller has Internet access once every 90 days so that it can refresh its Let’s Encrypt certificate. By not using SSL protection, you put yourself at risk from man-in-the-middle attacks, which is why we enforce SSL certificates for local and cloud controllers.
Ok so I ended up resetting the router as well, then the controller was able to connect to the internet (to download a new firmware?) and boot up (I’m guess the router was still assigning the controller the bad ip I had set). After resetting I did have to update both the controller and router firmwares but I am almost certain that I had the latest version of the firmware running on each before this whole debacle. After resetting and updating everything, I was able to set up the controller and router again, then performed the static ip assignment with a different ip to the controller via the web interface and everything worked. I’m not really sure what caused the error the first time around but I’ll be sure to setup ssh access right away this time. Thank you everyone for your help!
@Alta-Jeff Thank you for the extra info regarding running completely offline. I am hoping to eventually setup my own gps time based ntp server so I will definitely try out what you described when I get to it. Thank you again for your help!
1 Like