[opensuse] DHCP lease requests
Hi Folks, I noticed that 12.1 seems to have changed DHCP behavior where a new lease is not requested when the network interface is brought up. This manifests itself when an Ethernet cable is moved from one network to another. The DHCP-obtained parameters, including IP address, netmask and default gateway, "stick". The configuration persists through reboots and manually bouncing the network. Yesterday the only way I could get it to reset was to remove the lease files in /var/lib/dhcpd, then bounce the network. This behavior is new to 12.1, has anyone else noticed it? How can we tell the DHCP client to re-obtain a lease when its interface is brought up? This behavior noticed on more than one install of x86-64. Thanks, Lew -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Lew Wolfgang wrote:
Hi Folks,
I noticed that 12.1 seems to have changed DHCP behavior where a new lease is not requested when the network interface is brought up. This manifests itself when an Ethernet cable is moved from one network to another. The DHCP-obtained parameters, including IP address, netmask and default gateway, "stick". The configuration persists through reboots and manually bouncing the network. Yesterday the only way I could get it to reset was to remove the lease files in /var/lib/dhcpd, then bounce the network.
On a reboot dhcpcd has to be started, so check to see what is happening at that point.
This behavior is new to 12.1, has anyone else noticed it? How can we tell the DHCP client to re-obtain a lease when its interface is brought up? This behavior noticed on more than one install of x86-64.
I have just checked the dhcp behaviour on my 12.1 laptop - nothing unusual, works just like before. (grep dhcp /var/log/messages). -- Per Jessen, Zürich (6.1°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 01/05/2012 04:31 AM, Per Jessen pecked at the keyboard and wrote:
Lew Wolfgang wrote:
Hi Folks,
I noticed that 12.1 seems to have changed DHCP behavior where a new lease is not requested when the network interface is brought up. This manifests itself when an Ethernet cable is moved from one network to another. The DHCP-obtained parameters, including IP address, netmask and default gateway, "stick". The configuration persists through reboots and manually bouncing the network. Yesterday the only way I could get it to reset was to remove the lease files in /var/lib/dhcpd, then bounce the network.
On a reboot dhcpcd has to be started, so check to see what is happening at that point.
This behavior is new to 12.1, has anyone else noticed it? How can we tell the DHCP client to re-obtain a lease when its interface is brought up? This behavior noticed on more than one install of x86-64.
I have just checked the dhcp behaviour on my 12.1 laptop - nothing unusual, works just like before. (grep dhcp /var/log/messages).
But did you move from one place to another that has a different address space? If the OP is using ifup you might want to try using NetworkManager instead. -- Ken Schneider SuSe since Version 5.2, June 1998 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Ken Schneider - openSUSE wrote:
On 01/05/2012 04:31 AM, Per Jessen pecked at the keyboard and wrote:
Lew Wolfgang wrote:
Hi Folks,
I noticed that 12.1 seems to have changed DHCP behavior where a new lease is not requested when the network interface is brought up. This manifests itself when an Ethernet cable is moved from one network to another. The DHCP-obtained parameters, including IP address, netmask and default gateway, "stick". The configuration persists through reboots and manually bouncing the network. Yesterday the only way I could get it to reset was to remove the lease files in /var/lib/dhcpd, then bounce the network.
On a reboot dhcpcd has to be started, so check to see what is happening at that point.
This behavior is new to 12.1, has anyone else noticed it? How can we tell the DHCP client to re-obtain a lease when its interface is brought up? This behavior noticed on more than one install of x86-64.
I have just checked the dhcp behaviour on my 12.1 laptop - nothing unusual, works just like before. (grep dhcp /var/log/messages).
But did you move from one place to another that has a different address space?
No, I didn't try that, but if the dhcp obtained settings were not renewed on reboot, that might be a place to investigate.
If the OP is using ifup you might want to try using NetworkManager instead.
I guess, although it wouldn't change the issue much, would it? -- Per Jessen, Zürich (7.7°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 01/05/2012 07:20 AM, Per Jessen wrote:
Ken Schneider - openSUSE wrote:
On 01/05/2012 04:31 AM, Per Jessen pecked at the keyboard and wrote:
Lew Wolfgang wrote:
Hi Folks,
I noticed that 12.1 seems to have changed DHCP behavior where a new lease is not requested when the network interface is brought up. This manifests itself when an Ethernet cable is moved from one network to another. The DHCP-obtained parameters, including IP address, netmask and default gateway, "stick". The configuration persists through reboots and manually bouncing the network. Yesterday the only way I could get it to reset was to remove the lease files in /var/lib/dhcpd, then bounce the network. On a reboot dhcpcd has to be started, so check to see what is happening at that point.
This behavior is new to 12.1, has anyone else noticed it? How can we tell the DHCP client to re-obtain a lease when its interface is brought up? This behavior noticed on more than one install of x86-64. I have just checked the dhcp behaviour on my 12.1 laptop - nothing unusual, works just like before. (grep dhcp /var/log/messages).
But did you move from one place to another that has a different address space? No, I didn't try that, but if the dhcp obtained settings were not renewed on reboot, that might be a place to investigate.
If the OP is using ifup you might want to try using NetworkManager instead. I guess, although it wouldn't change the issue much, would it?
I've noticed this behavior on two different installs. One was a laptop, the other a rack-mounted server. I assume the laptop was running NetworkManager. The behavior here was a lag in registering the new IP addresses, but it eventually locked in. Maybe a short lease? I'll look at the laptop again in more detail. But the server would have been running ifup. I don't have access to this box at this time, but I've got another 12.1 desktop that I can fiddle with. Regards, Lew -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Lew Wolfgang wrote:
But the server would have been running ifup. I don't have access to this box at this time, but I've got another 12.1 desktop that I can fiddle with.
I hope that plugging in the cable would cause a DHCP request, as I normally configure DHCP enabled systems that way. I currently have one 12.1 system here that's configured that way. I'll have to test it when I have some free time. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Per Jessen wrote:
On a reboot dhcpcd has to be started, so check to see what is happening at that point.
I think the idea is to have an immediate dhcp request when connecting to a network, which means dhcpcd should be restarted at that time. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 01/05/2012 08:26 AM, James Knott wrote:
Per Jessen wrote:
On a reboot dhcpcd has to be started, so check to see what is happening at that point.
I think the idea is to have an immediate dhcp request when connecting to a network, which means dhcpcd should be restarted at that time.
Right, but if there's a still-valid lease showing in /var/lib/dhcpcd it looks like the just-started dhcpcd doesn't request a new lease. At least this how it seemed to me, I was in a hurry. Regards, Lew -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Lew Wolfgang wrote:
On 01/05/2012 08:26 AM, James Knott wrote:
Per Jessen wrote:
On a reboot dhcpcd has to be started, so check to see what is happening at that point.
I think the idea is to have an immediate dhcp request when connecting to a network, which means dhcpcd should be restarted at that time.
Right, but if there's a still-valid lease showing in /var/lib/dhcpcd it looks like the just-started dhcpcd doesn't request a new lease. At least this how it seemed to me, I was in a hurry.
It would make sense for dhcpcd to re-request a still-valid lease, but if that is nack'ed by the dhcp server, dhcpcd will ask for a new suggestion. -- Per Jessen, Zürich (3.9°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Hi Folks, I've replicated the dhcpcd not getting a new lease on reboot/ifup, problem. This time on a desktop. I captured the dialogs below where we can see dhcpcd timing out after being run as a result of an if-up. But after the timeout, it checks to see if /var/lib/dhcpcd/ contains a valid lease. If it does, it uses that possibly invalid lease. If an old lease doesn't exist it broadcasts for a new one and all is then well. End result is the previous, and now possibly stale, dhcp lease being used. It even survives a complete reboot. This results in a dead network if subnets are changed. Removing /var/lib/dhcpcd/*, then rebooting or issuing /etc/init.d/network restart-all-dhcp-clients, will trigger a new lease broadcast and all is now well. This smells like a feature, intended to quicken the boot process, run amok. Regards, Lew Here's the spoor. IP address have been munged to protect the innocent. Unplugged Ethernet cable from a 192.168.1.0/24 subnet, then plugging into a full-up IPv4/IPv6 enabled network. Jan 5 13:13:09 ironhead kernel: [ 2652.274937] r8169 0000:03:00.0: eth0: link down Jan 5 13:13:14 ironhead kernel: [ 2657.525632] r8169 0000:03:00.0: eth0: link up ifconfig now showed the old 192.168.1.2 address, but did pick up the new IPv6 address. /var/lib/dhcpcd shows: -rw-r--r-- 1 root root 357 Jan 5 12:29 dhcpcd-eth0.info -rw-r--r-- 1 root root 0 Jan 5 13:31 dhcpcd-eth0.timestamp with dhcpcd-eth0.info containing: IPADDR='192.168.1.2' NETMASK='255.255.255.0' NETWORK='192.168.1.0' BROADCAST='192.168.1.255' ROUTES='' GATEWAYS='192.168.1.1' DNSSERVERS='192.168.1.1' DHCPSID='192.168.1.1' LEASEDFROM='1325795365' LEASETIME='86400' RENEWALTIME='43200' REBINDTIME='73440' INTERFACE='eth0' CLASSID='dhcpcd 3.2.3' CLIENTID='01:00:24:e8:08:00:43' DHCPCHADDR='00:24:e8:08:00:43' I then issued: /etc/init.d/network restart messages: Jan 5 13:44:51 ironhead network[4962]: Hint: you may set mandatory devices in /etc/sysconfig/network/config Jan 5 13:44:51 ironhead network[4962]: Setting up network interfaces: Jan 5 13:44:51 ironhead network[4962]: eth0 device: Realtek Semiconductor Co., Ltd. RTL8111/8168B Jan 5 13:44:51 ironhead ifup: eth0 device: Realtek Semiconductor Co., Ltd. RTL8111/8168B Jan 5 13:44:51 ironhead network[4962]: eth0 DHCP4 client is already running Jan 5 13:44:51 ironhead ifup-dhcp: eth0 DHCP4 client is already running Jan 5 13:44:51 ironhead network[4962]: eth0 IP address: 192.168.1.2/24 Jan 5 13:44:51 ironhead ifup-dhcp: eth0 IP address: 192.168.1.2/24 Jan 5 13:44:51 ironhead network[4962]: ..doneSetting up service network . . . . . . . . . .. done Jan 5 13:44:51 ironhead SuSEfirewall2: Setting up rules from /etc/sysconfig/SuSEfirewall2 ... Jan 5 13:44:51 ironhead SuSEfirewall2: Firewall rules successfully set I tried: /etc/init.d/network restart-all-dhcp-clients in messages: Jan 5 13:47:09 ironhead ifdown: eth0 device: Realtek Semiconductor Co., Ltd. RTL8111/8168B Jan 5 13:47:09 ironhead dhcpcd[5763]: eth0: sending signal 15 to pid 4325 Jan 5 13:47:09 ironhead dhcpcd[5763]: eth0: exiting Jan 5 13:47:09 ironhead dhcpcd[4325]: eth0: received SIGTERM, stopping Jan 5 13:47:09 ironhead dhcpcd[4325]: eth0: removing default route via 192.168.1.1 metric 0 Jan 5 13:47:09 ironhead dhcpcd[4325]: eth0: removing IP address 192.168.1.2/24 Jan 5 13:47:09 ironhead avahi-daemon[917]: Withdrawing address record for 192.168.1.2 on eth0. Jan 5 13:47:09 ironhead avahi-daemon[917]: Leaving mDNS multicast group on interface eth0.IPv4 with address 192.168.1.2. Jan 5 13:47:09 ironhead avahi-daemon[917]: Interface eth0.IPv4 no longer relevant for mDNS. Jan 5 13:47:09 ironhead dhcpcd[4325]: eth0: exiting Jan 5 13:47:10 ironhead network[5857]: Shutting down network interfaces: Jan 5 13:47:10 ironhead network[5857]: eth0 device: Realtek Semiconductor Co., Ltd. RTL8111/8168B Jan 5 13:47:10 ironhead ifdown: eth0 device: Realtek Semiconductor Co., Ltd. RTL8111/8168B Jan 5 13:47:10 ironhead dhcpcd[6127]: eth0: dhcpcd not running Jan 5 13:47:10 ironhead dhcpcd[6127]: eth0: exiting Jan 5 13:47:10 ironhead avahi-daemon[917]: Withdrawing address record for XXXX:XXX:XX:44:f92a:9373:e88a:923b on eth0. Jan 5 13:47:10 ironhead avahi-daemon[917]: Withdrawing address record for XXXX:XXX:XX:44:224:e8ff:fe08:43 on eth0. Jan 5 13:47:10 ironhead avahi-daemon[917]: Registering new address record for fe80::224:e8ff:fe08:43 on eth0.*. Jan 5 13:47:10 ironhead avahi-daemon[917]: Withdrawing address record for fe80::224:e8ff:fe08:43 on eth0. Jan 5 13:47:10 ironhead ifup: eth0 device: Realtek Semiconductor Co., Ltd. RTL8111/8168B Jan 5 13:47:11 ironhead kernel: [ 938.173492] r8169 0000:03:00.0: eth0: link down Jan 5 13:47:11 ironhead kernel: [ 938.173498] r8169 0000:03:00.0: eth0: link down Jan 5 13:47:11 ironhead kernel: [ 938.173808] ADDRCONF(NETDEV_UP): eth0: link is not ready Jan 5 13:47:11 ironhead ifup-dhcp: eth0 Starting DHCP4 client Jan 5 13:47:11 ironhead dhcpcd[6530]: eth0: dhcpcd 3.2.3 starting Jan 5 13:47:11 ironhead dhcpcd[6530]: eth0: hardware address = 00:24:e8:08:00:43 Jan 5 13:47:11 ironhead dhcpcd[6530]: eth0: broadcasting for a lease Jan 5 13:47:11 ironhead ifup-dhcp: . Jan 5 13:47:11 ironhead network[5857]: ..doneShutting down service network . . . . . . . . ...done Jan 5 13:47:12 ironhead kernel: [ 940.037464] show_signal_msg: 48 callbacks suppressed Jan 5 13:47:12 ironhead kernel: [ 940.037468] ntpd[4200]: segfault at 8 ip 00007f4822a31dee sp 00007fffeac10130 error 4 in ntpd[7f4822a15000+a1000] Jan 5 13:47:13 ironhead ifup-dhcp: . Jan 5 13:47:13 ironhead kernel: [ 940.669389] r8169 0000:03:00.0: eth0: link up Jan 5 13:47:13 ironhead kernel: [ 940.669827] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready Jan 5 13:47:14 ironhead avahi-daemon[917]: Registering new address record for fe80::224:e8ff:fe08:43 on eth0.*. Jan 5 13:47:15 ironhead ifup-dhcp: . Jan 5 13:47:17 ironhead ifup-dhcp: . Jan 5 13:47:20 ironhead ifup-dhcp: . Jan 5 13:47:22 ironhead ifup-dhcp: . Jan 5 13:47:24 ironhead avahi-daemon[917]: Registering new address record for XXXX:XXX:XX:44:f89a:27d4:eb7d:b86 on eth0.*. Jan 5 13:47:24 ironhead avahi-daemon[917]: Withdrawing address record for fe80::224:e8ff:fe08:43 on eth0. Jan 5 13:47:24 ironhead ifup-dhcp: . Jan 5 13:47:24 ironhead avahi-daemon[917]: Registering new address record for XXXX:XXX:XX:44:224:e8ff:fe08:43 on eth0.*. Jan 5 13:47:26 ironhead ifup-dhcp: . Jan 5 13:47:27 ironhead ifup-dhcp: Jan 5 13:47:27 ironhead ifup-dhcp: eth0 DHCP4 continues in background Jan 5 13:47:31 ironhead dhcpcd[6530]: eth0: timed out Jan 5 13:47:31 ironhead dhcpcd[6530]: eth0: trying to use old lease in `/var/lib/dhcpcd/dhcpcd-eth0.info' Jan 5 13:47:31 ironhead dhcpcd[6530]: eth0: adding IP address 192.168.1.2/24 Jan 5 13:47:31 ironhead dhcpcd[6530]: eth0: adding default route via 192.168.1.1 metric 0 Jan 5 13:47:31 ironhead avahi-daemon[917]: Joining mDNS multicast group on interface eth0.IPv4 with address 192.168.1.2. Jan 5 13:47:31 ironhead avahi-daemon[917]: New relevant interface eth0.IPv4 for mDNS. Jan 5 13:47:31 ironhead avahi-daemon[917]: Registering new address record for 192.168.1.2 on eth0.IPv4. Jan 5 13:47:31 ironhead ifdown: eth0 device: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 02) Jan 5 13:47:31 ironhead rsyslogd: [origin software="rsyslogd" swVersion="5.8.5" x-pid="901" x-info="http://www.rsyslog.com"] rsyslogd was HUPed Jan 5 13:47:31 ironhead ifup: eth0 device: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 02) Jan 5 13:47:31 ironhead SuSEfirewall2: /var/lock/SuSEfirewall2.booting exists which means system boot in progress, exit. Jan 5 13:47:31 ironhead dhcpcd[6530]: eth0: exiting Jan 5 13:47:40 ironhead ntp[7833]: Shutting down network time protocol daemon (NTPD)..done Jan 5 13:47:40 ironhead dbus-daemon[958]: **** /proc/self/mountinfo changed Removing /var/lib/dhcpcd/*, then doing another /etc/init.d/network restart-all-dhcp-clients gives us this: Jan 5 13:58:32 ironhead ifdown: eth0 device: Realtek Semiconductor Co., Ltd. RTL8111/8168B Jan 5 13:58:32 ironhead dhcpcd[8161]: eth0: sending signal 15 to pid 7831 Jan 5 13:58:32 ironhead dhcpcd[8161]: eth0: exiting Jan 5 13:58:32 ironhead dhcpcd[7831]: eth0: received SIGTERM, stopping Jan 5 13:58:32 ironhead dhcpcd[7831]: eth0: removing default route via 192.168.1.1 metric 0 Jan 5 13:58:32 ironhead dhcpcd[7831]: eth0: removing IP address 192.168.1.2/24 Jan 5 13:58:32 ironhead avahi-daemon[917]: Withdrawing address record for 192.168.1.2 on eth0. Jan 5 13:58:32 ironhead avahi-daemon[917]: Leaving mDNS multicast group on interface eth0.IPv4 with address 192.168.1.2. Jan 5 13:58:32 ironhead avahi-daemon[917]: Interface eth0.IPv4 no longer relevant for mDNS. Jan 5 13:58:32 ironhead dhcpcd-hook: /var/lib/dhcpcd/dhcpcd-eth0.info does not exist. Skipping 'ifdown -o dhcp' call Jan 5 13:58:32 ironhead dhcpcd[7831]: eth0: exiting Jan 5 13:58:33 ironhead avahi-daemon[917]: Withdrawing address record for XXXX:XXX:XX:44:f89a:27d4:eb7d:b86 on eth0. Jan 5 13:58:33 ironhead avahi-daemon[917]: Withdrawing address record for XXXX:XXX:XX:44:224:e8ff:fe08:43 on eth0. Jan 5 13:58:33 ironhead avahi-daemon[917]: Registering new address record for fe80::224:e8ff:fe08:43 on eth0.*. Jan 5 13:58:33 ironhead avahi-daemon[917]: Withdrawing address record for fe80::224:e8ff:fe08:43 on eth0. Jan 5 13:58:33 ironhead ifup: eth0 device: Realtek Semiconductor Co., Ltd. RTL8111/8168B Jan 5 13:58:33 ironhead kernel: [ 1620.688618] r8169 0000:03:00.0: eth0: link down Jan 5 13:58:33 ironhead kernel: [ 1620.688624] r8169 0000:03:00.0: eth0: link down Jan 5 13:58:33 ironhead kernel: [ 1620.688921] ADDRCONF(NETDEV_UP): eth0: link is not ready Jan 5 13:58:33 ironhead ifup-dhcp: eth0 Starting DHCP4 client Jan 5 13:58:33 ironhead dhcpcd[8502]: eth0: dhcpcd 3.2.3 starting Jan 5 13:58:33 ironhead dhcpcd[8502]: eth0: hardware address = 00:24:e8:08:00:43 Jan 5 13:58:33 ironhead dhcpcd[8502]: eth0: broadcasting for a lease Jan 5 13:58:33 ironhead ifup-dhcp: . Jan 5 13:58:35 ironhead ifup-dhcp: . Jan 5 13:58:36 ironhead kernel: [ 1623.129461] r8169 0000:03:00.0: eth0: link up Jan 5 13:58:36 ironhead kernel: [ 1623.129795] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready Jan 5 13:58:37 ironhead avahi-daemon[917]: Registering new address record for fe80::224:e8ff:fe08:43 on eth0.*. Jan 5 13:58:38 ironhead ifup-dhcp: . Jan 5 13:58:40 ironhead ifup-dhcp: . Jan 5 13:58:42 ironhead ifup-dhcp: . Jan 5 13:58:44 ironhead ifup-dhcp: . Jan 5 13:58:46 ironhead kernel: [ 1633.698012] eth0: no IPv6 routers present Jan 5 13:58:46 ironhead ifup-dhcp: . Jan 5 13:58:48 ironhead kernel: [ 1635.308581] martian source 255.255.255.255 from XXX.XXX.44.11, on dev eth0 Jan 5 13:58:48 ironhead kernel: [ 1635.308584] ll header: ff:ff:ff:ff:ff:ff:00:24:e8:0d:ee:63:08:00 Jan 5 13:58:49 ironhead ifup-dhcp: . Jan 5 13:58:50 ironhead ifup-dhcp: Jan 5 13:58:50 ironhead ifup-dhcp: eth0 DHCP4 continues in background Jan 5 13:58:50 ironhead SuSEfirewall2: Setting up rules from /etc/sysconfig/SuSEfirewall2 ... Jan 5 13:58:50 ironhead SuSEfirewall2: Firewall rules successfully set Jan 5 13:58:53 ironhead dhcpcd[8502]: eth0: timed out Jan 5 13:58:53 ironhead dhcpcd[8502]: eth0: trying to use old lease in `/var/lib/dhcpcd/dhcpcd-eth0.info' Jan 5 13:58:53 ironhead dhcpcd[8502]: eth0: lease information file `/var/lib/dhcpcd/dhcpcd-eth0.info' does not exist Jan 5 13:58:53 ironhead dhcpcd[8502]: eth0: broadcasting for a lease Jan 5 13:58:53 ironhead dhcpcd[8502]: eth0: offered XXX.XXX.44.20 from XXX.XXX.4.2 Jan 5 13:58:53 ironhead dhcpcd[8502]: eth0: checking XXX.XXX.44.20 is available on attached networks Jan 5 13:58:54 ironhead dhcpcd[8502]: eth0: leased XXX.XXX.44.20 for 3600 seconds Jan 5 13:58:54 ironhead dhcpcd[8502]: eth0: adding IP address XXX.XXX.44.20/24 Jan 5 13:58:54 ironhead dhcpcd[8502]: eth0: adding default route via XXX.XXX.44.1 metric 0 Jan 5 13:58:54 ironhead avahi-daemon[917]: Joining mDNS multicast group on interface eth0.IPv4 with address XXX.XXX.44.20. Jan 5 13:58:54 ironhead avahi-daemon[917]: New relevant interface eth0.IPv4 for mDNS. Jan 5 13:58:54 ironhead avahi-daemon[917]: Registering new address record for XXX.XXX.44.20 on eth0.IPv4. Jan 5 13:58:54 ironhead ifdown: eth0 device: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 02) Jan 5 13:58:54 ironhead ifup: eth0 device: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 02) Jan 5 13:58:55 ironhead SuSEfirewall2: Setting up rules from /etc/sysconfig/SuSEfirewall2 ... Jan 5 13:58:55 ironhead SuSEfirewall2: Firewall rules successfully set Jan 5 13:58:55 ironhead dhcpcd[8502]: eth0: exiting Now we can see dhcpcd broadcasting for a new lease and all is well. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 01/05/2012 08:34 AM, Lew Wolfgang wrote:
On 01/05/2012 08:26 AM, James Knott wrote:
Per Jessen wrote:
On a reboot dhcpcd has to be started, so check to see what is happening at that point.
I think the idea is to have an immediate dhcp request when connecting to a network, which means dhcpcd should be restarted at that time.
Right, but if there's a still-valid lease showing in /var/lib/dhcpcd it looks like the just-started dhcpcd doesn't request a new lease. At least this how it seemed to me, I was in a hurry.
OK, I confirmed the behavior on another 12.1 x86-64 desktop. I started the system with eth0 connected to a router which assigned a DHCP address of 192.168.1.2. I then unplugged the cable and connected to a fully up and running network. ifconfig showed the old, and now stale, IP address. /var/log/messages showed a "link down", then a "link up" message without re-running dhcpcd. I then issued a "/etc/init.d/network restart" which didn't help. Messages showed an entry from ifup-dhcp saying the "client is already running" and repeated the old IP address. So I then issued a "/etc/init.d/network restart-all-dhcp-clients". This option did a lot more as reflected in messages, but it still didn't renew the DHCP lease. It started dhcpcd but put it in background, then dhcpcd reported "eth0 timed out". At this point it tried to "use old lease in `/var/lib/dhcpcd/dhcpcd-eth0.info'", which still contained the old lease info, and proceeded to reuse the old lease without broadcasting for a new one. I then removed the lease files in /var/lib/dhcpcd/ and re-ran /etc/init.d/network restart-all-dhcp-clients. Now dhcpcd says the lease information file does not exist and proceeds to broadcast for a new lease. Now it works! So I see two issues: 1. dhcpcd doesn't seem to be tickled by the interface going down, then up (cable swap). 2. When dhcpcd does start/restart, it doesn't broadcast for a new lease if an old one exists. This sounds like a "feature" to streamline the boot process that turned into a bug. Regards, Lew -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Lew Wolfgang wrote:
On 01/05/2012 08:34 AM, Lew Wolfgang wrote:
On 01/05/2012 08:26 AM, James Knott wrote:
Per Jessen wrote:
On a reboot dhcpcd has to be started, so check to see what is happening at that point.
I think the idea is to have an immediate dhcp request when connecting to a network, which means dhcpcd should be restarted at that time.
Right, but if there's a still-valid lease showing in /var/lib/dhcpcd it looks like the just-started dhcpcd doesn't request a new lease. At least this how it seemed to me, I was in a hurry.
OK, I confirmed the behavior on another 12.1 x86-64 desktop.
I started the system with eth0 connected to a router which assigned a DHCP address of 192.168.1.2. I then unplugged the cable and connected to a fully up and running network. ifconfig showed the old, and now stale, IP address. /var/log/messages showed a "link down", then a "link up" message without re-running dhcpcd.
I then issued a "/etc/init.d/network restart" which didn't help. Messages showed an entry from ifup-dhcp saying the "client is already running" and repeated the old IP address.
I don't know the exact semantics of "rcnetwork restart" - it might make sense to expect dhcpcd to renew leases (dhcpcd -n).
So I then issued a "/etc/init.d/network restart-all-dhcp-clients". This option did a lot more as reflected in messages, but it still didn't renew the DHCP lease. It started dhcpcd but put it in background, then dhcpcd reported "eth0 timed out". At this point it tried to "use old lease in /var/lib/dhcpcd/dhcpcd-eth0.info'", which still contained the old lease info, and proceeded to reuse the old lease without broadcasting for a new one.
It must have done a broadcast, otherwise why would it report "eth0 timed out"? Following a time-out, it seems reasonable to attempt a fall-back to the previous lease.
I then removed the lease files in /var/lib/dhcpcd/ and re-ran /etc/init.d/network restart-all-dhcp-clients. Now dhcpcd says the lease information file does not exist and proceeds to broadcast for a new lease. Now it works!
The key question would appear to be - what caused the time-out on the first attempt?
So I see two issues:
1. dhcpcd doesn't seem to be tickled by the interface going down, then up (cable swap).
If it worked in a previous release, it sounds like a bug.
2. When dhcpcd does start/restart, it doesn't broadcast for a new lease if an old one exists.
Mine does. It requests the still-valid lease, and will reuse that one only if ack'ed by the dhcp server. If nack'ed, it'll broadcast for a new one. -- Per Jessen, Zürich (3.1°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Per Jessen wrote:
So I then issued a "/etc/init.d/network restart-all-dhcp-clients". This option did a lot more as reflected in messages, but it still didn't renew the DHCP lease. It started dhcpcd but put it in background, then dhcpcd reported "eth0 timed out". At this point it tried to "use old lease in /var/lib/dhcpcd/dhcpcd-eth0.info'", which still contained the old lease info, and proceeded to reuse the old lease without broadcasting for a new one.
It must have done a broadcast, otherwise why would it report "eth0 timed out"? Following a time-out, it seems reasonable to attempt a fall-back to the previous lease.
In the logs you posted, there is a 20 second span between broadcast and time-out: Jan 5 13:47:11 ironhead dhcpcd[6530]: eth0: broadcasting for a lease Jan 5 13:47:27 ironhead ifup-dhcp: eth0 DHCP4 continues in background Jan 5 13:47:31 ironhead dhcpcd[6530]: eth0: timed out Jan 5 13:47:31 ironhead dhcpcd[6530]: eth0: trying to use old lease in `/var/lib/dhcpcd/dhcpcd-eth0.info' Is there a problem with the DHCP server? If you check the server logs, you should see a complete trace of the negotation, but I guess the server isn't responding, hence the time-out. -- Per Jessen, Zürich (3.2°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 01/06/2012 03:25 AM, Per Jessen wrote:
Per Jessen wrote:
So I then issued a "/etc/init.d/network restart-all-dhcp-clients". This option did a lot more as reflected in messages, but it still didn't renew the DHCP lease. It started dhcpcd but put it in background, then dhcpcd reported "eth0 timed out". At this point it tried to "use old lease in /var/lib/dhcpcd/dhcpcd-eth0.info'", which still contained the old lease info, and proceeded to reuse the old lease without broadcasting for a new one. It must have done a broadcast, otherwise why would it report "eth0 timed out"? Following a time-out, it seems reasonable to attempt a fall-back to the previous lease. In the logs you posted, there is a 20 second span between broadcast and time-out:
Jan 5 13:47:11 ironhead dhcpcd[6530]: eth0: broadcasting for a lease Jan 5 13:47:27 ironhead ifup-dhcp: eth0 DHCP4 continues in background Jan 5 13:47:31 ironhead dhcpcd[6530]: eth0: timed out Jan 5 13:47:31 ironhead dhcpcd[6530]: eth0: trying to use old lease in `/var/lib/dhcpcd/dhcpcd-eth0.info'
Is there a problem with the DHCP server? If you check the server logs, you should see a complete trace of the negotation, but I guess the server isn't responding, hence the time-out.
Ah, good point about the timeout! The network is a large one, many thousands of hosts, and I don't have access to the server logs. But I know who does and will check with him today. I'll also try the switch in the opposite direction: from the big network to the natted side of a small router. There shouldn't be a timeout issue there. Regards, Lew -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Fri, Jan 6, 2012 at 11:36 AM, Lew Wolfgang <wolfgang@sweet-haven.com> wrote:
On 01/06/2012 03:25 AM, Per Jessen wrote:
Per Jessen wrote:
So I then issued a "/etc/init.d/network restart-all-dhcp-clients". This option did a lot more as reflected in messages, but it still didn't renew the DHCP lease. It started dhcpcd but put it in background, then dhcpcd reported "eth0 timed out". At this point it tried to "use old lease in /var/lib/dhcpcd/dhcpcd-eth0.info'", which still contained the old lease info, and proceeded to reuse the old lease without broadcasting for a new one.
It must have done a broadcast, otherwise why would it report "eth0 timed out"? Following a time-out, it seems reasonable to attempt a fall-back to the previous lease.
In the logs you posted, there is a 20 second span between broadcast and time-out:
Jan 5 13:47:11 ironhead dhcpcd[6530]: eth0: broadcasting for a lease Jan 5 13:47:27 ironhead ifup-dhcp: eth0 DHCP4 continues in background Jan 5 13:47:31 ironhead dhcpcd[6530]: eth0: timed out Jan 5 13:47:31 ironhead dhcpcd[6530]: eth0: trying to use old lease in `/var/lib/dhcpcd/dhcpcd-eth0.info'
Is there a problem with the DHCP server? If you check the server logs, you should see a complete trace of the negotation, but I guess the server isn't responding, hence the time-out.
Ah, good point about the timeout! The network is a large one, many thousands of hosts, and I don't have access to the server logs. But I know who does and will check with him today.
I'll also try the switch in the opposite direction: from the big network to the natted side of a small router. There shouldn't be a timeout issue there.
Regards, Lew
Lew, If it's that big of a network , then it may just have a issue building the spanning trees in the switches. One of my clients has 80 switches in a very disorganized way. Thus there are lots of routes from one place to another in there LAN. When they bring up a new machine and do dhcp, it takes about 45 seconds to get the new IP. I'm convinced most of the time is the switches playing games trying to figure out the most efficient way to connect the newly introduced machine to the dhcp server. Greg -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Greg Freemyer wrote:
When they bring up a new machine and do dhcp, it takes about 45 seconds to get the new IP. I'm convinced most of the time is the switches playing games trying to figure out the most efficient way to connect the newly introduced machine to the dhcp server.
Isn't that any easy problem to solve? Whichever switch the new machine is connected to just looks in its tables and asks "how did I send traffic to <the dhcp server> last time somebody asked me?" The answer doesn't depend in any way on there being a new machine. But I'm no expert, so perhaps I'll learn something! -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Fri, Jan 6, 2012 at 12:08 PM, Dave Howorth <dhoworth@mrc-lmb.cam.ac.uk> wrote:
Greg Freemyer wrote:
When they bring up a new machine and do dhcp, it takes about 45 seconds to get the new IP. I'm convinced most of the time is the switches playing games trying to figure out the most efficient way to connect the newly introduced machine to the dhcp server.
Isn't that any easy problem to solve? Whichever switch the new machine is connected to just looks in its tables and asks "how did I send traffic to <the dhcp server> last time somebody asked me?" The answer doesn't depend in any way on there being a new machine.
But I'm no expert, so perhaps I'll learn something!
In theory it could do that, but it doesn't seem to work out in practice. I don't know why in detail. === background for anyone interested At the switch level all communications is actually MAC to MAC, not IP to IP. So when you add a new machine to a LAN segment, the local switch network has to add your MAC to the tree-spanning tables which are maintained by all the switches. But when it does that, it makes a concerted effort to map your MAC to all the other MACs by the shortest path. If you have a class C (/24) then there aren't that many options so it takes no time to build the spanning tree. If you have a full class A (ie. /8 or 10.x.x.x) then you conceivably have 10's of thousands (or more) MACs to potentially keep up with and setup spanning trees for. In that case a haphazard interconnection of all the switches can cause loops which complicate the process of bringing up a new machine. The traditional solution is to introduce smaller lan segments and then have routers between the lan segments. ie. 10.0.0.x, 10.0.1.x, 10.0.2.x are all in use at my office and we have a routers setup that send traffic between those lan segments. You can get a cheap router these days, so it is not expensive to do that if it makes sense. But as I said, I have one client with 80 24-port switches in one huge lan segment. So that would be about 2000 ports / MAC addresses the switches have to map and track with various paths from one port to another. In their case it takes about 45 seconds to add a new machine (MAC) to the lan segment (switch network) and get a IP via DHCP. They are in the middle of new network design now to reduce that time significantly. Greg -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Greg Freemyer wrote:
If you have a full class A (ie. /8 or 10.x.x.x) then you conceivably have 10's of thousands (or more) MACs to potentially keep up with and setup spanning trees for.
Wait 'till you start working with IPv6 networks, where you can have up to 2^64 devices on a subnet! Of course, practical considerations may limit that somewhat. ;-) I have a /56 IPv6 subnet, which can be split into 256 /64 subnets. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Fri, Jan 6, 2012 at 1:48 PM, James Knott <james.knott@rogers.com> wrote:
Greg Freemyer wrote:
If you have a full class A (ie. /8 or 10.x.x.x) then you conceivably have 10's of thousands (or more) MACs to potentially keep up with and setup spanning trees for.
Wait 'till you start working with IPv6 networks, where you can have up to 2^64 devices on a subnet!
Of course, practical considerations may limit that somewhat. ;-)
I have a /56 IPv6 subnet, which can be split into 256 /64 subnets.
I'm a IPv6 neophyte, but I have wondered about that. Since IPv6 is 128 bits I think, a single /64 subnet is as big as the public facing Internet is today. (ie. Ignoring private IP space like 10.x.x.x). I have a hard time fathoming how something that big can be managed without some form of hierarchy. Greg -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Greg Freemyer wrote:
On Fri, Jan 6, 2012 at 1:48 PM, James Knott<james.knott@rogers.com> wrote:
Greg Freemyer wrote:
If you have a full class A (ie. /8 or 10.x.x.x) then you conceivably have 10's of thousands (or more) MACs to potentially keep up with and setup spanning trees for.
Wait 'till you start working with IPv6 networks, where you can have up to 2^64 devices on a subnet!
Of course, practical considerations may limit that somewhat. ;-)
I have a /56 IPv6 subnet, which can be split into 256 /64 subnets. I'm a IPv6 neophyte, but I have wondered about that.
Since IPv6 is 128 bits I think, a single /64 subnet is as big as the public facing Internet is today. (ie. Ignoring private IP space like 10.x.x.x).
Actually, it's the entire IPv4 address space squared! IPv4 has 2^32 or about 4 billion addresses. 2^64 is 18.4 quintillion. My /56 subnet is 2^72 or 4.7 sextillion, but I haven't used them all yet. ;-)
I have a hard time fathoming how something that big can be managed without some form of hierarchy.
Actually, the IPv6 address space is designed to be a hierarchy, so as to reduce routing table size. Also, most subnets will actually have only a tiny fraction of the possible addresses. The current practice, with recent versions of Linux, Windows etc., is to have at least 3 addresses per device. Those are the link local address, starting with FE80, which all IPv6 devices must have. Then there's a MAC based address on the subnet and due to privacy concerns, one on the subnet using a 64 bit random number, in place of the MAC based address. The MAC address, when used as part of an IPv6 address has FFFE stuck in the middle to fill it out to 64 bits. The reason for that random number address is that the MAC based one is tied to a specific computer and some people think that may be a security issue. So the random number address is used for outgoing connections and the MAC based, incoming. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
James Knott said the following on 01/06/2012 05:16 PM:
Actually, it's the entire IPv4 address space squared! IPv4 has 2^32 or about 4 billion addresses. 2^64 is 18.4 quintillion. My /56 subnet is 2^72 or 4.7 sextillion, but I haven't used them all yet. ;-)
Maybe you should have a word with your city council and arrange to address and control each and every street light in the city. And the next city. And the next one. In each direction. For a few thousand miles. Say about 12,000 miles in each direction. Still a bit left over, eh? -- "Key escrow to rule them all; key escrow to find them. Key escrow to bring them all and in the darkness bind them. In the land of surveillance where Big Brother lies." -- Peter Gutmann -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 01/06/2012 10:48 AM, James Knott wrote:
Greg Freemyer wrote:
If you have a full class A (ie. /8 or 10.x.x.x) then you conceivably have 10's of thousands (or more) MACs to potentially keep up with and setup spanning trees for.
Wait 'till you start working with IPv6 networks, where you can have up to 2^64 devices on a subnet!
Of course, practical considerations may limit that somewhat. ;-)
I have a /56 IPv6 subnet, which can be split into 256 /64 subnets.
Actually, our main network is fully IPv6 enabled. I didn't have any problems with the IPv6 auto configuration, which is obtained from the closest router if I'm not mistaken. Regards, Lew -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Lew Wolfgang wrote:
Actually, our main network is fully IPv6 enabled. I didn't have any problems with the IPv6 auto configuration, which is obtained from the closest router if I'm not mistaken.
Actually, it can obtain subnet info from any router on the local network, so that you could have multiple addresses for the various subnets. One thing IPv6 supports is deprecated addresses, which makes it easy to move from one subnet to another if, for example, you change ISPs. In this situation, you start with a new ISP & subnet, update your DNS and then, after a while, shut down the old ISP connection. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Dave Howorth wrote:
When they bring up a new machine and do dhcp, it takes about 45 seconds to get the new IP. I'm convinced most of the time is the switches playing games trying to figure out the most efficient way to connect the newly introduced machine to the dhcp server. Isn't that any easy problem to solve? Whichever switch the new machine is connected to just looks in its tables and asks "how did I send
Greg Freemyer wrote: traffic to<the dhcp server> last time somebody asked me?" The answer doesn't depend in any way on there being a new machine.
But I'm no expert, so perhaps I'll learn something!
Actually, with Spanning Tree Protocol (STP), it shouldn't even take that long. Each switch maintains a table of devices (MAC addresses) connected to it and through STP, the switches determine the best path. If a link fails, an alternate path, if available, is used. This all happens automagically. Of course, switches know nothing about DHCP requests or anything else to do with IP. They handle level 2 traffic (Ethernet etc.) only, not higher protocols. https://en.wikipedia.org/wiki/Spanning_tree_protocol -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 01/06/2012 03:25 AM, Per Jessen wrote:
Per Jessen wrote:
So I then issued a "/etc/init.d/network restart-all-dhcp-clients". This option did a lot more as reflected in messages, but it still didn't renew the DHCP lease. It started dhcpcd but put it in background, then dhcpcd reported "eth0 timed out". At this point it tried to "use old lease in /var/lib/dhcpcd/dhcpcd-eth0.info'", which still contained the old lease info, and proceeded to reuse the old lease without broadcasting for a new one. It must have done a broadcast, otherwise why would it report "eth0 timed out"? Following a time-out, it seems reasonable to attempt a fall-back to the previous lease. In the logs you posted, there is a 20 second span between broadcast and time-out:
Jan 5 13:47:11 ironhead dhcpcd[6530]: eth0: broadcasting for a lease Jan 5 13:47:27 ironhead ifup-dhcp: eth0 DHCP4 continues in background Jan 5 13:47:31 ironhead dhcpcd[6530]: eth0: timed out Jan 5 13:47:31 ironhead dhcpcd[6530]: eth0: trying to use old lease in `/var/lib/dhcpcd/dhcpcd-eth0.info'
Is there a problem with the DHCP server? If you check the server logs, you should see a complete trace of the negotation, but I guess the server isn't responding, hence the time-out.
Good catch, Per! That was part of the problem. I tried the case of moving the Ethernet cable from the big outside network to a natted local router and once dhcpcd was restarted it picked up the new lease after four seconds. But, I had to manually restart dhcpcd by running /etc/init.d/network restart-all-dhcp-clients. Bringing the interface down and up again didn't bounce dhcpcd. I checked on a 11.4 system and it behaved the same. So it appears that my only problem was the sluggish DHCP server on the big network. It could be that 11.4 behaves differently (I didn't test) but a valid argument can be made that 12.1 is working correctly. Still, it would be nice if a hardware-induced (cable swap) interface bounce would also generate a new dhcpcd broadcast. Feature request? Regards, Lew -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 01/06/2012 10:48 AM, Lew Wolfgang wrote:
Still, it would be nice if a hardware-induced (cable swap) interface bounce would also generate a new dhcpcd broadcast. Feature request?
I tried cable swapping on a MAC Mini and it worked exactly as expected. 1. Unplug the Ethernet cable from the home network and connect it to a natted stand-alone router. The MAC saw the port swap and after 12 seconds loaded the new IP addresses. 2. Unplug the cable and reconnect to the home network and after another 12 second delay it showed the correct address for the routable network. I'm sure that Windows boxes will perform in a similar fashion. Why not openSuSE? Not that this situation will be encountered very often, but it does violate Wolfgang's Principle of Least Astonishment. Also, why does the MAC's dhcpcd not timeout as 12.1 does? I'll try this drill on my home cable-modem network too. Regards, Lew -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Lew Wolfgang wrote:
On 01/06/2012 10:48 AM, Lew Wolfgang wrote:
Still, it would be nice if a hardware-induced (cable swap) interface bounce would also generate a new dhcpcd broadcast. Feature request?
I tried cable swapping on a MAC Mini and it worked exactly as expected.
1. Unplug the Ethernet cable from the home network and connect it to a natted stand-alone router. The MAC saw the port swap and after 12 seconds loaded the new IP addresses.
2. Unplug the cable and reconnect to the home network and after another 12 second delay it showed the correct address for the routable network.
I'm sure that Windows boxes will perform in a similar fashion.
Why not openSuSE? Not that this situation will be encountered very often, but it does violate Wolfgang's Principle of Least Astonishment.
I think it would be a clever thing to do - I don't know how often it's going to be really useful, but still. -- Per Jessen, Zürich (3.0°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Per Jessen wrote:
I think it would be a clever thing to do - I don't know how often it's going to be really useful, but still.
Actually, it's very useful for anyone working regularly on computer networks trying to resolve problems. There have been many times in Windows when I've had to do an ipconfig release & renew. With Linux, I simply set the interface to be started when the cable was unplugged. Rebooting or turning the equipment off/on would also cause the cable to "unplug". I have worked on a lot of networking equipment that comes set to 10.0.0.x by default and then had to reconfigure to the desired network range. After it has been changed, it's nice if the computer can follow the address automagically. Restarting the NIC, including dhcpcd when rebooting the device does that. When configuring a Linux computer for dhcp, I always set it to start the NIC on cable. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
James Knott wrote:
Per Jessen wrote:
I think it would be a clever thing to do - I don't know how often it's going to be really useful, but still.
Actually, it's very useful for anyone working regularly on computer networks trying to resolve problems. There have been many times in Windows when I've had to do an ipconfig release & renew. With Linux, I simply set the interface to be started when the cable was unplugged. Rebooting or turning the equipment off/on would also cause the cable to "unplug". I have worked on a lot of networking equipment that comes set to 10.0.0.x by default and then had to reconfigure to the desired network range. After it has been changed, it's nice if the computer can follow the address automagically. Restarting the NIC, including dhcpcd when rebooting the device does that. When configuring a Linux computer for dhcp, I always set it to start the NIC on cable.
Maybe this is only for NetworkManager, I don't see such an option for ifup/down. -- Per Jessen, Zürich (4.2°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Per Jessen wrote:
Maybe this is only for NetworkManager, I don't see such an option for ifup/down.
Every time the NIC is brought up, it should assume it's on a different network and run the dhcp client. What possible justification is there for not doing so? How is plugging in a cable supposed to be different from using ifdown/ifup? Either way, it should try to obtain an address. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
James Knott wrote:
Per Jessen wrote:
Maybe this is only for NetworkManager, I don't see such an option for ifup/down.
Every time the NIC is brought up, it should assume it's on a different network and run the dhcp client. What possible justification is there for not doing so?
Sure, I'm pretty certain that is the current situation. However, "being brought up/down" != "cable being plugging in/out". (afaik).
How is plugging in a cable supposed to be different from using ifdown/ifup?
The former is a physical status, the latter an admin desire :-) For instance, plugging in the cable does not imply you also want the interface brought up. -- Per Jessen, Zürich (4.2°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Per Jessen wrote:
For instance, plugging in the cable does not imply you also want the interface brought up.
It does if that's how you configured it. I always configure to do that with DHCP. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
James Knott wrote:
Per Jessen wrote:
For instance, plugging in the cable does not imply you also want the interface brought up.
It does if that's how you configured it. I always configure to do that with DHCP.
Cool, then there is no real problem. Unless the "ifplugd" setting doesn't ctually work, in which case - bugreport. -- Per Jessen, Zürich (4.2°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Per Jessen wrote:
Cool, then there is no real problem. Unless the "ifplugd" setting doesn't ctually work, in which case - bugreport.
It seems to me that was the original point of this thread. I don't have the original message anymore, so I can't verify. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
James Knott wrote:
Per Jessen wrote:
Cool, then there is no real problem. Unless the "ifplugd" setting doesn't ctually work, in which case - bugreport.
It seems to me that was the original point of this thread. I don't have the original message anymore, so I can't verify.
It's in the archives, but Lew Wolfgangs problem was two-fold - a dhcp timeout, and not getting the lease renewed/updated when unplugging/ plugging the cable. The solution to the latter would appear to be to define the interface as "ifplugd" when configuring it with yast. -- Per Jessen, Zürich (4.2°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 01/08/2012 11:47 AM, Per Jessen wrote:
James Knott wrote:
Cool, then there is no real problem. Unless the "ifplugd" setting doesn't ctually work, in which case - bugreport. It seems to me that was the original point of this thread. I don't have the original message anymore, so I can't verify. It's in the archives, but Lew Wolfgangs problem was two-fold - a dhcp timeout, and not getting the lease renewed/updated when unplugging/
Per Jessen wrote: plugging the cable. The solution to the latter would appear to be to define the interface as "ifplugd" when configuring it with yast.
Hi Per, Wow, I had no idea about "ifplugd"! I tried it and it takes care of my plug/unplug issue. I really don't know how I could have been ignorant so long about an important (for me) facility like this. If anyone listening is as ignorant as I was, I enabled ifplugd by editing /etc/sysconfig/network/ifcfg-eth0 and changing STARTMODE='auto' to STARTMODE='ifplugd'. I don't know if this is the politically correct way to set it, but it works. I think an argument can be made that ifplugd should be enabled by default on hard-wired interfaces. I'll fiddle with a 12.1 laptop tomorrow to see if NetworkManager behaves differently. Regarding my second dhcp timeout issue, I'm convinced at this point that it's being caused by some interaction with the large work network. It behaves correctly here at home. I'll see if I can get access to the dhcp server logs to maybe figure out what's going on. Some quality time with tcpdump may also be appropriate. Thanks to everyone for their help! Lew -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Lew Wolfgang wrote:
I don't know if this is the politically correct way to set it, but it works.
It is an option when you set up a network interface in Yast > Network Devices > Network Settings. The choices are: 1) At Boot Time 2) On Cable Connection 3) On Hotplug 4) Manual 5) Never 6) On NFSroot I normally use "On Cable Connection" for DHCP interfaces. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Fri, 06 Jan 2012 22:36:40 +0100, Per Jessen wrote:
Why not openSuSE? Not that this situation will be encountered very often, but it does violate Wolfgang's Principle of Least Astonishment.
I think it would be a clever thing to do - I don't know how often it's going to be really useful, but still.
I agree. A real world example is my university. On the wired network, when a unknown hw-address connects (and is not 802.1x capable) they are placed on a registration vlan and given a temporary dhcp lease. All www is redirected to a captive portal and the user is supposed to give his credentials. If the user succeeds entering a username and a password, we register his mac-address in our database and instructs the switch to put the the port offline for a short while. This is seen from the the client as a disconnect/connect and the process restarts, only this time the hw-addresss is known to the switch and the client is now placed on a suitable vlan. I think this is how most captive portals work. If it is correct that 12.1 just reuses the registration lease after the network has toggled. Then network registration will now take several minutes until the registration lease expires, as opposed to something like 30 sec. for Windows and Mac users. I will certainly have to test this tomorrow, when I get to work. -- Klaus -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Klaus Vink Slott wrote:
Then network registration will now take several minutes until the registration lease expires
The lease from my ISP is 7 days. A lease of several minutes would be unusual. A one day or week lease is common for business networks. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
hi James Søndag den 8. januar 2012 19:41:39 skrev James Knott:
A lease of several minutes would be unusual.
not on a registration VLAN. Users are requested to present credentials and subsequently moved to the correct VLAN. -- Klaus -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Klaus Vink Slott wrote:
On Fri, 06 Jan 2012 22:36:40 +0100, Per Jessen wrote:
Why not openSuSE? Not that this situation will be encountered very often, but it does violate Wolfgang's Principle of Least Astonishment.
I think it would be a clever thing to do - I don't know how often it's going to be really useful, but still.
I agree. A real world example is my university. On the wired network, when a unknown hw-address connects (and is not 802.1x capable) they are placed on a registration vlan and given a temporary dhcp lease. All www is redirected to a captive portal and the user is supposed to give his credentials. If the user succeeds entering a username and a password, we register his mac-address in our database and instructs the switch to put the the port offline for a short while. This is seen from the client as a disconnect/connect and the process restarts, only this time the hw-addresss is known to the switch and the client is now placed on a suitable vlan.
Good example, even if perhaps not very common. I've googled a bit, and I think your setup will work if the NIC is set up to work as/with "ifplugd". That may be what James Knott referred to. -- Per Jessen, Zürich (4.2°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Per Jessen wrote:
Good example, even if perhaps not very common. I've googled a bit, and I think your setup will work if the NIC is set up to work as/with "ifplugd". That may be what James Knott referred to.
VLANs are commonly used where there are different classes of hosts. For example, I have set up VoIP phone systems that use VLANs. What VLAN the phone or computer lands on is determined by info provided by the DHCP server. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Sunday den 8. January 2012 20:07:26 Per Jessen:
registration vlan and given a temporary dhcp lease.
Good example, even if perhaps not very common. I've googled a bit, and I think your setup will work if the NIC is set up to work as/with "ifplugd". That may be what James Knott referred to.
First thing today was testing this: I have found that using default setting (fresh 12.1 install) with Network manager and STARTMODE='onboot' it works. Only catch seems to be that network has to be disconnected for more than 5 sec. to ensure that the interruption is registered and a new dhcp lease is requested. Our switch down/up cycle is currently something like 15 sec. so I see no problem in how things work now. We might get better results by changing STARTMODE, but is this used at all when Network Manager controls the interface? The settings is not assessable from Yast when NM is in control. Anyway, as we have no control over what computers our students drags into our campus, we will go a long way to make sure most things work with common default setting. So from my point of view I see no problems with dhcp in 12.1 -- Klaus -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Per Jessen wrote:
Lew Wolfgang wrote:
Why not openSuSE? Not that this situation will be encountered very often, but it does violate Wolfgang's Principle of Least Astonishment.
I think it would be a clever thing to do - I don't know how often it's going to be really useful, but still.
I haven't thought about this very hard but what is the effect if I simply unplug a network cable and then plug it back in again? I would hope no effect - it should be completely transparent to any applications with TCP connections in progress. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Dave Howorth said the following on 01/09/2012 07:53 AM:
I haven't thought about this very hard but what is the effect if I simply unplug a network cable and then plug it back in again? I would hope no effect - it should be completely transparent to any applications with TCP connections in progress.
It will depend, surely, on how long the cable is unplugged for and what the applications are doing. The man page says you can specify the poll time and latencies and that might have something to do with it all as well. Like so many questions, "it all depends" on specific circumstances. -- Sacred cows make the best hamburgers. --Mark Twain -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Anton Aylward wrote:
I haven't thought about this very hard but what is the effect if I simply unplug a network cable and then plug it back in again? I would hope no effect - it should be completely transparent to any applications with TCP connections in progress. It will depend, surely, on how long the cable is unplugged for and what
Dave Howorth said the following on 01/09/2012 07:53 AM: the applications are doing.
The man page says you can specify the poll time and latencies and that might have something to do with it all as well.
Like so many questions, "it all depends" on specific circumstances.
As long as the cable is plugged in again before the lease expires, the same address should be provided. However, if unplugged long enough, open TCP connections and some applications or services will fail. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Dave Howorth wrote:
Per Jessen wrote:
Lew Wolfgang wrote:
Why not openSuSE? Not that this situation will be encountered very often, but it does violate Wolfgang's Principle of Least Astonishment. I think it would be a clever thing to do - I don't know how often it's going to be really useful, but still. I haven't thought about this very hard but what is the effect if I simply unplug a network cable and then plug it back in again? I would hope no effect - it should be completely transparent to any applications with TCP connections in progress.
It should be transparent even if a DHCP request happens. The request will include the previous address and the DHCP server is supposed to give out the requested address if available. In fact, in normal operation, there should be DHCP requests part way through the lease time, so that the lease is renewed long before it expires -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (8)
-
Anton Aylward -
Dave Howorth -
Greg Freemyer -
James Knott -
Ken Schneider - openSUSE -
Klaus Vink Slott -
Lew Wolfgang -
Per Jessen