Thanks for the hint! Unfortunately that does not help me, but it did inspire me to search a little further:
It seems that in my case, the problem is not really related to the network interface or dhcp itself - those are working fine. The problem seems to lie somewhere with nm-applet, dhcdbd, dbus, and (possibly) nss.
Here's how the problem manifests:
1. Boot with Network unplugged
2. Log in - nm-applet will show up with a warning icon: no network
3. Connect network
4. nm-applet will spin seemingly forever, waiting for a dhcp assigned network address
5. in reality, the network address has been assigned, and the network interface is up
6. nm-applet will periodically bring the network interface up and down, apparently trying to resolve the problem
7. meanwhile /var/log/messages is full of stuff like: "dhcdbd: message_handler: message handler not found under /com/redhat/dhcp/eth0 for sub-path eht0.dbus.get.******"
8. and /var/log/auth fills up with: dbus-daemon: nss_ldap: failed to bind to ldap server... etc....
9. system is very slow and unreactive from that point on
So on a hunch, I set the bind_timeout to 1 (1 second) in /etc/ldap.conf - this has not exactly fixed, but massivly improved the situation:
Now when I plug in the network nm-applet only spins for about 15seconds, before correctly showing a connected LAN.
It seems to be trying to get information via nss_ldap - the auth log shows continuous connection attempts while nm-applet is spinning. When nm-applet stops spinning, the nss connection attempts stop, and the dbus messages are spit out to /var/log/messages.
So it seems to me the problem lies in how the system is trying to access network information - mysterious, since I have nss setup only to serve users and groups from ldap, not hosts, domains and networks.
I will investigate this some more, including the nss setup and my pam setup for dbus.
I'll keep you posted if I find anything, in the meantime, if anyone has any ideas, let me know!
Hi!
Thanks for the hint! Unfortunately that does not help me, but it did inspire me to search a little further:
It seems that in my case, the problem is not really related to the network interface or dhcp itself - those are working fine. The problem seems to lie somewhere with nm-applet, dhcdbd, dbus, and (possibly) nss.
Here's how the problem manifests: dhcp/eth0 for sub-path eht0.dbus. get.*** ***"
1. Boot with Network unplugged
2. Log in - nm-applet will show up with a warning icon: no network
3. Connect network
4. nm-applet will spin seemingly forever, waiting for a dhcp assigned network address
5. in reality, the network address has been assigned, and the network interface is up
6. nm-applet will periodically bring the network interface up and down, apparently trying to resolve the problem
7. meanwhile /var/log/messages is full of stuff like: "dhcdbd: message_handler: message handler not found under /com/redhat/
8. and /var/log/auth fills up with: dbus-daemon: nss_ldap: failed to bind to ldap server... etc....
9. system is very slow and unreactive from that point on
So on a hunch, I set the bind_timeout to 1 (1 second) in /etc/ldap.conf - this has not exactly fixed, but massivly improved the situation:
Now when I plug in the network nm-applet only spins for about 15seconds, before correctly showing a connected LAN.
It seems to be trying to get information via nss_ldap - the auth log shows continuous connection attempts while nm-applet is spinning. When nm-applet stops spinning, the nss connection attempts stop, and the dbus messages are spit out to /var/log/messages.
So it seems to me the problem lies in how the system is trying to access network information - mysterious, since I have nss setup only to serve users and groups from ldap, not hosts, domains and networks.
I will investigate this some more, including the nss setup and my pam setup for dbus.
I'll keep you posted if I find anything, in the meantime, if anyone has any ideas, let me know!
Regards from Vienna,
Richard Unger