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
