Description of problem: An FC4 system running dhclient was booted and acquired a lease from the DHCP server. During the lease, the DHCP server configuration was changed to make the subnet mask more restrictive (smaller subnet), causing the netmask and broadcast address options to change. At renew time, the client renewed its lease with the DHCP server that has this new config. /var/lib/dhcp/dhclient-eth0.leases shows that the new option values were received, but they are never applied to the interface as seen by ifconfig. Version-Release number of selected component (if applicable): 3.0.2-24.FC4 How reproducible: always Steps to Reproduce: 1. Configure a DHCP server with subnet e.g. 172.16.4.0/24, option netmask 255.255.255.0, option broadcast address 172.16.4.255 and a static host reservation for an FC4 client. Keep the lease time short, e.g. 10 minutes. 2. Boot the FC4 client and have it acquire an address via DHCP. 3. Note that the interface is configured with inet addr:172.16.4.x Bcast:172.16.4.255 Mask:255.255.255.0. 4. Change the DHCP server configuration to make the subnet smaller, e.g. 172.16.4.0/25, option netmask 255.255.255.128, option broadcast address 172.16.4.127. 5. Wait for the FC4 client to renew. 6. Note that in the lease at the end of /var/lib/dhcp/dhclient-eth0.leases there are new option values for subnet-mask and broadcast-address, but ifconfig still shows the original Mask and Bcast values. 7. The FC4 client now can no longer reach the part of the old subnet that was split off from the new subnet. Actual results: First DISCOVER or RENEW: Nov 18 11:02:57 foo dhclient: DHCPREQUEST on eth0 to 172.16.x.y port 67 Nov 18 11:02:57 foo dhclient: DHCPACK from 172.16.x.y Nov 18 11:02:57 foo dhclient: bound to 172.16.4.100 -- renewal in 3273 seconds. lease { interface "eth0"; fixed-address 172.16.4.100; option subnet-mask 255.255.255.0; option routers 172.16.4.2; option dhcp-lease-time 7200; option dhcp-message-type 5; option domain-name-servers 172.16.x.y; option dhcp-server-identifier 172.16.x.y; option broadcast-address 172.16.4.255; option host-name "foo.bar"; option domain-name "bar"; renew 5 2005/11/18 16:02:57; rebind 5 2005/11/18 16:53:50; expire 5 2005/11/18 17:08:50; } eth0 Link encap:Ethernet HWaddr 00:11:43:aa:bb:cc inet addr:172.16.4.100 Bcast:172.16.4.255 Mask:255.255.255.0 inet6 addr: fe80::211:43ff:feaa:bbcc/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:48292208 errors:0 dropped:0 overruns:0 frame:0 TX packets:79273347 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:4180252947 (3.8 GiB) TX bytes:2942222584 (2.7 GiB) Base address:0xecc0 Memory:dfae0000-dfb00000 Next RENEW after server configuration change: Nov 18 11:57:30 foo dhclient: DHCPREQUEST on eth0 to 172.16.x.y port 67 Nov 18 11:57:30 foo dhclient: DHCPACK from 172.16.x.y Nov 18 11:57:30 foo dhclient: bound to 172.16.4.100 -- renewal in 2826 seconds. lease { interface "eth0"; fixed-address 172.16.4.100; option subnet-mask 255.255.255.128; option routers 172.16.4.2; option dhcp-lease-time 7200; option dhcp-message-type 5; option domain-name-servers 172.16.x.y; option dhcp-server-identifier 172.16.x.y; option broadcast-address 172.16.4.127; option host-name "foo.bar"; option domain-name "bar"; renew 5 2005/11/18 16:57:30; rebind 5 2005/11/18 17:47:57; expire 5 2005/11/18 18:02:57; } eth0 Link encap:Ethernet HWaddr 00:11:43:aa:bb:cc inet addr:172.16.4.100 Bcast:172.16.4.255 Mask:255.255.255.0 inet6 addr: fe80::211:43ff:feaa:bbcc/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:48293279 errors:0 dropped:0 overruns:0 frame:0 TX packets:79274506 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:4180354956 (3.8 GiB) TX bytes:2942610020 (2.7 GiB) Base address:0xecc0 Memory:dfae0000-dfb00000 Expected results: Bcast and Mask should be updated to reflect the dhclient-eth0.leases file: eth0 Link encap:Ethernet HWaddr 00:11:43:aa:bb:cc inet addr:172.16.4.100 Bcast:172.16.4.127 Mask:255.255.255.128 inet6 addr: fe80::211:43ff:feaa:bbcc/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:48293279 errors:0 dropped:0 overruns:0 frame:0 TX packets:79274506 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:4180354956 (3.8 GiB) TX bytes:2942610020 (2.7 GiB) Base address:0xecc0 Memory:dfae0000-dfb00000
Thanks for pointing this out! This is apparently a bug with all previous versions of dhclient-script, which only configured interfaces on a RENEW if the ip-address had changed. I'll update dhclient-script to test for subnet-mask and broadcast-address changes on an RENEW and reconfigure interfaces if they have changed.
Do routers get updated if they change? What about other option changes like interface/route metrics, interface MTU, etc?
Yes, the script will be updated to reconfigure appropriately if any of ip-address, subnet-mask, broadcast-address, interface-mtu, or routers changes after a RENEW .
From User-Agent: XML-RPC dhcp-3.0.2-26.FC4 has been pushed for FC4, which should resolve this issue. If these problems are still present in this version, then please make note of it in this bug report.
This bug is now fixed with dhcp-3.0.2-26.FC4, and dhcp-3.0.3-14 (FC-5) .
There appears to be a bug lurking in here: if [ x$reason = xBOUND ] || [ x$reason = xREBOOT ] || [ x$old_ip_address != x$new_ip_address ] || [ x$old_subnet_mask != x$new_subnet_mask ] || [ x$new_network_number != x$new_network_number ] || [ x$old_broadcast_address != x$new_broadcast_address ] || [ "x$old_routers" != "x$new_routers" ] || [ x$old_interface_mtu != x$new_interface_mtu ] ; then $new_network_number is compared != to itself, which will never be true.
Oops, yes, that's a typo, but luckily one that has no effect whatsoever. *_network_number is computed by dhclient from the ip-address/subnet-mask, so if they change, the expression will still evaluate to true. I'll take out the network_number clause in the next release.
I have updated to dhclient 3.0.2-28 on fc4. dhcp is not installed. I use a dlink 300G modem. Since upgrading I can not obtain the ip adress etc but before I had no problems. Also, on the same machine I also have fedora 3 and this has no problems. Is this a dhclient problem (fault) or are other factors (such as firewall settings) be causing this problem.
RE: Comment #9 : Please try the latest dhcp-3.0.2-30.FC4 RPMS from FC-4 Updates Testing. There have been no problems reported with dhcp-3.0.2-28+, besides an inability to set the default router if the default router is the same as the ip-address (fixed with dhcp-3.0.2-30.FC4). To find out what is going wrong with your dhclient session, please do the following: 1. Boot into single-user mode (give the '1' kernel boot argument to grub) 2. Bring up networking: # modprobe ipv6 # ifup lo # ifconfig ethX up (where ethX is the interface you want to configure with dhclient) 3. Start tcpdump: # tcpdump -nl -vvv -i ethX -s 4096 -X port bootpc or port bootps \ >/tmp/dhclient.tcpdump.log 2>&1 4. Bring up dhcp interface: # ifup ethX 5. Kill tcpdump and attach the /tmp/dhclient.tcpdump.log to this bug report or send it to me: # pkill tcpdump # mail -s 'dhclient bz173619' jvdias /tmp/dhclient.tcpdump.log Thank you!
Closing bugs in MODIFIED state from prior Fedora releases. If this bug persists in a current Fedora release (such as Fedora Core 5 or later), please reopen and set the version appropriately.