Re: openconnect
On 1.9.2020. 15:22, Stuart Henderson wrote: > On 2020-09-01, Hrvoje Popovski wrote: >> Hi all, >> >> does anyone use an openconnect server on openbsd and have guidelines on >> how to configure it? i see that an openconnect server can use radius, so >> it's interesting to me. Which client do you use to connect to the >> openconnect server? > > It worked when I tested after porting ocserv/openconnect, but I'm not using > it in production. You should be able to connect to ocserv using either the > openconnect client or cisco anyconnect client. > >> If there is something else that can use radius, i would like to know? > > at least these: > > - npppd (yeuch l2tp :) > > - openvpn (there's a username/pw auth method using a helper script, > you can write something calling a radius client to check auth, also > yeuch openvpn :) > > I did once see some code including radius support for iked but it > was tied up with a bunch of other changes and looked a bit complex > to separate. I don't recall whether it was just username/pw or if > it did full EAP. > > Tnx for information. It would be great to have radius support for iked so students could use eduroam username/pass for vpn ...
Re: openconnect
Hello All, Drifting off topic on this one but when I saw OpenVPN Openvpn performance on OpenBSD (with Tap Interfaces) is less than one would expect.. even turning off ciphers and auth... you can still get about 80-90mb/s on a machine that would forward about 3.5Gb/s - 5Gb/s In doing a test with tap interfaces and a userland bridge (thanks Claudio) to test where the bottleneck was (incase it was the Tap interface was slow) it looked like OpenBSD Tap interfaces were not performance of the tap interfaces were about 10% slower than bridging physical interfaces To blame... as OpenVPN vpn say themselves it needs a rewrite and perhaps the code inefficiencies in OpenVPN combined with the OpenBSD Mitigations limit performance. sorry for drifting a little off topic... Tom Smyth On Tue, 1 Sep 2020 at 14:40, Stuart Henderson wrote: > On 2020-09-01, Hrvoje Popovski wrote: > > Hi all, > > > > does anyone use an openconnect server on openbsd and have guidelines on > > how to configure it? i see that an openconnect server can use radius, so > > it's interesting to me. Which client do you use to connect to the > > openconnect server? > > It worked when I tested after porting ocserv/openconnect, but I'm not using > it in production. You should be able to connect to ocserv using either the > openconnect client or cisco anyconnect client. > > > If there is something else that can use radius, i would like to know? > > at least these: > > - npppd (yeuch l2tp :) > > - openvpn (there's a username/pw auth method using a helper script, > you can write something calling a radius client to check auth, also > yeuch openvpn :) > > I did once see some code including radius support for iked but it > was tied up with a bunch of other changes and looked a bit complex > to separate. I don't recall whether it was just username/pw or if > it did full EAP. > > > -- Kindest regards, Tom Smyth.
Re: openconnect
On 2020-09-01, Hrvoje Popovski wrote: > Hi all, > > does anyone use an openconnect server on openbsd and have guidelines on > how to configure it? i see that an openconnect server can use radius, so > it's interesting to me. Which client do you use to connect to the > openconnect server? It worked when I tested after porting ocserv/openconnect, but I'm not using it in production. You should be able to connect to ocserv using either the openconnect client or cisco anyconnect client. > If there is something else that can use radius, i would like to know? at least these: - npppd (yeuch l2tp :) - openvpn (there's a username/pw auth method using a helper script, you can write something calling a radius client to check auth, also yeuch openvpn :) I did once see some code including radius support for iked but it was tied up with a bunch of other changes and looked a bit complex to separate. I don't recall whether it was just username/pw or if it did full EAP.
openconnect
Hi all, does anyone use an openconnect server on openbsd and have guidelines on how to configure it? i see that an openconnect server can use radius, so it's interesting to me. Which client do you use to connect to the openconnect server? If there is something else that can use radius, i would like to know? Tnx
Re: Building OpenConnect with libintl
On 2012/11/13 08:01, Woodhouse, David wrote: On Fri, 2012-11-09 at 12:19 +0100, Marc Espie wrote: autocrap is part of the problem, not the solution. Their documentation concerning version numbering, and all the fuzz they add around it don't help at all. The old style (major.minor) is fairly simple to understand and to use, actually, as long as you don't try to play fucked up games with it. I've committed a patch to make it use -version-info on OpenBSD, and -version-number with GNU libtool. They seem to do the same thing, taking the sane ABI-version numbers that I give them, and putting them directly in the filename of the resulting library. http://git.infradead.org/users/dwmw2/openconnect.git/commitdiff/ada3dea0 I note you don't seem to have an soname — so if I add functions to libopenconnect and bump the minor release number, I think your GNOME and KDE authentication dialogs for the VPN are going to break. If you update OpenConnect and not rebuild those, of course. I appreciate you say you don't. But OpenConnect might occasionally have required security or compatibility upgrades, so users might want to. If people are installing software from packages, realistically they're going to have to follow packages for updates too - the package build infrastructure takes control of version numbers and enforces our own version numbers, so somebody building an updated OpenConnect themselves would need to update anything depending on it themselves (your major version number is beyond the one in packages, we start from 0.0 when something is first added to ports, largely as a check to ensure that the build infrastructure does handle overriding version numbers). Also besides changes in the packaged software itself triggering a version bump, sometimes we need to force libraries to get updated due to changes in the OS (very rare but occasionally necessary). The package tools keep track of library dependencies (rather than just package dependencies) and know that they need to update all depending ports if a lbrary is updated (and keep old libraries around in cases where not everything can be updated together). Unfortunately for every project like OpenConnect where developers are clear about how versioning works, there are probably 2 or 3 who don't, we do go as far as diffing source trees when updating to make sure we bump when needed and find that either bumps gets missed very often, or people just don't understand the rules at all (probably the most common error being projects which use their release version number for the library version irrespective of symbol changes). Within the patch branch for a stable release, we will backport important changes (manpower dependent..) if they don't break ABI, this does restrict what we can pull back a bit, however as our release cycles are fairly short (fixed six-monthly) this generally isn't a big problem in practice. (As far as the GNOME/KDE authentication goes, I believe this is via NetworkManager which we don't package at all, so I don't think this is going to affect us at present; I'm not sure of the current status of NM, but historically the HAL dependency made it too difficult). Does that mean I should actually make it just '-version-info @APIMAJOR@' and drop the ':@APIMINOR@' part for OpenBSD? I think it would make sense to keep both..
Re: Building OpenConnect with libintl
On Fri, 2012-11-09 at 12:19 +0100, Marc Espie wrote: autocrap is part of the problem, not the solution. Their documentation concerning version numbering, and all the fuzz they add around it don't help at all. The old style (major.minor) is fairly simple to understand and to use, actually, as long as you don't try to play fucked up games with it. I've committed a patch to make it use -version-info on OpenBSD, and -version-number with GNU libtool. They seem to do the same thing, taking the sane ABI-version numbers that I give them, and putting them directly in the filename of the resulting library. http://git.infradead.org/users/dwmw2/openconnect.git/commitdiff/ada3dea0 I note you don't seem to have an soname â so if I add functions to libopenconnect and bump the minor release number, I think your GNOME and KDE authentication dialogs for the VPN are going to break. If you update OpenConnect and not rebuild those, of course. I appreciate you say you don't. But OpenConnect might occasionally have required security or compatibility upgrades, so users might want to. Does that mean I should actually make it just '-version-info @APIMAJOR@' and drop the ':@APIMINOR@' part for OpenBSD? -- Sent with MeeGo's ActiveSync support. David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation [demime 1.01d removed an attachment of type application/x-pkcs7-signature which had a name of smime.p7s]
Re: Building OpenConnect with libintl
On Thu, Nov 08, 2012 at 03:38:18PM +, Woodhouse, David wrote: On Thu, 2012-11-08 at 14:36 +0100, Marc Espie wrote: Pass LIBTOOL=/usr/bin/libtool on make's command line. Trying to get through the spaghetti of gnu autocrap only leads to insanity. That falls under the don't fight that shit, it's hopeless. Hm, OpenBSD libtool doesn't seem to honour the argument '-version-number 2:1', so my resulting library is 'libopenconnect.so.0.0' instead of 'libopenconnect.so.2.1'. Should I be specifying that differently? I should specify we don't even try to implement that old option, or figure out how to do so :)
Re: Building OpenConnect with libintl
On Fri, 2012-11-09 at 11:17 +0100, Marc Espie wrote: On Thu, Nov 08, 2012 at 03:38:18PM +, Woodhouse, David wrote: On Thu, 2012-11-08 at 14:36 +0100, Marc Espie wrote: Pass LIBTOOL=/usr/bin/libtool on make's command line. Trying to get through the spaghetti of gnu autocrap only leads to insanity. That falls under the don't fight that shit, it's hopeless. Hm, OpenBSD libtool doesn't seem to honour the argument '-version-number 2:1', so my resulting library is 'libopenconnect.so.0.0' instead of 'libopenconnect.so.2.1'. Should I be specifying that differently? I should specify we don't even try to implement that old option, or figure out how to do so :) Thanks. I note that '-version-info 2:1' seems to do different things for OpenBSD vs. GNU libtool. On OpenBSD it gives me 'libopenconnect.so.2.1' as I expect, but GNU libtool on Linux gives 'libopenconnect.so.2.0.1'. Did I mention that I hate autocrap? -- Sent with MeeGo's ActiveSync support. David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation [demime 1.01d removed an attachment of type application/x-pkcs7-signature which had a name of smime.p7s]
Re: Building OpenConnect with libintl
On Fri, Nov 09, 2012 at 10:25:36AM +, Woodhouse, David wrote: On Fri, 2012-11-09 at 11:17 +0100, Marc Espie wrote: On Thu, Nov 08, 2012 at 03:38:18PM +, Woodhouse, David wrote: On Thu, 2012-11-08 at 14:36 +0100, Marc Espie wrote: Pass LIBTOOL=/usr/bin/libtool on make's command line. Trying to get through the spaghetti of gnu autocrap only leads to insanity. That falls under the don't fight that shit, it's hopeless. Hm, OpenBSD libtool doesn't seem to honour the argument '-version-number 2:1', so my resulting library is 'libopenconnect.so.0.0' instead of 'libopenconnect.so.2.1'. Should I be specifying that differently? I should specify we don't even try to implement that old option, or figure out how to do so :) Thanks. I note that '-version-info 2:1' seems to do different things for OpenBSD vs. GNU libtool. On OpenBSD it gives me 'libopenconnect.so.2.1' as I expect, but GNU libtool on Linux gives 'libopenconnect.so.2.0.1'. Did I mention that I hate autocrap? Well, don't get me started on the usual rant, but basically, most upstream vendors don't understand ABIs. autocrap is part of the problem, not the solution. Their documentation concerning version numbering, and all the fuzz they add around it don't help at all. The old style (major.minor) is fairly simple to understand and to use, actually, as long as you don't try to play fucked up games with it. Unfortunately: - most devs out there are morons. - there's enough commercial pressure in the linux world that they push too hard not to break binary compatibility (which often leads to disaster because it's WAYS too easy to break binary compatibility and not notice unless you have the exact mixmatch that breaks). symbol-versioning adds yet another hard-to-understand, deadly-when-you-get-it-wrong layer. Our libtools, both the one in base, and the gnu libtool port, cmake, and other build systems, have hooks to allow the system developer to *completely* override the upstream vendor ABI settings. For at least 3 reasons: 1/ a lot of upstream vendors are morons, and will bump library numbers based on release and don't look at the actual API. 2/ even with those that understand API, a lot don't understand ABI, and still will not bump when a critical data structure in their library undergoes a major change. 3/ even in the cases where upstream vendors DO care and understand, we still need to take control. Specifically, because we DO break our system ABIs regularly, and so, when you change the compiler, or a critical data structure in libc, the only way you can avoid a flag day is by bumping EVERY single library that uses those structures I was personally responsible for two of these, back when I was hacking on locale and we discovered we *had* to change FILE* to go forward, and back when we unified our C/C++ type systems so that size_t would alias to the same unsigned type everywhere... if you know C++'s ABI, C++ will encode every parameter and return type name into its symbols, after reducing them to their primitive type, so *every* library that referenced size_t had to be bumped... This is something critical to OpenBSD: we don't have enough manpower to do otherwise. An OpenBSD release has a shelf-life of one year, and the only way we manage to go forward is by keeping the base system and the ports tree in-synch. Compared to some other systems, we are very aggressive at removing old features and using new stuff right away.
Re: Building OpenConnect with libintl
On Fri, 2012-11-09 at 12:19 +0100, Marc Espie wrote: autocrap is part of the problem, not the solution. Their documentation concerning version numbering, and all the fuzz they add around it don't help at all. The old style (major.minor) is fairly simple to understand and to use, actually, as long as you don't try to play fucked up games with it. That's exactly what '-version-number' does. While '-version-info' plays fucked-up games with arithmetic on the numbers you give it, the deprecated '-version-number' just puts the arguments straight into the filename/soname as $DEITY intended. It looks like your -version-info in OpenBSD libtool is actually doing what GNU libtool's -version-number option does? -- dwmw2 [demime 1.01d removed an attachment of type application/x-pkcs7-signature which had a name of smime.p7s]
Building OpenConnect with libintl
I saw the OpenBSD 5.2 release and figured I should make sure the OpenConnect VPN client builds OK on it still. It does, but I noticed that it didn't build with localisation support, and tried to fix that. It seems that libintl *is* present, but it's installed in /usr/local and the compiler doesn't find it by default. I'm not entirely sure if this is a bug in the libintl/gettext installation, in the compiler default search paths, or a deliberate design decision that an installed library should fail to work by default... but I attempted to work around it by adding 'CFLAGS=-I/usr/local/include LDFLAGS=-L/usr/local/lib' to my configure invocation. That's tolerable for a first test build, but surely I shouldn't have to advise users to build things that way when using the platform's stock libintl? (I also needed to explicitly link against -liconv in addition to -lintl, which I've now added to the configure script in git.) Anyway, it doesn't *work* either â the build failed. It seems that when building the openconnect executable, it finds the old libopenconnect.so in /usr/local/lib *before* the new one it's just built in the build directory. And thus the link fails. That sounds like it might be a libtool/autotools bug â surely it should link against the library it just built, and put -L./.libs on the search path *before* anything else? I was using the latest available tools where given the choice; autoconf 2.69, automake 1.12 and libtool (not GNU libtool) 1.5.26. Should I try with GNU libtool instead? I assume I'm doing something wrong here. Advice on how to make it build properly on OpenBSD would be much appreciated... -- Sent with MeeGo's ActiveSync support. David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation [demime 1.01d removed an attachment of type application/x-pkcs7-signature which had a name of smime.p7s]
Re: Building OpenConnect with libintl
On 2012/11/08 11:23, Woodhouse, David wrote: I saw the OpenBSD 5.2 release and figured I should make sure the OpenConnect VPN client builds OK on it still. It does, but I noticed that it didn't build with localisation support, and tried to fix that. It seems that libintl *is* present, but it's installed in /usr/local and the compiler doesn't find it by default. I'm not entirely sure if this is a bug in the libintl/gettext installation, in the compiler default search paths, or a deliberate design decision that an installed library should fail to work by default... but I attempted to work around it by adding 'CFLAGS=-I/usr/local/include LDFLAGS=-L/usr/local/lib' to my configure invocation. That's tolerable for a first test build, but surely I shouldn't have to advise users to build things that way when using the platform's stock libintl? It's deliberate that the system preprocesser and linker don't search /usr/local/include and /usr/local/lib, I'm not sure of the original reasoning behind it. The usual method is exactly what you've done with the explicit LDFLAGS/CPPFLAGS and this is afaik standard behaviour on BSDs. When pkg-config is used there's generally no problem but this doesn't help with the very common libintl. (I also needed to explicitly link against -liconv in addition to -lintl, which I've now added to the configure script in git.) Anyway, it doesn't *work* either — the build failed. It seems that when building the openconnect executable, it finds the old libopenconnect.so in /usr/local/lib *before* the new one it's just built in the build directory. And thus the link fails. That sounds like it might be a libtool/autotools bug — surely it should link against the library it just built, and put -L./.libs on the search path *before* anything else? I was using the latest available tools where given the choice; autoconf 2.69, automake 1.12 and libtool (not GNU libtool) 1.5.26. Should I try with GNU libtool instead? I assume I'm doing something wrong here. Advice on how to make it build properly on OpenBSD would be much appreciated... libtool people: is there something we should be doing something to reorder the library directory list to ensure the .libs directory comes first in the search list? Or is there something else going on here? We have some places in the ports tree where we explicitly override LDFLAGS to include .libs directories (e.g. imagemagick) which I presume is for this same reason - there aren't very many instances of this though it's possible people have only worked-around this problem in cases where they found it really painful to uninstall an existing package and its dependencies when working on an update.
Re: Building OpenConnect with libintl
On Thu, Nov 08, 2012 at 12:57:42PM +, Stuart Henderson wrote: Anyway, it doesn't *work* either ??? the build failed. It seems that when building the openconnect executable, it finds the old libopenconnect.so in /usr/local/lib *before* the new one it's just built in the build directory. And thus the link fails. That sounds like it might be a libtool/autotools bug ??? surely it should link against the library it just built, and put -L./.libs on the search path *before* anything else? I was using the latest available tools where given the choice; autoconf 2.69, automake 1.12 and libtool (not GNU libtool) 1.5.26. Should I try with GNU libtool instead? I assume I'm doing something wrong here. Advice on how to make it build properly on OpenBSD would be much appreciated... libtool people: is there something we should be doing something to reorder the library directory list to ensure the .libs directory comes first in the search list? Or is there something else going on here? We have some places in the ports tree where we explicitly override LDFLAGS to include .libs directories (e.g. imagemagick) which I presume is for this same reason - there aren't very many instances of this though it's possible people have only worked-around this problem in cases where they found it really painful to uninstall an existing package and its dependencies when working on an update. *our* libtool looks first under .libs. If it doesn't, that's a bug. I surmise the bug-reporter is actually using gnu-libtool, or the libtool generated by THAT software. There's totally nothing we can do about gnu libtool, it is broken by design on anything that's not standard linux elf linking (and we're not, we treat libraries as specific objects, and don't really support linking stuff with libiconv.so)... fixing THAT upstream is really tiresome, because most of the FSF upstream guys will only cringe, tell us we should conform, and not change anything in their way of thinking/doing things (we probably don't follow some writ of Saint Stallman, god preserve us).
Re: Building OpenConnect with libintl
On Thu, Nov 08, 2012 at 01:27:31PM +, Woodhouse, David wrote: On Thu, 2012-11-08 at 14:06 +0100, Marc Espie wrote: *our* libtool looks first under .libs. If it doesn't, that's a bug. I surmise the bug-reporter is actually using gnu-libtool, or the libtool generated by THAT software. Hm, yes. I am *indeed* using GNU libtool. That's confusing; I didn't even know it was installed. If I run 'libtool --version', I get the non-GNU one. But ./libtool in my build directory ??? built from the git tree with libtoolize on the OpenBSD system, not from a tarball which obviously would have its own pre-autotoolised stuff ??? is the GNU one. So perhaps the next question is: what's wrong with my ./autogen.sh script? It currently looks like this: #!/bin/sh aclocal \ libtoolize --automake --copy --force \ automake --foreign --add-missing \ autoconf Should it have some kind of special case for OpenBSD? It looks like 'libtoolize' on my default path is the GNU one, while 'libtool' isn't. I don't think I did anything to screw with that; this should be a simple OpenBSD 5.2 install. And even if I fix the autogen.sh script for people building from the git tree, what about tarball releases that I make? Do I just let people know that those are *broken* on OpenBSD because GNU libtool doesn't work there? Confused... and hating autohell a little more than I did yesterday. Which I didn't know was possible. Pass LIBTOOL=/usr/bin/libtool on make's command line. Trying to get through the spaghetti of gnu autocrap only leads to insanity. That falls under the don't fight that shit, it's hopeless.
Re: Building OpenConnect with libintl
On Thu, 2012-11-08 at 14:36 +0100, Marc Espie wrote:
Pass LIBTOOL=/usr/bin/libtool on make's command line.
Thanks, that works. This commit should make it work for everyone
automatically, without them having to override it manually:
http://git.infradead.org/users/dwmw2/openconnect.git/commitdiff/8e2a463043
Now it should build out-of-the-box even when there's already a version
installed. It doesn't get NLS support unless you manually add /usr/local
to the compiler's search paths, but I'm prepared not to care about that
if that's what's expected on OpenBSD. I don't think it's sane for me to
*automatically* try adding /usr/local/{include,lib} on OpenBSD, is it?
I don't quite understand why that isn't the native toolchain default,
but it's not for me to fix it up in my own autohell. I have enough hell
of my own in there, without dealing with yours :)
Thanks for the help.
--
Sent with MeeGo's ActiveSync support.
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com Intel Corporation
[demime 1.01d removed an attachment of type application/x-pkcs7-signature which
had a name of smime.p7s]
Re: Building OpenConnect with libintl
Woodhouse, David david.woodho...@intel.com wrote: It seems that libintl *is* present, but it's installed in /usr/local and the compiler doesn't find it by default. [...] surely I shouldn't have to advise users to build things that way when using the platform's stock libintl? I would like to clarify that libintl is NOT part of a stock OpenBSD installation. It's third-party software and needs to be explicitly added as a package. (Well, most likely you add something else and it will pull in libintl as a dependency.) -- Christian naddy Weisgerber na...@mips.inka.de
Re: Building OpenConnect with libintl
On Thu, 2012-11-08 at 14:36 +0100, Marc Espie wrote: Pass LIBTOOL=/usr/bin/libtool on make's command line. Trying to get through the spaghetti of gnu autocrap only leads to insanity. That falls under the don't fight that shit, it's hopeless. Hm, OpenBSD libtool doesn't seem to honour the argument '-version-number 2:1', so my resulting library is 'libopenconnect.so.0.0' instead of 'libopenconnect.so.2.1'. Should I be specifying that differently? -- Sent with MeeGo's ActiveSync support. David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation [demime 1.01d removed an attachment of type application/x-pkcs7-signature which had a name of smime.p7s]
Re: Building OpenConnect with libintl
On Thu, Nov 08, 2012 at 03:38:18PM +, Woodhouse, David wrote: On Thu, 2012-11-08 at 14:36 +0100, Marc Espie wrote: Pass LIBTOOL=/usr/bin/libtool on make's command line. Trying to get through the spaghetti of gnu autocrap only leads to insanity. That falls under the don't fight that shit, it's hopeless. Hm, OpenBSD libtool doesn't seem to honour the argument '-version-number 2:1', so my resulting library is 'libopenconnect.so.0.0' instead of 'libopenconnect.so.2.1'. Should I be specifying that differently? Found this in the GNU libtool documentation: New projects should use the -version-info flag instead. It looks like -version-number is an accepted option (thus no error message), but no further processing is done on it. May be an oversight in our libtool? Note that the ports system overrides the version specified on the command line, to fit into the OpenBSD-specific versioning scheme. -- Sent with MeeGo's ActiveSync support. David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation [demime 1.01d removed an attachment of type application/x-pkcs7-signature which had a name of smime.p7s]
[NEW] net/openconnect
Please be gentle... this is my first ever port. From the site: OpenConnect is a client for Cisco's AnyConnect SSL VPN, which is supported by the ASA5500 Series, by IOS 12.4(9)T or later on Cisco SR500, 870, 880, 1800, 2800, 3800, 7200 Series and Cisco 7301 Routers, and probably others. OpenConnect is released under the GNU Lesser Public License, version 2.1. I used an earlier port of 2.26, and recently just saw that 3.02 was released a few days ago (4-19-2011). Please test. I have tested it on i386 and amd64. Works great to my office's Cisco ASA VPN. Thanks to Landry Bruell for straightening me out on the LIBDEPENDS in my old makefile. And thanks for Jiri B. for the original... Comments are suggested... [demime 1.01d removed an attachment of type application/x-gzip which had a name of openconnect-3.02.tar.gz]
