[opensuse] Leap 15.2: Fail to start network during reboot
The last two times my system has been rebooted, it failed to start the network service. I had to do a manual restart to get internet service. I have no idea where to look to correct the problem. Here are the relevant log entries from the latest reboot (apologies for the long lines -- I did not write them :) ):
2020-08-21T07:00:58.683449-06:00 hadron systemd[1]: Starting wicked DHCPv4 supplicant service... 2020-08-21T07:00:58.684634-06:00 hadron systemd[1]: Starting wicked AutoIPv4 supplicant service... 2020-08-21T07:00:58.685617-06:00 hadron systemd[1]: Starting wicked DHCPv6 supplicant service... 2020-08-21T07:00:58.708869-06:00 hadron systemd[1]: Started wicked AutoIPv4 supplicant service. 2020-08-21T07:00:58.709093-06:00 hadron systemd[1]: Started wicked DHCPv6 supplicant service. 2020-08-21T07:00:58.709203-06:00 hadron systemd[1]: Started wicked DHCPv4 supplicant service. 2020-08-21T07:00:58.710197-06:00 hadron systemd[1]: Starting wicked network management service daemon... 2020-08-21T07:00:58.727620-06:00 hadron systemd[1]: Started wicked network management service daemon. 2020-08-21T07:00:58.730168-06:00 hadron systemd[1]: Starting wicked network nanny service... 2020-08-21T07:00:58.750880-06:00 hadron systemd[1]: Started wicked network nanny service. 2020-08-21T07:00:58.751912-06:00 hadron systemd[1]: Starting wicked managed network interfaces... 2020-08-21T07:01:02.276106-06:00 hadron wickedd-dhcp4[1380]: eth0: Request to acquire DHCPv4 lease with UUID 8bc53f5f-8cf8-0400-7805-000004000000 2020-08-21T07:01:12.551065-06:00 hadron wickedd-dhcp4[1380]: unable to confirm lease 2020-08-21T07:01:17.550092-06:00 hadron wickedd-dhcp4[1380]: eth0: defer timeout 15 reached (state INIT) 2020-08-21T07:01:18.898020-06:00 hadron wickedd-dhcp4[1380]: eth0: Request to acquire DHCPv4 lease with UUID 8bc53f5f-8cf8-0400-7805-000004000000 2020-08-21T07:01:21.647605-06:00 hadron wickedd-dhcp4[1380]: eth0: Committed DHCPv4 lease with address 192.168.100.11 (lease time 20 sec, renew in 10 sec, rebind in 17 sec) 2020-08-21T07:01:24.416691-06:00 hadron wicked[1432]: lo up 2020-08-21T07:01:24.416892-06:00 hadron wicked[1432]: eth0 up 2020-08-21T07:01:24.417323-06:00 hadron systemd[1]: Started wicked managed network interfaces. 2020-08-21T07:01:32.711744-06:00 hadron wickedd-dhcp4[1380]: eth0: Committed DHCPv4 lease with address 192.168.100.11 (lease time 20 sec, renew in 10 sec, rebind in 17 sec) 2020-08-21T07:01:32.803748-06:00 hadron wickedd[1400]: route ipv4 0.0.0.0/0 via 192.168.100.1 dev eth0#2 type unicast table main scope universe protocol dhcp covered by a ipv4:dhcp lease 2020-08-21T07:01:43.747638-06:00 hadron wickedd-dhcp4[1380]: eth0: Committed DHCPv4 lease with address 192.168.100.11 (lease time 20 sec, renew in 10 sec, rebind in 17 sec) 2020-08-21T07:01:43.803702-06:00 hadron wickedd[1400]: route ipv4 0.0.0.0/0 via 192.168.100.1 dev eth0#2 type unicast table main scope universe protocol dhcp covered by a ipv4:dhcp lease 2020-08-21T07:02:00.782677-06:00 hadron wickedd-dhcp4[1380]: unable to renew lease within renewal period; trying to rebind
Here is where I restarted the network:
2020-08-21T07:03:10.496616-06:00 hadron systemd[1]: Stopping wicked managed network interfaces... 2020-08-21T07:03:10.510545-06:00 hadron wickedd-dhcp4[1380]: eth0: Request to release DHCPv4 lease with UUID 8bc53f5f-8cf8-0400-7805-000004000000: releasing... 2020-08-21T07:03:11.081974-06:00 hadron wicked[6657]: eth0 device-ready 2020-08-21T07:03:11.082735-06:00 hadron systemd[1]: Stopped wicked managed network interfaces. 2020-08-21T07:03:11.084097-06:00 hadron systemd[1]: Starting wicked managed network interfaces... 2020-08-21T07:03:14.447887-06:00 hadron wickedd-dhcp4[1380]: eth0: Request to acquire DHCPv4 lease with UUID 8bc53f5f-8cf8-0400-7805-00000a000000 2020-08-21T07:03:15.339660-06:00 hadron wickedd-dhcp4[1380]: eth0: Committed DHCPv4 lease with address 24.72.0.229 (lease time 172800 sec, renew in 86400 sec, rebind in 172500 sec) 2020-08-21T07:03:16.371503-06:00 hadron wicked[6774]: lo up 2020-08-21T07:03:16.371707-06:00 hadron wicked[6774]: eth0 up 2020-08-21T07:03:16.372201-06:00 hadron systemd[1]: Started wicked managed network interfaces.
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 21/08/2020 15.29, Darryl Gregorash wrote:
The last two times my system has been rebooted, it failed to start the network service. I had to do a manual restart to get internet service. I have no idea where to look to correct the problem.
Here are the relevant log entries from the latest reboot (apologies for the long lines -- I did not write them :) ):
Long lines are good; wrapped log lines are bad.
2020-08-21T07:00:58.683449-06:00 hadron systemd[1]: Starting wicked DHCPv4 supplicant service... 2020-08-21T07:00:58.684634-06:00 hadron systemd[1]: Starting wicked AutoIPv4 supplicant service... 2020-08-21T07:00:58.685617-06:00 hadron systemd[1]: Starting wicked DHCPv6 supplicant service... 2020-08-21T07:00:58.708869-06:00 hadron systemd[1]: Started wicked AutoIPv4 supplicant service. 2020-08-21T07:00:58.709093-06:00 hadron systemd[1]: Started wicked DHCPv6 supplicant service. 2020-08-21T07:00:58.709203-06:00 hadron systemd[1]: Started wicked DHCPv4 supplicant service. 2020-08-21T07:00:58.710197-06:00 hadron systemd[1]: Starting wicked network management service daemon... 2020-08-21T07:00:58.727620-06:00 hadron systemd[1]: Started wicked network management service daemon. 2020-08-21T07:00:58.730168-06:00 hadron systemd[1]: Starting wicked network nanny service... 2020-08-21T07:00:58.750880-06:00 hadron systemd[1]: Started wicked network nanny service. 2020-08-21T07:00:58.751912-06:00 hadron systemd[1]: Starting wicked managed network interfaces... 2020-08-21T07:01:02.276106-06:00 hadron wickedd-dhcp4[1380]: eth0: Request to acquire DHCPv4 lease with UUID 8bc53f5f-8cf8-0400-7805-000004000000 2020-08-21T07:01:12.551065-06:00 hadron wickedd-dhcp4[1380]: unable to confirm lease 2020-08-21T07:01:17.550092-06:00 hadron wickedd-dhcp4[1380]: eth0: defer timeout 15 reached (state INIT) 2020-08-21T07:01:18.898020-06:00 hadron wickedd-dhcp4[1380]: eth0: Request to acquire DHCPv4 lease with UUID 8bc53f5f-8cf8-0400-7805-000004000000 2020-08-21T07:01:21.647605-06:00 hadron wickedd-dhcp4[1380]: eth0: Committed DHCPv4 lease with address 192.168.100.11 (lease time 20 sec, renew in 10 sec, rebind in 17 sec) 2020-08-21T07:01:24.416691-06:00 hadron wicked[1432]: lo up 2020-08-21T07:01:24.416892-06:00 hadron wicked[1432]: eth0 up 2020-08-21T07:01:24.417323-06:00 hadron systemd[1]: Started wicked managed network interfaces. 2020-08-21T07:01:32.711744-06:00 hadron wickedd-dhcp4[1380]: eth0: Committed DHCPv4 lease with address 192.168.100.11 (lease time 20 sec, renew in 10 sec, rebind in 17 sec) 2020-08-21T07:01:32.803748-06:00 hadron wickedd[1400]: route ipv4 0.0.0.0/0 via 192.168.100.1 dev eth0#2 type unicast table main scope universe protocol dhcp covered by a ipv4:dhcp lease
The network interface gets a LAN address and a route. Seems correct. Weird lease time of 20 seconds, though, too short. So short that the computer doesn't have time to renew and fails.
2020-08-21T07:01:43.747638-06:00 hadron wickedd-dhcp4[1380]: eth0: Committed DHCPv4 lease with address 192.168.100.11 (lease time 20 sec, renew in 10 sec, rebind in 17 sec) 2020-08-21T07:01:43.803702-06:00 hadron wickedd[1400]: route ipv4 0.0.0.0/0 via 192.168.100.1 dev eth0#2 type unicast table main scope universe protocol dhcp covered by a ipv4:dhcp lease 2020-08-21T07:02:00.782677-06:00 hadron wickedd-dhcp4[1380]: unable to renew lease within renewal period; trying to rebind
Here is where I restarted the network:
2020-08-21T07:03:10.496616-06:00 hadron systemd[1]: Stopping wicked managed network interfaces... 2020-08-21T07:03:10.510545-06:00 hadron wickedd-dhcp4[1380]: eth0: Request to release DHCPv4 lease with UUID 8bc53f5f-8cf8-0400-7805-000004000000: releasing... 2020-08-21T07:03:11.081974-06:00 hadron wicked[6657]: eth0 device-ready 2020-08-21T07:03:11.082735-06:00 hadron systemd[1]: Stopped wicked managed network interfaces. 2020-08-21T07:03:11.084097-06:00 hadron systemd[1]: Starting wicked managed network interfaces... 2020-08-21T07:03:14.447887-06:00 hadron wickedd-dhcp4[1380]: eth0: Request to acquire DHCPv4 lease with UUID 8bc53f5f-8cf8-0400-7805-00000a000000 2020-08-21T07:03:15.339660-06:00 hadron wickedd-dhcp4[1380]: eth0: Committed DHCPv4 lease with address 24.72.0.229 (lease time 172800 sec, renew in 86400 sec, rebind in 172500 sec)
Now this is weird, it is getting a very different network address, this time public. This is very weird. It seems you have two different DHCP servers in the same network, one from your ISP, another from the LAN.
2020-08-21T07:03:16.371503-06:00 hadron wicked[6774]: lo up 2020-08-21T07:03:16.371707-06:00 hadron wicked[6774]: eth0 up 2020-08-21T07:03:16.372201-06:00 hadron systemd[1]: Started wicked managed network interfaces.
-- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
On 2020-08-21 10:51 a.m., Carlos E. R. wrote:
On 21/08/2020 15.29, Darryl Gregorash wrote:
The last two times my system has been rebooted, it failed to start the network service. I had to do a manual restart to get internet service. I have no idea where to look to correct the problem.
Here are the relevant log entries from the latest reboot (apologies for the long lines -- I did not write them :) ):
Long lines are good; wrapped log lines are bad.
If only quoting half of each line of text was as easy as taking a screenshot of just half of a screen.
2020-08-21T07:01:32.711744-06:00 hadron wickedd-dhcp4[1380]: eth0: Committed DHCPv4 lease with address 192.168.100.11 (lease time 20 sec, renew in 10 sec, rebind in 17 sec) 2020-08-21T07:01:32.803748-06:00 hadron wickedd[1400]: route ipv4 0.0.0.0/0 via 192.168.100.1 dev eth0#2 type unicast table main scope universe protocol dhcp covered by a ipv4:dhcp lease
The network interface gets a LAN address and a route. Seems correct. Weird lease time of 20 seconds, though, too short. So short that the computer doesn't have time to renew and fails.
Except 192.168.100.1 is my cable modem, and it certainly does not have a DHCP server in it. I ave never seen that IP appear in my logs before, except the last 2 reboots. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Darryl Gregorash wrote:
On 2020-08-21 10:51 a.m., Carlos E. R. wrote:
On 21/08/2020 15.29, Darryl Gregorash wrote:
The last two times my system has been rebooted, it failed to start the network service. I had to do a manual restart to get internet service. I have no idea where to look to correct the problem.
Here are the relevant log entries from the latest reboot (apologies for the long lines -- I did not write them :) ):
Long lines are good; wrapped log lines are bad.
If only quoting half of each line of text was as easy as taking a screenshot of just half of a screen.
2020-08-21T07:01:32.711744-06:00 hadron wickedd-dhcp4[1380]: eth0: Committed DHCPv4 lease with address 192.168.100.11 (lease time 20 sec, renew in 10 sec, rebind in 17 sec) 2020-08-21T07:01:32.803748-06:00 hadron wickedd[1400]: route ipv4 0.0.0.0/0 via 192.168.100.1 dev eth0#2 type unicast table main scope universe protocol dhcp covered by a ipv4:dhcp lease
The network interface gets a LAN address and a route. Seems correct. Weird lease time of 20 seconds, though, too short. So short that the computer doesn't have time to renew and fails.
Except 192.168.100.1 is my cable modem, and it certainly does not have a DHCP server in it. I ave never seen that IP appear in my logs before, except the last 2 reboots.
Something on your network provides a DHCP service, using a range of 192.168.100.[2-254] The actual range is a guess, but it's quite typical for an access modem to be 192.168.x.1, run a DHCP server and advertise itself as the default gateway. It does seem quite likely that your cable modem has a DHCP server. As Carlos points out, 20sec is a very short lease - I don't know what the idea of that might be. -- Per Jessen, Zürich (19.2°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2020-08-22 7:13 a.m., Per Jessen wrote:
Darryl Gregorash wrote:
Except 192.168.100.1 is my cable modem, and it certainly does not have a DHCP server in it. I ave never seen that IP appear in my logs before, except the last 2 reboots.
Something on your network provides a DHCP service, using a range of 192.168.100.[2-254] The actual range is a guess, but it's quite typical for an access modem to be 192.168.x.1, run a DHCP server and advertise itself as the default gateway. It does seem quite likely that your cable modem has a DHCP server.
As Carlos points out, 20sec is a very short lease - I don't know what the idea of that might be.
I just spoke with the ISP, and the modem does not have a DHCP server in it. It would make no sense for it to have a DHCP server unless it was a router, which it is not. As far as I am concerned, 192.168.100.11 is being assigned by the OS, because the DHCP request has failed (timed out), on account of a network interface that has not been properly initialized. Please recall that this problem has never occurred except during a reboot right after a kernel update. I have already rebooted once after my first post, and everything went fine. Do you wish to see the log from that boot? Yes, it is strange that the subnet assigned to the network card is the same as the subnet the modem uses. I have no explanation for that, but after speaking with the ISP, I am certain that the modem is not responsible for that. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 8/22/20 12:40 PM, Darryl Gregorash wrote:
I just spoke with the ISP, and the modem does not have a DHCP server in it. It would make no sense for it to have a DHCP server unless it was a router, which it is not.
If your modem is in bridge mode, you would use the ISPs DHCP server. If it's in gateway mode, the DHCP server would be in the modem.
As far as I am concerned, 192.168.100.11 is being assigned by the OS, because the DHCP request has failed (timed out), on account of a network interface that has not been properly initialized.
I have never seen that happen. DHCP clients will usually default to the 169.254.0.0 /16 range, unless configured for something else. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
James Knott wrote:
On 8/22/20 12:40 PM, Darryl Gregorash wrote:
I just spoke with the ISP, and the modem does not have a DHCP server in it. It would make no sense for it to have a DHCP server unless it was a router, which it is not.
If your modem is in bridge mode, you would use the ISPs DHCP server. If it's in gateway mode, the DHCP server would be in the modem.
+1
As far as I am concerned, 192.168.100.11 is being assigned by the OS, because the DHCP request has failed (timed out), on account of a network interface that has not been properly initialized.
I have never seen that happen. DHCP clients will usually default to the 169.254.0.0 /16 range, unless configured for something else.
Yep, some zeroconf default. -- Per Jessen, Zürich (22.2°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2020-08-22 10:44 a.m., James Knott wrote:
On 8/22/20 12:40 PM, Darryl Gregorash wrote:
I just spoke with the ISP, and the modem does not have a DHCP server in it. It would make no sense for it to have a DHCP server unless it was a router, which it is not.
If your modem is in bridge mode, you would use the ISPs DHCP server. If it's in gateway mode, the DHCP server would be in the modem.
How would it switch from bridge mode to gateway mode simply because of a reboot -- and then only after a kernel update?
As far as I am concerned, 192.168.100.11 is being assigned by the OS, because the DHCP request has failed (timed out), on account of a network interface that has not been properly initialized.
I have never seen that happen. DHCP clients will usually default to the 169.254.0.0 /16 range, unless configured for something else.
That is what I would have expected too, but who knows? I suppose I could unplug the ethernet cable and do a reboot to find out. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
22.08.2020 19:40, Darryl Gregorash пишет:
As far as I am concerned, 192.168.100.11 is being assigned by the OS, because the DHCP request has failed (timed out), on account of a network interface that has not been properly initialized.
Please recall that this problem has never occurred except during a reboot right after a kernel update. I have already rebooted once after my first post, and everything went fine. Do you wish to see the log from that boot?
Yes, it is strange that the subnet assigned to the network card is the same as the subnet the modem uses. I have no explanation for that, but after speaking with the ISP, I am certain that the modem is not responsible for that.
Is this address present in any file in /var/lib/wicked or /run/wicked? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2020-08-22 11:05 a.m., Andrei Borzenkov wrote:
Is this address present in any file in /var/lib/wicked or /run/wicked?
No, but all that is in those locations are the current leaseinfo files. There are no references to subnet 192.168.100.x in /etc either. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Sat, 2020-08-22 at 10:40 -0600, Darryl Gregorash wrote:
On 2020-08-22 7:13 a.m., Per Jessen wrote:
Darryl Gregorash wrote:
Except 192.168.100.1 is my cable modem, and it certainly does not have a DHCP server in it. I ave never seen that IP appear in my logs before, except the last 2 reboots.
Something on your network provides a DHCP service, using a range of 192.168.100.[2-254] The actual range is a guess, but it's quite typical for an access modem to be 192.168.x.1, run a DHCP server and advertise itself as the default gateway. It does seem quite likely that your cable modem has a DHCP server.
As Carlos points out, 20sec is a very short lease - I don't know what the idea of that might be.
I just spoke with the ISP, and the modem does not have a DHCP server in it. It would make no sense for it to have a DHCP server unless it was a router, which it is not.
As far as I am concerned, 192.168.100.11 is being assigned by the OS, because the DHCP request has failed (timed out), on account of a network interface that has not been properly initialized.
Please recall that this problem has never occurred except during a reboot right after a kernel update. I have already rebooted once after my first post, and everything went fine. Do you wish to see the log from that boot?
Yes, it is strange that the subnet assigned to the network card is the same as the subnet the modem uses. I have no explanation for that, but after speaking with the ISP, I am certain that the modem is not responsible for that.
I'm on Spectrum here in the U.S. and it seems that getting an IP address from them is a 2 step process. I'll 1st get a local address like the 192.168.100.11 and then I get routeable IP address like 174.10x.xxx.173. When I was using openSUSE as a router, I occasionally had issues during a reboot getting a routeable address. - I'm now using pfSense, and it just works. Mark -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Mark Petersen wrote:
I'm on Spectrum here in the U.S. and it seems that getting an IP address from them is a 2 step process. I'll 1st get a local address like the 192.168.100.11 and then I get routeable IP address like 174.10x.xxx.173.
So your local devices have public IP-addresses? That is an idea from by-gone days. The two-step process could be part of some authentication scheme though. -- Per Jessen, Zürich (22.2°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 8/22/20 1:30 PM, Per Jessen wrote:
So your local devices have public IP-addresses? That is an idea from by-gone days. The two-step process could be part of some authentication scheme though.
???? The only reason devices don't get public addresses is due to NAT being used to get around the shortage of IPv4 addresses. I can plug my computer directly into my modem (in bridge mode) and get a public address. In fact, I can do that twice, with each device getting it's own public IPv4 address. On IPv6, my LAN gets a block of 18.4 billion, billion addresses and I can get up to 256 of those blocks. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Darryl Gregorash wrote:
On 2020-08-22 7:13 a.m., Per Jessen wrote:
Darryl Gregorash wrote:
Except 192.168.100.1 is my cable modem, and it certainly does not have a DHCP server in it. I ave never seen that IP appear in my logs before, except the last 2 reboots.
Something on your network provides a DHCP service, using a range of 192.168.100.[2-254] The actual range is a guess, but it's quite typical for an access modem to be 192.168.x.1, run a DHCP server and advertise itself as the default gateway. It does seem quite likely that your cable modem has a DHCP server.
As Carlos points out, 20sec is a very short lease - I don't know what the idea of that might be.
I just spoke with the ISP, and the modem does not have a DHCP server in it. It would make no sense for it to have a DHCP server unless it was a router, which it is not.
Okay - I wonder what kind of setup you have, but I am not really familiar with the "cable modem" expression. If your cable modem is _not_ a router, your home network is directly connected to the overall telco/cable network. Unless the next uplevel switch is using vlans, all of your neighbours can listen in on what you're doing.
As far as I am concerned, 192.168.100.11 is being assigned by the OS, because the DHCP request has failed (timed out), on account of a network interface that has not been properly initialized.
No, that would be the OS rolling a pair of dice. Why not 10.1.2.3 or 172.16.45.67 ? or 185.84.248.1 ? iow, where does that number come from?
Please recall that this problem has never occurred except during a reboot right after a kernel update. I have already rebooted once after my first post, and everything went fine. Do you wish to see the log from that boot?
It might be interesting to see, yes. -- Per Jessen, Zürich (22.6°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2020-08-22 11:27 a.m., Per Jessen wrote:
Darryl Gregorash wrote:
Please recall that this problem has never occurred except during a reboot right after a kernel update. I have already rebooted once after my first post, and everything went fine. Do you wish to see the log from that boot?
It might be interesting to see, yes.
(With no apologies to Carlos for the line-wrap ;) ) grep "2020-08-21T17:45" /var/log/messages-20200822 | grep wicked 2020-08-21T17:45:30.455163-06:00 hadron systemd[1]: Starting wicked DHCPv4 supplicant service... 2020-08-21T17:45:30.455775-06:00 hadron systemd[1]: Starting wicked AutoIPv4 supplicant service... 2020-08-21T17:45:30.456535-06:00 hadron systemd[1]: Starting wicked DHCPv6 supplicant service... 2020-08-21T17:45:30.474541-06:00 hadron systemd[1]: Started wicked AutoIPv4 supplicant service. 2020-08-21T17:45:30.474687-06:00 hadron systemd[1]: Started wicked DHCPv6 supplicant service. 2020-08-21T17:45:30.474769-06:00 hadron systemd[1]: Started wicked DHCPv4 supplicant service. 2020-08-21T17:45:30.475555-06:00 hadron systemd[1]: Starting wicked network management service daemon... 2020-08-21T17:45:30.493142-06:00 hadron systemd[1]: Started wicked network management service daemon. 2020-08-21T17:45:30.495886-06:00 hadron systemd[1]: Starting wicked network nanny service... 2020-08-21T17:45:30.515803-06:00 hadron systemd[1]: Started wicked network nanny service. 2020-08-21T17:45:30.516572-06:00 hadron systemd[1]: Starting wicked managed network interfaces... 2020-08-21T17:45:34.031587-06:00 hadron wickedd-dhcp4[1368]: eth0: Request to acquire DHCPv4 lease with UUID 9b5c405f-41b7-0000-6705-000004000000 2020-08-21T17:45:35.154532-06:00 hadron wickedd-dhcp4[1368]: eth0: Committed DHCPv4 lease with address 24.72.0.229 (lease time 172800 sec, renew in 86400 sec, rebind in 172500 sec) 2020-08-21T17:45:36.018340-06:00 hadron wicked[1419]: lo up 2020-08-21T17:45:36.018506-06:00 hadron wicked[1419]: eth0 up 2020-08-21T17:45:36.019048-06:00 hadron systemd[1]: Started wicked managed network interfaces. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Darryl Gregorash wrote:
2020-08-21T17:45:35.154532-06:00 hadron wickedd-dhcp4[1368]: eth0: Committed DHCPv4 lease with address 24.72.0.229 (lease time 172800 sec, renew in 86400 sec, rebind in 172500 sec)
Question - do all of your devices (a smartphone on wifi for instance) get those real/public addresses ? It's certainly a kickback to by-gone/pre-NAT days. -- Per Jessen, Zürich (21.6°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 22/08/2020 19.46, Darryl Gregorash wrote:
On 2020-08-22 11:27 a.m., Per Jessen wrote:
Darryl Gregorash wrote:
Please recall that this problem has never occurred except during a reboot right after a kernel update. I have already rebooted once after my first post, and everything went fine. Do you wish to see the log from that boot?
It might be interesting to see, yes.
(With no apologies to Carlos for the line-wrap ;) )
Grr
grep "2020-08-21T17:45" /var/log/messages-20200822 | grep wicked 2020-08-21T17:45:30.455163-06:00 hadron systemd[1]: Starting wicked DHCPv4 supplicant service... 2020-08-21T17:45:30.455775-06:00 hadron systemd[1]: Starting wicked AutoIPv4 supplicant service... 2020-08-21T17:45:30.456535-06:00 hadron systemd[1]: Starting wicked DHCPv6 supplicant service... 2020-08-21T17:45:30.474541-06:00 hadron systemd[1]: Started wicked AutoIPv4 supplicant service. 2020-08-21T17:45:30.474687-06:00 hadron systemd[1]: Started wicked DHCPv6 supplicant service. 2020-08-21T17:45:30.474769-06:00 hadron systemd[1]: Started wicked DHCPv4 supplicant service. 2020-08-21T17:45:30.475555-06:00 hadron systemd[1]: Starting wicked network management service daemon... 2020-08-21T17:45:30.493142-06:00 hadron systemd[1]: Started wicked network management service daemon. 2020-08-21T17:45:30.495886-06:00 hadron systemd[1]: Starting wicked network nanny service... 2020-08-21T17:45:30.515803-06:00 hadron systemd[1]: Started wicked network nanny service. 2020-08-21T17:45:30.516572-06:00 hadron systemd[1]: Starting wicked managed network interfaces... 2020-08-21T17:45:34.031587-06:00 hadron wickedd-dhcp4[1368]: eth0: Request to acquire DHCPv4 lease with UUID 9b5c405f-41b7-0000-6705-000004000000 2020-08-21T17:45:35.154532-06:00 hadron wickedd-dhcp4[1368]: eth0: Committed DHCPv4 lease with address 24.72.0.229 (lease time 172800 sec, renew in 86400 sec, rebind in 172500 sec) 2020-08-21T17:45:36.018340-06:00 hadron wicked[1419]: lo up 2020-08-21T17:45:36.018506-06:00 hadron wicked[1419]: eth0 up 2020-08-21T17:45:36.019048-06:00 hadron systemd[1]: Started wicked managed network interfaces.
That's nicer :-D Maybe there is a timing issue that makes the other lease appear or not. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
On 2020-08-22 12:13 p.m., Carlos E. R. wrote:
On 22/08/2020 19.46, Darryl Gregorash wrote:
On 2020-08-22 11:27 a.m., Per Jessen wrote:
Darryl Gregorash wrote:
Please recall that this problem has never occurred except during a reboot right after a kernel update. I have already rebooted once after my first post, and everything went fine. Do you wish to see the log from that boot?
It might be interesting to see, yes.
(With no apologies to Carlos for the line-wrap ;) )
Grr
0:)
2020-08-21T17:45:35.154532-06:00 hadron wickedd-dhcp4[1368]: eth0: Committed DHCPv4 lease with address 24.72.0.229 (lease time 172800 sec, renew in 86400 sec, rebind in 172500 sec) 2020-08-21T17:45:36.018340-06:00 hadron wicked[1419]: lo up 2020-08-21T17:45:36.018506-06:00 hadron wicked[1419]: eth0 up 2020-08-21T17:45:36.019048-06:00 hadron systemd[1]: Started wicked managed network interfaces.
That's nicer :-D Yes, and normal.
Maybe there is a timing issue that makes the other lease appear or not. I think that is what I have been saying -- the network interface is not yet properly set up.
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Sat, 22 Aug 2020 11:46:50 -0600 Darryl Gregorash <raven@accesscomm.ca> wrote:
(With no apologies to Carlos for the line-wrap ;) )
You can apologize to me instead then :) Please either get a mail client that can produce unwrapped messages, or learn how to use the appropriate facility in the one you do use, if it has them. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 22/08/2020 20.58, Dave Howorth wrote:
On Sat, 22 Aug 2020 11:46:50 -0600 Darryl Gregorash <raven@accesscomm.ca> wrote:
(With no apologies to Carlos for the line-wrap ;) )
You can apologize to me instead then :)
Please either get a mail client that can produce unwrapped messages, or learn how to use the appropriate facility in the one you do use, if it has them.
On Thunderbird: get "Toggle Word Wrap" addon by Jan Kisza. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
On 2020-08-22 2:34 p.m., Carlos E. R. wrote:
On 22/08/2020 20.58, Dave Howorth wrote:
On Sat, 22 Aug 2020 11:46:50 -0600 Darryl Gregorash <raven@accesscomm.ca> wrote:
(With no apologies to Carlos for the line-wrap ;) )
You can apologize to me instead then :)
Please either get a mail client that can produce unwrapped messages, or learn how to use the appropriate facility in the one you do use, if it has them.
On Thunderbird: get "Toggle Word Wrap" addon by Jan Kisza.
I do wish you'd sent that 5 minutes earlier ;) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 22/08/2020 22.43, Darryl Gregorash wrote:
On 2020-08-22 2:34 p.m., Carlos E. R. wrote:
On 22/08/2020 20.58, Dave Howorth wrote:
On Sat, 22 Aug 2020 11:46:50 -0600 Darryl Gregorash <> wrote:
(With no apologies to Carlos for the line-wrap ;) )
You can apologize to me instead then :)
Please either get a mail client that can produce unwrapped messages, or learn how to use the appropriate facility in the one you do use, if it has them.
On Thunderbird: get "Toggle Word Wrap" addon by Jan Kisza.
I do wish you'd sent that 5 minutes earlier ;)
Sorry! :-D I mention it everytime I have a chance, I use the feature a lot. But I can not make some lines long and have other wrapping - for that, I use Alpine instead. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
On 2020-08-22 12:58 p.m., Dave Howorth wrote:
On Sat, 22 Aug 2020 11:46:50 -0600 Darryl Gregorash <raven@accesscomm.ca> wrote:
(With no apologies to Carlos for the line-wrap ;) )
You can apologize to me instead then :)
Please either get a mail client that can produce unwrapped messages, or learn how to use the appropriate facility in the one you do use, if it has them.
Please be so kind as to explain how to do that in Thunderbird -- going into "about:config" every time I "need" to send a long line is not an option. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Sat, 22 Aug 2020 14:41:50 -0600 Darryl Gregorash <raven@accesscomm.ca> wrote:
On 2020-08-22 12:58 p.m., Dave Howorth wrote:
On Sat, 22 Aug 2020 11:46:50 -0600 Darryl Gregorash <raven@accesscomm.ca> wrote:
(With no apologies to Carlos for the line-wrap ;) )
You can apologize to me instead then :)
Please either get a mail client that can produce unwrapped messages, or learn how to use the appropriate facility in the one you do use, if it has them.
Please be so kind as to explain how to do that in Thunderbird -- going into "about:config" every time I "need" to send a long line is not an option.
I see that Carlos already answered your question, but why on earth do you think it is reasonable to ask me to learn anything about the MUA that YOU choose to use? I know mine can handle it; that's enough for me. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 22/08/2020 23.23, Dave Howorth wrote:
On Sat, 22 Aug 2020 14:41:50 -0600 Darryl Gregorash <raven@accesscomm.ca> wrote:
On 2020-08-22 12:58 p.m., Dave Howorth wrote:
On Sat, 22 Aug 2020 11:46:50 -0600 Darryl Gregorash <raven@accesscomm.ca> wrote:
(With no apologies to Carlos for the line-wrap ;) )
You can apologize to me instead then :)
Please either get a mail client that can produce unwrapped messages, or learn how to use the appropriate facility in the one you do use, if it has them.
Please be so kind as to explain how to do that in Thunderbird -- going into "about:config" every time I "need" to send a long line is not an option.
I see that Carlos already answered your question, but why on earth do you think it is reasonable to ask me to learn anything about the MUA that YOU choose to use? I know mine can handle it; that's enough for me.
Well, I have been fighting the need for long lines in Thunderbird for almost two decades without finding a solution. Someone told me how to do it perhaps four years ago. It is not well known. It is not a feature of Thunderbird. It is an obscure addon. You can consider the question rhetorical: I do it this way because I don't know how to do it differently. Often good software has some wrong features. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
On 22/08/2020 19.27, Per Jessen wrote:
Darryl Gregorash wrote:
On 2020-08-22 7:13 a.m., Per Jessen wrote:
Darryl Gregorash wrote:
Except 192.168.100.1 is my cable modem, and it certainly does not have a DHCP server in it. I ave never seen that IP appear in my logs before, except the last 2 reboots.
Something on your network provides a DHCP service, using a range of 192.168.100.[2-254] The actual range is a guess, but it's quite typical for an access modem to be 192.168.x.1, run a DHCP server and advertise itself as the default gateway. It does seem quite likely that your cable modem has a DHCP server.
As Carlos points out, 20sec is a very short lease - I don't know what the idea of that might be.
I just spoke with the ISP, and the modem does not have a DHCP server in it. It would make no sense for it to have a DHCP server unless it was a router, which it is not.
Okay - I wonder what kind of setup you have, but I am not really familiar with the "cable modem" expression. If your cable modem is _not_ a router, your home network is directly connected to the overall telco/cable network. Unless the next uplevel switch is using vlans, all of your neighbours can listen in on what you're doing.
Maybe, maybe not. Each client may effectively connected upstream with a different fibre cable, to a switch at the ISP (or at the curb). The switch can isolate clients from one another.
As far as I am concerned, 192.168.100.11 is being assigned by the OS, because the DHCP request has failed (timed out), on account of a network interface that has not been properly initialized.
No, that would be the OS rolling a pair of dice. Why not 10.1.2.3 or 172.16.45.67 ? or 185.84.248.1 ? iow, where does that number come from?
Something is assigning that short lived 192.168.100.11 address. Mark idea might be it. Otherwise, it would be the oS machine which has a dhcp server running. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
On 2020-08-21 7:29 a.m., Darryl Gregorash wrote:
The last two times my system has been rebooted, it failed to start the network service. I had to do a manual restart to get internet service. I have no idea where to look to correct the problem.
I should have pointed out that the last time this happened (and maybe the first time also), I had just rebooted after a kernel update. A few minutes ago, I rebooted again, and obtained a proper DHCP lease from my ISP -- no manual network restart required. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 8/21/20 7:41 PM, Darryl Gregorash wrote:
A few minutes ago, I rebooted again, and obtained a proper DHCP lease from my ISP -- no manual network restart required.
Oh, You don't have a router between you and your ISP? Even an $50 cheapo wireless router will provide a constant IP on your home side of the network that will not be impacted by reboots -- and all do dhcp as well. (though if you have a 10 year old 64-bit dell box in the closet, I'd encourage you to set that up as a dhcp and nameserver for your local network - a raspberry PI works fine for that too. A 35 year old 386/25 is more than enough power for dhcp/dns -- if the capacitors are still good :) Whatever you do, if you can, put a routing device between you and your ISP that will maintain the IP from your ISP and serve as a gateway for your home network -- solves many, many problems... -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 8/21/20 9:25 PM, David C. Rankin wrote:
Whatever you do, if you can, put a routing device between you and your ISP that will maintain the IP from your ISP and serve as a gateway for your home network -- solves many, many problems...
But he might no longer have a public address on that box. BTW, I used to use Suse for my firewall¹. What should I have put in front of it, when it was already my firewall/router? 1. I changed to pfSense, as Suse couldn't handle DHCPv6-PD. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 8/21/20 8:31 PM, James Knott wrote:
On 8/21/20 9:25 PM, David C. Rankin wrote:
Whatever you do, if you can, put a routing device between you and your ISP that will maintain the IP from your ISP and serve as a gateway for your home network -- solves many, many problems...
But he might no longer have a public address on that box. BTW, I used to use Suse for my firewall¹. What should I have put in front of it, when it was already my firewall/router?
1. I changed to pfSense, as Suse couldn't handle DHCPv6-PD.
No, no, There are many ways to do it and all are fine. What I understood was the problem was the loss of IP and replacement of public IP on reboot for kernel update. Whether you use a suse box as a firewall/router or a piece of hardware (both have pluses and minuses), if the problem was the IP handed out by the ISP on reboot -- then putting something between the network and ISP that doesn't have as frequent kernel updates will help (of course you have to question the security of the kernel it is running then....) -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 8/21/20 9:48 PM, David C. Rankin wrote:
1. I changed to pfSense, as Suse couldn't handle DHCPv6-PD.
No, no,
There are many ways to do it and all are fine. What I understood was the problem was the loss of IP and replacement of public IP on reboot for kernel update. Whether you use a suse box as a firewall/router or a piece of hardware (both have pluses and minuses), if the problem was the IP handed out by the ISP on reboot -- then putting something between the network and ISP that doesn't have as frequent kernel updates will help (of course you have to question the security of the kernel it is running then....)
With my ISP, my address is so stable it's virtually static. It only changes if I change hardware. Regardless, pfSense also gets updates, though not as frequent as OpenSUSE. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2020-08-21 7:25 p.m., David C. Rankin wrote:
On 8/21/20 7:41 PM, Darryl Gregorash wrote:
A few minutes ago, I rebooted again, and obtained a proper DHCP lease from my ISP -- no manual network restart required.
Oh,
You don't have a router between you and your ISP? Even an $50 cheapo wireless router will provide a constant IP on your home side of the network that will not be impacted by reboots -- and all do dhcp as well.
No, it's a cable modem. It has never given me any problem in the past, and AFAIK I have only seen this after a reboot due to a kernel update. Might it have something to do with the fact that now, for the first time, I am booting from a UEFI setup rather than a BIOS setup?
Whatever you do, if you can, put a routing device between you and your ISP that will maintain the IP from your ISP and serve as a gateway for your home network -- solves many, many problems...
That will not work, if this is a problem of the network service (wicked) being started before the network card has been properly initialized. I cannot see in the log files whether or not this is the case (I really don't know what to look for). -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 22/08/2020 04.37, Darryl Gregorash wrote:
On 2020-08-21 7:25 p.m., David C. Rankin wrote:
On 8/21/20 7:41 PM, Darryl Gregorash wrote:
Whatever you do, if you can, put a routing device between you and your ISP that will maintain the IP from your ISP and serve as a gateway for your home network -- solves many, many problems...
That will not work, if this is a problem of the network service (wicked) being started before the network card has been properly initialized. I cannot see in the log files whether or not this is the case (I really don't know what to look for).
grep wicked /var/log/messages | less -S Then use "search" (?/) to find "dhcp" entries. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
On 2020-08-22 3:19 a.m., Carlos E. R. wrote:
On 22/08/2020 04.37, Darryl Gregorash wrote:
On 2020-08-21 7:25 p.m., David C. Rankin wrote:
On 8/21/20 7:41 PM, Darryl Gregorash wrote:
Whatever you do, if you can, put a routing device between you and your ISP that will maintain the IP from your ISP and serve as a gateway for your home network -- solves many, many problems...
That will not work, if this is a problem of the network service (wicked) being started before the network card has been properly initialized. I cannot see in the log files whether or not this is the case (I really don't know what to look for).
grep wicked /var/log/messages | less -S
Then use "search" (?/) to find "dhcp" entries.
That is all in the first post in this thread, Carlos. Do you wish me to post what a normal reboot looks like? That's easy, it looks just like what happened when I issued the 'rcnetwork restart' command. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 8/21/20 9:29 AM, Darryl Gregorash wrote:
The last two times my system has been rebooted, it failed to start the network service. I had to do a manual restart to get internet service. I have no idea where to look to correct the problem.
Did it actually fail? Or was it a DHCP problem as you seem to imply later? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2020-08-21 7:33 p.m., James Knott wrote:
On 8/21/20 9:29 AM, Darryl Gregorash wrote:
The last two times my system has been rebooted, it failed to start the network service. I had to do a manual restart to get internet service. I have no idea where to look to correct the problem.
Did it actually fail? Or was it a DHCP problem as you seem to imply later?
I would have to say that it appears the network service was started before the network card was properly initialized. See also my reply to David re: UEFI. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 22/08/2020 03.33, James Knott wrote:
On 8/21/20 9:29 AM, Darryl Gregorash wrote:
The last two times my system has been rebooted, it failed to start the network service. I had to do a manual restart to get internet service. I have no idea where to look to correct the problem.
Did it actually fail? Or was it a DHCP problem as you seem to imply later?
IMHO, it is a dhcp problem. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
participants (8)
-
Andrei Borzenkov -
Carlos E. R. -
Darryl Gregorash -
Dave Howorth -
David C. Rankin -
James Knott -
Mark Petersen -
Per Jessen