Bugzilla – Bug 970774
Static ip settings specified for eth card in Yast not properly applied if the link is physically down at the moment
Last modified: 2018-04-12 14:08:29 UTC
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:44.0) Gecko/20100101 Firefox/44.0
Static ip settings (ip address specifically) specified for eth card in Yast do not get properly applied if the link is physically down at boot. The proper settings are still missing if the link becomes physically available later. The only way to get my manually specified ip settings fully applied is to have physical link up at the right moment.
Steps to Reproduce:
1. In yast to to networrk settings, overview tab, select your eth card, press edit, then enter some valid manual configuration - static ip address, netmask, netname, set activation "On boot" or "On hotplug".
2. Make sure network cable is unplugged from this ethernet card, reboot the box.
3. Use "ifconfig" or "ip addr show" to check that ip address was not applied.
4. Plug the network cable, then check again that ip address was not applied.
Static manual ip settings do not get applied if the link is physically down at boot time.
Static manual ip settings should just be applied. Unconditionally. No matter what. That's what they just exist for.
Essentially the consequence is that if the box started in some unfortunate moment when the uplink was (temporary) down, static manual ip settings do not get applied and therefore the box appears unaccessible.
Note: from my observation this looks rather like a wickedd problem than a yast problem, but I haven't dig much yet. It feels like maybe wikedd is watching physical link to get ready to start DHCP, missing the fact that for static config this is irrelevant and it should just straight proceed.
Knut, Michal, any thoughts on this?
Do we need y2logs for this? (I guess not)
(In reply to Stefan Hundhammer from comment #2)
> Knut, Michal, any thoughts on this?
> Do we need y2logs for this? (I guess not)
It is well documented so don't think so. i will try to reproduce it with current info.
Now tracking in Trello:
Some more info: after applying a "fix" (to wicked package) listed below, I get my static ip addr properly assigned as soon as the link becomes physically ip. So it partly "cures" the problem (insane way, yes, just for testing purposes I make it think the link is physically up):
--- netinfo.h.orig 2016-03-16 11:51:29.062238690 +0300
+++ netinfo.h 2016-03-16 11:51:49.969238410 +0300
@@ -290,7 +290,7 @@
static inline int
ni_netdev_link_is_up(const ni_netdev_t *ifp)
- return ifp->link.ifflags & NI_IFF_LINK_UP;
+ return ifp->link.ifflags & NI_IFF_DEVICE_UP;
static inline int
Yet another note. At some point previously, I had DHCP enabled for this card. It might be that something unintentionally left from that previous setup is still hanging around somewhere, causing this problem, although I can't see any...
I've just found the following statement in the wicked's README, which partly confirms what happens:
- The nanny daemon (if enabled) helps to automatically
bring up configured interfaces as soon as the device
is available (interface hotplugging) and set up IP
configuration when a link (carrier) is detected.
Please notice "when a link (carrier) is detected" in this fragment. It means the implicite "tiny" assumption that IP configuration is unneeded until the link is physically up. I believe this assumption is totally wrong and terrific. Well maybe its ok for a cellphone kind of environment, but on a server there might be e.g. a network service which wants to bind to a specific ip address at startup, and it will then certainly fail to start if no such ip address exists, etc etc. Generally such kind of behaviour easily screws a server one way or another (if I read it correctly).
Ok, it is essentially yet another duplicate of Bug 911562.
In short: use wicked package from updates to opensuse 13.2 and manually add:
I can confirm yes it helps.
However, this knowledge of how to "fix" fixed ip came with unnecessary frustration and waste of time. IMHO it would make sense to use "LINK_REQUIRED=no" per default in case of manually specified static ip, even for an interface as simple as a plain ethernet card, for reasons perfectly highlighted already in Bug 911562.
*** Bug 983844 has been marked as a duplicate of this bug. ***
Ok, see also https://lists.opensuse.org/wicked-devel/2016-06/msg00005.html (for a detailed explanation of why 'LINK_REQUIRED=no' is not quite good for default and why one still might want to set it manually in certain cases)
This version of openSUSE changed to end-of-life (EOL ) status. As such
it is no longer maintained, which means that it will not receive any
further security or bug fix updates.
As a result we are closing this bug.
If you can reproduce this bug against a currently maintained version of
openSUSE, or consider the bug still valid, please feel free to reopen this
bug against that version, or open a new ticket.
Thank you for reporting this bug and we are sorry it could not be fixed
during the lifetime of the release.