Bug 1203904
Summary: | NetworkManager-openvpn uses 100% CPU | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Patrick MacArthur <generalpenguin89> | ||||||||
Component: | NetworkManager-openvpn | Assignee: | Dan Williams <dcbw> | ||||||||
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||
Severity: | unspecified | Docs Contact: | |||||||||
Priority: | unspecified | ||||||||||
Version: | 21 | CC: | choeger, dcbw, huzaifas, jklimes, psimerda, steve, sukhamayganguly, thaller | ||||||||
Target Milestone: | --- | ||||||||||
Target Release: | --- | ||||||||||
Hardware: | x86_64 | ||||||||||
OS: | Unspecified | ||||||||||
Whiteboard: | |||||||||||
Fixed In Version: | NetworkManager-1.0.2-1.fc22 | Doc Type: | Bug Fix | ||||||||
Doc Text: | Story Points: | --- | |||||||||
Clone Of: | Environment: | ||||||||||
Last Closed: | 2015-05-11 19:04:23 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
Patrick MacArthur
2015-03-19 22:37:29 UTC
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 |