luci-base: ui.js rollback does not work on a connection loss (LAN IP change)

[feckert]

Is there an existing issue for this?

• I have searched among all existing issues (including closed issues)

screenshots or captures

No response

Actual behaviour

I have changed the IP of the interface via which I am connected. In my case it was the LAN IP.
After I pressed Apply I get the following modal overview.

If I press Apply, reverting in case of connectivity loss the connection does not recover!

Does anyone else have this issue?

Expected behaviour

If I press the button Apply, reverting in case of connectivity loss, the system should roleback to the
configuration that worked.

Steps to reproduce

Network->Interface->lan change the IP
Press Apply
Press Apply, reverting in case of connectivity loss

Additional Information

I am using a custom build and a custom target.
But the LuCI is not patched.

What browsers do you see the problem on?

Firefox

Relevant log output

No response

[systemcrash]

Hmm. A bit of an edge case to be honest. The device likely committed to the new IP, to which you didn't connect. IIUC, I think connection to the (new IP) interface is a prerequisite to commit to the changes for the option you chose. Not certain.

What does @jow- say here?

[hnyman]

It is not an edge case, but the core functionality of that rollback dialog, so that you don't accidentally lock you out when erroneously changing something, or when intentionally change Lan IP which was the largest soft-brick reason in past years. See #1769 from year 2018 with lots of tweaking to get it right.

It has worked earlier well.

But I think that there was a button style revamp or something like that a while ago, and wonder if that may have any role in this , if the behaviour has really changed

[systemcrash]

As far as I know it was just the button text.

[hnyman]

@feckert
I just tested with OpenWrt SNAPSHOT r28443-9ea174c7bf compiled on 29.12.2024 :

1 a ) changing LAN ip subnet and unplugging PC for the timeout and it worked ok,

1 b ) changing LAN ip subnet and just left browser to wait for the old address for the timeout and it worked ok,

2 )
I then tested changing just router IP but not subnet, and just left browser to wait for the old address. It again worked. (and Windows ipconfig in cmd showed that router did change ip to .6 before reverting back to .1)
Still really just rolled back and not rebooted: 10d 0h 14m 15s

3 )
I then compiled up-to-date r28534-f5b1d340be / LuCI Master 25.001.48925~f5c1806 and still works ok.

Does it fail to you again?

Ps.
One thing that pops into mind when looking at the two files where rollback is explicitly mentioned, is that they both were touched by the ES6 changes:
modules/luci-base/htdocs/luci-static/resources/ui.js
modules/luci-base/htdocs/luci-static/resources/uci.js

I wonder if feckert found some corner case...

[systemcrash]

Worked fine for you. So what should work, works.

@feckert is this case reproducible? Can you successfully repeat it?

[systemcrash]

BTW @feckert what is your build date or master commit SHA?

[feckert]

I have done a screencast:
Mostly it does not work. Now I'm a bit confused. When I recorded the screencast, I managed to get it to work the way I thought it should!

This is what I am doing.

Does not work
https://github.com/user-attachments/assets/f6b11282-e408-4c6e-a298-d81d2367203b

Works as expected
https://github.com/user-attachments/assets/309f853f-c22b-4aec-a81e-db749ebda6a7

BTW @feckert what is your build date or master commit SHA?

This is my base commit SHA c9cc773449d71d930ed2fd1e4e8a1dd95d91ae25

[hnyman]

Might you have somehow too complex logic / connection path fron the browser to to the router?

The error mentions "connection 10.2.3.40:4332" which sounds unrelated to the 192.168.0.50 context.
That makes me to think that there is some more routing / tunneling / VPN happening than we see?
Maybe some VPN breaks connection session for security reasons due to changing IP, and that makes browser to lose session?

[feckert]

Good hint. I will follow it up. I'll leave the ticket open. I'll clarify this tomorrow. @hnyman Thanks

[systemcrash]

Might you have somehow too complex logic / connection path fron the browser to to the router?

I was going to propose something similar, that some alternative VPN might have been up and available.