Bug 492147 - static uncontrolled ip == off-line in Gnome
static uncontrolled ip == off-line in Gnome
Product: Fedora
Classification: Fedora
Component: NetworkManager (Show other bugs)
All Linux
low Severity medium
: ---
: ---
Assigned To: Dan Williams
Fedora Extras Quality Assurance
: 494523 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2009-03-25 11:52 EDT by David Nečas
Modified: 2009-06-19 18:07 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-06-19 18:07:32 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description David Nečas 2009-03-25 11:52:41 EDT
Description of problem:
Since one of the updates (apparently), having a static NM-not-controlled eth0 connection means Gnome thinks I am off-line.

Version-Release number of selected component (if applicable):

How reproducible:
Always (the current state), not possible (the exact events leading to that).

Steps to Reproduce:
1. ifcfg-eth0:
# Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller

chkconfig --level 2345 network on
chkconfig --level 2345 NetworkManager on

3. Boot to Gnome (with no other network connection).

Actual results:
nm-applet shows `no connection' state and the tooltip reads `No network connection'.  Firefox starts in off-line mode.

Otherwise, the connection works, ifconfig prints for eth0

eth0      Link encap:Ethernet  HWaddr ...
          inet addr:  Bcast:  Mask:
          inet6 addr: fe80::.../64 Scope:Link
          RX packets:2491 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2169 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:1564149 (1.4 MiB)  TX bytes:366733 (358.1 KiB)
          Interrupt:19 Base address:0x2000 

as expected.  Connecting and disconnecting the cable shows that NetworkManager is aware of the connection state:

Mar 25 16:31:40 localhost kernel: r8169: eth0: link down
Mar 25 16:31:40 localhost NetworkManager: <info>  (eth0): carrier now OFF (device state 1)
Mar 25 16:31:43 localhost kernel: r8169: eth0: link up
Mar 25 16:31:43 localhost NetworkManager: <info>  (eth0): carrier now ON (device state 1)

Somehow, this information does not get to Gnome.  I don't know if dbus-monitor is expected to print something on cable connection/disconnection but it does not.

Expected results:
Concerning the connection the same; but in addition, nm-applet and other parts of Gnome know about the connection.

Additional info:
This used to work.

Things went wrong after some of the updates *and* a failure of the wired connection.  This occurred on March 17th, i.e. not immediately after the NM update.

After the failure, eth0 spontaneously became NM-controlled with DHCP on, I lost the static IP configuration and service network was spontaneously disabled.  I configured everything again and re-enabled the network service.  The network works, but Gnome does not know about it.
Comment 1 Dan Williams 2009-04-08 21:41:29 EDT
If you are not allowing NetworkManager to control your primary network connection, then you probably want to turn NetworkManager off.  NetworkManager is meant to control the primary network connection.  Is there some reason you've made NM ignore eth0?
Comment 2 David Nečas 2009-04-09 04:36:14 EDT
I have lots of bad experience with NetworkManager understanding (or rather lack of understanding) that I want a wired device's IP static and never spontaneously change to something else.  On the other hand, NM works well with ad hoc connections such as WiFi so do not want to disable it entirely.

But I digress.  The point is: Since the connection state is known even if NM does not control the connection there is no reason why it could not be reflected in Gnome.

Well, I made the connection NM-controlled for now, looking forward to loss of the static configuration on the nearest occasion...
Comment 3 Dan Williams 2009-04-09 09:36:04 EDT
Static connections should not get dropped by NM unless you pull the plug and kill the wired device's carrier.  But when you plug back in, it will get applied again.  If you find that NM does, for some reason, drop the connection, please grab /var/log/messages from the time that it drops and attach to the bug so I can figure out what's going on.   Again, if it's a static connection, there's no real reason for NM to terminate it except for carrier changes.
Comment 4 David Nečas 2009-04-09 10:03:25 EDT
Unfortunately, we are talking about two separate issues:

1) Whether my reasons for disabling NM for a particular network interface were valid and what might/should have been done instead.

2) The actual subject of this bug, that is, when the network interface is not NM-controlled, the GUI thinks I am off-line.

Please focus on 2).  I am willing to admit any my fault concerning 1) and I can also try to gather relevant data for another bugreport (which is not easy because the sequences of events leading to problems are often hard to reproduce, there are already quite a few reports of similar issues that might or might not have the same cause and NM changes so often that data a few months old can be irrelevant).  However, this does not make 2) disappear.
Comment 5 Dan Williams 2009-04-09 10:43:46 EDT
(In reply to comment #4)
> Unfortunately, we are talking about two separate issues:
> 1) Whether my reasons for disabling NM for a particular network interface were
> valid and what might/should have been done instead.
> 2) The actual subject of this bug, that is, when the network interface is not
> NM-controlled, the GUI thinks I am off-line.

Of course the GUI doesn't think you're online, because the network interface isn't NM controlled!  If the interface was NM controlled, then the GUI would think you were online.  That's the whole point here.  If you're not using NetworkManager to control your primary internet connection, then you can turn NM off, and the GUI simply wont care whether you're online or off.  Or, you can let NM control your primary network connection, and the GUI will correctly figure out online/offline by asking NM.

Obviously, if the primary network connection isn't controlled by NM, there's no information available as to whether it's online or offline, since NM is the thing that provides that information.

If NM for some reason terminates the static connection, let me know, becuase that could be a bug.
Comment 6 David Nečas 2009-04-09 11:16:47 EDT
> Of course the GUI doesn't think you're online, because the network
> interface isn't NM controlled!

OK, if I accept this[*], then the problem is the lack of a command that would tell the GUI that I am, in fact, on-line now so that it is not necessary to tell each application separately.

I have not tried to run `service NetworkManager stop'.   But this would not be a solution even if it automagically brought me to the old days when programs simply assumed I had network connection when I ran something that required it.  Because NM must be started and stopped as root, whereas the whole point is to convince a bunch of user processes (owned by me) that the machine is on-line.

So, to reiterate.  In the setup desribed, both static and ad-hoc connections work, I never need to run anything as root, the machine is on-line -- yet there are no means to convince the GUI that it is on-line.  This is a bug.

[*] As a matter of fact, I do not.  Not controlled != connection state is unknown.
Comment 7 Dan Williams 2009-04-09 11:59:08 EDT
No, the fix is to use NetworkManager to manage your primary internet connection, becuase NetworkManager figures out when you're online and when you're not for the various different connection methods.  Or don't use NM.  Again, you have two choices:

1) let NetworkManager control your primary network connection

2) turn NetworkManager off and manually control your network connections

Again, if there's a bug where NetworkManager is not sufficiently able to control your primary internet connection, please let me know.  Otherwise, this is not bug, because the two solutions to your problem are mentioned above.
Comment 8 Dan Williams 2009-04-11 07:29:19 EDT
*** Bug 494523 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.