You bring up so many different points, that it's hard to keep track of them. It would be better to discuss them individually or open Bugs for it.
> I managed to also integrate it with the plasma applet thing for KDE > 4, > which is really nice in user interface terms for the largest part > (after > you realise the non-button-like tool icon is not decoration but a > vital > part of its configuration). > Which is not a NM issue but KDE, it is one of the least intuïtive > ways > to present a button and pretend to hope that the user will understand > to > click on it. The argument against the argument against was probably > "well, he just has to hover over it, doesn't he"?. Anyway. KDE/plasma-nm design decision. Please open a bug. > I happened to create a kind of forward shell script that added the > option --cipher none to NM's openvpn invocation. This may be the > cause > of my current problems, in that NM constantly loses track of an > existing > openvpn connection/process. From your wrapper script, do you invoke the openvpn binary with "exec", contrary to "call"? That seems important. > Symptoms I've seen were: > > * OpenVPN takes longer to connect due to an issue. When finally it > connects (as it keeps running in the background) this happens: > > /usr/lib/nm-openvpn-service-openvpn-helper --tun -- tun0 1500 1528 > 10.8.0.6 10.8.0.5 init > > Could not send configuration information: The name > org.freedesktop.NetworkManager.openvpn was not provided by any > .service > files". your installation seems broken. > So basically what I see is that if OpenVPN disconnects, it notifies > NM, > but once it reconnects, NM doesn't know and the process becomes like > a > ghost process. > > And I have to manually shut it down each and every time. > > At least if I run my VPN manually I have NO ISSUES except for the one > issue that NM will not allow me to remove the default route for its > managed connection. > > So whatever way you frame it, NM is really my only issue ;-). OpenVPN > itself works without a hitch. > > > ============================== > > Then you have the problem that NM doesn't know about OpenVPN's > "cipher > none" mode. You cannot get it (I cannot get it) to pass that > parameter > to OpenVPN. It's a UI bug only (https://git.gnome.org/browse/network-manager-openvp n/commit/?id=be63c404a146704e3e4840f050d5bdd63bc94826) You can still use the none cipher by configuring it either with nmcli or by editing the connection file under /etc/NetworkManager/system -connections/. > > ============================== > > The only benefit for NM for me at this point is its gui. Without the > lock icon in the system tray, it is hard for me to know whether I am > running VPN or not. And because of its interface it's easier to start > and stop it. Using the console to do that is not fun. > > ============================== > > Sometimes my tunnel fails and since it is a simple SSH tunnel using > /root/.ssh/config but with a custom startup script, I have to check > on > its status using the console. That is tiresome by itself, but OpenVPN > is > capable of just picking up where it left; it's just that NM mostly is > not. > > ============================== > > I have a custom dispather.d script that sets another route on vpn-up. > I > need this for my tunnel host (which is also the VPN host). I think I > can > also do this using VPN options (extra routes) but my problem at this > point is this: > > Is there a way to obtain the equivalent of OpenVPN variable > "net_gateway"? _ net_gateway _ is a variable that indicates the OLD > gateway address before VPN is activated. I know there is IP4_ROUTE_N > and > IP4_NUM_ROUTES. But at best this is a list of all routes. Do I have > to > manually search it for the route to 0.0.0.0? Same for VPN_, I don't > know > if it contains the new route or the old routes. Maybe both even. IP4_GATEWAY environment variable. See `man NetworkManager` Or `nmcli -t -f IP4.GATEWAY connection show uuid $CONNECTION_UUID` > In OpenVPN the program gives me the required route target so I don't > have to fix it in any script. With NM I have to write a custom script > or > add a route to the config that seems to have to be fixed????. > > ============================== > > When NM has a connection as managed, manual interference with IP > address > and such becomes impossible. I consider this a big problem. The > problem > does not arise with adding new IP addresses to any device. What is your basis to claim "impossible". It is possible. What issues did you encounter? > ============================== > > When manually using OpenVPN from/above/on top of a connection that is > managed, I cannot remove the default route of the managed connection, > whereas that is mostly 'necessary' for the main type of VPN use. > > NM should honour user decisions more instead of forcing correctness > from > its own model, which is (or very likely can be) incomplete. > > The fallacy is to think or consider that NM is always fully > configured. You can configure default-routes externally. NM should not interfere if you set "ipv4.never-default=yes". > > Or even that it is feature complete. > > ============================== > > The issues with "forgetting" the OpenVPN process could be caused by > my > renaming openvpn to openvpn.real. But that would be rather odd > because > it would imply a dependency on the process NAME whereas it seems as > though NM takes care of a 'callback' feature in OpenVPN. Maybe it's "forgetting" the process, because your wrapper script spawns away. Did you use "exec"? Thomas
signature.asc
Description: This is a digitally signed message part
_______________________________________________ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
