IP address for HDA keeps jumping - new install Amahi 11
After Amahi 10 suddenly decided not to let me go into the dashboard any more (why? I did nothing to you!) I bit the bullet and did a clean install of Amahi 11. Network/Internet connectivity was a bit flakey, but I managed to get it going and add my data disks manually - that wasn't flagged in advance, was it! Anyway, all working. Installed Plex and OpenVPN. Suddenly all network connectivity was gone; the router could see the Internet, but after an ip renewal, I lost my connection to everything! Eventually I used the rescue start of Amahi 11 and the network came back.
according to the router home page, my HDA keeps changing from 192.168.0.80 to 192.168.0.125. Why on earth!? Plex works (permanently on 80). OpenVPN doesn't (whether I set forwarding to 80 or 125). Amahi Anywhere does work.
I have the DNS Alias in advanced setting for the hda as 80. The control panel has it as 80. I've set the dynamic IP range to 20-254. Obviously the DHCP server on the router is disabled.
What's going on?
Can't work out how to get the Common Logs out for you, but here's paste.fedoraproject.org/paste/IFLizfuUI07FN3w-4u28-g
#4 Updated by cpg over 1 year ago
It looks like there are a lot of network interfaces. Some of them are physical, some are virtual, like the docker one and tun one.
It seems to me that those (which ones, I'm not sure) may have software associated that has a DHCP client running on them. This explains why some of the IPs associated could be getting DHCP addresses.
What other software or apps did you install?
PS: next time please avoid images and use text using the pre directive here.
#5 Updated by CurlyLizard over 1 year ago
The mystery is that under Amahi 10, the system was running perfectly, with the IP address steady as a rock on .80, and with Plex and OpenVPN installed, and OpenVPN working.
The server is a ProLiant, with a separate interface to my Windows computer on IP .60 - that hasn't changed.
I haven't intentionally installed anything with docker or tun, whatever that is.
The problems started after installing Plex and OpenVPN from your apps page, not manually. Since then I have installed:
access logs (trying to output logs for the bug-tracker, failed!)
server logs viewer (ditto)
HDA Troubleshooting Tools (in case needed, haven't touched them)
#6 Updated by CurlyLizard over 1 year ago
Update - I went away for a few days and after about 24 hours lost remote connection to the server. On returning I discovered that all networking had stopped working, I had to reset the router again to access the network and internet, and get everything working once more. I also uninstalled and reinstalled Plex for good measure. DHCP is off on the router, and DNS is handled by the HDA, as per settings. Plex can now only be accessed by using the IP directly and not at all by plexms.home.com, as previously. The hda oscillates between 192.168.0.80 and 192.168.0.140 now.
#7 Updated by CurlyLizard over 1 year ago
I'm guessing there's no clue about this? I'm still unable connect remotely via OpenVPN ("waiting for server reply"); nothing appears in a remote browser when I use its yourhda.com address; internally I can't get to plex or any app via their home.com addresses, only via IP addresses. Otherwise it works. Just not as well as it used to under Amahi 10.
#8 Updated by cpg over 1 year ago
It's hard to tell without more debugging details ..
Can you somehow disable all other networking devices??
I don't recall having seen before a system with so many extraneous network devices. Maybe newer OS versions try too hard to use those other devices somehow and confusion ensues ..
#9 Updated by CurlyLizard over 1 year ago
I understand it's hard, and all the more so remotely! My hardware setup hasn't changed, though. Basically I have a cable modem into a router, which then leads to a managed switch. The switch takes lines into the server (it's an HPE server, with two connections and IP addresses, one for direct admin and one for the actual server); otherwise clients include a powerline adaptor, wired connection to main PC and cable TV (Tivo) box; otherwise wireless connections to the usual clients (laptops, tablets, phones, Chromecast). So I'm not sure what extraneous networking devices there could be. Could there perhaps be some settings in the switch I need to change? I'll be honest, I don't really understand most of the switch settings...
#10 Updated by CurlyLizard over 1 year ago
One more update. Reinstalled OpenVPN server and also client, and that's now working! So it's just the IP address jumps (if it's working, don't care about those) and the inability to access any apps via home.com addresses. Most informative (and slightly sad) browser error message is from Firefox: "Firefox has detected that the server is redirecting the request for this address in a way that will never complete."
#12 Updated by CurlyLizard over 1 year ago
Sadly not stable. Amahi brought down the network again in the middle of the night - dns/dhcp servers cut everything off again, and nothing reachable via ping from amahi itself. Once again the only solution is to plug the router into the main PC, factory reset it and set it up again; restart the server, test that it's again administering the network, switch off dhcp on the router and we're back. But again, the home.com addresses aren't working and OpenVPN isn't either. Reinstalling OpenVPN hasn't worked yet. This is slowly getting tiresome.
#13 Updated by CurlyLizard about 1 year ago
Not sure if anyone is venturing in here at all, but I finally worked out what was going on.
When setting up to start with (and resetting after each time Amahi brought the network down) all devices, including the HDA, were of course getting IP addresses assigned by my router. This was set to give IP addresses in the range 192.168.0.100-199 - but the HDA is registered as 192.168.0.80, so out of this range. When DHCP was switched off on the router, the HDA would cling on to the 80 address and whatever 100+ address it was assigned.
Last time the network went down, I reset the router to provide addresses from 20 up to 199, then rebooted the HDA and started from the "rescue" option. After a couple more restarts, the HDA was assigned (and stuck to) the 80 IP address alone. And there it remains, with everything seemingly working and stable (for a few days so far, anyway).
The Cockpit app shows the address assigned to 3 network interfaces: eno1, eno2 and ens1f1. Before, eno1 would have one address and eno2 the other, conflicting one. I don't know enough about servers to know whether it's a quirk of this one (HP Proliant Gen8) to have two interfaces like this. Anyway, there we are.
I am having the same issue.
Seems this is something to do with how Fedora 27 does networking. NetworkManager and network services are both running. Disabling either one does not help as NetworkManager cannot truly be disabled or it breaks other things.
I cannot seem to stop it from assigning two IP addresses to my HDA :(
#15 Updated by CurlyLizard 12 months ago
Well, my system has run consistently without problem since the solution I posted above. I don't know if it applies to anyone else. The key was allowing the router to assign addresses in the range encompassing the hda's one, then running the hda in rescue mode once so that the errant IP address was reassigned. If that makes sense.
- Status changed from New to Closed
I had a similar issue this week.
I don't know exactly why, but my network device started to call itself eno1 after calling itself enp0s25. This happened after a power unplug.
This had happened before: it started to call itself enp0s25 a few months back after a long-overdue BIOS update. However, that is fairly justifiable, as the BIOS may advertise the hardware to the OS after the BIOS was revved up to a version never by quite a few years. ACPI standards, etc. may have changed and now the hardware may be "seen differently."
Now, this change I experienced this week (only got to it today) was unexpected. I am on Fedora 32 and my system had been stable, however, I do apply updates regularly, in hope of finding any issues before any of the Amahi users in our community. I am not sure why or how this happened. It could be related to kernel changes.
I'm closing this in frustration, as I have not been able to ascertain how this device re-enumeration is triggered. It's definitely a long-term issue.
Also available in: Atom