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`?

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.

# 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.

> 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.

what gives
  nmcli general
when you see the VPN entries disabled?

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 :)

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.

Created attachment 1214575 [details]
NM log with level=TRACE

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.

(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

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.

Looks good!

Patch applied to master and nm-1-4:

https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=084da69a305be740b5e3cd3e6d3a9a827657a81d

https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?h=nm-1-4&id=561a0a428d1d2ba678788e645f1ce52263ad8ac5

vpn connections are not blocked by any connecting device

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