If you change the LAN subnet, and then wait 30 seconds to a minute for the LuCI to complain that it couldn't reconnect and it rolled back, and then you click "apply unchecked" then it should work. If this doesn't work, you should file a bug. Are you saying it doesn't work? Because I believe I've done this and it did work... but I haven't tested it recently.
3 Likes
I agree disable may be a good feature request.
I do advise against a LuCI-visible method of disabling it, though. Perhaps exposing the time length may be good.
I say that because working with another person...I completely realized they expected LuCI to navigate to the new page and/or somehow redirect all the IP connections made on HTTP for the old IP.
- I'm just unsure what people actually believe the rollback is.
- I'm also confused on why some people report not seeing the dialogue where "Apply Unchecked" appears.
- I'm also never clear if these people allow their PC/wireless client, WiFi and/or router's switch to reinitialize and get new IPs...this may take longer than 30 seconds, especially if some people attempt network configs over WiFi
- I advise against exposing the disable because some devices don't have static reset buttons that clear the overlay - and applying a bad or undesired config tended to effectively brick those models
2 Likes
Unfortunately, I cannot verify that now, because I have installed this particular device at friend's several months ago. The only thing I remember was after several attempts I gave up and set up an ssh.
one thing I can imagine is that people try to renew their DHCP, and browse to the new address, but are too slow and then the router reverts at which point the new DHCP address is invalid and they have to renew AGAIN to be able to do the revert thing...
if I know I'm going to lose the connection I just sit there until it asks to apply unchecked
2 Likes
I just:
- manually force the (wired) client to disconnect/reconnect to the Ethernet, hence beginning the process to get a new IP (e.g. pull RJ-45 plug/plug back in) - I do this as habit in case:
- I'm on a downstream switch; or
- The device resets "too fast" for the client interface to perform a down/up, etc.
- Have new LuCI URL ready-typed in a new tab
- Get new IP via DHCP
- Hit Enter to load new URL
That sometimes takes ~24 seconds...so I can only imagine people who try to make such config changes (i.e. ones that could cause a loss of connectivity to LuCI) - via WiFi.
I also observe that some users don't even realize these steps may be necessary to perform on clients after renumbering a LAN...this is common knowledge to most LAN Techs and Network Engineers, though.
1 Like
From my point of view the need to change the LAN IP address is quite rare; most users are content with the default IP and mask. It takes some knowledge of networks to trigger the desire to change the LAN IP.
The few times I did such a change I had to lower the DHCP lease time to the lowest value of 2 minutes and manually edit the network config file to apply with a service network restart. So it never occurred to me to time out during LAN IP change. However it has happened to me that some firewall rule was not correct and a rollback was necessary.
Other than that, there are workarounds to bypass this small miscomfort, like edit the config files directly, use a wired connection if changing wireless settings, setup a temporary secondary interface and use that one to apply changes to the main one.
Generally speaking the commit/rollback is a very good feature that is used in enterprise solutions, so it should be kept in the OpenWrt as well.
To sum it all, I see no sense to disable the safety net, even optionally, for a handful of operations that can be accomplished otherwise.
3 Likes
on top of all problems, one time after auto-revert something else broke, maybe procd or netifd, device returned to old config and was unreachable, no ssh web or ping replies, only dhcp worked which isprobably why this badly desgined feature settled down at the reverted settings. had to unplug and replug power on that end to access device again.
@psyborg ...that's what confuses me...can you explain how reverting to the old config gave you problems like described?
Also, I only understand this occurs when LuCI is unreachable after a settings change in the same.
I guess I'm missing that...or perhaps you're saying you didn't know exactly what happened either?
FYI, I'm willing to play with a test router over the weekend, in attempt to reproduce these described issues - for the benefit of the community. Perhaps we can actually pinpoint something for a bug report.
1 Like
I had some time today so I quickly tested it.
TL;DR it works as expected.
Device is Carambola 2 running 18.06.2
Connected with cable on LAN, changed only the IP of the LAN interface. DHCP lease was for 2 hours and recently acquired, so no chance of requesting one during the procedure. After pressing save and apply the roll-back counter started and timed out. I didn't do anything like "dhcp renew" or "exercising the jack". After looking at the screen for 30 seconds the router rolled back and asked me what to do now. I selected the "apply unchecked" so it started again applying the changes. I again didn't do anything and I noticed that Network Manager was renewing the IP address. Indeed my PC had acquired the new IP address. I presume the router did a "shut/no shut" on the LAN interface. I entered the new IP in my browser and I was back in Luci.
3 Likes
Is this still not possible to do? I always have tHis thing doing this where I get to wait 30 seconds then 30 seconds and possibly even more 30 seconds... I tBought ddwrt was the only thing with 30 30 30
This auto-rollback is a joke.
Practically not possible to change the LAN IP with a USB to ethernet converter, as it takes way more than 30 seconds for the adapter to set up the link before the rollback happens.
+1 to disable this completely, or at least have the option to disable it, or make the default timeout to 120 seconds at least...
just wait until rollback and click apply unchecked... does this not work for you? it takes less than 120 seconds so I don't see why you'd want to extend the timeout
Auto rollback is a feature no person who is interest in OpenWRT looks upon. I'll tell my story as an example:
Due to a faulty cable, ap1 (1043nd/192.168.23.1/static ip/DHCP server/4+1 nat router) was taken off suspect of being fried and ap2 (1043nd/192.168.23.2/macaddr-bound DHCP client/5 port L2 access-point) became ap1.
Problem persisted, upon further investigation we found a faulty cable, hence ap1 got back onto his 192.168.23.1 role (we had openvpn/ddns/dhcp reservations/forwardings not copied over to ap2), so we only needed to switch ap2 from 192.168.23.1/dhcpserver to back to 192.168.23.2 via dhcp.
Might seem easy, but we couldn't place ap2 and ap1 at the same lan segment or we would end up in an IP conflict + two distinct authoritative DHCP servers answering for the same 192.168.23.0/24 network.
30 seconds is not enough time to be able to submit the change operation, reconnect the cables as intended (respecting VLAN arrangement for upstream port and so) and in the end we had (time & again) a roll back window, tried "apply unchecked", resulted in nothing apparently.
In the end the solution had to be ssh into 192.168.23.1 with a direct cable and editing /etc/config/network, but then we had to erase ap1's legit pubkey out of cache, update it to accept ap2's, edit the file/reboot, and then erase ap1's fake/ap2 pubkey out of cache again, so no future key errors would be raised.
If the purpose was to make life simpler, it really worked otherwise.
1 Like
I will add my use case here:
I am producing and selling a IOT device that the user can configure. It starts as a wifi access point, the user connects to that, and then can change the AP name. If he doesn't immediately connect to the new AP (takes some time, rewriting the password etc.), he loses the changes. This is a use case that will NEVER result in a brick. I now patched this by increasing the timeout, but that feature should be optional and we should be able to disable it if needed (just add a simple "option rollback_enabled false").
Thanks!
1 Like
@jow and/or whoever added the nice toggle next to apply > apply unchecked...
nice job! although i didn't mind waiting 30 secs before and it was rare that i ever changed lanip... ( having said that one in every ~5~ uses i'd forget to wait )...
was just messing around testing some auto-majic IB(snapshot) images and have needed the toggle more than 6 times in an hour.... so it's working good!
( for anyone else who does not use luci...or needs a remote failsafe... here is an !unfinished!NOTFORREALUSE cmdline "remote rollback" script that might be of note to someone )
1 Like
Auto-Rollback is an absolute burden to deal with. Please rethink the logic in this. If someone is willing to flash custom firmware, they don't need you holding their hand while changing their LAN.
I was not on-site and had to try to talk someone through dealing with it, only to find out that they were so confused that they had both ethernet, and wireless connected to new AP, and the old AP, accordingly.
Of course, that wasn't straightforward, but having them complain that the router 'wasn't taking new settings', without any real usable information meant I got to take a nice drive and get this 5 minute task done.. in 2.5 hours.
Use the new Apply unchecked function. It is in master.
At least the timeout should be adjustable!
All my devices are remotely managed using OpenVPN tunnels. Whenever the WAN connection is involved, the given timeout is not enough, to cope with the re-connection time needed by OpenVPN. As a result (being forced to use 'apply unchecked' all the times) we have three service interruptions, one for the first change, one for the rollback-change and one for the final change. This is ugly and mind wrecking.
I need rather 60 seconds for a successful change and OpenVPN recovery to achieve a proper browser feedback avoiding the rollback.
Imagine to 'play' with MWAN3 configurations under these circumstances...
Well, another nice option would be to have the 'Apply unchecked' available in front of the whole process, not only after the rollback!
Manuel
uci set luci.apply=internal
uci set luci.apply.rollback=60
uci commit luci
3 Likes
I feel kinda stupid now. I've searched for the term 'fallback', not 'rollback', when I tried to figure that out myself using 'uci'. 
And that little drop-down is not available in 18, so I still miss that one until upgrading to 19. Actually my fault, sorry about that!
I tried to upgrade several 18-boxes to 19, but WLAN-configurations get partly destroyed on dual band devices, when keeping the configuration (three radio devices in the web ui, when there are only two physical and second radio config applies to the phantom radio device). So it's not doable remotely in cases, where boxes are using STA-mode as WAN link. 
Thanks for the time reading and for the screenshots!
Manuel