Bug 1299666 - NetworkManager thinks it only has local connectivity after boot or suspend-resume
NetworkManager thinks it only has local connectivity after boot or suspend-re...
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: NetworkManager (Show other bugs)
23
x86_64 Linux
unspecified Severity medium
: ---
: ---
Assigned To: Lubomir Rintel
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2016-01-18 18:36 EST by frank7d2
Modified: 2016-05-03 10:14 EDT (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 1265730
Environment:
Last Closed: 2016-05-03 10:14:41 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
output of `journalctl -u NetworkManager -b` after reboot (444.04 KB, text/plain)
2016-01-25 04:57 EST, frank7d2
no flags Details

  None (edit)
Description frank7d2 2016-01-18 18:36:15 EST
+++ This bug was initially created as a clone of Bug #1265730 +++

Description of problem:
Whenever I boot the system or resume it from a suspend, GNOME Network Manager's status icon shows the ethernet icon with a question mark as NM thinks it only has local connectivity. If I restart the NetworkManager.service, it the icon changes to the standard ethernet icon.

Version-Release number of selected component (if applicable):
NetworkManager-0.9.10.2-5.fc21.x86_64

How reproducible:
100 %

Steps to Reproduce:
1. suspend and resume a machine with ethernet connection

Actual results:
NM thinks it only has local connectivity

Expected results:
NM reports global (Internet) connectivity

Additional info:
don't have another F21 machine to check it it's specific to my machine or not

--- Additional comment from N. Jackson on 2015-10-05 09:08:56 EDT ---

On 2015-09-23 11:01:35 EDT Vratislav Podzimek wrote: 

> don't have another F21 machine to check it it's specific to my machine or not

It's not just your machine.

I started seeing this (the '?' instead of the usual WiFi strength indicator) yesterday after updating to kernel-4.1.8-100.fc21.x86_64. (FWIW updates to enca, epiphany-runtime, freedts, liberation-fonts, perl-Encode, python-pycurl, python3-pycurl, and sqlite came down at the same time.)

As suggested,

    $ su -c 'service NetworkManager restart'

clears the problem temporarily for me. However, suspending and resuming did not bring the problem back. (Perhaps because I resumed immediately after suspending.)

I'd be happy to provide more information or perform tests if needed.

N.

--- Additional comment from Jirka Klimes on 2015-10-06 07:26:31 EDT ---

(In reply to Vratislav Podzimek from comment #0)
> Created attachment 1076255 [details]
> the chunk of the journalctl output from suspend to resume and NM restart
> 

NetworkManager correctly auto-activates ethernet connection on resume (even if it takes some time due to computer slow wake up).

Sep 23 07:29:21 workstation.podzimkovi.no-ip.biz NetworkManager[7425]: <info>  waking up...
...
Sep 23 07:29:26 workstation.podzimkovi.no-ip.biz kernel: ata6: link is slow to respond, please be patient (ready=0)
Sep 23 07:29:26 workstation.podzimkovi.no-ip.biz kernel: ata5: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
Sep 23 07:29:26 workstation.podzimkovi.no-ip.biz kernel: ACPI Error: [DSSP] Namespace lookup failure, AE_NOT_FOUND (20150410/psargs-359)
Sep 23 07:29:26 workstation.podzimkovi.no-ip.biz kernel: ACPI Error: Method parse/execution failed [\_SB_.PCI0.SAT0.SPT4._GTF] (Node ffff88040e0d1000), AE_NOT_FOUND (20150410/psparse-536)
Sep 23 07:29:26 workstation.podzimkovi.no-ip.biz kernel: ACPI Error: [DSSP] Namespace lookup failure, AE_NOT_FOUND (20150410/psargs-359)
Sep 23 07:29:26 workstation.podzimkovi.no-ip.biz kernel: ACPI Error: Method parse/execution failed [\_SB_.PCI0.SAT0.SPT4._GTF] (Node ffff88040e0d1000), AE_NOT_FOUND (20150410/psparse-536)
Sep 23 07:29:26 workstation.podzimkovi.no-ip.biz kernel: ata5.00: configured for UDMA/133
Sep 23 07:29:27 workstation.podzimkovi.no-ip.biz kernel: ata6: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
Sep 23 07:29:27 workstation.podzimkovi.no-ip.biz kernel: ACPI Error: [DSSP] Namespace lookup failure, AE_NOT_FOUND (20150410/psargs-359)
Sep 23 07:29:27 workstation.podzimkovi.no-ip.biz kernel: ACPI Error: Method parse/execution failed [\_SB_.PCI0.SAT0.SPT5._GTF] (Node ffff88040e0d1078), AE_NOT_FOUND (20150410/psparse-536)
Sep 23 07:29:27 workstation.podzimkovi.no-ip.biz kernel: ACPI Error: [DSSP] Namespace lookup failure, AE_NOT_FOUND (20150410/psargs-359)
Sep 23 07:29:27 workstation.podzimkovi.no-ip.biz kernel: ACPI Error: Method parse/execution failed [\_SB_.PCI0.SAT0.SPT5._GTF] (Node ffff88040e0d1078), AE_NOT_FOUND (20150410/psparse-536)
Sep 23 07:29:27 workstation.podzimkovi.no-ip.biz kernel: ata6.00: configured for UDMA/133
Sep 23 07:29:31 workstation.podzimkovi.no-ip.biz kernel: alx 0000:03:00.0 p4p1: NIC Up: 100 Mbps Full
Sep 23 07:29:31 workstation.podzimkovi.no-ip.biz NetworkManager[7425]: <info>  (p4p1): link connected
Sep 23 07:29:31 workstation.podzimkovi.no-ip.biz NetworkManager[7425]: <info>  (p4p1): device state change: unavailable -> disconnected (reason 'carrier-changed') [20 30 40]
Sep 23 07:29:31 workstation.podzimkovi.no-ip.biz NetworkManager[7425]: <info>  Auto-activating connection 'Wired connection 1'.


Anyway, can you get output of
$ nmcli device
$ nmcli general
to see the NetworkManager state, because the issue can be just Gnome icon problem.

--- Additional comment from Fedora End Of Life on 2015-11-04 05:17:46 EST ---

This message is a reminder that Fedora 21 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 21. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '21'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 21 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

--- Additional comment from N. Jackson on 2015-11-04 08:57:58 EST ---

I neglected to report this before, but for me at least -- the situation may be different for the OP -- the problem lasted only a few days (during which time it happened absolutely consistently) and went away after an update, so it must have been very promptly fixed.

So -- assuming I was experiencing the same issue as the OP (and it certainly seems that it was the same) -- this bug can indeed be safely closed.

N.

--- Additional comment from Vratislav Podzimek on 2015-11-12 12:45:52 EST ---

This is what I got today after resume from suspend:

[root@workstation koki]# nmcli device
DEVICE      TYPE      STATE                                  CONNECTION         
virbr0      bridge    connected                              virbr0             
p4p1        ethernet  connected                              Wired connection 1 
virbr0-nic  tap       connected                              virbr0-nic         
virbr1      bridge    connecting (getting IP configuration)  Bridge virbr1      
lo          loopback  unmanaged                              --                 

[root@workstation koki]# nmcli general
STATE       CONNECTIVITY  WIFI-HW  WIFI     WWAN-HW  WWAN    
connecting  none          enabled  enabled  enabled  enabled 

[root@workstation koki]# systemctl restart NetworkManager

[root@workstation koki]# nmcli device
DEVICE      TYPE      STATE                                  CONNECTION         
virbr0      bridge    connected                              virbr0             
p4p1        ethernet  connected                              Wired connection 1 
virbr0-nic  tap       connected                              virbr0-nic         
virbr1      bridge    connecting (getting IP configuration)  Bridge virbr1      
lo          loopback  unmanaged                              --                
 
[root@workstation koki]# nmcli general
STATE      CONNECTIVITY  WIFI-HW  WIFI     WWAN-HW  WWAN    
connected  full          enabled  enabled  enabled  enabled

--- Additional comment from Vratislav Podzimek on 2015-11-12 15:58:19 EST ---

I just tried to suspend and resume a Fedora 23 system running on the same machine and everything works here as expected. So since F21 is almost EOL anyway, I don't think anybody should spend extra time tracking down this issue.

--- Additional comment from Fedora End Of Life on 2015-12-02 10:27:53 EST ---

Fedora 21 changed to end-of-life (EOL) status on 2015-12-01. Fedora 21 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

-------------------------------------------------------------------------
I have a fresh installation of Fedora 23 workstation on a hp 820g1 laptop.

I experience the same behaviour as the cloned bug, except that after supend/resume there is connectivity if there was connectivity before.
So, after every boot I have to restart NetworkManager.service.

I have this problem since I set up the system a couple of months ago. The system has been updated once a week or so.
Comment 1 Beniamino Galvani 2016-01-19 03:09:10 EST
Can you please add level=DEBUG to the [logging] section of /etc/NetworkManager/NetworkManager.conf, reboot the system and attach the output of "journalctl -u NetworkManager -b"? Thanks.
Comment 2 frank7d2 2016-01-25 04:57 EST
Created attachment 1117894 [details]
output of `journalctl -u NetworkManager -b` after reboot
Comment 3 Beniamino Galvani 2016-03-25 11:45:38 EDT
(In reply to frank7d2 from comment #2)
> Created attachment 1117894 [details]
> output of `journalctl -u NetworkManager -b` after reboot

Hi, sorry for the delay. There is a Bridge1 connection for interface br0 with autoconnect=yes and NM is trying to activate it before signaling the termination of startup procedure, but the interface has no slaves, and thus, no carrier. I suggest to set autoconnect=no or delete it if you don't need it.
Comment 4 frank7d2 2016-03-27 15:29:53 EDT
thank you very much. I used the bridge for VMs on my old system and had copied it together with other stuff to my new system. My fault.
Comment 5 Beniamino Galvani 2016-05-03 10:14:41 EDT
(In reply to frank7d2 from comment #4)
> thank you very much. I used the bridge for VMs on my old system and had
> copied it together with other stuff to my new system. My fault.

I guess this can be closed then.

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