Hi OpenSuSE List, I have encounter an anomaly that from Google searches seems to be specific to OpenSuSE. There has been a couple of discussions dating back to 2014-2016 about this or perhaps something related, just Google for the error message like I did to find them. I dunno if those reports were fixed or not. I am running OpenSuSE15.4 x64 and having some issues with routes (perhaps) on my dhcpd server. When I make changes in the configuration of my dhcpd server, and then try to release and renew a dhcp lease on a client system, using the following commands - dhclient -r -v; dhclient -v, nothing happens/changes. (particularly with routes that I am working on, which are deployed by the dhcpd service.) So what are these error messages from the dhclient-script about and are they serious and the culprit behind what appears to be an apparent failure? Is this the same error as was reported back in 2014-2016? and if so why hasn't it been fixed yet? It appears that there might have been a patch provided but I neither know how or whether it can even be applied to the dhclient-script in OpenSuSE 15.4. Log files were unhelpful and didn't report anything new. Inquiring minds need to know, lol, and as always many thanks for any and all suggestions/help offered, in advance. Marc... Here is the command and the output I got - # dhclient -r -v; dhclient -v Internet Systems Consortium DHCP Client 4.3.6-P1 Copyright 2004-2018 Internet Systems Consortium. All rights reserved. For info, please visit https://www.isc.org/software/dhcp/ Listening on LPF/eth0/00:13:3b:4a:59:8a Sending on LPF/eth0/00:13:3b:4a:59:8a Listening on LPF/eth1/00:13:3b:4a:59:89 Sending on LPF/eth1/00:13:3b:4a:59:89 Listening on LPF/eth2/00:1b:21:a1:21:1c Sending on LPF/eth2/00:1b:21:a1:21:1c Listening on LPF/eth3/40:8d:5c:e3:98:0b Sending on LPF/eth3/40:8d:5c:e3:98:0b Sending on Socket/fallback Internet Systems Consortium DHCP Client 4.3.6-P1 Copyright 2004-2018 Internet Systems Consortium. All rights reserved. For info, please visit https://www.isc.org/software/dhcp/ /sbin/dhclient-script: unable to pre-init requested interface eth0 /sbin/dhclient-script: unable to pre-init requested interface eth1 /sbin/dhclient-script: unable to pre-init requested interface eth2 /sbin/dhclient-script: unable to pre-init requested interface eth3 /sbin/dhclient-script: unable to pre-init requested interfaces -- see log messages If you think you have received this message due to a bug rather than a configuration issue please read the section on submitting bugs on either our web page at www.isc.org or in the README file before submitting a bug. These pages explain the proper process and the information we find helpful for debugging. exiting. -- --... ...-- .----. ... -.. . .-- .- --... .--. -..- .-- -- .- .-. -.-. <b>Computers: the final frontier. These are the voyages of the user Marc.<br> His mission: to explore strange new hardware. To seek out new software and new applications.<br> To boldly go where no Marc has gone before!<br></b>
On 17.06.2023 04:33, Marc Chamberlin via openSUSE Users wrote:
Hi OpenSuSE List, I have encounter an anomaly that from Google searches seems to be specific to OpenSuSE. There has been a couple of discussions dating back to 2014-2016 about this or perhaps something related, just Google for the error message like I did to find them. I dunno if those reports were fixed or not.
I am running OpenSuSE15.4 x64 and having some issues with routes (perhaps) on my dhcpd server. When I make changes in the configuration of my dhcpd server, and then try to release and renew a dhcp lease on a client system, using the following commands - dhclient -r -v; dhclient -v, nothing happens/changes. (particularly with routes that I am working on, which are deployed by the dhcpd service.)
Irrespectively of other questions, using dhclient directly is most certainly the wrong way to do it. You do not use it directly to manage your network (if you did, you would not have had this error) and you must use tools used to manage network to reconfigure it.
So what are these error messages from the dhclient-script about and are they serious and the culprit behind what appears to be an apparent failure? Is this the same error as was reported back in 2014-2016? and if so why hasn't it been fixed yet? It appears that there might have been a patch provided but I neither know how or whether it can even be applied to the dhclient-script in OpenSuSE 15.4.
Log files were unhelpful and didn't report anything new.
Log files are most certainly helpful because dhclient-script should even log why it failed.
Inquiring minds need to know, lol, and as always many thanks for any and all suggestions/help offered, in advance. Marc...
Here is the command and the output I got -
# dhclient -r -v; dhclient -v
Internet Systems Consortium DHCP Client 4.3.6-P1 Copyright 2004-2018 Internet Systems Consortium. All rights reserved. For info, please visit https://www.isc.org/software/dhcp/
Listening on LPF/eth0/00:13:3b:4a:59:8a Sending on LPF/eth0/00:13:3b:4a:59:8a Listening on LPF/eth1/00:13:3b:4a:59:89 Sending on LPF/eth1/00:13:3b:4a:59:89 Listening on LPF/eth2/00:1b:21:a1:21:1c Sending on LPF/eth2/00:1b:21:a1:21:1c Listening on LPF/eth3/40:8d:5c:e3:98:0b Sending on LPF/eth3/40:8d:5c:e3:98:0b Sending on Socket/fallback Internet Systems Consortium DHCP Client 4.3.6-P1 Copyright 2004-2018 Internet Systems Consortium. All rights reserved. For info, please visit https://www.isc.org/software/dhcp/
/sbin/dhclient-script: unable to pre-init requested interface eth0
Educated guess - dhclient-script provided by SUSE checks whether wicked is active and refuses to interfere. And it even logs this and tells you to check the logs. wicked.service) logger -t "${0##*/}" -p daemon.error -- \ "dhclient conflicts with enabled ${_id#Id=} and disabled" return 1 ;;
/sbin/dhclient-script: unable to pre-init requested interface eth1 /sbin/dhclient-script: unable to pre-init requested interface eth2 /sbin/dhclient-script: unable to pre-init requested interface eth3 /sbin/dhclient-script: unable to pre-init requested interfaces -- see log messages
If you think you have received this message due to a bug rather than a configuration issue please read the section on submitting bugs on either our web page at www.isc.org or in the README file before submitting a bug. These pages explain the proper process and the information we find helpful for debugging.
exiting.
On 6/16/23 20:51, Andrei Borzenkov wrote:
On 17.06.2023 04:33, Marc Chamberlin via openSUSE Users wrote:
Hi OpenSuSE List, I have encounter an anomaly that from Google searches seems to be specific to OpenSuSE. There has been a couple of discussions dating back to 2014-2016 about this or perhaps something related, just Google for the error message like I did to find them. I dunno if those reports were fixed or not.
I am running OpenSuSE15.4 x64 and having some issues with routes (perhaps) on my dhcpd server. When I make changes in the configuration of my dhcpd server, and then try to release and renew a dhcp lease on a client system, using the following commands - dhclient -r -v; dhclient -v, nothing happens/changes. (particularly with routes that I am working on, which are deployed by the dhcpd service.)
Irrespectively of other questions, using dhclient directly is most certainly the wrong way to do it. You do not use it directly to manage your network (if you did, you would not have had this error) and you must use tools used to manage network to reconfigure it. Thanks Andrei for your reply. OK uh no-where did I come across any documentation saying I should not be using dhclient. Most of the time, when I have a problem, I use Google to search for answers/solutions. Using dhclient was one of the suggestions I found, so I tried it and it failed. I did more Googling to see if I could find a solution to that new problem. My intent was to simply cause a dhcp client to drop a lease on an IP address along with associated routing rules and to acquire a new dhcp lease with updated routing rules. If you want me to use a different tool to manage my dhcp leases please tell me what tool(s) I should be using instead.
So what are these error messages from the dhclient-script about and are they serious and the culprit behind what appears to be an apparent failure? Is this the same error as was reported back in 2014-2016? and if so why hasn't it been fixed yet? It appears that there might have been a patch provided but I neither know how or whether it can even be applied to the dhclient-script in OpenSuSE 15.4.
Log files were unhelpful and didn't report anything new.
Log files are most certainly helpful because dhclient-script should even log why it failed.
Yeah I see my mistake, I had used grep to find all lines in the messages log file that had the string "dhclient:" in it (damn colon muxed me!). And all I got were messages reporting what was already seen in the verbose output from executing the dhclient command. I later discovered I should have grepped for lines containing "dhclient-script:" as well. This is where I would have found the additional message about the incompatibility between dhclient-script and wicked. (FYI: I don't like or use journalctl and have stuck with using rsyslog. Better yet would be to follow the KISS principal and have each service or app log messages to their own log file IMHO, perhaps in addition to logging to some grand glorified single log file or journal!) To be honest, I think it is a little obtuse to have two different labels for messages, in the log files, that come from running the dhclient command. This comes from a developer designing a user interface which requires the same deep understanding that the developer has, of how an application was designed and modeled, and not from the perspective of a user who has only a shallow surface view of the application. Nor was the developer considerate enough to have the output from dhclient-script included in the verbose output from dhclient that was sent to either stdout or stderr. That said, so what tool should I use, when using the wicked network manager, to cause a system to drop and reacquire a new dhcp lease? Especially when doing this over a remote VNC session connected to the client system, without being dropped and losing my connection? So far, Google has not been much help...
Inquiring minds need to know, lol, and as always many thanks for any and all suggestions/help offered, in advance. Marc...
stuff deleted for brevity...
/sbin/dhclient-script: unable to pre-init requested interface eth0
Educated guess - dhclient-script provided by SUSE checks whether wicked is active and refuses to interfere.
Hmm, I guess I would like to know why in order to better grok dhclient-script....
And it even logs this and tells you to check the logs.
wicked.service) logger -t "${0##*/}" -p daemon.error -- \ "dhclient conflicts with enabled ${_id#Id=} and disabled" return 1 ;;
Further Google research has led me to this bug report - https://lists.opensuse.org/archives/list/bugs@lists.opensuse.org/message/5VQ... which points further to - http://bugzilla.novell.com/show_bug.cgi?id=997507 Unfortunately, while I do have an account on bugzilla.novell.com, I don't have authorization from Novell for reading this bug report's details, nor am I shown how to gain such authorization. But from the contents of the first bug report message at lists.opensuse.org/archives... I strongly suspect this bug report is very apropos to what I am experiencing. more stuff deleted for brevity... -- --... ...-- .----. ... -.. . .-- .- --... .--. -..- .-- -- .- .-. -.-. <b>Computers: the final frontier. These are the voyages of the user Marc.<br> His mission: to explore strange new hardware. To seek out new software and new applications.<br> To boldly go where no Marc has gone before!<br></b>
On 17.06.2023 19:25, Marc Chamberlin via openSUSE Users wrote: ...
That said, so what tool should I use, when using the wicked network manager, to cause a system to drop and reacquire a new dhcp lease?
wicked does not offer any option to do it, so ifdown/ifup is the most straightforward answer. There seems to be D-Bus method to initiate DHCP transaction, but as almost everything else it is not documented so someone has to dig in sources to find out proper arguments.
Especially when doing this over a remote VNC session connected to the client system, without being dropped and losing my connection?
Any reconfiguration of the network remotely can result in connection drop. How did you expect to avoid connection drop by releasing DHCP lease in the first place? Besides, DHCP client is expected to renew lease regularly and DHCP server should provide updated information next time lease is renewed. So there should be no need to do it manually. ...
Hmm, I guess I would like to know why
One more educated guess - because wicked is using internal implementation of DHCP client, not dhclient. You cannot have two different DHCP clients managing the same interface. dhclient is not even installed by default because it is not needed in openSUSE. ...
which points further to - http://bugzilla.novell.com/show_bug.cgi?id=997507
Unfortunately, while I do have an account on bugzilla.novell.com, I don't have authorization from Novell for reading this bug report's details,
Use bugzilla.opensuse.org
On 2023-06-17 20:02, Andrei Borzenkov wrote:
On 17.06.2023 19:25, Marc Chamberlin via openSUSE Users wrote: ...
Hmm, I guess I would like to know why
One more educated guess - because wicked is using internal implementation of DHCP client, not dhclient. You cannot have two different DHCP clients managing the same interface. dhclient is not even installed by default because it is not needed in openSUSE.
Interesting. I have it installed in my main desktop machine. cer@Telcontar:~/tmp> rpm -qf /usr/share/man/man8/dhclient.8.gz dhcp-client-4.3.6.P1-150000.6.17.1.x86_64 cer@Telcontar:~/tmp> cer@Telcontar:~/tmp> rpm -qa | grep dhcp dhcp-4.3.6.P1-150000.6.17.1.x86_64 yast2-dhcp-server-4.4.2-150400.1.7.noarch dhcp-server-4.3.6.P1-150000.6.17.1.x86_64 dhcp-tools-1.6-1.27.x86_64 dhcp-client-4.3.6.P1-150000.6.17.1.x86_64 cer@Telcontar:~/tmp> I guess I could remove them. No, NetworkManager depends on dhcp-client. I can only remove the server components and dhcp-tools -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
On 2023-06-17 12:02, Andrei Borzenkov wrote:
On 17.06.2023 19:25, Marc Chamberlin via openSUSE Users wrote: ...
That said, so what tool should I use, when using the wicked network manager, to cause a system to drop and reacquire a new dhcp lease?
wicked does not offer any option to do it, so ifdown/ifup is the most straightforward answer. There seems to be D-Bus method to initiate DHCP transaction, but as almost everything else it is not documented so someone has to dig in sources to find out proper arguments.
~ # grep dhcp /var/log/messages 2023-06-17T11:53:35.608373-06:00 hadron wickedd-dhcp4[1452]: eth0: Committed DHCPv4 lease with address xx.xx.xx.xx (lease time 21600, renew in 10800 sec, rebind in 18900 sec) 2023-06-17T11:53:35.744456-06:00 hadron wickedd[1471]: route ipv4 0.0.0.0/0 via xx.xx.xx.xx dev eth0#2 type unicast table main scope universe protocol dhcp covered by a ipv4:dhcp lease ~ # systemctl status wickedd-dhcp4.service ● wickedd-dhcp4.service - wicked DHCPv4 supplicant service Loaded: loaded (/usr/lib/systemd/system/wickedd-dhcp4.service; enabled; vendor preset: disabled) Active: active (running) since Tue 2023-06-06 12:29:11 CST; 1 week 4 days ago Main PID: 1452 (wickedd-dhcp4) Tasks: 1 (limit: 4915) CGroup: /system.slice/wickedd-dhcp4.service └─ 1452 /usr/lib/wicked/bin/wickedd-dhcp4 --systemd --foreground Jun 16 08:57:19 hadron wickedd-dhcp4[1452]: eth0: Committed DHCPv4 lease with address xx.xx.xx.xx (lease time 21600, renew in 10800 sec, rebind in 18900 sec) wickedd-dhcp4 is automatically started when using wicked.
On 17.06.2023 23:56, Darryl Gregorash wrote:
On 2023-06-17 12:02, Andrei Borzenkov wrote:
On 17.06.2023 19:25, Marc Chamberlin via openSUSE Users wrote: ...
That said, so what tool should I use, when using the wicked network manager, to cause a system to drop and reacquire a new dhcp lease?
wicked does not offer any option to do it, so ifdown/ifup is the most straightforward answer. There seems to be D-Bus method to initiate DHCP transaction, but as almost everything else it is not documented so someone has to dig in sources to find out proper arguments.
...
wickedd-dhcp4 is automatically started when using wicked.
And how exactly it answers the question "how to force lease renewal"?
On 2023-06-17 23:19, Andrei Borzenkov wrote:
On 17.06.2023 23:56, Darryl Gregorash wrote:
On 2023-06-17 12:02, Andrei Borzenkov wrote:
On 17.06.2023 19:25, Marc Chamberlin via openSUSE Users wrote: ...
That said, so what tool should I use, when using the wicked network manager, to cause a system to drop and reacquire a new dhcp lease?
wicked does not offer any option to do it, so ifdown/ifup is the most straightforward answer. There seems to be D-Bus method to initiate DHCP transaction, but as almost everything else it is not documented so someone has to dig in sources to find out proper arguments.
...
wickedd-dhcp4 is automatically started when using wicked.
And how exactly it answers the question "how to force lease renewal"? I posted the output of the service, from my logs. It all looks automatic to me; at least I have never had to force anything, and my lease keeps getting renewed. Why don't you try the man pages? See man wickedd man wicked
On 18.06.2023 11:04, Darryl Gregorash wrote:
On 2023-06-17 23:19, Andrei Borzenkov wrote:
On 17.06.2023 23:56, Darryl Gregorash wrote:
On 2023-06-17 12:02, Andrei Borzenkov wrote:
On 17.06.2023 19:25, Marc Chamberlin via openSUSE Users wrote: ...
That said, so what tool should I use, when using the wicked network manager, to cause a system to drop and reacquire a new dhcp lease?
wicked does not offer any option to do it, so ifdown/ifup is the most straightforward answer. There seems to be D-Bus method to initiate DHCP transaction, but as almost everything else it is not documented so someone has to dig in sources to find out proper arguments.
...
wickedd-dhcp4 is automatically started when using wicked.
And how exactly it answers the question "how to force lease renewal"? I posted the output of the service, from my logs. It all looks automatic to me; at least I have never had to force anything, and my lease keeps getting renewed.
So read the full discussion again.
Why don't you try the man pages? See man wickedd man wicked
On 2023-06-18 04:12, Andrei Borzenkov wrote:
And how exactly it answers the question "how to force lease renewal"? I posted the output of the service, from my logs. It all looks automatic to me; at least I have never had to force anything, and my lease keeps getting renewed.
So read the full discussion again.
Why don't you try the man pages? See man wickedd man wicked I did read it all, and I am asking you why you need to force lease renewal at all? A lease is gained every time you start the network, and it is renewed automatically at an interval specified (I assume) by the DHCP server that issued the lease.
On 2023-06-18 14:01, Darryl Gregorash wrote:
On 2023-06-18 04:12, Andrei Borzenkov wrote:
And how exactly it answers the question "how to force lease renewal"? I posted the output of the service, from my logs. It all looks automatic to me; at least I have never had to force anything, and my lease keeps getting renewed.
So read the full discussion again.
Why don't you try the man pages? See man wickedd man wicked I did read it all, and I am asking you why you need to force lease renewal at all? A lease is gained every time you start the network, and it is renewed automatically at an interval specified (I assume) by the DHCP server that issued the lease.
Don't ask him, ask the OP. Actually, he wrote why in the first or second post. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
On 2023-06-17 18:25, Marc Chamberlin via openSUSE Users wrote:
On 6/16/23 20:51, Andrei Borzenkov wrote:
On 17.06.2023 04:33, Marc Chamberlin via openSUSE Users wrote:
Further Google research has led me to this bug report -
https://lists.opensuse.org/archives/list/bugs@lists.opensuse.org/message/5VQ...
which points further to - http://bugzilla.novell.com/show_bug.cgi?id=997507
Unfortunately, while I do have an account on bugzilla.novell.com, I don't have authorization from Novell for reading this bug report's details, nor am I shown how to gain such authorization. But from the contents of the first bug report message at lists.opensuse.org/archives... I strongly suspect this bug report is very apropos to what I am experiencing.
Edit the URL to: https://bugzilla.opensuse.org/show_bug.cgi?id=997507 -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
On 6/17/23 11:58, Carlos E. R. wrote:
On 2023-06-17 18:25, Marc Chamberlin via openSUSE Users wrote:
On 6/16/23 20:51, Andrei Borzenkov wrote:
On 17.06.2023 04:33, Marc Chamberlin via openSUSE Users wrote:
Further Google research has led me to this bug report -
https://lists.opensuse.org/archives/list/bugs@lists.opensuse.org/message/5VQ...
which points further to - http://bugzilla.novell.com/show_bug.cgi?id=997507
Unfortunately, while I do have an account on bugzilla.novell.com, I don't have authorization from Novell for reading this bug report's details, nor am I shown how to gain such authorization. But from the contents of the first bug report message at lists.opensuse.org/archives... I strongly suspect this bug report is very apropos to what I am experiencing.
Edit the URL to:
Thanks Carlos, yes that is the same problem I am experiencing. Unfortunately I cannot login to bugzilla to add a comment. (I will start a new thread about this new issue)
-- --... ...-- .----. ... -.. . .-- .- --... .--. -..- .-- -- .- .-. -.-. <b>Computers: the final frontier. These are the voyages of the user Marc.<br> His mission: to explore strange new hardware. To seek out new software and new applications.<br> To boldly go where no Marc has gone before!<br></b>
participants (4)
-
Andrei Borzenkov -
Carlos E. R. -
Darryl Gregorash -
Marc Chamberlin