|
Good day all, As this is my first message to the debian community, I am
unsure of wether or not this is the appropriate way to share my findings. I appologize therefore is this is not the right way to do
so. The issue : On both Etch and Lenny, some of us experience an issue with
the Network Manager. For some reason, Network Manager calls dhclient up and awaits
for a message on dbus advising it that it has actually received an valid IP
address. This however doesnt seem to happen properly and NM thinks it
hasnt received an IP address when it actually has. Taking a closer look at /var/log/syslog, one can see the
following logs during NMs attempt at configuring the interface : Jun 21 02:15:37 Bazooka avahi-daemon[3081]: New relevant
interface eth0.IPv4 for mDNS. Jun 21 02:15:37 Bazooka avahi-daemon[3081]: Registering new
address record for 192.168.1.177 on eth0.IPv4. Jun 21 02:15:37 Bazooka dhclient: bound to 192.168.1.177 --
renewal in 41208 seconds. Jun 21 02:15:41 Bazooka NetworkManager: Old device 'eth0'
activating, won't change. Jun 21 02:16:11 Bazooka NetworkManager: Old device 'eth0'
activating, won't change. Jun 21 02:16:17 Bazooka NetworkManager: Device 'eth0' DHCP
transaction took too long (>45s), stopping it. Jun 21 02:16:17 Bazooka dhclient: There is already a pid
file /var/run/dhclient.eth0.pid with pid 7905 Jun 21 02:16:17 Bazooka dhclient: killed old client process,
removed PID file Jun 21 02:16:17 Bazooka dhclient: DHCPRELEASE on eth0 to
192.168.1.1 port 67 The cause: While I have not pinpointed the exact cause of this issue, I
have a couple of ideas and pointers : First of all, on needs to make sure that dhclient actually
has an exit-hook that will send the appropriate dbus message once its actions
are completed. This script should look like so : if [ -n "${dhc_dbus}" ]; then /usr/bin/dbus-send \ --system \ --dest=com.redhat.dhcp \ --type=method_call \ /com/redhat/dhcp/$interface \ com.redhat.dhcp.set \ 'string:'"`env | /bin/egrep -v
'^(PATH|SHLVL|_|PWD|dhc_dbus)\='`"; fi; And should be located somewhere in /etc/dhclient3/
(/etc/dhcp3/dhclient-exit-hooks.d/dhcdbd in Lenny) If you actually have that script, there also seems to be an
issue with the actual contents of the message being send via dbus. I am unsure of wether this is caused by the actual DHCP
Server (dnsmasq in my case) or by Dhclient3 but it appears that a couple of
environment variables are populated with garbage. In particular, dhclient seems
to set new_server_name and old_server_name to something quite random. I am assuming that it might be caused by dnsmasq malforming
the dhcp response or dhclient trying to read the server_name variable at the
wrong offset somehow. Either way, this causes the result of env | /bin/egrep -v
'^(PATH|SHLVL|_|PWD|dhc_dbus)\=' ends up containing those 2 variables and NM
seems to be unhappy about their values. The solution: While this is a quick and dirty fix, it does do the trick. Simply change (PATH|SHLVL|_|PWD|dhc_dbus) to
(PATH|SHLVL|_|PWD|dhc_dbus|new_server_name|old_server_name) to ommit passing
those 2 variables in the dbus message. I think that this issue might require a bug report to either
dnsmasq or dhclient maintainers but at this time I am unsure of which
application is actually causing the issue. It would be interesting to compare dhcp response messages
between dnsmasq and dhcp-server in order to see if dhclient returns readable
values in the server_name fields when using the latter. Hoping this will be of some help. Guillaume Giraudon |