Red Hat Bugzilla – Bug 443634
No network connection available
Last modified: 2008-05-06 12:05:55 EDT
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
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
A popup "No network connection available. Problem with loading repository
metadata, this can be caused by network problems or repository
I don't know, this is the first time I try to use this tools
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
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?
- Device: eth0 ----------------------------------------------------------------
HW Address: 00:00:00:00:00:00
Carrier Detect: yes
Speed: 100 Mb/s
- Device: wlan0
Type: 802.11 Wireless
HW Address: 00:1D:E0:A2:7D:AD
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:188.8.131.52 Bcast:184.108.40.206 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
RX bytes:27587 (26.9 KiB) TX bytes:15898 (15.5 KiB)
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
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
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
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
"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".
>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.
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.