Re: network-manager-iodine
Hi Dan, On Mon, Feb 27, 2012 at 09:42:04AM -0600, Dan Williams wrote: [..snip..] > Plugins use the "failure" signal to indicate that, using libnm-glib that > would be: > > nm_vpn_plugin_failure (NM_VPN_PLUGIN (plugin), > NM_VPN_PLUGIN_FAILURE_CONNECT_FAILED); > > with the correct error code. The current error codes aren't very > detailed, but if there's one we need we can certainly add it. And in It's enough to distinguish between bad password and other failures which should help users to track down problems. Added that. > reality, we should be adding a more detailed error signal that also > takes a descriptive string with more information that can be logged by > NM or passed up to the user. That's not hard to implement, just a > parallel signal to Failure that has a "us" dbus signature. That would indeed be nice since iodine terminates connections after 60 seconds. So telling the user exactly this would be helpful. I'll add this to my to do list but won't be able to work on this in the near future. Thanks, -- Guido ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: network-manager-iodine
On Sun, 2012-02-26 at 18:40 +0100, Guido Günther wrote: > Hi Dan, > On Fri, Feb 24, 2012 at 02:25:49PM -0600, Dan Williams wrote: > > On Thu, 2012-02-09 at 13:49 +0100, Guido Günther wrote: > > > Hi > > > I've written a small network-manager VPN plugin that uses iodine to > > > tunnel through DNS which can be usefull in case you're behind a firewall > > > but DNS queries are allowed: > > > > > > https://honk.sigxcpu.org/piki/projects/network-manager-iodine/ > > > git clone git://honk.sigxcpu.org/git/network-manager-iodine.git > > > > > > There are auth and property dialogs and we run chrooted and unprivilged > > > by default. I wonder if this is suitable to be moved over to > > > git.gnome.org alongside with the other modules. > > > > Very nice; also quite clean. Though I wonder if iodine couldn't be > > patched to accept the password over stdin instead of the environment? > > It turned out that this is already possible so I changed the code to use > stdin. Thanks for having a look! > > > In any case, it appears that only the program's user can > > read /proc//environ so we're probably safe there, but environment > > inheritance is fraught with danger. I could be wrong, but if iodine > > spawns a process later, and forgets to clear the environment, it might > > leak the password through to that child process. But anyway... Yeah, > > this is suitable to be moved to git.gnome.org. I think you've got a git > > account now; want to request a git repo and push it? > > Done, thanks. I have one question though. What's the correct way to > return errors from the plugin to NetworkManger from functions that run > when real_connect has already finished? Like iodine_stderr_cb? Plugins use the "failure" signal to indicate that, using libnm-glib that would be: nm_vpn_plugin_failure (NM_VPN_PLUGIN (plugin), NM_VPN_PLUGIN_FAILURE_CONNECT_FAILED); with the correct error code. The current error codes aren't very detailed, but if there's one we need we can certainly add it. And in reality, we should be adding a more detailed error signal that also takes a descriptive string with more information that can be logged by NM or passed up to the user. That's not hard to implement, just a parallel signal to Failure that has a "us" dbus signature. Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Setting openVPN options
Em Monday 27 February 2012, Volker Kuhlmann escreveu: > On Sun 26 Feb 2012 05:38:58 NZDT +1300, Lamarque V. Souza wrote: > > Which openvpn version do you use? > > openvpn-2.2.1-18.1.2.x86_64 I use 2.2.0 here. > openSUSE 12.1 With Gentoo. > > I am not aware of this problem (I am the responsible for Plasma NM, the > > > > KDE applet for NetworkManager). I have just check it here and my wifi > > connection stays in the plasmoid and the kcm (Manage Connections") lists > > after I disconnect it. > > For debugging all of this I intentionally disconnect the wifi connection > by clicking on the panel applet icon, which shows a connection summary > with connection list on the left and the configured NM connections and > fond APs on the right. Click on the white X with the red round > background in the top right corner of each connection drops the > connection, and removes the wifi connections (all of them) from the > right side. It happens every single time. Immediately after that, an > iwlist wlan0 scan shows the closest AP (mine) immediately, but the AP > list on the right is not populated again for quite some time afterwards. > As the list is empty, one can't click on it to start the connection > again. It's often faster to turn off "enable wireless" and turn it on > again immediately. This look like kded4 or NetworkManager crashed when you disconnected the wifi connection. By the fact that the AP list is not populated for some time I guess it was NetworkManager. kded4 restarts itself when it crashes, so if it was kded4 the list should have been re-populated some seconds later. Can you send me NetworkManager's log and ~/.xsession-errors file? > Wifi driver is broadcom wl (apologies, not one I'd have chosen). I used to have my problems with broadcom drivers. Fortunately my broadcom card is now supported by native driver. > > > Sure there is a security issue to deal with, but given that NM asks for > > > a root password each time there's a change to the connection settings I > > > don't see any security *problem* here. > > > > The problem is implemeting in NM all the checks to make sure the options > > > > are safe. NM cannot just pass them to openvpn daemon. > > Sorry, NM asks for the *root* password here. Safety checks no longer > exist. Why do they no longer exist? Running as root does not mean the program should take any parameter without checking it. > It's ironic that the insistence on checks leads to a less-secure program > that is incapable of putting in the one security option I insist I have > in there. openvpn warns loudly if it's missing. Keyword MITM. Which option is that? If it is always required it should not even be an option. > > auto-connect for VPN is not implemented in NM as far as I know. There > > > > are some scripts from users in this mailing list to do just that. I have > > never tested them though. > > The autoconnect tickbox is still there for VPN. Even if it didn't work, > I'd be happy to be able to manually click on the connection name to get > it started. That works as long as you have another non-VPN connection already started. > > I can delete routes. > > I'm all ears. What's the trick? For my scenario above where I just do not want the VPN to set the default route you should do the following (all in the IPv4 tab in the connection editor): . in Basic settings mark Method as "Automatic (VPN) addresses only". This option makes NM sets up only network address, netmask and IP address, and no routes. . in Routes check "Use only for resources on this connection" My VPN sets the local network 10.0.0.0/24 but I also need to access a different internal network (192.168.0.0/24), so I add a new route for it. That works for me, the problem is that I need to do two things and most people believe that just checking "Use only for resources on this connection" is enough to set up a VPN connection that does not set the default route. > > > * NM starts openvpn with an openvpn option that causes the vpn to stop > > > dead halfway through the startup. Impossible to fix with NM. > > > > Which option is that? > > To be honest I'm reluctant to say, because it gains nothing. It's > pointless to deal with one particular option while ignoring the other 3. If the option should not be used how do you think someone could remove it from NM without knowing each one it is? > I've cranked up kvpnc, which is pretty annoyingly buggy, but differs > from NM in one crucial point: it gets the job done. The alternative is > to manually create an openvpn config file (done that by now) and a > 1-line script for convenience. Needs a root login (as does kvpnc), but > it's lightning fast to the alternatives. Ok then, good that the other alternatives work. -- Lamarque V. Souza KDE's Network Management maintainer http://planetkde.org/pt-br
Re: Setting openVPN options
On Sun 26 Feb 2012 05:38:58 NZDT +1300, Lamarque V. Souza wrote: > Which openvpn version do you use? openvpn-2.2.1-18.1.2.x86_64 openSUSE 12.1 > I am not aware of this problem (I am the responsible for Plasma NM, the > KDE applet for NetworkManager). I have just check it here and my wifi > connection stays in the plasmoid and the kcm (Manage Connections") lists > after > I disconnect it. For debugging all of this I intentionally disconnect the wifi connection by clicking on the panel applet icon, which shows a connection summary with connection list on the left and the configured NM connections and fond APs on the right. Click on the white X with the red round background in the top right corner of each connection drops the connection, and removes the wifi connections (all of them) from the right side. It happens every single time. Immediately after that, an iwlist wlan0 scan shows the closest AP (mine) immediately, but the AP list on the right is not populated again for quite some time afterwards. As the list is empty, one can't click on it to start the connection again. It's often faster to turn off "enable wireless" and turn it on again immediately. Wifi driver is broadcom wl (apologies, not one I'd have chosen). > > Sure there is a security issue to deal with, but given that NM asks for > > a root password each time there's a change to the connection settings I > > don't see any security *problem* here. > > The problem is implemeting in NM all the checks to make sure the > options > are safe. NM cannot just pass them to openvpn daemon. Sorry, NM asks for the *root* password here. Safety checks no longer exist. It's ironic that the insistence on checks leads to a less-secure program that is incapable of putting in the one security option I insist I have in there. openvpn warns loudly if it's missing. Keyword MITM. > auto-connect for VPN is not implemented in NM as far as I know. There > are some scripts from users in this mailing list to do just that. I have > never > tested them though. The autoconnect tickbox is still there for VPN. Even if it didn't work, I'd be happy to be able to manually click on the connection name to get it started. > Not everybody wants to route all traffic through VPN. I use VPN to > access specific sites, not the whole Internet. In my case that would disrupt > my other connections since the VPN I access are local networks and have no > access to the Internet. > That is my case. Well, I must admit that VPN routing in NM is not > obvious, sometimes I need to change settings in two or three different > dialogs > to make it work as I want. There are solid arguments for both those cases, so NM really should be able to handle both. I don't see how I can get that fine a control over routes in NM - but will happily read a howto. > I can delete routes. I'm all ears. What's the trick? > > * NM starts openvpn with an openvpn option that causes the vpn to stop > > dead halfway through the startup. Impossible to fix with NM. > > Which option is that? To be honest I'm reluctant to say, because it gains nothing. It's pointless to deal with one particular option while ignoring the other 3. I've cranked up kvpnc, which is pretty annoyingly buggy, but differs from NM in one crucial point: it gets the job done. The alternative is to manually create an openvpn config file (done that by now) and a 1-line script for convenience. Needs a root login (as does kvpnc), but it's lightning fast to the alternatives. Thanks, Volker -- Volker Kuhlmann http://volker.dnsalias.net/ Please do not CC list postings to me. ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
