Am 16.06.2016 um 14:42 schrieb Nikolai Zhubr: > Hello all, > 16.06.2016 13:52, Marius Tomaschewski: >> Am 18.05.2016 um 18:16 schrieb Jason Schultz: >>> I hope I am not starting a new thread with this, I am attempting to >>> reply to Nikolai Zhubr's last message from his thread: >>> https://lists.opensuse.org/wicked-devel/2016-03/msg00004.html >>> >>> I had started a similar thread a couple weeks before that here, which >>> also did not get a response: >>> >>> https://lists.opensuse.org/wicked-devel/2016-03/msg00000.html >>> >>> The reason for replying again is to agree with the conclusion that >>> "LINK_REQUIRED=no" should be the default >>> in order to prevent this type of issue when there's no physical link. >> >> Definitely not. Many, many things (in the kernel and elsewhere) starts >> after the carrier detection / cannot start without carrier, e.g. ipv6, >> bond + bridge protocols, any kind of link authentication (wpa), any >> autoconfiguration incl. dhcp, duplicate address detection [required >> (except in obsolete RFCs) and enabled also for ipv4] ... > > Ok, then you should disallow BOOTPROTO='static' and also all those tons > of software that are not designed to bind dynamically to randomly > appearing interfaces, so as to be truly consistent.
The problem with BOOTPROTO='static' is, that it never were static in the past, that is, it never disabled ipv6 autoconfig (accept_ra as autoconf flag is just about address, not including routes or dns), e.g. ipv6. BOOTPROTO=dhcp also does not disable static or autoconf -- it enables to use dhcp (dhcp4 || dhcp6). > No, there is nothing wrong with this (fully-dynamic) behaviour in > itself. It may appear handy and fit in many cases, e.g. for mobiles. > However problem is: > - compatibility, > - expectations, > - consistency. well, all of this to what? obsolete RFCs? bug compatibility? SLES-11 / 13.1 didn't monitored the link because it were unable to do it reliably, what caused regular bug reports -- same as it is now, just from the another direction. It was impossible to detect this reliably (especially with older kernels) and it were just looking at the administrative enablement; the "UP" flag (ip link set up), which does not mean much. The interface may never come UP, STP (on bridge) may detect loop in topology and just close ports forwarding (or the switch behind does). (ipv4 + ipv6) duplicate address detection probes send to /dev/null are not really useful, so the kernel never starts ipv6 before the carrier is detected, ... when the kernel detects duplicate of the fe80 link layer address, it simply means there is a MAC duplicate [quite often since virtualization!!]. It is not done by default, but depending on sysfs settings, it causes to disable ipv6 on the interface (inclusive of a "rm -rf /proc/sys/net/ipv6/conf/$ifname"), broken pre-bound sockets, ... The behavior is like this because newer rfc require it and because customer requested this functionality (e.g. ipv4 duplicate address detection done by default). > (-and still not all of us run Suse on mobiles but some do on servers and > desktops!) of course, we try to support mobile hardware as good as we can, but it is not really in the main focus of wicked. > If you force a beautifull new behaviour that is horribly incompatible > with (a lot of regular) existing software, incompatible with people's > expectations, and introduces inconsistencies like silently treating > BOOTPROTO='static' as kind of bogus or obsolete, then you should really > really make it clear that this new shiny solution is still NOT something > that can be relied upon as a proper REPLACEMENT of old buggy scriptware. > But better yet... make it reasonably compatilble, please. Sorry, but I'll not change the default to a LINK_REQUIRE=no nonsense. It was simply impossible to make it in the past, but now it is. And it is a IMO reasonably compbatible to before. > Don't take me wrong, I understand and appreciate the amount of hard > thinking and effort wickedd developers have invested into it already, > and I'd really like it success and good acceptance. I seriously hope > wickedd helps to avoid some ancient and annoying network issues (that > I'm quite aware of and suffer from time to time on non-wickedd > installations). > > But still again: unexpectidly broken BOOTPROTO='static' does not add > much joy, especially when you suddenly find your server inaccessible. I > really see no reason for not defaulting to LINK_REQUIRED=no when > BOOTPROTO=static. BOOTPROTO=static never disabled ipv6 autoconf. It never disabled L2 protocols like bride STP, it also never disabled many other things (multicast groups joined, ...) which all require carrier. It can't do this now too. > In such case dhcp does not need to even be mentioned. > Regarding duplicate address detection I'm not exactly sure how it should > work in all detail, but I'd suppose it would need to somehow deal with > link going physically up and down repratedly anyway? So what is the > benefit of bothering so much at some particular moment then? Except of this, nanny will reapply leases (=config in static case) and cause a verify. There are defense rules for this defined and the kernel handles it. I don't say, wicked is bug free and makes everything the right way. e.g. STARTMODE=hotplug simply sucks and causes to wait full 30sec timeout even neither needed nor requested instead to just continue with other interfaces. But report is open for this. But LINK_REQUIRED=no default is definitely the wrong way to go. Gruesse / Regards, Marius Tomaschewski <m...@suse.de>, <m...@suse.com> -- SUSE LINUX GmbH, GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nürnberg), Maxfeldstraße 5, 90409 Nürnberg, Germany -- To unsubscribe, e-mail: wicked-devel+unsubscr...@opensuse.org To contact the owner, e-mail: wicked-devel+ow...@opensuse.org
