I have a MikroTik LHG XL HP5 that I flashed some while ago and set up in NAT mode. A change in LAN routers required changing the IP addresses for the device and the gateway. There was no problem in doing that. The firmware version originally used to flash the device was aredn-3.20.3.0-ar71xx-mikrotik-rb-nor-flash-16M-sysupgrade. Checking the list of available upgrades in the Admin tab, I selected the 3.22.8.0 version and clicked the [Download] button expecting that the file would be downloaded to my computer, but was surprised that it immediately started to download to the MikroTik device. I don't know if the Save Settings box was checked by default but, in any case, none of the settings were saved and I was back to "just flashed" condition. So I started over with the setup, but ran into problems with some of the controls when trying to set up NAT mode, specifically the LAN Mode and (WAN) Protocol dropdown lists as well as the (LAN) DHCP Server checkbox would immediately evoke a browser (Safari) message that the "server unexpectedly dropped the connection". This occurred as soon as the control setting was changed. The page would reload ok, albeit with all unsaved changes back to defaults. Usually a second attempt would work OK. Soldiering on, I finally got all those changes entered, but clicking on the [Save Changes] button evoked an AREDN message "Bad Gateway, changes not saved". Many tries, always the same result. None of those problems occurred with the old firmware version.
Another issue is that, while the time and year are displayed correctly, the month and day are incorrect--that issue will be apparent in the time stamps in the attached support info. Perhaps that is the result of the initial setup with internet connectivity, but that was partially changed by the upgrade. By the way, the supportdata file saved to my Mac computer with the extension .gz which isn't accepted for upload here--I changed it to .tgz.
Finally, my expertise level with AREDN issues is essentially that of a beginner.
Bernie B. NJ6W
This setup works 3.20.3.0, but evokes a "Bad Gateway" message in 3.22.8.0 when Save Changes is attempted.
Thanks for the Support Data file. We are taking a look at the issue and will let you know what we find.
In the interim, would it be possible for you to use Direct mode? Unless there is a specific reason why you must use NAT mode, it would be easy to switch to Direct mode so everything will continue working.
You give your LHG Internet access through a VLAN-capable switch. The AREDN online documentation describes them here:
https://arednmesh.readthedocs.io/en/latest/arednGettingStarted/advanced_config.html#node-vlans
There are links in the documentation to other videos and articles about configuring inexpensive "smart" switches. Hope that helps.
Ok, I've been able to upgrade to yesterdays build, aredn-1700-6ba17b8, but not without some difficulty. Since my node was in NAT mode when I started the upload, I was hoping that the settings for that would be saved, but they weren't and I had to switch to a direct connection to continue. My computer received an IP address and I was able to access the status page, but it was mostly blank and none of the navigation buttons would respond. I found that I could navigate directly to the admin page from my browser, but not to any other pages except status. I did download support data somewhere in my thrashing around (not very methodically). Nothing seemed to work, either not responsive or Bad Gateway messages. I reset the node to just flashed mode, and that didn't seem to help but I could still navigate directly to the admin page address and was able to uploaded the sysupgrade again. This time, all behaved normally. I suspect that it was a mistake to attempt the upgrade while in NAT mode and with Save settings checked--probably just the former.
The bottom line is that the changes made in pull/500 did resolve the issue of not being able to save changes to NAT mode. For some reason trying to install the upgrade while in NAT mode results in an unstable condition that was resolved by performing the upgrade a second time.
(Oh yeah, since the "t" was dropped from the supportdata extension maybe someone should change the allowed file type for upload.)