Description of problem: When I click on a menu entry like "GNOME desktop" or "KDE desktop", I get immediately a popup which tell me "No network connection available", but network connection is OK. Version-Release number of selected component (if applicable): gpk-application-0.1.12 on Fedora 9 Preview KDE live x86_64 How reproducible: Always Steps to Reproduce: 1. Install Fedora 9 Preview KDE live x86_64 2. Install network and check it works 3. In the "F" menu, choose Administration -> Add/Remove sofware 4. Click in the list in the left Actual results: A popup "No network connection available. Problem with loading repository metadata, this can be caused by network problems or repository misconfiguration." Expected results: I don't know, this is the first time I try to use this tools Additional info: The selected repos are: Fedora 8.93 - x86_64 Fedora 8.93 - x86_64 - Updates And if I unplug network from the laptop, it takes a long time before the popup open.
Are you running NetworkManager?
No, I setup network with system-config-network
Humm.. It seems I was wrong. NetworkManager is running. If I select only Fedora Rawhide as repository, the popup is different : "No package cache is available. Package cache was invalid and has been rebuilt."
>Package cache was invalid and has been rebuilt That's been fixed already, i just need to upload a new snapshot. Do you use NetworkManager to connect your network, or use system-config-network? Do you have the icon in the top right?
I first used system-config-network but I saw later that the NetworkManager daemon was running. There is no icon on the desktop but something labeled "Add widget - Zoom out"
What's the output of nm-tool?
NetworkManager Tool State: disconnected - Device: eth0 ---------------------------------------------------------------- Type: Wired Driver: e1000e State: unmanaged HW Address: 00:00:00:00:00:00 Capabilities: Supported: yes Carrier Detect: yes Speed: 100 Mb/s Wired Settings - Device: wlan0 ---------------------------------------------------------------- Type: 802.11 Wireless Driver: iwl4965 State: disconnected HW Address: 00:1D:E0:A2:7D:AD Capabilities: Supported: yes Wireless Settings WEP Encryption: yes WPA Encryption: yes WPA2 Encryption: yes Wireless Access Points Output of ifconfig eth0 Link encap:Ethernet HWaddr 00:0B:97:DD:15:85 inet addr:82.224.136.31 Bcast:82.224.136.255 Mask:255.255.255.0 inet6 addr: fe80::20b:97ff:fedd:1585/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:78 errors:0 dropped:0 overruns:0 frame:0 TX packets:97 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:27587 (26.9 KiB) TX bytes:15898 (15.5 KiB) Memory:fc600000-fc620000 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:2908 errors:0 dropped:0 overruns:0 frame:0 TX packets:2908 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:4738152 (4.5 MiB) TX bytes:4738152 (4.5 MiB)
This sounds like a NetworkManager bug, then - it's reporting the network is down when it isn't. If I'm reading it right, eth0 is explicitly set to not managed by NM, but still, it makes NM less useful if it's reporting of the disconnected/connected status isn't accurate. Assigning to dcbw for comment.
No, if the device is not managed by NetworkManager, _by definition_ NetworkManager is unaware of it's state and whether it has a connection. Go into system-config-network, click on your device in the list, and check the "Controlled by NetworkManager" checkbox, and save. NM will now be able to manage your device.
Checking "Controlled by NetworkManager" don't change anything! And I don't like you close this bug without you really purpose a solution. I'm tired about RedHat people who never listen to me. You are « la goutte d'eau qui fait déborder le vase ». Find a french people who be able to translate my anger! I'm tired to never find a minimum of consideration. I'll go to find it in another distribution. I was a Redhat/Fedora user/contributor since I discover Linux 8 years ago. Now, this is the end.
If NetworkManager isn't going to be a reliable indicator of 'has a network connection', then we need to change our logic to check for a network connection differently, and not rely solely on NM.
>la goutte d'eau qui fait déborder le vase The last drop of water to make the vase spill? Or the last straw to break the camels back? Either way I think maybe closing this bug might have been a little premature. What's difficult for us to do, is that you seem to be running the NetworkManager service, and not using it - so even if we try to connect to NM and then fall back to the output of "ping" - it will fail as NM would give a valid connection. We could maybe check the res_query() status regardless of what system is used - if you could help us add something like that it would be very appreciated, and accepted upstream. Richard.
Robin: if NetworkManager is running, you use that for indication of network connectivity. If NM is not running, then some other method must be used. If the user has unmanaged a device, that's their problem, and not something that we are really going to "support". Users who unmanage devices from NM know enough figure stuff out for themselves. The largest reason for this in the past was static IP, which NM 0.7 certainly supports.
Dan - oops, sorry, I meant to reopen this and reassign it back to me. By 'change our logic' in comment #11, I meant change PackageKit's logic, which right now says (IIRC): "If NetworkManager reports no connections, don't even try to get updates." IOW, using PackageKit requires that the user use NetworkManager. This probably isn't a reasonable requirement for all users, so we should either address it in PK or explicitly declare that using PK requires that the user use NM. Not NetworkManager's bug at this point, so assigning back to me.
Robin: ah, I see. IMHO, correct behavior is: 1) If NM service is running: query NM for active connections, do the right thing with GSM/CDMA, etc too since you can actually get that information out of NM. 2) If NM service is not running, scrape routing table for the default route. If there is a default route, assume a connection to the internet. If no default route, assume no connection. But allow the user to force a PK update if they want through the "Update System" dialog.
I updated with gnome-packagekit-0.1.12-5.20080416git.fc9.x86_64 There is no more the message "No network connection available". Now, when I click on a software group, I get "No results were found" in the right window of gpk. The only selected repository is "Fedora - Rawhide". Sorry if there is something that I don't understand but as I'm still on FC6 on other PC, there is the first time I try to use gpk.
I updated my system with gpk-update-viewer, so now, if I'm running it, it tells me of course "There are no updates available". But if I click "Refresh", I get "No network connection available".
Dan, >If NM service is not running, scrape routing table for the default route. >If there is a default route, assume a connection to the internet. >If no default route, assume no connection. How do I trivially grab the default route? I'll add the fallback code today. Thanks. Richard.
Created attachment 304648 [details] what i'm about to push to master Something like this should fix up the network detection problems when we are not using NetworkManager.