[Bug 1183762] [NEW] dhclient-script flushes & re-adds an alias IP every time a lease is renewed

markdv 1183762 at bugs.launchpad.net
Fri May 24 10:32:12 UTC 2013


Public bug reported:


The dhclient-script flushes & re-adds an alias IP every time a lease is renewed.

Why?

The alias IP in configured in dhclient.conf, which is read on startup.
Even if the configuration was altered some time after an initial BOUND|REBOOT state/event dhclient would not know about it at RENEW time.
So as far as I can tell "$alias_ip_address" is guaranteed to never change after the initial BOUND|REBOOT event/state therefore making it pointless to reconfigure it at every RENEW.

Now, the superfluous reconfiguration might appear to be harmless at first, but if the primary leased address is used to masquerade(iptables) connections it DOES hurt.
This is because when the secondary IP address is removed all connection tracking entries for the entire interface are flushed which can cause existing connections to be dropped/terminated.
Which is how I found out and am reporting this issue.... :(

Although I think I'm of the opinion that this iptables/conntrack
behaviour is probably also sub-optimal (to say the least), this should
not be used as an excuse to perform any unnecessary actions of which the
side-effects (now or in the future) are unknown and possibly undesired.

If my reasoning is correct the following barely tested patch seems to
work for m:

--- dhclient-script.orig-dist	2013-05-23 21:43:24.441696833 +0200
+++ dhclient-script	2013-05-24 12:13:36.966021941 +0200
@@ -235,7 +235,8 @@
             hostname "$new_host_name"
         fi
 
-        if [ -n "$old_ip_address" ] && [ -n "$alias_ip_address" ] &&
+        if { [ "$reason" = "BOUND" ] || [ "$reason" = "REBOOT" ] ;} &&
+           [ -n "$old_ip_address" ] && [ -n "$alias_ip_address" ] &&
            [ "$alias_ip_address" != "$old_ip_address" ]; then
             # alias IP may have changed => flush it
             ip -4 addr flush dev ${interface} label ${interface}:0
@@ -271,7 +272,8 @@
             done
         fi
 
-        if [ -n "$alias_ip_address" ] &&
+        if { [ "$reason" = "BOUND" ] || [ "$reason" = "REBOOT" ] ;} &&
+           [ -n "$alias_ip_address" ] &&
            [ "$new_ip_address" != "$alias_ip_address" ]; then
             # separate alias IP given, which may have changed
             # => flush it, set it & add host route to it

Regards,
Mark.

** Affects: isc-dhcp (Ubuntu)
     Importance: Undecided
         Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to isc-dhcp in Ubuntu.
https://bugs.launchpad.net/bugs/1183762

Title:
  dhclient-script flushes & re-adds an alias IP every time a lease is
  renewed

Status in “isc-dhcp” package in Ubuntu:
  New

Bug description:
  
  The dhclient-script flushes & re-adds an alias IP every time a lease is renewed.

  Why?

  The alias IP in configured in dhclient.conf, which is read on startup.
  Even if the configuration was altered some time after an initial BOUND|REBOOT state/event dhclient would not know about it at RENEW time.
  So as far as I can tell "$alias_ip_address" is guaranteed to never change after the initial BOUND|REBOOT event/state therefore making it pointless to reconfigure it at every RENEW.

  Now, the superfluous reconfiguration might appear to be harmless at first, but if the primary leased address is used to masquerade(iptables) connections it DOES hurt.
  This is because when the secondary IP address is removed all connection tracking entries for the entire interface are flushed which can cause existing connections to be dropped/terminated.
  Which is how I found out and am reporting this issue.... :(

  Although I think I'm of the opinion that this iptables/conntrack
  behaviour is probably also sub-optimal (to say the least), this should
  not be used as an excuse to perform any unnecessary actions of which
  the side-effects (now or in the future) are unknown and possibly
  undesired.

  If my reasoning is correct the following barely tested patch seems to
  work for m:

  --- dhclient-script.orig-dist	2013-05-23 21:43:24.441696833 +0200
  +++ dhclient-script	2013-05-24 12:13:36.966021941 +0200
  @@ -235,7 +235,8 @@
               hostname "$new_host_name"
           fi
   
  -        if [ -n "$old_ip_address" ] && [ -n "$alias_ip_address" ] &&
  +        if { [ "$reason" = "BOUND" ] || [ "$reason" = "REBOOT" ] ;} &&
  +           [ -n "$old_ip_address" ] && [ -n "$alias_ip_address" ] &&
              [ "$alias_ip_address" != "$old_ip_address" ]; then
               # alias IP may have changed => flush it
               ip -4 addr flush dev ${interface} label ${interface}:0
  @@ -271,7 +272,8 @@
               done
           fi
   
  -        if [ -n "$alias_ip_address" ] &&
  +        if { [ "$reason" = "BOUND" ] || [ "$reason" = "REBOOT" ] ;} &&
  +           [ -n "$alias_ip_address" ] &&
              [ "$new_ip_address" != "$alias_ip_address" ]; then
               # separate alias IP given, which may have changed
               # => flush it, set it & add host route to it

  Regards,
  Mark.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1183762/+subscriptions




More information about the foundations-bugs mailing list