Re: openvpn plugin
Christian Guedel schrieb: > On Tue, 2006-08-29 at 16:23 +0200, Groug wrote: >> Did you check out sources from the CVS head or from the >> NETWORKMANAGER_0_6_0_RELEASE branch ? Hi Christian. Just back from a few holidays... > I just checked out with > > cvs -z3 co -D 2006-03-28 -r NETWORKMANAGER_0_6_0_RELEASE > NetworkManager/vpn-daemons/openvpn If you say that you use NM 0.6.2 then try a checkout with cvs -z3 co -r NETWORKMANAGER_0_6_2_RELEASE This should work together with the 0.6.2 version from Ubuntu (I would not expect such fundamental patches in the package that this doesn't work). > Aug 29 16:40:13 bluelagoon nm-openvpn[26744]: script failed: shell > command did not exit normally It seems that for some reason the executable that is called by openvpn to read the data from openvpn (IP config, DNS etc.). Unfortunately it does not tell us why this happened. If you could try out the version matching your NM version we could see if that solves the problem. If it does not we will need some more feedback in the log why this happened.. Tim -- Tim Niemueller <[EMAIL PROTECTED]> www.niemueller.de = Imagination is more important than knowledge. (Albert Einstein) ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: FC5, Madwifi, NM -- network recovery after suspend-to-ram?
Derek Atkins schrieb:
> Hey,
>
> My only issue right now is that the wireless network doesn't seem to
> "come back" automatically after a suspend-to-ram. Maybe I'm not doing
Add a file /etc/pm/hooks/80madwifi and will it with:
#!/bin/bash
. /etc/pm/functions
MADWIFI_MODULES="wlan_wep wlan_ccmp wlan_tkip ath_pci ath_rate_sample
ath_hal wlan_scan_sta wlan"
unload_modules()
{
[ -z "$MADWIFI_MODULES" ] && return 0
for x in $MADWIFI_MODULES ; do
/sbin/rmmod $x >/dev/null 2>&1 0<&1
done
return 0
}
load_modules()
{
[ -z "$MADWIFI_MODULES" ] && return 0
for x in $MADWIFI_MODULES ; do
/sbin/modprobe $x >/dev/null 2>&1 0<&1
done
return 0
}
case "$1" in
suspend)
;;
resume)
unload_modules
load_modules
;;
*)
;;
esac
exit $?
This does the trick for me. The MADWIFI_MODULES have to be in one line.
This could be extended to check if there are actually any madwifi
drivers loaded before going rampart so that we can bundle this in the NM
package for instance as a "unfortnately needed up to now"-script...
Tim
--
Tim Niemueller <[EMAIL PROTECTED]> www.niemueller.de
=
Imagination is more important than knowledge. (Albert Einstein)
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: PPTP Plugin Updated -- Ver. 0.6.9 Generally PPP capable?
Cesar Cardoso schrieb:
> 2006/6/2, Antony J Mee <[EMAIL PROTECTED]>:
>
>> This is a totally general PPPD plugin...
>
> So I imagine that now we can believe that in some time in the future
> NM will make those dialers (gkdial, gnome-ppp etc) obsolete? Yay! :)
For this see http://fedoraproject.org/wiki/SummerOfCode/2006/TimNiemueller
I'm working on it :-)
Tim
--
Tim Niemueller <[EMAIL PROTECTED]> www.niemueller.de
=
Imagination is more important than knowledge. (Albert Einstein)
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: OpenVPN
Jeffrey C. Ollie wrote: > I've dug into the code a bit and come up with the attached patch, but it > still doesn't seem to be working. Watching the system bus with > dbus-monitor shows the following DBus message being sent: Hi Jeffrey. First: Many thanks for the patch! It wasn't the right way to solve the problem but I took the new dns-suffix feature and added it, I will commit this to the repository soon. The login banner does not have to be sent (also not empty) since what you changed in the private "in-plugin" communication from the helper to the service, the same for the MSS. You probably ran in the very same problem I ran into when investigating this problem. You probably took a release-version of NetworkManager (I still had 0.6.2 installed and didn't install the whole NetworkManager from CVS, as I should have) but used the OpenVPN-plugin from CVS. On March 29th a new field was added (the MSS) to the IP4Config message (this is the uint32 0 that you see just before the two last strings below). But this was after the 0.6.2 release. Because of this the configuration data was invalid that was send to NM by the OpenVPN-plugin. > ]uint32 0 > string "" > string "" So the solution is to use NetworkManager from CVS for now or to checkout an older version (March 28th and older probably) of the OpenVPN-plugin. This leads to a general question: Should we either package the whole NetworkManager tree (including [working] VPN-plugins) for a release or should we make the VPN-Plugin numbers match to the NM-release they work with and release a new package for these plugins at the same time a NM package is being released? This way this problem would probably not have occured. If we keep the release numbers in sync it may be worth re-thinking about having the VPN stuff as additional packages inside the tree. They could as well be integrated with some autoconf --with-vpnc --with-openvpn stuff. I'm not particular familiar with .deb, but I'd expect they have the same ability to specify subpackages for one spec as can be done for RPM, right? Would that be a problem in the case of Fedora (NM is in Core, VPN plugins are in Extras). Another thing that I noticed is that the CVS repo is still having 0.6.0 as the version number... It may be worth thinking about naming the revisions in the repository so that you see that it is being worked on (could be old kernel style, 0.6.2 is a release, 0.6.3 is a development cycle in CVS, 0.6.4 is a release again etc.). This didn't happen often and is unlikely to happen too often in the future, but a little bit more structure here could help to catch the few cases without much additional work. Tim -- Tim Niemueller <[EMAIL PROTECTED]> www.niemueller.de = Imagination is more important than knowledge. (Albert Einstein) ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NetworkManager OpenVPN plugin
Sebastian Willert wrote: > Hi, Hi Sebastian. > I am trying to extend the NetworkManager OpenVPN plugin to support > misconfigured VPNs (e.g. without proper nsCert types) and VPNs that can > be accessed from Intra- as well as the Internet (those tend to change > the source of their packages from external to internal, thus requiring > the --float option). Things seem to work quite well, so I thought it > might be worthwhile proposing the changes. Sounds reasonable. If you send me the patch I will have a look. > The name of the current Ubuntu source package from the > http://kubuntu.no-ip.org/kubuntu repository suggests that there is an > svn out there (that I wasn't able to find). I think it would be best if > I could produce diffs from there. Do you mean the CVS that NetworkManager is kept in? You can find it at cvs.gnome.org. There are instructions how to check out code. > Furthermore I'd really like to discuss my changes (not sure I they align > well with gnome philosophy for instance) and, provided you consider > accepting those, sensible changes to the properties dialog. Send a patch so that we have a basis for a decision. Tim -- Tim Niemueller <[EMAIL PROTECTED]> www.niemueller.de = Imagination is more important than knowledge. (Albert Einstein) ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: OpenVPN setup
Mario Limonciello wrote: > Hello list, Hi Mario. > Now I can connect fine using the config file that I have placed in /etc/ > and manually launching the daemon. When I use NM however, it complains > that I'm not doing any verification of server side keys. How did you create the NM configuration for that VPN? Can you give indications how you translated client.conf values to NM mask entries? > My log on my laptop has something along these lines: > Apr 18 15:56:11 localhost nm-openvpn[27403]: TLS_ERROR: BIO read > tls_read_plaintext error: error:14090086:SSL > routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed > Apr 18 15:56:11 localhost nm-openvpn[27403]: TLS Error: TLS object -> > incoming plaintext read error > Apr 18 15:56:11 localhost nm-openvpn[27403]: TLS Error: TLS handshake > failed This is where it breaks. I think the problem may be the following: NM strictly enforces the server key to be a server key. This means: In the certificate presented to your client is a flag which denotes the certificate to be a "server" certificate. This is for the following reason: Imagine a network where a client has been compromised. If you would not check for the server flag this client certificate could be used to fake a server (as the certificate is still valid and signed by the CA). But in the HOWTO this is _not_ done, and so this may be the reason why this fails. I strongly recommend to use the easy-rsa suite that comes with OpenVPN to create keys and signing requests. If you can't do that consider the following: the line that reads openssl req -nodes -new -keyout server.key -out server.csr in the tutorial should be openssl req -nodes -new -keyout server.key -out server.csr -extensions server (on one line). Than sign this csr and try it again. It may already solve your problem. I also don't know what the latest versions are that have been compiled for Ubuntu. Is that really the current version? Check version numbers from the package (or better: source) with the ones from CVS (cvs.gnome.org). And have you given the CACert CA file in the appropriate field in the config GUI? Hope that helps and gives you a hint where to search. You may also consider to look at http://www.niemueller.de/wiki/?OpenVPNwithNetworkManager for some "known working" configurations (also it will need some documentation merging efforts for the CSR). Tim -- Tim Niemueller <[EMAIL PROTECTED]> www.niemueller.de = Imagination is more important than knowledge. (Albert Einstein) ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: autoip config option?
Nikolaus Filus wrote: > Hi, > > before any comments, some questions from a not-so-well-informed-one: > - For which scenarios assigns nm an auto-ip? If no IP configuration can be obtained from other sources (DHCP). > - Where is auto-ip useful? In any scenario where machines on the local-link need to exchange information over an IP network without central infrastructure. The typical scenario is an ad-hoc network, where ad-hoc can also mean a bunch of machines interconnected with cables and a switch but without a DHCP server. > - is it possible to differentiate between an AP and a Adhoc-net? Not necessarily. You could as well have an AP without DHCP available, either if it is just not configured or if the server is down. Another use case I experienced is when the AP is up but the uplink is broken (and the DHCP is on a central base and not on the AP itself). Now you can connect to the AP but do not get IP configuration. > IMHO is auto-ip not necessary for connections with an AP, as it is > (mostly) used for "real" networks with its own topology. auto-ip would be > good in ad-hoc networks, when a friend is nearby and you want just share > some data. If this is not the scenario in NM, I would like to be able to > turn auto-ip off on a per-network basis. As said also in AP and cabled networks it can make sense. A reasonable assumption is that we want AutoIP if there is no DHCP available. Marking this clearly with an additional icon should be sufficient to track down problems quickly. I would even find an option "Raise a network" interesting where you setup an AP on your own host quickly. The timeout for ad-hoc network is too short. Last time when I tried it both stations had to connect in 20 seconds if I'm right after this it would fall back to other reachable networks. > How can the peers be described and what is signal-strength then, when > connected to an adhoc network? Is it usefull to show the bars then? Hmm, Robert, do you have information how this is done, if it is done? > In my reasoning, there is no real connection when on auto-ip, so why show > the bars? Otherwise it should be marked as a special case, as I'm not > able to connect to an known peer. As said we can use AutoIP in an infrastructure network and we should not deny that possibility per se. Also having completely different icons or bars is pretty confusing. I still vote for that "sub-icon". Tim -- Tim Niemueller <[EMAIL PROTECTED]> www.niemueller.de = Imagination is more important than knowledge. (Albert Einstein) ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: autoip config option?
Rémi Cardona wrote: > I was thinking instead of having yet another icon over the signal bars > (with vpn, it's getting quite crowded down in the notification area) > maybe the bars could be a different color, say dark gray, instead of the > default blue (on gentoo, I don't know if other distros' themes change > that color). Otherwise, you wouldn't even be able to see the signal bars > anymore. I don't think this is a good idea because it is not very clear that the configuration is different if the bars have a different color. This requires already quite a bit of knowledge about the tool. An exclamation marks tells everybody that something is different.. Since AutoIP is defined on the local-link only there are no routers anyway and thus it is very unlikely that a VPN connection would be setup in that case. Although something like opportunistic encryption or client-to-client VPN may come. I think keeping the upper part free is enough. > Or another option, have a notification popup saying the network's alive > ... but with an non DHCP address. I vote against this. I'm already annoyed by the VPN windows. This can for example move into the notification later. This can be done in addition to the icon idea. That brings me to the idea that we should do this for the VPN message, also (and maybe an additional entry in the menu right next to "Disconnect from VPN" that says "Show message" if someone really wants to read it later...). Tim -- Tim Niemueller <[EMAIL PROTECTED]> www.niemueller.de = Imagination is more important than knowledge. (Albert Einstein) ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: autoip config option?
Ben Roberts wrote: > Is there a case for a configuration option to disable autoip? It > drives me absolutely nuts ... Maybe we could have this as a "hidden" GConf key, if we don't want to expose the in the UI. > I understand that this enables a minimal network to be set up > automatically in the case when there is no DHCP server present, but > this is *surely* a relatively rare use case. In the majority of I do not agree. I'm familiar with that topic since I did some research on this recently. It will get more and more important if users start trying to setup an ad-hoc network on-the-go to copy files and the like. Last weekend I had to install a new laptop. I had to copy some files over to the Windoze-part. But instead of having to setup an IP subnet I just waited half a minute and then I was set with an AutoIP configuration and could start copying files. If mDNS would be in place I would not even have to lookup what IP that actually was but could just the hostnames on the local-link. But that's another story. > I particularly query why autoip is used on wireless connections, I'm > not even sure Windows does this by default...? The problem is that in Windows does since Win98. MacOS does. NM does. > I suppose having a different icon for autoip connections (as Nikolaus > suggests) would be a start but equally that might increase confusion. My suggestion would be an "additional" icon displayed like the lock when a VPN connection is up. Usually I don't tend to give Windoze as an example, but if you have an AutoIP-configuration setup it shows a yellow warning sign. A yellow exclamation mark in the lower left corner (or right if we are sure that AutoIP and VPN do not happen at the same time) could make this noticable to the user. Another thing that really bugged me was that by default the lo interface gets the route set to the local-link addresses on Fedora. You have to set "NOZEROCONF=yes" in the config file. I'd consider this to be a bug since you won't get any traffic through on the "real" device... To summarize: - Maybe option to turn AutoIP off, maybe a hidden GConf key - Have a visual indication for AutoIP being used. - Fix Fedora lo-device handling Tim -- Tim Niemueller <[EMAIL PROTECTED]> www.niemueller.de = Imagination is more important than knowledge. (Albert Einstein) ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Pre-down script?
Dan Williams wrote:
> On Thu, 2006-02-16 at 22:06 +0100, Christian Güdel wrote:
>
> Not really. How exactly are you supposed to know that the connection is
> "down" before it _is_ actually down? The only case where you can know
We can now in the case of receiving a sleep signal via dbus. If we shut
down a VPN there also some kind of link going down. For instance at
university you have touse VPN or you can only connect to an
informational web server.
What would help is a general awareness of the system about connections.
For example Gaim could use that to logout properly from the IM networks
you are connected to, some kind of dyndns service could set a special IP
address that makes you know that the machine is down.
Tim
--
Tim Niemueller <[EMAIL PROTECTED]> www.niemueller.de
=
Imagination is more important than knowledge. (Albert Einstein)
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Cannot connect with madwifi
Dan Williams wrote: > On Wed, 2006-02-15 at 09:23 +0100, Tim Niemueller wrote: >> Feb 15 09:20:35 evilgenius kernel: ADDRCONF(NETDEV_UP): ath0: link is >> not ready > > Yep, likely its dropping the connection due to a scan. But that's > normal for most cards right now. That sucks. We had an option to disable scanning when connected. What abot reviving this until the drivers catch up? > Are you saying that the old madwifi doesn't work at all, or that it just > drops and reconnects every 20 seconds? Having net for 20 seconds and then not for the next 20 seconds is equivalent to not working I think. But I can associate. > It seems madwifi-ng is pretty F-ed up right now, given my experience > with it on Monday with a fresh pull of SVN. It doesn't even rescan and > attempt to reassociate when you set a new essid on the thing. It worked nicely with the old version I had before I think from before the WPA stuff landed. Is that a specific problem with wpa_supplicant? And what about that open vs. restricted stuff? I see that in the interface it does distuinguish between open and shared key (is that open and restricted?) but in the end it doesn't matter - it results in the same behaviour, trying to connect with security mode open. Tim -- Tim Niemueller <[EMAIL PROTECTED]> www.niemueller.de = Imagination is more important than knowledge. (Albert Einstein) ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Cannot connect with madwifi
Tim Niemueller wrote: > Hi. Hi again. > I'm using a prism card with HostAP 0.4.7 on the other side (it's an old > box) with WEP. The first thing I noticed and that was mentioned before I > think is that the security mode is now set to open instead of restricted > as before. So I changed that setting on the access point as well but it > didn't help. iwconfig output suggests that the key is correctly set but > it cannot get a "lock" on the network. The AP MAC is correctly display. I can now add that I have been able to connect with the old madwifi driver. But this one reconnects about every 20 seconds with a message Feb 15 09:20:35 evilgenius kernel: ADDRCONF(NETDEV_UP): ath0: link is not ready in the log file. So it boils down to a madwifi problem, as it seems. Is NM triggering scans and then the connection breaks down? Is there some patch that I have to apply for madwifi-ng to get it running or anything I can do to get the old madwifi to associate? Tim -- Tim Niemueller <[EMAIL PROTECTED]> www.niemueller.de = Imagination is more important than knowledge. (Albert Einstein) ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Cannot connect with madwifi
Hi. It has been a while since I worked on NM for the last time so I discovered the problem just now. Maybe there is an easy fix I missed. I have an Atheros card and I use the madwifi-ng driver (I tried with and without the patch you mentioned, Dan. With the patch the " could not trigger wireless scan on device ath0: Invalid argument" message went away I think). But now I cannot associate. I'm using a prism card with HostAP 0.4.7 on the other side (it's an old box) with WEP. The first thing I noticed and that was mentioned before I think is that the security mode is now set to open instead of restricted as before. So I changed that setting on the access point as well but it didn't help. iwconfig output suggests that the key is correctly set but it cannot get a "lock" on the network. The AP MAC is correctly display. What am I missing? Any hints where to look at? Tim -- Tim Niemueller <[EMAIL PROTECTED]> www.niemueller.de = Imagination is more important than knowledge. (Albert Einstein) ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Patch to add libnotify support to nm-applet
Rodney Dawes wrote: > notifications with libnotify/notification-daemon, to nm-applet. It's I like it. But I would even like it better if it would display the notification like gnome-power-manager with an arrow pointing to the object in the notification area that this notification belongs to. Tim -- Tim Niemueller <[EMAIL PROTECTED]> www.niemueller.de = Imagination is more important than knowledge. (Albert Einstein) ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [patch] novellvpn - vpn daemon for ipsec gateways
T Sureshkumar wrote: > Sorry to initiate further discussion on this. I just had a second > thought on this. > > Turnpike framework enables to write plugin extentions to racoon so > that many vendors (open & closed) and authentication modes can be > supported with Racoon. Nortel too have a xuath+hybrid authentication > proprietary mode, so this cannot be added to vpnc. OK. > rather than the client used to connect to gateway. So it would be ideal > to have the first level selection to list multiple names for a single > service. You mean for a single client application? Ideally we do not re-invent the wheel all too often and then have three entries for Cisco-VPN gateways in the end, although there may be a situtation where multiple clients reproduce the same functionality (because it may be just a subset of a more complex task the client can accomplish). > Right now, the nm-vpn service is a glue code to invoke a particular > client and pass parameters. So, the service would still be based on a > particular client and a descriptive UI could guide the user to use a > particular client. Otherwise, first level selection can be based on VPN > types (SSL, pptp, ipsec) and second level selection could be based on > (gateway type, authentication modes and client). This means top level > VPN class, subclassed by VPN types and types further subclassed to a > particular vpn client. If this is the idea, the framework is to be > developed and I suggest till then, we can have novellvpn as it is (since > a service is tied to a single client binary). What do you say? I'm not sure if we need a hierarchy that deep. I think what would do the job quite well is to define a list of well-known VPN gateway configurations you connect to. By configuration I do not mean every aspect like port etc. but just the basic settings like "ipsec+xauth" or "ipsec+xauth+nortel" or whatever. All VPN clients would have to register for any number of services (a common naming scheme should be established with a README describing the already supported types as kind of a template registry) and then the VPN manager compiles a list of available VPN types from this information. This could also be handy for example to offer the different basic configuration possibilities for OpenVPN to the user (X.509, password, hybrid) and then show a clean user interface with exactly the needed information and not such a mess as right now. The user chooses a type. If there are multiple clients implementing the protocol the user can choose either one of them and get's to a client- and vpn-type-specific GUI to enter the data as today. So there may be an additional step compared to today choosing the client and the initial list would change. In this case I think you are right in keeping "novellvpn" as a name as it just names the client (as for vpnc). Comments? Tim -- Tim Niemueller <[EMAIL PROTECTED]> www.niemueller.de = Imagination is more important than knowledge. (Albert Einstein) ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Compiling with nrpms
Hi. Has anybody tried lately to compile NM on FC4 with nrpms gnome installed? I get a lot messages of the kind /usr/include/cairo/cairo.h:443: warning: declaration of 'y1' shadows a global declaration /usr/include/bits/mathcalls.h:242: warning: shadowed declaration is here Same in hal.h (index), src/vpn-manager/nm-vpn-manager.h and src/vpn-manager/nm-dbus-vpn.h (signal), gtk-2.0/gtk/gtkaboutdialog.h:113 (link). After patching all these files I was able to compile the newest NM again. Does anybody know if patches for this went upstream to the appropriate places? Dan: Any ceveats in committing trivial patches renaming the appropriate arguments in the header only for NM files? I still think that we have a general problem somewhere. Including headers in other headers should be avoided whereever possible to not run into these problems (and to save compile time). I haven't traced back where these headers get included so that they harm us. But I still think that we should think about moving local headers (included with "") before the global headers (included with <>). Also re-arranging some of includes (for instance for the hal.h you could make sure that comes after ) could work around quite a few problems so that we would not depend on other libs to fix their header. Especially the y1 message makes it obvious that a pretty common term (if you deal with coordinates) can cause harm depending on the include sequence... My 2 cents, what do you think? Tim -- Tim Niemueller <[EMAIL PROTECTED]> www.niemueller.de = Imagination is more important than knowledge. (Albert Einstein) ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [patch] fix madwifi strength
Robert Love wrote:
> As madwifi[-ng] users are painfully aware, the Atheros driver spits out
> some whack figures for strength. The driver maintainers have been
> hesitant to fix the values.
Hi Robert.
Since I have a Atheros card myself I'd be happy to take that patch! I
see Dan's point in keeping the code clean and non-specific to drivers.
But on the other hand we have to face reality and see that not all
drivers provide the same information. Here it may be a lack of a strong
definition of the semantics these values should have in the first place.
Many laptops nowadays use Atheros chip and NM could provide a better
experience by applying one of these patches.
Short: I vote for this to go into NM.
Tim
--
Tim Niemueller <[EMAIL PROTECTED]> www.niemueller.de
=
Imagination is more important than knowledge. (Albert Einstein)
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: CVS compile error...
Antony J Mee wrote: > Anybody else seen this: Yes > My brain is lagging a little this morning and I'm not quite sure where > to start with that. > Any suggestions are welcomed. That is a problem with the includes. I submitted a patch to Dan that fixes this by moving all "" includes before the <> includes. Dan doesn't like that and wants to get a "real" fix. Tim -- Tim Niemueller <[EMAIL PROTECTED]> www.niemueller.de = Imagination is more important than knowledge. (Albert Einstein) ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: essid with spaces?
Dan Williams wrote: > Tim, > > Could you attach to nm-applet with gdb, let it run, and then get a > backtrace for me when it crashes? Lachlan was faster so I guess that should be sufficient!? Interestingly today I did not yet have any crash (using a version about two weeks old) so it does not always seem to crash... Tim -- Tim Niemueller <[EMAIL PROTECTED]> www.niemueller.de = Imagination is more important than knowledge. (Albert Einstein) ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: essid with spaces?
Dan Williams wrote: > > Is there any chance that the problem is a non-UTF8 character rather than > a space? I checked out spaces today with my WRT54G and NM appeared to > deal with them just fine. It's known to crash with some non-UTF8 ESSIDs > though. What's the essid that crashes for you? I have the same problem with the ESSID "niemueller wavelan". Tim -- Tim Niemueller <[EMAIL PROTECTED]> www.niemueller.de = Imagination is more important than knowledge. (Albert Einstein) ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [patch] novellvpn - vpn daemon for ipsec gateways
Haripriya S wrote: > Hi Tim, > > I think you have a valid point. But the reason why chose we call this > novellvpn service is because it uses the Novell VPN client for talking to the > gateways (similar to Cisco vpnc service using the Cisco VPN client). The > Novell client supports (as of now) both the standard modes (X.509) for > standard ipsec gateway support, and also supports an XAuth derivative > (proprietary extensions) for talking to a Nortel contivity switch (will also > support Novell BorderManager specific modes in the future). That's why we > called it novellvpn service since the info we pass for the non-X.509 modes > will not be usable by every ipsec client. OK, so it seems that novellvpn is a front-end for ipsec-tools and turnpike/Racoon and a bunch of related stuff? Is it OS? Is there a project website for this besides the Wiki page? X.509 support is on the vpnc todo. Could it be that adding this to vpnc would make novellvpn a nortelvpn with later planned novellvpn extensions? Maybe this calls for a method in NM to allow vpn-plugins to display more than one name. This way the novellvpn could have entries in the list for "IPSec VPN" and "Nortel VPN" and not just "Novell VPN" (which I'm pretty sure no one would expect to be used for IPSec). So the semantic should shift from naming the client to naming the type of VPN you can connect to (since this is the interesting information to the user and not what program is actually used to establish the connection). This may require later some additional choice if there are multiple clients for a specific VPN type (like vpnc and novellvpn for IPSec/XAuth). Tim -- Tim Niemueller <[EMAIL PROTECTED]> www.niemueller.de = Imagination is more important than knowledge. (Albert Einstein) ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [patch] novellvpn - vpn daemon for ipsec gateways
T Sureshkumar wrote: > hey, > >This patch is a sequel to the one which I have posted on 9th Jan > 2006. This new patch consists of novellvpn service to connect to IPSec > Gateways, which are configured to authenticate using standard mode with If it is a standard IPSec client why not call it by it's real name (ipsec)? Novell VPN suggested to me that they are doing some "fancy" stuff like Cisco which makes them incompatible to the rest of the world. But if it is standard IPSec there are quite a variety of gateways we will be able to connect to, for instance something simple as an OpenWRT box with OpenSWAN. Is there an option of naming this neutrally to keep marketing warfare out and to suggest to people that this is what they need if they want to connect to a plain IPSec gateway by the package name already!? Cisco just has a big stake with their XAuth draft so they already stamped it "Cisco VPN" but I don't see that there are 90% Novell machines serving plain IPSec. Don't get me wrong, I really like your efforts, and I like Novell for letting you doing so, but we should keep being the technical guys, not the marketing ones. Tim -- Tim Niemueller <[EMAIL PROTECTED]> www.niemueller.de = Imagination is more important than knowledge. (Albert Einstein) ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: kde support
Terry wrote:
> I am guessing this is a known "issue". Should I be seeing the NM icon
> in my KDE tray when the service is running?
Are you running nm-applet?
Tim
--
Tim Niemueller <[EMAIL PROTECTED]> www.niemueller.de
=
Imagination is more important than knowledge. (Albert Einstein)
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NM & ath0 trouble
Dan Williams wrote: > On Wed, 2006-01-04 at 21:23 -0500, Sven Rinke wrote: > > > Haha, I hadn't realized they didn't have SET_NETDEV_DEV... I could > swear the driver had that correct at least 6 months ago or so, I have > used an Atheros b/g card quite extensively before with 2.6.12 and 2.6.13 > kernels. Weird. Well, I'll give it a shot and see what happens in the > next couple days here. Note that the mentioned website is about the new madwifi-ng driver, which uses the new HAL from Atheros. The old madwifi driver can be checked out as madwifi-old branch (http://www.madwifi.org/browser/branches/madwifi-old) from svn and works just fine. Tim -- Tim Niemueller <[EMAIL PROTECTED]> www.niemueller.de = Imagination is more important than knowledge. (Albert Einstein) ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NetworkManager PPTP Support
Antony J Mee wrote: > Some may be interested to know that this is 98.36% a general plugin for > managing a pppd connection from NetworkManager [...] > :-) ), Robert... Any thoughts on that? Is work wired/wireless network + > home USB ADSL a use case too far? There is already a "Dialup connection" menu which is filled from entries supplied by the system. They are not handled very well at the moment (you can only start a connection, there is not connection indication if it got started and you cannot modify it). But this PPP stuff may be a start to make this a more general tool that is able to configure some dialup connections and handle them nicely. I would love that feature since I use PPP over my mobile to connect on the road if there is no WiFi (so it's not just ADSL that is interesting). Tim -- Tim Niemueller <[EMAIL PROTECTED]> www.niemueller.de = Imagination is more important than knowledge. (Albert Einstein) ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: VPN client configuration
Doug Farmer wrote: > hey Tim, Hi Doug. > I don't mean to be a bother but I need to install a newer version of No prob, I'm in the mood for this right before christmas ;-) > dbus and I can't do so using yum since it says that I am up to date. I > am using version 0.33 of dbus and the NetworkManager needs a version >= > 0.35. I downloaded 0.60 of dbus but can not find any documentation on > how to install. I even tried the documentation on dbus' website and > still couldn't find anything. You wouldn't happen to know how to install > dbus would you? > > Again, I appreciate all you help and cooperation. There are two ways to accomplish this. Alternative 1: Get the appropriate source RPMs from Fedora Core development, compile and install. Alternative 2: Use the nrpms repository. This is what I would prefer. nrpms (http://www.nrpms.net) is a repository that has packages of the newest Gnome version and stuff for FC4. See http://www.nrpms.net/Docs/Yum/ how to enable this. After you have installed the mentioned package (use the all packages file) you have to do a "yum update" which will update quite a few packages. I'm using nrpms on my Notebook and it works just fine. Note that there may be problems that I'm not aware of so think about it before doing it. Have backups and a cup of coffee ready. I would recommend Alternative 2. Think about the risks before. I think they are somewhat harmless but as we say in Germany: The devil hides in the details. Tim -- Tim Niemueller <[EMAIL PROTECTED]> www.niemueller.de = Imagination is more important than knowledge. (Albert Einstein) ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: VPN client configuration
Doug Farmer wrote: > Tim, Hi Doug. > Thanks for the response. I have installed vpnc on my machine. As far as > the plug-in is concerned...I have downloaded the source but how do I > compile and install the package? Like I said, I am very new to > Linux/Unix so I need all the help I can to get myself free of MS. I do > really appreciate your help. > > Which package do you recommend that I get rid of? I thought that I had > all the up-to-date packages that were offered through 'yum'?! Again, any > help is appreciated. NetworkManager.i386 0.4-15.cvs20050404 NetworkManager.i386 0.5.1-1.FC4.4 So it seems that you have two version of NetworkManager installed. Get rid of the first with # rpm -e NetworkManager-0.4-15.cvs20050404 Then install vpnc from extras with # yum install vpnc Then download ftp://download.fedora.redhat.com/pub/fedora/linux/extras/development/SRPMS/NetworkManager-vpnc-0.3-3.src.rpm and rebuild with # rpmbuild --rebuild NetworkManager-vpnc-0.3-3.src.rpm yum install any devel packages that may be required. This will create a package in /usr/src/redhat/RPMS/i386, install it with # rpm -Uvh /usr/src/redhat/RPMS/i386/NetworkManager-vpnc-0.3-3.i386.rpm Then restart NM with # /etc/init.d/NetworkManager restart to reload the list of available plugins. I'm not sure maybe you need to do a "killall nm-applet" to get the current list of VPNs. Not you can configure and use VPN connections. Tim -- Tim Niemueller <[EMAIL PROTECTED]> www.niemueller.de = Imagination is more important than knowledge. (Albert Einstein) ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: VPN client configuration
Doug Farmer wrote: > I am trying to figure out how configure a vpn connection through the > NetworkManager, but have been unsuccessful. I am fairly new to using > Linux so please bear with me if my questions don't seem very educated. > My dilema is that I do not even see an menu option in the NetworkManager > that I can use to create a VPN connection. Do I have all the packages What kind of VPN connection? Cisco or OpenVPN? > I think that I have everything since all that was offered using 'yum' is > what I installed. Can anyone direct me towards a document on how to > setup the VPN client or can you tell me if I have not > installed/configured something that I should have. You need to install a plug-in for NM to get support for your favorite VPN solution. First you should uninstall one of the NetworkManager packages (the older one) to avoid problems. If you want vpnc get vpnc from FC 4 Extras and install it. Then get NetworkManager-vpnc src rpm from FC Devel Extras and rebuild (rpmbuild --rebuild ...) and install the generate package. For OpenVPN get OpenVPN vom FC 4 Extras and install it. Then download http://www.niemueller.de/software/patches/NetworkManager-openvpn-0.3.1-1.src.rpm and rebuild with "rpmbuid --rebuild " and install the generated package afterwards. Restart NetworkManager with /etc/init.d/NetworkManager restart and the VPN entries should appear in the applet menu. Tim -- Tim Niemueller <[EMAIL PROTECTED]> www.niemueller.de = Imagination is more important than knowledge. (Albert Einstein) ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Next release
Crispin Flowerday wrote: > - I then took the nm-openvpn diff.gz file from the above url > - patched that into the vpn-daemons/openvpn tree Please note that this patch is only needed with the "old" version of NM. it is not needed if using a working cvs version of NM. For this you could try cvs -d :pserver:[EMAIL PROTECTED]:/cvs/gnome login cvs -d :pserver:[EMAIL PROTECTED]:/cvs/gnome -D 2006-12-05 co NetworkManager This will checkout a version of NM which is two weeks old. Then build as usual: cvs NetworkManager/vpn-daemon/openvpn ./autogen.sh ./configure make cd ../.. ./autogen.sh ./configure make Add any configure/autogen.sh flags that you need on your system. Popular is something like "--prefix=/usr --sysconfdir=/etc". Especially the sysconfdi flag may be needed to install the files for hal to the correct place. Tim -- Tim Niemueller <[EMAIL PROTECTED]> www.niemueller.de = Imagination is more important than knowledge. (Albert Einstein) ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: OpenVPN routes
George Billios wrote: > This one goes to Tim. Hi George, hi list. > For example, I don't only want to 'tell' my packets that for 10.5.x.x/16 > go through tap0 but be more specific and say that for 10.5.x.x/16 you > should go to 10.5.x.10 which could be different from the gateway to > other end of the vpn connection. > > I can accomplish that with "PUSH" commands from the openvpn server but > it doesn't work at the moment with NetworkManager implementation due to > current NetworkManager restrictio, as you told me in another email, so I > thought maybe you can also add a gateway field in the routes configuration. OK, I understand the problem. We could extend the syntax of the routing parameters to take an optional gateway argument or we take the information we get from the vpn gateway and display a note to the user that there are specific settings in place. This could be done with libnotify or as a regular popup (I would prefer the notify stuff, it's less obtrusive). Either way we need a method to send routes to NM core that should be set besides what it sets anyway (or maybe even overriding the original settings). I will have a look and come up with a patch. Unfortunately at the moment time is quite limited as a few other things have to be done by this year. Will find some free minutes though! Tim -- Tim Niemueller <[EMAIL PROTECTED]> www.niemueller.de = Imagination is more important than knowledge. (Albert Einstein) ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Next release
Ken VanDine wrote: > Hello all, Hi. > Is there any idea (however so vague) when there will be another > NetworkManager release? We are trying to do some stuff with the openvpn > client in NM and it seems to be hit or miss in cvs at the moment. Just checkout a version from a specific data about two weeks earlier before the major new work on WPA started for now. This worked reasonably well for me. Tim -- Tim Niemueller <[EMAIL PROTECTED]> www.niemueller.de = Imagination is more important than knowledge. (Albert Einstein) ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
NM-OpenVPN 0.3.2
I have just checked in NM-OpenVPN 0.3.2. This adds support for encrypted keys for X.509 and X.509 + User/Pass connection types. It also allows the port to connect to to be set by adding the port setting to the VPN connection settings using gconf-editor. To use this open gconf-editor, go to /system/networking/vpn_connections/ and edit the key vpn_data. Add two new list items one with content "port" and one with the port number. Happy testing and nice weekend, Tim -- Tim Niemueller <[EMAIL PROTECTED]> www.niemueller.de = Imagination is more important than knowledge. (Albert Einstein) ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: OpenVPN port selection
Dan Williams wrote:
> If you whip up some patches to expand the information that the
> vpn-service passes to NM, by all means post them.
OK. Right now I'm reading into the rest of NM to get that PtP address
problem fixed.
[...]
> Then we get into really ugly territory with the UI for VPN routing
> configuration.
That is true. The login banner could be be used to at least mention
these differences to the user.
Tim
--
Tim Niemueller <[EMAIL PROTECTED]> www.niemueller.de
=
Imagination is more important than knowledge. (Albert Einstein)
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: RFC: WPA-related API changes
Dan Williams wrote:
> That's 6 already. We get to add 2 more if we care about ASCII keys too
> (though I don't think people really use those). These are going to be
I do use ASCII keys. Since it is useless to try a dictionary based
attack (you probably can break WEP faster with other means) it doesn't
matter if you only use a small subset of the hex space. Even with ASCII
keys you can have phrases that include several character classes to make
it harder to guess/break while it still is easier to remember.
Tim
--
Tim Niemueller <[EMAIL PROTECTED]> www.niemueller.de
=
Imagination is more important than knowledge. (Albert Einstein)
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: OpenVPN port selection
George Billios wrote: > Tim, Hi George. > Could you also add a port option for openvpn? Hmm, the only thing where it is really useful is the shared secret connection type, since there every connection has a different port... For the rest this shouldn't matter since OpenVPN got a port assigned from IANA. The vpnc-plugin doesn't have that feature, either. I don't want to just put it in the optional information expander like the rest. This get's bloated. But for now I cannot think of a better place. Does someone else have a better idea? > Also I saw that you haven't implemented support for 'push' options from > the vpn server, like if the servers 'pushes' a DNS server or a specific > route which must be added to the clients routing table. Will you > implement this also? That is not completely correct. I take care of DNS and WINS push messages (see src/nm-openvpn-service-openvpn-helper.c, the foreign_option_%i stuff). I do not care about the routes for now since NM does not (yet?) have support for sending these after the connection has been established via dbus, use the routes field in the optional information expander. Tim -- Tim Niemueller <[EMAIL PROTECTED]> www.niemueller.de = Imagination is more important than knowledge. (Albert Einstein) ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
NM-OpenVPN 0.3.1
I have just checked in NM-OpenVPN 0.3.1. I have applied Crispin's patch, also the login banner part. I will have a look at a nicer solution tommorrow. I have also added support for TCP connections. It is just another check button in the optional information section. Does it still fit a 1024x768 screen? I haven't had time to look at support for encrypted keys for now. Will have a look soon. Tim -- Tim Niemueller <[EMAIL PROTECTED]> www.niemueller.de = Imagination is more important than knowledge. (Albert Einstein) ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: RFC: WPA-related API changes
Dan Williams wrote: > Hi, Hi. > 2) Move higher-level key types to the applets, rather than keeping logic > for them in NetworkManager. Right now we have the constants for ASCII, Am I right if I say that we just define two interfaces, one which is nice for the machine which we will use for communication applet <-> NetworkManager and another which presents the user with the usual terms so this will be the applet <-> user interface. So several different terms in the user interface (ASCII key or hex key for wep) have a unified form in the applet/NM interface (the n byte key + WEP type). In the case this is how it is meant I'd vote for this. > This would break existing stored preferences. A conversion helper in the applet could fix this when the new applet is run for the first time. > The goal here is to move more user-provided details into the applets and > to simplify NetworkManager itself, and provide an API that dovetails > closely with the core system APIs like wireless-tools. Will make it a lot easier and saves doubled work/code. > I foresee moving more of this functionality (some of the "smart" bits) > out to the applets and/or clients of NetworkManager rather than keeping > it in NM itself. As we try to build out the capability of NM past the > original goals of seamless laptop/mobile use, this will get more and > more important. What should be considered is that moving more functionality to the clients of NM raises the amount of work someone has to do for a new client. Maybe some pieces could be tied together to an utils module or a small lib to support this. This could also make it easier to keep different clients in-sync. I'm not sure how well this would work with clients for different desktops like Gnome and KDE. But I'd assume that it would tremendously lower the work that has to be done to write an applet for Xfce (which a friend suggested to me makes sense since he doesn't want to have to use GConf and Gnome keyring on his Xfce machine). Just my two cents. Tim -- Tim Niemueller <[EMAIL PROTECTED]> www.niemueller.de = Imagination is more important than knowledge. (Albert Einstein) ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NM-OpenVPN 0.3.0
Ryan Skadberg wrote:
> A quick request, can we add the ability to pick the protocol? Seems as
> if I use TCP and default is UDP and there is no option to pick TCP, so I
> can't seem to use this yet. I get a cannot connect to server error.
Yes, that's an easy one. I think for this I have to think about a new
widget layout though. I guess this won't fit on a small screen anymore.
Will have a look today.
Tim
--
Tim Niemueller <[EMAIL PROTECTED]> www.niemueller.de
=
Imagination is more important than knowledge. (Albert Einstein)
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NM-OpenVPN 0.3.0
I really can't get used to the reply scheme... Ryan Skadberg wrote: > One more. > > I seem to have to enter a password to unlock my PEM. If I just do Yes, if you have crypted your key this is true. Code to deal with the management console is even in there already for the password authentication mode. > Looking at the code, NM doesn't seem to handle a private key, it just > seems to handle a username/password combination that is then sent to the > local management server. True. > Any chance we can get support for this added in? Wish I were a better C > coder, but that should give you the information you might need. Please > let me know if you need something more. I did not implement this because I still hope that there will be some unified architecture for Gnome soon to manage certificates so I didn't put too much effort in this. I will have a look at this. Basically I have to know if the key is crypted before I try to establish the connection since I cannot show another password dialog if needed but I have to request this information before this attempt is made... I guess OpenSSL should be able to tell. Tim -- Tim Niemueller <[EMAIL PROTECTED]> www.niemueller.de = Imagination is more important than knowledge. (Albert Einstein) ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
NM-OpenVPN 0.3.0
I have just checked in NM-OpenVPN 0.3.0. It contains support for a new connection type "X.509 with Password Authentication" which basically merges the existing X.509 and Password Authentications into one connection type as requested. It also supports using the TAP device instead of TUN. Sorry Crispin, I had already some code before I got your patch. Since I try to stick as close as possible with the VPN parameters saved in GConf to the actual OpenVPN option names I added a new parameter dev which now carries tun or tap. Old configs will still work, if this parameter has not been set (which is only possible if you used a version prior to 0.3.0 to create/edit a configuration) it will default to tun. I applied your other patch that fixes the problem that the GIOChannel was not closed properly. Thanks for that! I have also added the syslog parameter. It looks that I just thought that I used this as the code looked before... Please try again and let me know if it works for you. I will update my Website with a new example configuration for the new mode now. Tim -- Tim Niemueller <[EMAIL PROTECTED]> www.niemueller.de = Imagination is more important than knowledge. (Albert Einstein) ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Building NM from CVS
Dan Williams wrote:
Sending a second time. Forgot to change recipient after reply. So that
you know what Dan answered to...
> Eventually, each vpn daemon should probably have its own CVS module.
I do not agree. The plug-ins are dependend on NM - so dependent that
they make no sense without it since the only purpose is to integrate
support for specific VPNs into NM. I think it is best to keep them
inside NM. That makes it more obvious to keep them in sync if the
DBUS-protocol is changed (as it appears to be needed in the near future
for the PtP address for instance).
> In any case, I got around this by commenting out the bits
> of /usr/bin/intltoolize that check for INTLTOOL_MAKEFILE at the bottom.
> That seems to have no adverse affects. I cannot find _anywhere_ on the
> web that documents why that check exists...
It seems to be stupid but in the Makefile.in.in from intltool itself
(see
http://cvs.gnome.org/viewcvs/intltool/Makefile.in.in?rev=1.4&view=markup)
they have just added a comment line with that string... I have added
this now as well to our files. That seems to fix the problem. Will check
them in in a couple of minutes.
Tim
--
Tim Niemueller <[EMAIL PROTECTED]> www.niemueller.de
=
Imagination is more important than knowledge. (Albert Einstein)
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: OpenVPN support questions
Crispin Flowerday wrote: > Hi, Hi Crispin. > I have been trying the new openvpn support (0.2.0, ubuntu packages from > http://bootlab.org/~j/NetworkManager-breezy/), and have a few questions: > > - My office VPN uses certificates, and username / pass authentication, > is this supported ? No, not at the moment. But since basically all code is there it is no problem. Will add that over the weekend. > - When openvpn is spawned, does it log what it is doing anywhere? The --syslog flag is added to OpenVPN so all essential logging information should be available in syslog. > Basically I can't get the vpn working, and even starting NM with > --no-daemon doesn't appear to log anything from openvpn, so I'm not > exactly sure why it isn't connecting. Please check the syslog if there is any information. Please also give "ps ax" a try (you must be quick to see the OpenVPN process after you clicked on the connection in the NM applet). > FWIW, the openvpn config file I got from the sysadmin looks like: > > client > dev tap That is a problem, we are using tun mode. I'm not absolutely sure about the implications of using tap. I will have a look. Maybe all it takes is a boolean flag in the optional information expander. It's getting tight on the screen in this case though. Can someone send me a screenshot (maybe off-list) of the widget running on a 1024x768 screen? > proto udp > remote xxx.xxx.xxx.xxx 1194 > resolv-retry infinite > nobind > user nobody > group nogroup > persist-key > persist-tun this is the information you give in the X.509 tab > ca ca.crt > cert crispin-00.crt > key crispin-00.key using this at the same time is not supported at the moment. As I said, will have a look over the weekend. > auth-user-pass > ns-cert-type server This must be set in the optional info expander. > comp-lzo > verb 3 Tim -- Tim Niemueller <[EMAIL PROTECTED]> www.niemueller.de = Imagination is more important than knowledge. (Albert Einstein) ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
NM/OpenVPN 0.2.0
I have just checked in version 0.2.0 of the NM OpenVPN integration. This adds support for username/password and shared secret connections. It also fixes a bug where the wrong address was returned as VPN gateway. Till now it returned the remote address in the VPN net (usually a private range address) and not the real remote IP address that we connect to. This prevented it from working if the VPN gateway was not on the same network and no specific networks to route were given. This probably caused the problems for most people. I wrote a small page that describes the different usage scenarios that I thought of at http://www.niemueller.de/wiki/?OpenVPNwithNetworkManager Tim -- Tim Niemueller <[EMAIL PROTECTED]> www.niemueller.de = Imagination is more important than knowledge. (Albert Einstein) ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: nm freezes system with nm-vpnc
Ferréol de Soras wrote: > hi, > > I use vpnc to connect to my university's wifi network. Versions of vpnc, NetworkManager and distro? > *Not using networkmanager at all, (iwconfig/dhclient/vpnc by hand) > after a variable amount of time, (10 min, 1h, 3h, 6h...) the link just > hangs, ie no packet can go through the tunnel. Running commands vpnc does not support re-keying. Depending on the re-keying interval of the VPN gateway this may be the problem. > > *When just using nework-manager to connect to the right SSID and get > DHCP, but running vpnc through the command line, it just works the > same, ie connection hangs, but system doesn't. Maybe same as above. In either case (if it's rekeying or not) I would think that these two problem are in fact the same. > *When using the vpnc-applet from network manager, when the vpn becomes > unavaible, it hangs totally the system. Have you tried to run NetworkManager on the console with the --no-daemon option (this time I got it right :-) ) to see if there is any output before it hangs? Can you still login via SSH from outside the machine (that worked for me for a couple of hangs caused by the applet which have been solved) and kill NM/applet? Tim -- Tim Niemueller <[EMAIL PROTECTED]> www.niemueller.de = Imagination is more important than knowledge. (Albert Einstein) ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NM gets it wrong
Dan Williams wrote: > > Right, this is all an artifact of the vpnc implementation. In vpnc, the > PtP and local address are the same. This was something only a second > VPN implementation could find :) > > The NMIP4Config structure doesn't have an entry for PtP addresses. > We'll likely need to add one and also augment the vpn-service -> NM API > to deal with that, so that each individual vpn service can do what it > wants to with that. Which variable is the "server" address that gets > passed from OpenVPN to your helper? Is it VPNGATEWAY? Yes, it's VPNGATEWAY. The local IP address is stored in ip4_address. Even if the local IP and the remote are the same for VPN, why is it not sufficient to have the ip4_gateway set to the remote gateway and ip4_address to the local address? What are the semantics of these fields? > > We should probably bug davidz about this one... bug bug ;-) Tim -- Tim Niemueller <[EMAIL PROTECTED]> www.niemueller.de = Imagination is more important than knowledge. (Albert Einstein) ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
NM gets it wrong
Hi guys.
I have been doing some work on OpenVPN. The good news: The new modes
(shared key and password) are working in my test setup. Finished some of
the features requested/bugs reported.
I still can't fix the problem that has already been described earlier
(by [EMAIL PROTECTED]): If the VPN connection is established, OpenVPN assigns
two IPs. From the clients point of view the remote address is the
server, the local is the own IP. Both are transmitted via OpenVPN.
In my test case the server has address 10.9.0.5, the client 10.9.0.6. So
the output should look like:
[EMAIL PROTECTED]:[~/dev/NetworkManager]# ifconfig tun0
tun0 Link encap:UNSPEC Hardware Adresse [...]
inet addr:10.9.0.6 P-t-P:10.9.0.5 Maske:255.255.255.255
[...]
it looks like this right after the connection has been started! And
OpenVPN gives this information to the helper. But as soon as this
information is sent to NM the output looks like:
[EMAIL PROTECTED]:[~/dev/NetworkManager]# ifconfig tun0
tun0 Link encap:UNSPEC Hardware Adresse [...]
inet Adresse:10.9.0.6 P-z-P:10.9.0.6 Maske:255.255.255.255
[...]
Not the inet addr and P-t-p addresses, they are the same! I have
double-checked. The OpenVPN service sends the correct information to NM.
I added output to the openvpn service and used dbus-monitor to see what
actually gets send.
I'm not even sure if this is a problem. A route to the remote address is
correctly set. In the example given this looks like:
[EMAIL PROTECTED]:[~/dev]# route -n
Kernel IP Routentabelle
ZielRouter Genmask Flags Metric RefUse
Iface
10.9.0.5192.168.4.1 255.255.255.255 UGH 0 00 ath0
192.168.4.0 0.0.0.0 255.255.255.0 U 0 00 ath0
169.254.0.0 0.0.0.0 255.255.0.0 U 0 00 lo
0.0.0.0 0.0.0.0 0.0.0.0 U 0 00 tun0
And although I cannot ping the remote IP I'm still able to route traffic
over that connection.
Does anybody have an idea where this gets messed up and why and where NM
sets the P-t-P address or what I did so horribly wrong and actuall _if_
this is a problem. Did you do any more tests j?
Another thing that I noticed that if you edit two VPN connections of
different VPN type (vpnc and openvpn) one after another the second time
it will show you both widgets stacked on one screen. Is that a problem
that I introduced or something that is not been seen yet since there has
been only one VPN service till now?
Tim
--
Tim Niemueller <[EMAIL PROTECTED]> www.niemueller.de
=
Imagination is more important than knowledge. (Albert Einstein)
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Wireless networking / VPN not working
Christian Güdel wrote:
>
> I compiled it with ./autogen.sh --prefix=/usr; make; make install for
> both nm and nm-openvpn...
>
> Something that I missed?
Probably --sysconfdir=/etc. The NM configs and especially the dbus
configs are copied there. NM cannot advertise the VPN services if the
dbus files are not correctly installed. Not that for now you also need
to restart dbus and NetworkManager as mentioned in an earlier thread.
Tim
--
Tim Niemueller <[EMAIL PROTECTED]> www.niemueller.de
=
Imagination is more important than knowledge. (Albert Einstein)
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Wireless networking / VPN not working
Christian Güdel wrote:
>
> I forgot that the OpenVPN support isn't working either. It says "No
> suitable software was found on your system" but openvpn is installed?!
That looks as if you did not correctly install the VPN modules. From
what I have looked up in the code briefly this happens if the shared
library for the properties dialog cannot be found. Did you use the same
prefix and sysconfdir for NM and the VPN plug-ins? The message does not
mean that it didn't found OpenVPN. It rather means that parts of the NM
plug-in could not be found.
Tim
--
Tim Niemueller <[EMAIL PROTECTED]> www.niemueller.de
=
Imagination is more important than knowledge. (Albert Einstein)
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Build error on Ubuntu Breezy
Robert Love wrote:
> Which certainly fails if the build directory is not the same as the
> source directory. But I see this all the time, too.
Is there a fix for this available? For now I installed the old 0.33
which temporarily solves this for me. This is pretty annoying if you
cannot call autogen.sh in one of the VPN folders...
Tim
--
Tim Niemueller <[EMAIL PROTECTED]> www.niemueller.de
=
Imagination is more important than knowledge. (Albert Einstein)
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: nm-applet should track dbus setWirelessEnabled
Karl Hegbloom wrote: > ... so that the wireless link is brought down when I hibernate my > laptop. What I've noticed is that even though the wireless network is I'm doing the following: dbus-send --system \ --print-reply \ --reply-timeout=2000 \ --dest=org.freedesktop.NetworkManager \ /org/freedesktop/NetworkManager\ org.freedesktop.NetworkManager.sleep >/dev/null 2>&1 0<&1 I think I found it in FC5 pm-utils and pulled it into my custom sleep-script. This will disable all networking including VPN. When the machine wakes up again do a dbus-send --system\ --dest=org.freedesktop.NetworkManager \ /org/freedesktop/NetworkManager \ org.freedesktop.NetworkManager.wake >/dev/null 2>&1 0<&1 to get it scanning again. Is that what you intended to do? Tim -- Tim Niemueller <[EMAIL PROTECTED]> www.niemueller.de = Imagination is more important than knowledge. (Albert Einstein) ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: OpenVPN Questions
David Zeuthen wrote: > > So... if I understand this right, some .crt and .key files are for all > users while some are per-user, right? So, maybe embed the ones shared > for all users in gconf? There is only one cert needed by all users: The CA file. Still I think this is something that should be installed per user, for example if a company has a pool of laptops that can be lend but for different departments there are different VPNs. > And make the authentication dialog prompt the user for the missing > per-user certificates? Or even better... look up in a certificate store > somewhere, e.g. I'm thinking NSS integration in the future... I think this is something that should be done on the Desktop-Level, not per Application. So if a Desktop-wide method to store certificates emerges with should use that. For the same reason I think that it is not the best idea for now to store these settings in GConf. Another problem that we will have in either case: OpenVPN can only read the certificates from real files. So we either need a patch to OpenVPN to be able to take the certificates from say STDIN or create temporary files while connecting. Tim -- Tim Niemueller <[EMAIL PROTECTED]> www.niemueller.de = Imagination is more important than knowledge. (Albert Einstein) ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: OpenVPN Questions
David Zeuthen wrote: > I haven't looked at your code but I sounds like you are advocating > configuration files in e.g. /etc or ~/.local/etc (I could be wrong > though) and I think this is not something we want. Think of the benefits > of using gconf here. No, this was about the import feature of NM so that administrators can give their users just a config file they can import so that the user does not have to write directions like "fill abc in field x". So the question is if we want to be able to import the openvpn config the admin distributes right now (which could also be used by openvpn) or if we want to import a ini style file (like PCF files but with different entries, which would be close to OpenVPN terminology). All settings are saved in gconf. Passwords will be saved in gnome-keyring. Certificates are given as files since it seems that there is no central infrastructure in place right now (please correct me if I missed something). On http://www.marcanoonline.com/wiki/Desktop_Certificate_Database_Library_proposal is a proposal for a centralized storage, but until this has been implemented we have to reference the paths on the harddrive to the .crt and .key files. Tim -- Tim Niemueller <[EMAIL PROTECTED]> www.niemueller.de = Imagination is more important than knowledge. (Albert Einstein) ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: OpenVPN Questions
Ryan Skadberg wrote: Hi Ryan. > 1) How do I debug? I can't seem to find any logs to use. Start the NetworkManager on a root console with --nodaemon. This will give plenty of output. There is also some information in your syslog, but especially the OpenVPN output will not be in the syslog. The coming version will use the syslog option of OpenVPN for easier debugging. > 2) Just to make sure I have things set up correct, I got the following > files from my IT guys: > * ca.crt > * skadz.conf > * skadz.crt > * skadz.key > So, I think they would match up with the configuration like this: I assume that your machine is named skadz, then you need: * CA file, which is named ca.crt. This is used to sign all keys and on your client side to verify that the server presented a valid certificate to you * skadz.crt, skadz.key: This is your public/private key pair. Ideally you would create the key file on your machine, from that certificate signing request, give that to the IT department and they will send you the certificate back. Thus the private part would remain private to you. Often for convenience (and since it is to be used for company-stuff only anyway) and because the scripts that come with OpenVPN foster that way this process is done by the IT department * skdaz.conf: Note that the OpenVPN-plug-in does _not_ read OpenVPN-config files but rather uses some special ini files that contain the information needed. I will put up some documentation on this with next check-in. The reason why I did this is mainly that this was the easiest way to go without creating a new parser. Does anyone think there is an urgent need to be able to parse the real OpenVPN config files? One pro I can think of is that the IT department would not need to create special NM config files. > CA File: ca.crt > Certificate: skadz.crt > Key: skadz.key > > Correct? Yes. > 3) When the password dialog pops up, it asks for both a password and a > group password. I don't seem to have a group password, do I need one? No, that dialog is meaningless. Just enter something in both entry fields for now. This dialog will go away with the next version. I just kept it there since I will recycle it for the password-only mode and I wanted to get it out to get feedback. > I think those are the questiosn for now, probably will have more as I go > here. Just let me know. Tim -- Tim Niemueller <[EMAIL PROTECTED]> www.niemueller.de = Imagination is more important than knowledge. (Albert Einstein) ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: OpenVPN in NM CVS.
[EMAIL PROTECTED] wrote: > Hi, Hi. > i added ubuntu packages for the OpenVPN plugin to > http://bootlab.org/~j/NetworkManager-breezy/ > so for those running ubuntu breezy, > just apt-get install network-manager-openvpn Cool! > some issues i have, > *general question regaring vpn plugins, do i have to restart > NetworkManager to make new plugins available? Since you have to restart dbus (to get the new permissions for the module loaded) you also will need do restart the NetworkManager. At least during my tests it would not recover from a dbus failure. David posted the real answer for this. > *Use LZO compression is always unselected than editing a connection. > while "Only use VPN connection for..." is always selected. This is a bug, I'm going to look at it. I'm right now adding support for static-key and password-authenticated connections so code is in flux at this time. I will commit an intermediate version for this bug depending on when my CVS accounts gets live. > *convenience, it would be nice if the file chooser dialog would be in > the last folder, since it will be quite common to have all 3 files in > one folder. so navigation to it 3 times seems wrong. This is true. Will do that. > *deleting a connection and adding it again does not work. > only after removing all traces in > ~/.gconf/system/networking/vpn_connections OK, will check that. From what Robert send earlier this seems to be a bug in the VPN manager which is not correctly deleting the values from gconf since these settings are not managed in the VPN plug-in itself. > *routing did not work for me, while using openvpn with a config file It's strange that the P-t-P address is the same as the inet addr. I can confirm that, it happens here, too. NM always set the default gateway to the tun device, which should be OK. But why is the P-t-P address that strange? I was able to ping beyond the routing barrier, though. Will have a look at this again. Tim -- Tim Niemueller <[EMAIL PROTECTED]> www.niemueller.de = Imagination is more important than knowledge. (Albert Einstein) ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
OpenVPN support
Hi guys. I have added OpenVPN support to NetworkManager. The code is based on the vpnc code with the changes needed for OpenVPN. Right now only X.509 configurations are supported based on the OpenVPN 2.0 HOWTO. More about this on the page mentioned below. I propose this package for integration into NetworkManager HEAD. Messages on this mailinglist suggest that there are users that need this feature. Give it a try. You can find the code, notes and some instructions at http://www.niemueller.de/software/patches/networkmanager.php Comments and patches welcome! If you want to work on one of points on the TODO list on the page please let me know to avoid double work. Tim -- Tim Niemueller <[EMAIL PROTECTED]> www.niemueller.de = Imagination is more important than knowledge. (Albert Einstein) ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
