Situation: some soho router a.k.a. internet gateway device with some standard isp. LAN side the igd assigns ipv4 addresses via dhcv4 to the clients. Windows and all work nicely, only the leap, now 15.0 device suddenly is barely locatable on the network, all port assignments in the igd firewall, portforwarding and ipv4 assignment is bust. The router *did* assign always the same rfc1918 ipv4 address to most of the LAN clients. But then again OpenSUSE Leap 15.0 machine decided to go nuts and talk to the igd in a way that is beyond my understanding and I could not find out how this machine suddenly gets still the same 'always the same ipv4' steady ipv4 address, but all the rules and forwardings to this machine wouldnt work on the igd, until I needed to remove the machine from the igd config settings and reconfigure everything. How is this even possible? The igd assigns 'same' ipv4 addresses on the LAN by taking the MAC address of the LAN clients into consideration. In fact, this is the only thing that the igd talks about how it were to identify the LAN clients. Still, there must have been some more stuff that was beyond the visibility of the igd userinterface (web interface) that was taken into account, as all the port forwardings were not valid and did not reach this Leap 15.0 client at all, although everything was fine when the Leap was stil at 43.2 level. Then I found the release notes of 15.0... ::: 7.2 Wicked: Using RFC 4361 DHCPv4 client-id on Ethernet ...speaking about fancy 'new' rfc being taken into consideration with dhcp ipv4 setups as far as I understand. Only I have never heard about this rfc until the leap 15.0 documentation, and more importantly it was completely intransparent to me that the igd actually did distinguish the leap 43.2 stage from the leap 15.0 state of the machine. Obviously the MAC address has not changed at all, and the igd config was selected to maintain a virtually static ipv4 LAN wise, but it didnt. Again, openSUSE has caused me serious headaches and unreachable systems where I needed to manually intervene and set things straight or reconfigure or start from scratch. This gets really annoying a lot and I just dont understand why there cant be a steady and stable way to do things or at least to migrate things from one opensuse release to the very next in a steady way. Things like nonbooting systems I read about a lot by others posts or bug-reports, or things like this here about essential things changing rendering systems behave differently on an essential level are of the same impact to me. I am very disappointed of opensuse, again, and this project just doesnt grow on me at all any more. In my opinion there are way too many reboots of various kinds of software layers, stacks and components in the opensuse ecosystem, and as a general rule, a system upgrade is one of the worst nightmares I can possibly think of, when working in an opensuse environment. I can absolutely not recommend opensuse to anyone. I just dont know how many more releases I can handle with these kinds of incidents any more. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org