Description of problem: When connecting to a VPN that pushes a moderately complex set of routes to the client, the connection succeeds but uses 100% CPU and spams the logs with the same message over and over again. This issue does not occur when connecting to a VPN which pushes only a single default route. Version-Release number of selected component (if applicable): NetworkManager-0.9.10.1-3.20150219git.fc21.x86_64 NetworkManager-openvpn-1.0.0-1.fc21.1.x86_64 How reproducible: Connect to an openvpn server which pushes something like the following two routes: 0.0.0.0/1 -> gateway 128.0.0.0/1 -> gateway Steps to Reproduce: 1. Set up VPN in NetworkManager client configuration. 2. Connect to VPN. 3. Examine CPU usage with something like top. Actual results: NetworkManager indicates that the VPN is up, but does not print out all expected log messages to the systemd journal, and spams the journal with the following message over and over again: Mar 19 14:57:18 lancelot NetworkManager[9062]: <error> [1426802238.475451] [devices/nm-device.c:1750] nm_device_generate_connection(): (tap0): Generated connection does not verify: ipv4.routes: 1. route is invalid Expected results: NetworkManager indicates that the VPN is up and prints messages into the systemd journal concluding with "Activation (tap0) successful, device activated." Additional info:
I reproduced that by setting up testing OpenVPN server using sample files from /usr/share/doc/openvpn/sample/... and adding push "route remote_host 255.255.255.255 net_gateway" push "route 0.0.0.0 128.0.0.0 10.8.0.5" push "route 128.0.0.0 128.0.0.0 10.8.0.5" to server.conf The problem is that 0.0.0.0/1 is denied in libnm-util verify() as invalid. The NM 1.0 and master seems fine. It uses libnm instead and there might be other fixes as well. Test scratch build with a fix: http://koji.fedoraproject.org/koji/taskinfo?taskID=9279924
Created attachment 1004532 [details] [PATCH] fix loop in NM on 0.0.0.0/1 route Allow 0.0.0.0/1 route in libnm-util:verify()
(In reply to Jirka Klimes from comment #2) > Created attachment 1004532 [details] > [PATCH] fix loop in NM on 0.0.0.0/1 route > > Allow 0.0.0.0/1 route in libnm-util:verify() this looks right. The loop of regenerating and failing a connection would also need fixing, right?
Shouldn't we also verify the routes in libnm-util/nm-setting-ip6-config.c? and actually, it should be - if (!nm_ip4_route_get_dest (route)) { + if (prefix == 0) { we want to reject here default routes -- which is a route with prefix==0.
(In reply to Jirka Klimes from comment #1) > I reproduced that by setting up testing OpenVPN server using sample files > from > /usr/share/doc/openvpn/sample/... > and adding > push "route remote_host 255.255.255.255 net_gateway" > push "route 0.0.0.0 128.0.0.0 10.8.0.5" > push "route 128.0.0.0 128.0.0.0 10.8.0.5" > to server.conf > > The problem is that 0.0.0.0/1 is denied in libnm-util verify() as invalid. > > The NM 1.0 and master seems fine. It uses libnm instead and there might be > other fixes as well. > > Test scratch build with a fix: > http://koji.fedoraproject.org/koji/taskinfo?taskID=9279924 The scratch build fixed the issue for me.
Created attachment 1005246 [details] [PATCH] fix loop in NM on 0.0.0.0/1 route Actually, we can just remove the 'if (!nm_ip4_route_get_dest (route)' check. There's no such check for IPv6 routes.
(In reply to Jirka Klimes from comment #6) > Created attachment 1005246 [details] > [PATCH] fix loop in NM on 0.0.0.0/1 route > > Actually, we can just remove the 'if (!nm_ip4_route_get_dest (route)' check. > There's no such check for IPv6 routes. yes, the !prefix check below is enough. I think ipv6 should validate the routes too, as it does for ipv4. it still needs fixing of the loop when the generated connection does not verify.
(In reply to Thomas Haller from comment #7) > (In reply to Jirka Klimes from comment #6) > > Created attachment 1005246 [details] > > [PATCH] fix loop in NM on 0.0.0.0/1 route > > > > Actually, we can just remove the 'if (!nm_ip4_route_get_dest (route)' check. > > There's no such check for IPv6 routes. > > yes, the !prefix check below is enough. > > I think ipv6 should validate the routes too, as it does for ipv4. > In the next patch iteraction. > > it still needs fixing of the loop when the generated connection does not > verify. Yes, we should look into it. But actually it is independent of the routes verification and can be done separately later.
Created attachment 1005251 [details] [PATCH] fix loop in NM on 0.0.0.0/1 route
Looks fine to me. On 1.0+ Thomas did some work to allow 0.0.0.0 routes in the settings specifically, which is why they work OK. 0.9.10 doesn't have those enhancements so the best we can do is work around it for situations like this.
Committed upstream: ba35c63 libnm-util: allow 0.0.0.0/1 route in verify() (rh #1203904) - master cd5c904 libnm-util: allow 0.0.0.0/1 route in verify() (rh #1203904) - nm-1-0 5a09a12 libnm-util: allow 0.0.0.0/1 route in verify() (rh #1203904) - nm-0-9-10
(In reply to Jirka Klimes from comment #8) > (In reply to Thomas Haller from comment #7) > > it still needs fixing of the loop when the generated connection does not > > verify. > Yes, we should look into it. But actually it is independent of the routes > verification and can be done separately later. leaving bug in NEW to fix ^^^ :) The larger bug is IMO that hell breaks loose if we generate an invalid connection.
NetworkManager-0.9.10.2-3.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/NetworkManager-0.9.10.2-3.fc21
NetworkManager-1.0.2-1.fc22,network-manager-applet-1.0.2-1.fc22,NetworkManager-openconnect-1.0.2-1.fc22,NetworkManager-openvpn-1.0.2-1.fc22,NetworkManager-vpnc-1.0.2-1.fc22,NetworkManager-openswan-1.0.2-1.fc22 has been submitted as an update for Fedora 22. https://admin.fedoraproject.org/updates/NetworkManager-1.0.2-1.fc22,network-manager-applet-1.0.2-1.fc22,NetworkManager-openconnect-1.0.2-1.fc22,NetworkManager-openvpn-1.0.2-1.fc22,NetworkManager-vpnc-1.0.2-1.fc22,NetworkManager-openswan-1.0.2-1.fc22
I can confirm that the issue is no longer present with NetworkManager-0.9.10.2-3.fc21.
Package NetworkManager-1.0.2-1.fc22, NetworkManager-openconnect-1.0.2-1.fc22, NetworkManager-vpnc-1.0.2-1.fc22, network-manager-applet-1.0.2-1.fc22, NetworkManager-openvpn-1.0.2-1.fc22, NetworkManager-openswan-1.0.2-1.fc22: * should fix your issue, * was pushed to the Fedora 22 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing NetworkManager-1.0.2-1.fc22 NetworkManager-openconnect-1.0.2-1.fc22 NetworkManager-vpnc-1.0.2-1.fc22 network-manager-applet-1.0.2-1.fc22 NetworkManager-openvpn-1.0.2-1.fc22 NetworkManager-openswan-1.0.2-1.fc22' as soon as you are able to, then reboot. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2015-7767/NetworkManager-1.0.2-1.fc22,network-manager-applet-1.0.2-1.fc22,NetworkManager-openconnect-1.0.2-1.fc22,NetworkManager-openvpn-1.0.2-1.fc22,NetworkManager-vpnc-1.0.2-1.fc22,NetworkManager-openswan-1.0.2-1.fc22 then log in and leave karma (feedback).
NetworkManager-1.0.2-1.fc22, NetworkManager-openconnect-1.0.2-1.fc22, NetworkManager-vpnc-1.0.2-1.fc22, network-manager-applet-1.0.2-1.fc22, NetworkManager-openvpn-1.0.2-1.fc22, NetworkManager-openswan-1.0.2-1.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.
NetworkManager-0.9.10.2-5.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.
fedora not take update