Comment 0 for bug 43379

The Actors:
  Fire -- the stalwart DHCP server running Debian Stable (Sarge)
  Dib -- the noble laptop and DHCP client, possessing a heart of gold
  and an instance of nm-applet. Dib runs the latest Dapper (May 5th
  2006) running nm-applet version 0.6.2-0ubuntu5.
  Christian -- the mad scientist

The Scene:
  A dark and stormy night.
  Fire has already given Dib a dynamic IP addressed based on his wifi
  MAC address.
  Christian wants to make Dib's IP static when Dib is connected via wifi.

What Happened:
  Christian, sitting at his laptop, Dib, starts to edit the Fire's
  DHCPd configuration remotely via SSH. He sets Dib's wifi MAC
  address to return the same IP as the wired MAC does.

  Christian restarts the DHCP server. The next time Dib asks the DHCP
  server what it's IP address is, it will change from .189 to .16

  A few minutes later, Dib sends the DHCP request. All the SSH
  connections freeze (as expected) and the nm-applet shows its
  reconnecting to the network. As nm-applet gets to the end of its
  reconnect cycle, when it should have shown the wifi bars again, it
  vanishes.

  Christian confirms that nm-applet is still running. Christian tries
  to restart nm-applet, but to no avail... Christian checks the
  network, it is correctly configured, but nm-applet has lost its
  mind.

  A complete reboot is required to make nm-applet work again.

What was Expected:
  It should have "Just Worked".

Conclusion:
  nm-applet or network-manager didn't deal very well with the same
  network connection handing out a new IP address, even though this is
  acceptable DHCP behavior.

  Also, Christian gets into strange moods at time and submits bug
  reports with a bizarre sense of humor. But at least the reports are
  proof-read.