Description of problem: Updating to the latest version of NetworkManager caused inability to connect to either wired or wireless network. Version-Release number of selected component (if applicable): 0.8.997-6.git20110328.fc15 How reproducible: Always Steps to Reproduce: 1. Use latest version release 2. 3. Actual results: NetworkManager vainly attempt to connect. Expected results: Network should be connected Additional info:
Can we get the NM-related messages from /var/log/messages ? Are you in GNOME, KDE, or what? Thanks!
Created attachment 488512 [details] /var/log/message | grep NetworkManager Gnome 3 in Fallback mode running Gallium3D 0.4 on llwnpipe for AMD Fusion E-350 based laptop. Unfortunately, hardware-acceleration is broken for Gnome-Shell. Anyway, here is the requested /var/log/messages
It appears the cause of problem is: Mar 29 10:05:24 muamba NetworkManager[987]: <error> [1301418324.25581] [nm-session-monitor.c:326] nm_session_monitor_init(): Error loading /var/run/ConsoleKit/database: Error statting file /var/run/ConsoleKit/database: No such file or directory
what does 'systemctl status console-kit-daemon.service' show?
#systemctl status console-kit-daemon.service console-kit-daemon.service - Console Manager Loaded: loaded (lib/systemd/system/console-kit-daemon.service) Active: active (running) since Tue, 29 Mar 2011 11:12:52 -0700; 4min 4s ago Main POD: 1165 (console-kit-dae) CGroup: name=systemd:/system/console-kit-daemom.service 1165 /user/sbin/console-kit-daemon --no-daemon
it's only been running for four minutes? does /var/run/ConsoleKit/database exist _now_? (I'm guessing the problem here is ConsoleKit not running at log in or some other issue with it.)
Yes, it does now. I am still unable to connect with the laptop. =(
can you try to connect again and look at what new messages show up in /var/log/messages during the attempt, and add them to the report? thanks. (i should probably just come over and take a look for myself, huh :>)
Created attachment 488535 [details] New /var/log/message | grep NetworkManager Here is. That would be nice =)
seems to fail to get an IP address. have you rebooted since installing the NM update, btw?
I did. Same result.
Created attachment 488698 [details] /var/log/message | grep NetworkManager New installation from Fedora 15 Beta RC1 that now runs Gnome-Shell. NetworkManager still has issue.
So...it's clearly DHCP failing, but I couldn't tell you why. Up to Dan, I guess. (I could note that on my machine, the DHCP stage after a resume from suspend takes far, far longer than you'd expect it to on a wired interface, I guess; usually 20-30 seconds. It even does time out occasionally, but a second attempt makes it connect almost immediately. Not sure if that's at all related to this.)
oh, btw, I guess it may help to have full /var/log/messages (not grepped - in case there's any relevant output from the kernel) and lspci -nn (so we know what the network hardware is). thanks.
Created attachment 488830 [details] full /var/log/messages Here is a full /var/log/messages report
Created attachment 488998 [details] lspci -nn Here is missing information. I updated to latest NetworkManager with no sucess.
So it looks like we're getting offers from the DHCP server on the wired network: Mar 30 01:45:26 muamba dhclient[1306]: DHCPDISCOVER on em2 to 255.255.255.255 port 67 interval 5 Mar 30 01:45:27 muamba dhclient[1306]: DHCPOFFER from 192.168.1.254 Mar 30 01:45:27 muamba dhclient[1306]: DHCPREQUEST on em2 to 255.255.255.255 port 67 Mar 30 01:45:30 muamba dhclient[1306]: DHCPREQUEST on em2 to 255.255.255.255 port 67 Mar 30 01:45:34 muamba dhclient[1306]: DHCPREQUEST on em2 to 255.255.255.255 port 67 Mar 30 01:45:43 muamba dhclient[1306]: DHCPDISCOVER on em2 to 255.255.255.255 port 67 interval 8 Mar 30 01:45:43 muamba dhclient[1306]: DHCPOFFER from 192.168.1.254 but the DHCP server isn't responding to the request for the address that was offered. It should look like this: Mar 28 08:50:35 dcbw dhclient[1206]: DHCPOFFER from 192.168.1.1 Mar 28 08:50:35 dcbw dhclient[1206]: DHCPREQUEST on wlan12 to 255.255.255.255 port 67 Mar 28 08:50:35 dcbw dhclient[1206]: DHCPACK from 192.168.1.1 Same thing on wifi. Is there a chance that the firewall rules are blocking DHCP? Try running the following in a terminal and then try reconnecting to your AP by picking it from the menu. sudo service iptables stop and lets see what we get.
You might also try rebooting the wifi AP (assuming that's also the DHCP server) because sometimes consumer-level wifi APs actually do get screwed up.
can you also try: systemctl disable NetworkManager.service ifup em2 (or ifup wlan12) and see if that works? just to see if it's actually NM-specific or not.
Created attachment 489200 [details] latest messages No luck with service iptables stop
(In reply to comment #19) > can you also try: > > systemctl disable NetworkManager.service > ifup em2 (or ifup wlan12) > > and see if that works? just to see if it's actually NM-specific or not. At first that command would not work until I rebooted the system. I now use em2 but I cannot use wlan0 for some odd reason.
actually it would make sense that it can't bring up the wireless connection without further configuration (the old if* scripts can't read NM's configuration data, AIUI). But you can bring up the wired interface if you do it that way? So somehow, NM is screwing up the DHCP process...
That problem occurred after updating to NM 0.9. 0.8 version worked fine on F15 Alpha. I wonder if the Network Controller module is broken with this newer NM.
Issue turned out to be a conflict with selinux-policy because I received sealert when attempting to use NetworkManager.
Here is a report from sealert from bug #693581
Created attachment 489902 [details] Latest /var/log/messages After updating selinux-policy from koji repository, the problem still occurred.
Can you try 'setenforce Permissive' at a console or boot with 'enforcing=0' parameter and see if that changes the behavior?
Sadly neither suggestion has effect on the behaviour.
The selinux denial may be unrelated, in that case. you can try with 'selinux=0' to turn selinux off harder, but it will require a relabel next time you boot with it enabled (takes some time).
No effect with selinux=0 either. After relabelling, sealert popped out when attempting to connect to either wired or wireless network. modem-manager, NetworkManager, phcscd and pulseaudio source process are reported on sealert and require huge list of label.
What selinux and systemd do you have? Hope you're not getting bitten by the various bugs surrounding actually being able to disable selinux atm. sigh.
selinux-policy 3.9.16-12 systemd 22-1
oh, yeah, that's the possibly broken stuff, so we could be in a pickle. well, in the meantime, can we see the contents of the selinux alerts, at least the ones that look relevant?
Created attachment 489918 [details] modem-manager sealert
Created attachment 489919 [details] NetworkManager sealert
Created attachment 489920 [details] pcscd sealert
Can you try with the updates from https://admin.fedoraproject.org/updates/selinux-policy-3.9.16-12.fc15,udev-167-2.fc15,systemd-23-1.fc15 , which should fix the selinux stuff? Thanks.
Updated selinux-policy and systemd seems to fix policy issue. Still no effect on NM behaviour that kept timed out.
so, seems the selinux stuff is just a red herring, but we still don't know what's causing this :(
This kind of bug appears to be a blocker for beta release =(. Trying to downgrade to old version of NM (0.8) will cause broken dependency.
well, if it was happening to more people, but as long as it's just you, it's a bit trickier - I haven't seen anyone else report a bug quite like this, yet.
Connecting on a AP Guest worked though I do not have password. Any WPA access will timed out.
On i686 Gnome 3 Live based on Fedora 15 beta, NetworkManager is working smoothly. Not sure if the issue is related to x86_64.
Turned out the entire network issue is related to this bug #693247. I can confirm it is SELinux bug. Should this report be closed as duplicate?
well, I thought you said it doesn't work if you boot with selinux disabled?
Still does not work with selinux disabled. What is odd is NetworkManager runs fine on i686 Fedora 15 based Gnome 3 Live. I am completely baffled about the issue. Hopefully udev update will resolve the problem.
No effect with latest udev update.
I installed Fedora 15 Beta RC2. The problem still exists with NetworkManager, using ifup em2 after disabling NM service no longer gives online access. It seems problem occurs on x86-64 architecture because i686 Gnome 3 Live media based on Fedora 15 is not affected.
(In reply to comment #18) > You might also try rebooting the wifi AP (assuming that's also the DHCP server) > because sometimes consumer-level wifi APs actually do get screwed up. Problem affects all AP I attempt to access except some of them with Guest name. I even rebooted my own wifi AP, NM still managed to screw up. I noticed that problem is not happening with i686 Gnome 3 Live Fedora 15 based. My laptop did not have that problem prior to Network 0.8 then used on Fedora 15 Alpha.
Comment on attachment 489918 [details] modem-manager sealert latest selinux-policy fixes does not effect NM behaviour related to DHCP
Created attachment 491884 [details] Latest /var/log/messages How to debug dhcp? I looked at my router that can see ip from my laptop. I am also including wpa_supplicant.log if that helps.
Created attachment 491885 [details] wpa_supplicant.log
Created attachment 491915 [details] Messages with succesful access to public AP Update. I was able to connect to a public AP (unsecured). I include the message. It appears the bug may be from WPA AP those have trouble to successfully set the AP. hope that will help investigating the problem.
Looking at Realtek website http://www.realtek.com.tw/downloads/downloadsView.aspx?Langid=1&PNid=48&PFid=48&Level=5&Conn=4&DownTypeID=3&GetDown=false&Downloads=true#RTL8192SE, it appears to be a kernel bug.
what are you looking at on that page exactly? You could certainly try with an older / newer kernel, you should still be able to pull various builds from Koji.
rt8188ce driver updated on April 6, 2011. I did not see the newer update of that driver inside changelog from latest kernel. The odd issue is the problem only occurs in post installation, not in live media. =(
Upgrading my wired network desktop (Acer Aspire E380) from F14 to F15 brought the same encountered issue with Toshiba Satelitte C650D. NM kept trying to connect. All updates were applied including kernel, wpa_supplicant, ModemManager. The router provided by my ISP lists the addresses. Screenshot included.
Created attachment 495927 [details] Router status
Created attachment 496006 [details] latest messages Updated /var/log/messages with both report of NM (unable to get dhpack stage) and ifconf from desktop.
Further investigation. The issue is maybe dhclient after post installation of Fedora 15. NM can list available AP and wired. Perhaps the bug should be against dhclient.
Technical note added. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: Taken from Dan quote: Mar 30 01:45:26 muamba dhclient[1306]: DHCPDISCOVER on em2 to 255.255.255.255 port 67 interval 5 Mar 30 01:45:27 muamba dhclient[1306]: DHCPOFFER from 192.168.1.254 Mar 30 01:45:27 muamba dhclient[1306]: DHCPREQUEST on em2 to 255.255.255.255 port 67 Mar 30 01:45:30 muamba dhclient[1306]: DHCPREQUEST on em2 to 255.255.255.255 port 67 Mar 30 01:45:34 muamba dhclient[1306]: DHCPREQUEST on em2 to 255.255.255.255 port 67 Mar 30 01:45:43 muamba dhclient[1306]: DHCPDISCOVER on em2 to 255.255.255.255 port 67 interval 8 Mar 30 01:45:43 muamba dhclient[1306]: DHCPOFFER from 192.168.1.254 but the DHCP server isn't responding to the request for the address that was offered. It should look like this: Mar 28 08:50:35 dcbw dhclient[1206]: DHCPOFFER from 192.168.1.1 Mar 28 08:50:35 dcbw dhclient[1206]: DHCPREQUEST on wlan12 to 255.255.255.255 port 67 Mar 28 08:50:35 dcbw dhclient[1206]: DHCPACK from 192.168.1.1 Issue affected both desktop and laptop after upgrade and installation from scratch
Renamed the bug because of dhcp issue.
Created attachment 496606 [details] ifcfg-auto_ethernet
Just to be clear is this only happening with WPA secured access points? I have a WPA2 secured access point at home and I'm not having this problem with either of the 2 F15 laptop installs I currently have. I'll pulled updates on both of those laptops yesterday over the secured home network in fact. I'm willing to try to reproduce this with test network configuration if there was a specific configuration that needed to be confirmed. -jef
Yes. In addition, my desktop which is wired connected got impacted as well. Note that running Live Media on both desktop and laptop does not display the issue. As talked with Adam on #fedora-qa, maybe the old nm config per user is the cause but I don't know the name of config file.
Mine works with #c19, but fails with NM. If I stop NM first, then manually run 'ifup eth0' or use 'network' instead of NM, it works as expected. Mine is wired only. Desktops: gnome-failback, lxde, xfce all behave the same.
Wired connections not working? Well I can definitely say that's not the case for me. Have you tried with a completely fresh user to confirm if its a stale config file? My systems are fresh 64bit Beta installs+updates running gnome shell as the interface, very little if any system or user config customization at all. Are all the affected systems upgrades from something pre-F15-Beta? -jef
(In reply to comment #67) > Wired connections not working? Not with NM. Wired connection only work with manual setup: ifcfg and network. > Are all the affected systems upgrades from something pre-F15-Beta? Yes for the desktop (upgrade straight from F14) which worked fine until latest NM update. I did a fresh network installation from my laptop using both Live Media and DVD for testing purpose. On both case, NM was able to access to Internet. I will do a fresh installation with F15 Final TC1 on my laptop.
luya: it'd be nice to track this one down before you blow away the affected installs. Looks like NM's config per-user is in gconf, System / Networking / Connections; can you take a look there and see if you can spot a difference between affected and non-affected configurations? Thanks!
Created attachment 496884 [details] gconf.xml for nm-applet Only possible nm config per user is located at .gconf/apps/nm-applet. I recently connected on another WPA2 AP at other place far from home. Odd because my home router has similar configuration yet dhcp will not respond.
Created attachment 496885 [details] Latest /var/log/messages
There's definitely a problem with your DHCP server/configuration. From your log in comment #71, connection to 'TELUS1603' always fails with DHCP timeout, while connection to 'private_wlan' and 'A11CD5' are successful; getting DHCPACK. So, I suggest you ensured there's no firewall in the way, fired up wireshark and see the DHCP datagram exchange. Moreover there are assertions in the log: May 3 11:14:45 muamba NetworkManager[3709]: nm_connection_get_setting: assertion `NM_IS_CONNECTION (connection)' failed causing NM to crash. But those are not related to this problem and are now fixed upstream (30c63ddcb721dc6c8a8273da4808d898e379eb44 : settings: fix assertion checks). (In reply to comment #69) > luya: it'd be nice to track this one down before you blow away the affected > installs. Looks like NM's config per-user is in gconf, System / Networking / > Connections; can you take a look there and see if you can spot a difference > between affected and non-affected configurations? Thanks! NM 0.9 doesn't use gconf to store connections any more. The whole concept was simplified and now we have just one settings service (instead of two system x user). As a consequence connections are stored by NM itself and are either in /etc/sysconfig/network-scripts/ifcfg-* (ifcfg-rh plugin) of /etc/NetworkManager/system-connections (keyfile plugin). Connection can be marked to be visible only for some users.
(In reply to comment #72) > There's definitely a problem with your DHCP server/configuration. From your log > in comment #71, connection to 'TELUS1603' always fails with DHCP timeout, while > connection to 'private_wlan' and 'A11CD5' are successful; getting DHCPACK. > > So, I suggest you ensured there's no firewall in the way, fired up wireshark > and see the DHCP datagram exchange. > > Moreover there are assertions in the log: > May 3 11:14:45 muamba NetworkManager[3709]: nm_connection_get_setting: > assertion `NM_IS_CONNECTION (connection)' failed Firewall is set to NAT on modem/router used for PVR as well. Should I set it lower to see in that case? Note that problem does not happen on Live Media, I will send /var/log/messages shortly.
jirka: please note the wrinkle that this is only happening with an upgraded f14, it works correctly (against the same router) in a clean f15. so it looks to be certainly caused by some kind of configuration issue in a 14->15 upgrade. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
i'm wondering if the network device renaming might have anything to do with this? -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Created attachment 497183 [details] /var/log/messages from F15 Beta Live Media Default configuration from F15 Beta live media. dhcp server has no problem in that case
Formatted over old install, and clean installed tc1, NM now works as expected again. Post update to NetworkManager-gnome-0.8.999-1.fc15.x86_64 solves this issue for me. (Even on wired network)
Created attachment 497600 [details] Wireshark report from desktop (Acer E380) Included wireshark report. I have updated NM to latest version, the problem still occurs. Same result on my laptop.
When I try to open the wireshark-desktop.txt in Wireshark i get: "The file wireshark-desktop.txt isn't a capture file in a format Wireshark understands." Can you save the packet dump in Wireshark in libpcap format (it is the default one)? Thanks
Created attachment 497818 [details] Wireshark report from desktop (Acer E380) wireshark format
Jirko, I don't see anything wrong in the DHCP messages so at the moment I can't tell why there's no DHCPACK.
Created attachment 497931 [details] Wireshark wlan0 from laptop
DHCPACK is lost/dropped somewhere or it's not even sent. - Try to monitor DHCP communication on the router side (if there is such option) - Try an USB WiFi stick to use another hardware and driver - Try downgrading to kernel used in the F15 Beta live - Try installing latest driver I am out of ideas, actually.
(In reply to comment #83) > DHCPACK is lost/dropped somewhere or it's not even sent. > > - Try to monitor DHCP communication on the router side (if there is such > option) No option availabe =( > - Try an USB WiFi stick to use another hardware and driver I do not have one at the moment. > - Try downgrading to kernel used in the F15 Beta live Tried with no effect. > - Try installing latest driver Issue is both laptop and desktop are affected. Laptop uses realtek and desktop Marvell.
Created attachment 498842 [details] Wireshark report from desktop (Acer E380) running kernel F15 beta
For details: Modem is Actiontec V1000h. Running on other OS like OSX Snow Leopard, Windows (7 and Vista), Fedora Live Media show no error. Mystery continues.
Created attachment 499072 [details] message from F15RC3 Design edition Live Attachment from latest live media.
Created attachment 499073 [details] Latest /var/log/messages from Toshiba C650 Installed F15RC3 from Live Media. Wireless is still a problem but ethernet is working fine this time.
Created attachment 499231 [details] Updated wlan0 from Toshiba C650 Wireshark wlan0 report
Created attachment 501172 [details] Updated wlan0 from Toshiba C650 Installed from F15 Design Spin which somehow solved wired network issue on both desktop and laptop. Wireless network is still a problem on post installation.
Created attachment 501371 [details] Updated wlan0 from Toshiba C650 Latest update of wlan0 from Wireshark showing fully connected wireless network with 0.8.993-3.git20110526.fc15 update. I included this attachment for comparison. I am still puzzled why wireless did not work for two months. Interesting that Design spin restored wired connection unlike DVD and Live Desktop. I will wait one week before closing this bug report. Thanks for trying to resolve this odd bug.