Bug 1386106 - NM fails to detect Red Hat VPN after first login
Summary: NM fails to detect Red Hat VPN after first login
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: NetworkManager
Version: 7.3
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: rc
: ---
Assignee: Beniamino Galvani
QA Contact: Desktop QE
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-10-18 07:54 UTC by Alexander Todorov
Modified: 2017-08-01 09:19 UTC (History)
7 users (show)

Fixed In Version: NetworkManager-1.8.0-0.2.git20170215.1d40c5f4.el7
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-08-01 09:19:37 UTC


Attachments (Terms of Use)
Screenshot of NM after login (80.02 KB, image/png)
2016-10-26 07:30 UTC, Alexander Todorov
no flags Details
NM log with level=TRACE (283.11 KB, text/plain)
2016-10-27 11:14 UTC, Alexander Todorov
no flags Details
[PATCH] manager: force connectivity check when there is a default active connection (3.57 KB, patch)
2016-10-28 13:24 UTC, Beniamino Galvani
no flags Details | Diff


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2017:2299 normal SHIPPED_LIVE Moderate: NetworkManager and libnl3 security, bug fix and enhancement update 2017-08-01 12:40:28 UTC

Description Alexander Todorov 2016-10-18 07:54:54 UTC
Description of problem:

After upgrade to RHEL 7.3 I have:

NetworkManager-1.4.0-12.el7.x86_64
NetworkManager-vpnc-1.0.8-1.el7.x86_64 (from EPEL)

After logging into the desktop environment all of my VPN connections are disabled. Restarting NM enables them and I'm able to connect. I don't see anything that may hint as to what the problem is but maybe I'm not looking into the right logs. Please let me know how to provide more information.

Related bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1298732#c9

Comment 1 Thomas Haller 2016-10-21 10:09:12 UTC
The bug description is not very clear to me.

What do you mean with "connections are disabled"? You mean, the VPNC connection profile is not activated? Did you do anything before logging into the desktop environment that should have activated the connection profile?


Maybe you can detail better what you actually did. What gives `nmcli device` and `nmcli connection show`?

Comment 2 Alexander Todorov 2016-10-26 07:30:56 UTC
Created attachment 1214190 [details]
Screenshot of NM after login

This is how NM looks like right after logging into the desktop. I will try the commands next.

NOTE: I'm using an older kernel because my system seems to freeze randomly with the latest one but the kernel version doesn't seem to affect this bug.

Comment 3 Alexander Todorov 2016-10-26 07:39:37 UTC
# nmcli device

DEVICE      TYPE      STATE                                  CONNECTION 
docker0     bridge    connected                              docker0    
virbr0      bridge    connected                              virbr0     
wlp3s0      wifi      connected                              atelie8    
br0         bridge    connecting (getting IP configuration)  bridge-br0 
lo          loopback  unmanaged                              --         
virbr0-nic  tun       unmanaged  

# nmcli connection show
NAME                     UUID                                  TYPE             DEVICE  
atelie8                  19da775d-cbda-49f4-a4b2-8d9cd2128292  802-11-wireless  wlp3s0  
bridge-br0               06a8d306-ffd8-495e-a9fa-2a9f8f65c78c  bridge           br0     
docker0                  22bd73b6-69b5-4500-b72c-bc903b2a5bf3  bridge           docker0 
virbr0                   91e38df8-2ac1-4075-9d28-c73035b6cc1c  bridge           virbr0  
Red Hat Amsterdam        419733a7-f008-45df-9e1c-bf714b7a21a5  vpn              --      
.... skip ....

This is the output before I restart NM and connect to VPN. Afterwards it's the same with the exception that "Red Hat Amsterdam" is now connected.

Comment 4 Alexander Todorov 2016-10-26 07:40:44 UTC
> Did you do anything before logging into the desktop environment that should have activated the connection profile?

Nope. Reboot, login and then you have the above screenshot.

Comment 5 Thomas Haller 2016-10-26 09:13:24 UTC
what gives
  nmcli general
when you see the VPN entries disabled?

Comment 6 Alexander Todorov 2016-10-27 10:31:25 UTC
This is strange. nmcli general shows I'm still connecting to network, while clearly I have connected already:

$ nmcli general
STATE       CONNECTIVITY  WIFI-HW  WIFI     WWAN-HW  WWAN    
connecting  none          enabled  enabled  enabled  enabled 

$ ip a s
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: wlp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 34:36:3b:86:04:e2 brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.107/24 brd 192.168.0.255 scope global dynamic wlp3s0
       valid_lft 7171sec preferred_lft 7171sec
    inet6 fe80::3636:3bff:fe86:4e2/64 scope link 
       valid_lft forever preferred_lft forever
3: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN 
    link/ether 56:84:7a:fe:97:99 brd ff:ff:ff:ff:ff:ff
    inet 172.17.42.1/16 scope global docker0
       valid_lft forever preferred_lft forever
4: br0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN 
    link/ether b6:66:b8:3e:5d:33 brd ff:ff:ff:ff:ff:ff
5: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN 
    link/ether 52:54:00:e6:cc:48 brd ff:ff:ff:ff:ff:ff
    inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0
       valid_lft forever preferred_lft forever
6: virbr0-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast master virbr0 state DOWN qlen 500
    link/ether 52:54:00:e6:cc:48 brd ff:ff:ff:ff:ff:ff

As of writing the VPN entries are still disabled but I do have Internet access obviously :)

Comment 7 Thomas Haller 2016-10-27 10:43:59 UTC
the items in the GUI are disabled, because you (seemingly) have no connectivity.

I think overall that doesn't make sense, and the UI should just allow the user to click on it (and possibly activation failing later as the user is not connected to the internet). So, that could be improved in the UI.


As to why you have no connectivity, is a different question.
Please attach a debugging logfile of NetworkManager with level=TRACE logging.

Comment 8 Alexander Todorov 2016-10-27 11:14:23 UTC
Created attachment 1214575 [details]
NM log with level=TRACE

Comment 9 Beniamino Galvani 2016-10-28 13:24:59 UTC
Created attachment 1214990 [details]
[PATCH] manager: force connectivity check when there is a default active connection

From comment 3 and comment 6 output, it seems that we fail to
recognize full connectivity when there is a connection stuck in the
activation (bridge-br0). The attached patch should fix the issue on NM
side, but I agree that the UI should be also modified to always allow
the activation of VPN connections.

Comment 10 Thomas Haller 2016-10-28 15:38:52 UTC
(In reply to Beniamino Galvani from comment #9)
> Created attachment 1214990 [details]
> [PATCH] manager: force connectivity check when there is a default active
> connection

lgtm.

> I agree that the UI should be also modified to always allow
> the activation of VPN connections.

+1

Comment 11 Beniamino Galvani 2016-11-07 09:35:12 UTC
After the connectivity check is fixed on NM side, probably the UI requirement of connectivity should be kept, because when there isn't any connectivity (not even LOCAL or SITE), the VPN can't be established.

Comment 12 Lubomir Rintel 2016-11-07 10:57:39 UTC
Looks good!

Comment 15 Vladimir Benes 2017-06-13 13:19:47 UTC
vpn connections are not blocked by any connecting device

Comment 16 errata-xmlrpc 2017-08-01 09:19:37 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2017:2299


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