Bug 1386106
Summary: | NM fails to detect Red Hat VPN after first login | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Product: | Red Hat Enterprise Linux 7 | Reporter: | Alexander Todorov <atodorov> | ||||||||
Component: | NetworkManager | Assignee: | Beniamino Galvani <bgalvani> | ||||||||
Status: | CLOSED ERRATA | QA Contact: | Desktop QE <desktop-qa-list> | ||||||||
Severity: | high | Docs Contact: | |||||||||
Priority: | high | ||||||||||
Version: | 7.3 | CC: | atragler, bgalvani, lrintel, rkhan, sukulkar, thaller, vbenes | ||||||||
Target Milestone: | rc | ||||||||||
Target Release: | --- | ||||||||||
Hardware: | Unspecified | ||||||||||
OS: | Unspecified | ||||||||||
Whiteboard: | |||||||||||
Fixed In Version: | NetworkManager-1.8.0-0.2.git20170215.1d40c5f4.el7 | Doc Type: | If docs needed, set a value | ||||||||
Doc Text: | Story Points: | --- | |||||||||
Clone Of: | Environment: | ||||||||||
Last Closed: | 2017-08-01 09:19:37 UTC | Type: | Bug | ||||||||
Regression: | --- | Mount Type: | --- | ||||||||
Documentation: | --- | CRM: | |||||||||
Verified Versions: | Category: | --- | |||||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||||
Embargoed: | |||||||||||
Attachments: |
|
Description
Alexander Todorov
2016-10-18 07:54:54 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`? 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 |