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.
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.