[opensuse] What is so special and non-standard about Leap 15.0 network stack dhcpv4 client wise?
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
On 06/04/2018 01:23 PM, cagsm wrote:
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. ...
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.
I remember somewhere along the line in the 4.xx kernels someone thought it was smart to randomize mac addresses. Some overly cautious code to prevent you from being tracked as you walked into a department store, and their router noticed a mac it could trace across the net or some equally outlandish situation. Supposedly only for wifi, I know this became a problem for cat 5 connections too. https://wiki.archlinux.org/index.php/NetworkManager#Configuring_MAC_Address_... Google this: disable mac address randomization and you will see this hit every distro out there. So: then I have to ask: ARE you POSITIVE your mac remains the same for the entire session? Also, IGDs ping an IP before they issue it, even with a reservation in place for a specific mac address. If they get a response they won't issue that IP, they will issue a different one. Add to that the mac randomization issue and you have a perfect mess. Like I said this SHOULD not affect wired networks, but I've seen it do so myself. Seems like once you get it set, it sticks. But its maddening. -- After all is said and done, more is said than done. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2018-06-04 22:23, cagsm wrote:
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.
Sorry, but I don't understand what you are reporting at all. Only that in the end you rant, but I don't understand the issue from your description. I don't understand that release notes section, either. However, if John Andersen hit the nail then I can start to see the issue. -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)
On 06/04/2018 03:23 PM, cagsm wrote:
Then I found the release notes of 15.0...
::: 7.2 Wicked: Using RFC 4361 DHCPv4 client-id on Ethernet
Comment #5 in bug 1080832 "https://bugzilla.opensuse.org/show_bug.cgi?id=1080832" explains how to revert to the earlier standard. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (4)
-
cagsm -
Carlos E. R. -
John Andersen -
Neil Rickert