|
Bugzilla – Full Text Bug Listing |
| Summary: | NetworkManager fails to see the link is up | ||
|---|---|---|---|
| Product: | [openSUSE] SUSE Linux 10.1 | Reporter: | Marian Jancar <mjancar> |
| Component: | Network | Assignee: | Robert Love <rml> |
| Status: | RESOLVED DUPLICATE | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Normal | ||
| Priority: | P5 - None | ||
| Version: | Alpha 3 | ||
| Target Milestone: | --- | ||
| Hardware: | Other | ||
| OS: | Other | ||
| Whiteboard: | |||
| Found By: | Other | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
|
Description
Marian Jancar
2005-12-12 10:28:43 UTC
This isn't a dupe of #134829? Can you try using the latest powersave package? It notifies NM of suspend and resume. In #134829 only the icon is wrong, here fails the NM itself. I will retry with latest powersaved (though I have quite recent becouse of a powersaved bug). Would the lack of the notification cause the NM to fail even in case I issue /etc/init.d/networkmanager restart? Restarting the daemon should make not fail.. Is 0.5.1cvs20051209 failing in the same way or only as in #134829? Also, I submitted 20051212 to autobuild today, you can try that. Its different, in #134829 NM works, only the displayed icon is wrong, here the NM doesn't work at all. Restarting it doesn't help, full reboot is required. I should note that if you run 'dhcpcd eth0' manually (yourself), NetworkManager is definitely going to get very confused. Are you seeing this problem without doing _any_ manual intervention? All interfaces are fully managed by NetworkManager, no networking if* scripts are used, no other dhcp clients, etc.? Yes, I run the dhcpcd as last resort to get the IP and to verify that there is no problem with cabling etc. That is the root of this problem -- NetworkManager needs to handle the network configuration itself. If you manually run a DHCP client or ifup the interface, NetworkManager gets confused. The idea is that it has full control of your interfaces. It does not just spawn a DHCP client, but it controls and monitors it closely (via DBUS and dhcdbd). So ... your problem will go away if you do not manually run dhcpcd. Its not the root, it was remedy, after NM not assignin the IP after about two minutes and two restarts. I am confused. You wrote "After reboot with the 0.5.1cvs20051209-2 it works, but the applet icon is wrong, then after resume it works again and the icon is right," which sounds as if the problem is just the wrong icon? Ok I will describe it in detail: I came to work, resumed the laptop, NM didn't give me IP, I run the dhcpcd to get an IP, updated to NM from /work, killed the dhcpcd, restarted the NM, it still didnt work, I rebooted, NM got an IP but the applet displayed no connection, then to test it I suspended and resumed, NM got IP and the icon correctly displayed wired connection. The failure (no IP) happens only on resume and is quite random. Right, exactly. So, "updated to NM from /work, killed the dhcpcd, restarted the NM, it still didnt work, I rebooted, NM got an IP but the applet displayed no connection, then to test it I suspended and resumed, NM got IP and the icon correctly displayed wired connection." It sounds as if the problem, with the new version, is the icon showing the wrong state? I've got all the latest stuff via rug (including new NM icons). I just booted (not resumed) my laptop while it was wired. After logging in, NM tray icon says I'm disconnected, but clicking on icon opens the bubble that ways I'm wired. ifconfig says I'm wired and all is well. After switching from wired to wireless, then back to wired, the NM tray icon is now correct. Bart: Hey, good. That is bug #134829, which is the icon says disconnected but you are connected. I am trying to acertain whether this bug is a dupe or not. If, with the latest version, Marian is only seeing the icon troubles, then it is. This is a separate issue, I see NM sometimes not assigning the IP after resume. The applet icon is missing completely or shows no connection when this happens. Restarting the NM doesn't help, full reboot is neccessary in such case. The interface itself works fine, it can be assigned an IP manualy and works, so I don't think this could be driver issue. May be it is related to resuming with the wire allready plugged in or plugging it in after the resume, I will try to get some reproducible results. It is caused by Novell VPN client, it adds the VPN ip to the eth0, then after resume NM ignores the interface. Still the only way to recover from that is reboot:
fujiwara-no-sai:/ # /etc/init.d/networkmanager stop
Shutting down the NetworkManager done
fujiwara-no-sai:/ # ip l set eth0 down
fujiwara-no-sai:/ # ip a flush dev eth0
fujiwara-no-sai:/ # /etc/init.d/networkmanager start
Starting the NetworkManager done
fujiwara-no-sai:/ # sleep 10
fujiwara-no-sai:/ # ip a
1: lo: <LOOPBACK,UP> mtu 16436 qdisc noqueue
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:0b:97:32:6f:c6 brd ff:ff:ff:ff:ff:ff
3: gre0: <NOARP> mtu 1476 qdisc noop
link/gre 0.0.0.0 brd 0.0.0.0
5: sit0: <NOARP> mtu 1480 qdisc noop
link/sit 0.0.0.0 brd 0.0.0.0
7: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop qlen 1000
link/ether 00:13:ce:69:5e:02 brd ff:ff:ff:ff:ff:ff
fujiwara-no-sai:/ #
Should be fixed by the new Novell VPN client for NetworkManager ... if not, definitely a bug! *** This bug has been marked as a duplicate of 140504 *** |