Bug 970774 - Static ip settings specified for eth card in Yast not properly applied if the link is physically down at the moment
Static ip settings specified for eth card in Yast not properly applied if the...
Status: RESOLVED WONTFIX
: 983844 (view as bug list)
Classification: openSUSE
Product: openSUSE Distribution
Classification: openSUSE
Component: Network
13.2
x86-64 openSUSE 13.2
: P5 - None : Normal (vote)
: ---
Assigned To: wicked maintainers
E-mail List
https://trello.com/c/ZiCg64wV
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2016-03-11 21:34 UTC by Nikolai Zhubr
Modified: 2018-04-12 14:08 UTC (History)
4 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Nikolai Zhubr 2016-03-11 21:34:32 UTC
User-Agent:       Mozilla/5.0 (X11; Linux x86_64; rv:44.0) Gecko/20100101 Firefox/44.0
Build Identifier: 

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. 

Reproducible: Always

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.
Actual Results:  
Static manual ip settings do not get applied if the link is physically down at boot time.

Expected Results:  
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.
Comment 1 Nikolai Zhubr 2016-03-14 09:02:50 UTC
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.
Comment 2 Stefan Hundhammer 2016-03-14 14:00:06 UTC
Knut, Michal, any thoughts on this?
Do we need y2logs for this? (I guess not)
Comment 3 Knut Alejandro Anderssen González 2016-03-14 14:23:46 UTC
(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.
Comment 4 Stefan Hundhammer 2016-03-14 14:33:22 UTC
Now tracking in Trello:

  https://trello.com/c/ZiCg64wV
Comment 5 Nikolai Zhubr 2016-03-16 09:25:20 UTC
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
Comment 6 Nikolai Zhubr 2016-03-16 09:33:11 UTC
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...
Comment 7 Nikolai Zhubr 2016-03-17 09:26:16 UTC
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.

https://github.com/openSUSE/wicked/blob/master/README

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).
Comment 9 Nikolai Zhubr 2016-03-18 23:59:48 UTC
Ok, it is essentially yet another duplicate of Bug 911562.

In short: use wicked package from updates to opensuse 13.2 and manually add:

LINK_REQUIRED=no

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.
Comment 10 Pawel Wieczorkiewicz 2016-06-21 09:28:47 UTC
*** Bug 983844 has been marked as a duplicate of this bug. ***
Comment 11 Nikolai Zhubr 2016-06-21 09:57:55 UTC
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)
Comment 12 Tomáš Chvátal 2018-04-12 14:08:29 UTC
This version of openSUSE changed to end-of-life (EOL [1]) 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.

[1] https://en.opensuse.org/Lifetime