When setting up Rockstor a couple of days ago the system got the IP-address 192.168.0.163 through DHCP. After installation I changed the IP-address through the web GUI to 192.168.0.80.
I could then access the system through this IP-address but started using the hostname (Rockstor) instead as that was easier, both for web access and for SMB access.
Today I decided to troubleshoot the issues with my Rock-Ons not using the correct config shares and realized that I no longer could access the system through the 192.168.0.80 IP-address. When checking the network configuration it had reverted to 192.168.0.163, despite still being set to Manual config method.
I changed the IP-address to 192.168.0.80 and saved but to no use, it’s still using the .163 address.
Changing back to Auto (DHCP) it kept the .163 address as expected. I changed back to Manual and set the .80 address but still to no use. The config still shows .163 and I can’t access the system on .80.
Only after rebooting did the IP-address change.
Perhaps this is by design but there’s nothing to indicate this when updating the network config.
@MainrtNr5 Hello again and thanks for the report. Much appreciated.
Of note here is that we don’t present any Web-UI on port 80 (http) only 443 (https). So it may be there was some superstitious learning going on here :). If you could double check your findings while taking care to use only https and come-up with a repeatable easy reproducer then this could form the basis for a bug report issue on GitHub as this should all work as intended. And no a reboot shouldn’t be required.
Hope that helps, and thanks again for testing and reporting all this.
Thanks for the video… that is definitely a clear way to describe the issue!
I quickly tried to reproduce the first problem your video shows and unfortunately couldn’t reproduce it… On a fresh VM (running Rockstor-4.0.6), here’s what I did:
Edit Wired connection 1, the only one in this VM, and thus the currently active connection.
Change DHCP to manual
Edit IP address from 192.168.1.35 to 192.168.1.135
Clicking the “Submit” button works and gets me back to the Network page. On your video, this hangs with the blue loading arrows.
I could thus confirm that the changes were taken into account on the command line. This is where my lack of knowledge in NetworkManager shows, unfortunately, so excuse any inaccuracy. As this is the currently active connection, even though Rockstor does puts the connection down then up after this change, it is not actually in use as there’s a device with the old settings still at play. I could see this when looking into the settings themselves:
First, to identify the connection:
rockdev:~ # nmcli con show
NAME UUID TYPE DEVICE
Wired connection 1 7590d252-8a23-40a1-ab87-442a48ca00f3 ethernet eth0
Then, let’s look at the settings for this connection (I simplified the output for clarity):
Not that I really know whether I am looking at the right piece of code, but for the nmcli, shouldn’t the option reapply be used to make use of a changed interface (e.g. changed IP address) so the old interface config is discarded and the changed one applied? When looking here, I only see the reloading of connections (e.g. for newly defined interfaces):
and I couldn’t see any mention of the device reapply switch after a connection change within the network.py area that would represent a call like ncmli device reapply <ifname>
which would remove the need to reboot, and also avoid a “sticky” interface, if I am not mistaken.
Maybe it matters that I had already changed to manual and rebooted the server before performing the test, where you changed from DHCP to manual and then performed the test directly afterwards?
Also, it might be because you’re not running any Rock-Ons.
The reason for me suspecting this is that I’ve had a somewhat rare bug where I click on “Edit” for the wired connection and get the form for editing the Docker connection. I can’t reliably reproduce that bug though so I haven’t reported it yet.
Yes, I’m wondering that too after looking at what is happening under the hood exactly. Briefly, when editing a connection, we delete the previous one, and create a new one with the new settings, and then reload it. For reference:
When editing an existing connection, we trigger the following:
As we can see above, we:
step 1: get the device name of the current connection, to be used in step 3 below
step 2: delete the current connection
step 3: we create a new connection with the newly-updated settings:
It’s in the new_connection_helper() function that we modify the different settings (IP address, DHPC, etc…) using nmcli con mod ...:
@Hooverdan, it does seem like we could finalize the procedure with a nmcli d reapply <ifname> indeed, but it would need to be tested and verify it actually fix that need for a reboot.
Nevertheless, I don’t think this is the root cause of @MainrtNr5’s issue here so I’ll try to see what I can find about that.
That’s what I was thinking as well. I will need to set up a proper testing and debugging of that part of the code to see what is happening here.
As usual, I might have spoken too soon… I still need to inspect what is really happening here in the background, but I could indeed reproduce @MainrtNr5’s issue (@MainrtNr5: you were right: with the connection already set to manual, I could reproduce what you see). After submitting the IP address change, it does hang (understandably, as that is the connection used for the webUI), and the DHCP-provided address was back in use. After a nmcli device reapply eth0, the new IP address set in the form was up and functional.
We still need to make sure this is actually what the root cause is, so that we can make sure it is the proper fix, but at least we’re making progress thanks to both of you!
No need to prioritize this over other work items, it’s not a deal breaker for me and I don’t want you to spend time on this just because I posted it to the forum when there might be other more pressing issues to deal with.