Daniel Lenski [Thu, 17 Aug 2017 03:07:45 +0000 (20:07 -0700)]
improved MTU calculation for GlobalProtect ESP
On Wed, Aug 16, 2017 at 8:03 PM, Daniel Lenski wrote:
> I believe the correct [ESP padding] algorithm is actually as follows:
>
> * From payload MTU, add 2 footer bytes, round *up* to a multiple of
> the blocksize. Add the size of the MAC, IV, and other headers. That's
> the size of the packet on the wire.
> * From wire packet MTU, subtract headers and MAC and IV, round *down*
> to a multiple of blocksize, subtract TWO footer bytes, and that's the
> largest payload you can carry.
Signed-off-by: Daniel Lenski <dlenski@gmail.com> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Daniel Lenski [Tue, 15 Aug 2017 18:42:58 +0000 (11:42 -0700)]
fix DTLS_OVERHEAD and GlobalProtect ESP overhead calculation
GlobalProtect doesn't try to calculate MTU until after it has information on
the ESP ciphersuite, so it can use the real HMAC/encryption key lengths when
calculating ESP overhead. In practice, I have never seen or heard of a GP
VPN that uses anything other than AES128+SHA1, but both the clients and
servers appear to include support for AES256.
DTLS_OVERHEAD was not correctly accounting for possibility of AES256
(32-byte IV).
Signed-off-by: Daniel Lenski <dlenski@gmail.com> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
David Woodhouse [Tue, 15 Aug 2017 16:35:16 +0000 (17:35 +0100)]
Fix gpst parse_portal_xmk() some more
If both 'portal-name' and 'gateways' nodes exist, but the 'gateways'
node comes first, we'd never handle the 'portal-name'. It might never
happen in practice... but that's no excuse :)
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
David Woodhouse [Tue, 15 Aug 2017 15:15:51 +0000 (16:15 +0100)]
gpst: Mangle User-Agent haeder in one place
If we really need to override it for *all* requests, let's just do that
in gpst_common_headers(). Although maybe it'd be better just to ensure
that vpninfo->useragent is set appropriately in the first place?
It's not clear what we're gaining by preserving ->urlpath either, since
it never gets used as-is; we only *ever* override it with our own
strings. So we might as well just free the old one and set it.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
David Woodhouse [Tue, 15 Aug 2017 14:34:29 +0000 (15:34 +0100)]
Clean up gpst parse_portal_xml() a little
There was a potential crash if building up the XML in 'buf' didn't
work, because buf->data could be NULL yet we still passed it back
to vpninfo->write_new_config(). So check with buf_error() first.
We can't use a 'static' form because in theory this can be invoked
twice simultaneously for different VPNs, in the same process (and it
isn't even *impossible* the way kde-plasma-nm handled authentication).
Add a FIXME for the fact that we aren't escaping characters which need
it in the XML we build up.
Some other cosmetics, like using calloc() as $DEITY intended instead
of duing the multiplication ourselves.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
David Woodhouse [Tue, 15 Aug 2017 13:50:55 +0000 (14:50 +0100)]
Clean up gpst parse_login_xml() a little
Fix a potential double-free when we hit a non-"argument" node, which could
cause a 'goto err_out' with value still set to the one that was already
freed last time round the loop.
Cosmetic changes to the args array, and change the loop over them. The
'continue' on !arg->opt doesn't seem to be useful; let's use !arg->opt
as the condition to terminate the loop instead.
Most 'const' removal, although actually I think it probably *can* be
const if we just use xml_node->content directly, and that means we don't
need to free it at all. Didn't want to make that change without testing
it though.
Steal cookie->data instead of strdup() and then immediately freeing it,
like we do for Juniper.
Other trivial cosmetic changes (spaces, !x instead of x==NULL or even
X == NULL).
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
David Woodhouse [Tue, 15 Aug 2017 11:30:40 +0000 (12:30 +0100)]
gpst: Clean up some 'const char *' that shouldn't be const
... and the associated forced casts to non-const on free()
Although actually... given that we aren't doing the string expansion
thing, perhaps the 'var' returned by xmlnode_get_text() *could* be
const in this case, and just return node->content. Most callers do
seem to have to free it instead of really keeping it, and the few
that want to keep it can use strdup(). Dan?
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Daniel Lenski [Tue, 15 Aug 2017 04:32:05 +0000 (21:32 -0700)]
when connecting to a GlobalProtect portal (not gateway), generate an xmlconfig so that NetworkManager can list all the gateway servers
GlobalProtect distinguishes "portal" and "gateway" servers. Often the same
server supports both (/global-protect URLs are for the portal, /ssl-vpn URLs
are for the gateway). The official clients always connect through the
portal. Mostly, the portal configuration is not useful for OpenConnect; it
restricts the behavior of the official clients.
However, the portal configuration does contain a list of allowed gateways
(just as AnyConnect VPNs can list other servers).
This commit generates an xmlconfig in the same format as AnyConnect VPNs, so
that the NetworkManager plugins can list all the supported gateways.
Signed-off-by: Daniel Lenski <dlenski@gmail.com> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Daniel Lenski [Tue, 15 Aug 2017 04:32:04 +0000 (21:32 -0700)]
Add support for GlobalProtect ESP tunnel
Most of the existing ESP support code (written for Juniper/nc) can be reused
for GlobalProtect ESP. The ESP algorithms, SPIs, and keys are sent as part of the
getconfig XML response.
GlobalProtect requires a fairly awkward "tap dance" between the TCP mainloop and
the UDP mainloop in order to support ESP:
* Prior to the getconfig XML request, the HTTPS tunnel will not work (even though
the authcookie is already known from the login response) and the ESP tunnel
also will not work (because the ESP keys are not known).
* After the getconfig XML request, either the ESP tunnel or the HTTPS tunnel can
be connected, but not both. As soon as the HTTPS tunnel is disconnected,
the ESP keys are invalidated. On the other hand, if the ESP tunnel stops
responding due to some firewall that interferes with UDP, the HTTPS tunnel
can still be connected.
* Therefore, in order to allow the ESP tunnel to start, the TCP mainloop must
refrain from actually connecting to the HTTPS tunnel unless the ESP tunnel
is disabled or has failed to connect... but it can't wait *too* long
because then the HTTPS keepalive connection may be dropped, and the user
will wonder why no traffic is flowing even though the VPN has allegedly
started. The wait time is currently hard-coded at 5 seconds (half the DPD
interval used by the official clients).
Another quirk of the GlobalProtect ESP support: it uses specially
constructed ICMP request/reply ("ping") packets as the probes for ESP
initiation and DPD.
* These packets must contain a "magic payload" in order to work.
* In most GlobalProtect VPNs, the packets are addressed to the public, external IPv4
address of the VPN gateway server even though they are sent over the ESP
tunnel (???), but in some cases they must be addressed to a different address
which is misleading described as <gw-address> in the getconfig XML response.
Don't blame me. I didn't design this.
Signed-off-by: Daniel Lenski <dlenski@gmail.com> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Daniel Lenski [Tue, 15 Aug 2017 04:32:02 +0000 (21:32 -0700)]
detect user[name], pass[word] form fields using only the first 4 characters
The current process_auth_form_cb hard-codes the interpretation of these form
fields based on their names. GlobalProtect has identical fields but with
slightly different names.
Signed-off-by: Daniel Lenski <dlenski@gmail.com> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Daniel Lenski [Wed, 21 Jun 2017 18:23:52 +0000 (11:23 -0700)]
try alternate vpnc-script location (used by Debian-based distros)
This patch checks for the vpnc-script in the location used by
the standard vpnc-script package on Debian- and Ubuntu-based
Linux systems, /usr/share/vpnc-scripts/vpnc-script, in addition
to the standard /etc/vpnc/vpnc-script.
Signed-off-by: Daniel Lenski <dlenski@gmail.com> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Daniel Lenski [Sat, 20 May 2017 22:43:27 +0000 (15:43 -0700)]
add new_keys argument to esp_setup_keys() in preparation for supporting GlobalProtect ESP
The existing ESP key setup code can be almost entirely reused for
GlobalProtect ESP, except for the fact that esp_setup_keys() always
overwrites the secret keys with new random keys.
Since GlobalProtect ESP always uses keys provided by the server, a new
argument is added to esp_setup_keys() to make this behavior optional.
The Juniper-specific code in oncp.c calls it with new_keys=1 in order
to explicitly request it.
Signed-off-by: Daniel Lenski <dlenski@gmail.com> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Daniel Lenski [Sat, 20 May 2017 22:43:26 +0000 (15:43 -0700)]
add vpn_proto member functions .udp_send_probes and .udp_catch_probe in preparation for supporting GlobalProtect ESP
The existing Juniper ESP code can be almost entirely reused for
GlobalProtect ESP, except for the Juniper-specific code for sending and
recognizing the probe packets used for ESP initiation and DPD.
The Juniper-specific code is moved into functions names esp_send_probes
(sends Juniper probe packets) and esp_catch_probe (recognizes Juniper probe
packet responses), which are called via vpn_proto member functions.
Signed-off-by: Daniel Lenski <dlenski@gmail.com> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Daniel Lenski [Sat, 20 May 2017 22:43:25 +0000 (15:43 -0700)]
tweak the dtls_state handling in preparation for supporting GlobalProtect ESP
If a protocol wishes to have dtls_state set to DTLS_SLEEPING after closing
UDP, then it must now do so explicitly, because the mainloop will no longer
set it. This patch make both existing protocols set dtls_state explicitly
after closing the UDP connection. (The nc protocol already did so
explicitly, but the anyconnect protocol didn't.)
The previous behavior, wherein dtls_state was *always* set to DTLS_SLEEPING
after closing UDP, was incompatible with the GlobalProtect VPN.
Disconnecting and reconnecting GlobalProtect VPN doesn't just require
require reconnecting the UDP socket and resending probes; it actually
invalidates any previously-obtained ESP secret.
Signed-off-by: Daniel Lenski <dlenski@gmail.com> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Daniel Lenski [Wed, 14 Jun 2017 22:54:56 +0000 (15:54 -0700)]
relax requirements for Juniper hostname packet response
This fixes the "Unexpected response of size 3 after hostname packet" or "Invalid packet waiting for KMP 301" errors
which I get intermittently when connecting to an old Juniper NC server:
Here's what is going on: this server is (sometimes) concatenating the 3-byte
response packet together with the longer IP-configuration packet that
follows. When they are concatenated together, the server sends only a
single 2-byte length prefix for both (0x01d2 = 466).
Signed-off-by: Daniel Lenski <dlenski@gmail.com> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Daniel Lenski [Sat, 20 May 2017 22:43:22 +0000 (15:43 -0700)]
factor out common dump_buf_hex() and free_optlist() utility functions
These will be used in GlobalProtect protocol support, so it makes sense
to factor them out into shared utility functions rather than use slight
variants for each protocol.
Signed-off-by: Daniel Lenski <dlenski@gmail.com> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
David Woodhouse [Mon, 14 Aug 2017 10:33:16 +0000 (11:33 +0100)]
Require GnuTLS 3.2.10+ for GnuTLS builds
It's not worth the effort to keep it building for <3.2 any more; nobody
cares... or noticess when we accidentally break it. So kill it; we've
been threatening to for ages.
Use 3.2.10 as the base because 3.2.x before that was broken on Windows.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
David Woodhouse [Mon, 14 Aug 2017 09:42:41 +0000 (10:42 +0100)]
Allow reading stdin on Windows instead of forcibly opening console
This was filed against Ľubomír Carik's github project for openconnect-gui;
https://github.com/openconnect/openconnect-gui/issues/101
It isn't perfect, as the ANSI code page on Windows can be different
from the OEM code page used for the console, so fgetws() is likely
to do the wrong thing — which is why we force-opened the console and
used ReadConsoleW() in the first place. But perfect is the enemy of
good in this case, as reading from something other than stdin is
*definitely* wrong. We still use ReadConsoleW() when stdin does happen
to be the console, so that part shouldn't regress.
I hate Windows...
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
David Woodhouse [Thu, 25 May 2017 20:15:27 +0000 (21:15 +0100)]
Fix charset handling for --key-password on command line
It was always converting to UTF-8 for input from the terminal; there
was a plausible reason for using the legacy charset as-is but it's
better to be consistent.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Daniel Lenski [Mon, 15 May 2017 04:22:06 +0000 (21:22 -0700)]
store length of ESP encryption and HMAC keys so that they can be manipulated separately for both Juniper and GP
David Woodhouse wrote:
> Daniel Lenski wrote:
>> - unsigned char secrets[0x40];
>> + unsigned char secrets[0x40]; /* Encryption key bytes, then HMAC key bytes */
>
> You're allowed to object to that horridness and split it into two
> separate fields for the encryption and HMAC keys, instead of just
> documenting it.
>
> In fact, one might argue that would be the better approach...
Signed-off-by: Daniel Lenski <dlenski@gmail.com> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Nikos Mavrogiannopoulos [Sun, 5 Mar 2017 10:43:15 +0000 (11:43 +0100)]
Added support for RFC7469 key PIN
That allows the hash provided to the client to be the RFC7469 key PIN.
That is, a base64 encoding of the public key sha256 hash instead of the hex
equivalent. That reduces the number of characters that need to be typed.
Signed-off-by: Nikos Mavrogiannopoulos <nmav@gnutls.org> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Daniel Lenski [Sun, 8 Jan 2017 20:27:54 +0000 (12:27 -0800)]
add oncp_bye() to logout the Juniper session
The nc protocol lacked a .vpn_close_session function; without logout, the
VPN cookie remains active and can be used to restart the session, which is a
security hazard—especially when passing around OpenConnect logs on the
mailing list for development and troubleshooting.
Juniper logout is straightforward: GET /dana-na/auth/logout.cgi (with the
appropriate DSID cookie set).
Signed-off-by: Daniel Lenski <dlenski@gmail.com> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Daniel Lenski [Wed, 19 Apr 2017 20:12:48 +0000 (13:12 -0700)]
enumerate supported VPN protocols via openconnect_get_supported_protocols()
Add two new public functions:
* int openconnect_get_supported_protocols(struct oc_vpn_proto **protos)
Fetches a list of protocols supported by the client. Each supported
protocol has a short name (as accepted by the --protocol command-line
option), pretty name, longer description, and list of flags.
The return value of the function is the number of protocols supported (or
negative if an error occurred).
The flags indicate features that are meaningful for this protocol, to be
used by tools like the Networkmanager configuration UI. Current flags:
* OC_PROTO_PROXY: can connect via HTTP or SOCKS proxy
* OC_PROTO_CSD: supports verification of the client via CSD trojan
* OC_PROTO_AUTH_CERT: supports authentication by client certificate
* OC_PROTO_AUTH_OTP: supports authentication by OATH HOTP/TOTP token
* OC_PROTO_AUTH_STOKEN: supports authentication by RSA SecurID token (stoken)
Frees the list of protocols fetched by openconnect_get_supported_protocols()
The description of the "anyconnect" protocol matches the IETF draft
standard for openconnect VPN (https://tools.ietf.org/html/draft-mavrogiannopoulos-openconnect-00).
Signed-off-by: Daniel Lenski <dlenski@gmail.com> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Nikolay Martynov [Fri, 12 May 2017 23:57:29 +0000 (19:57 -0400)]
Do not drop vpn connection if packet arrived is larger than MTU
Sometimes server sends us packets that are larger than negotiated MTU.
Current implementation bails out in this case.
This patch makes openconnect to reserve space and handle incoming packets
that have size up to 16384 (to match CSTP).
This improves connection stability.
Signed-off-by: Nikolay Martynov <mar.kolya@gmail.com> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Nikolay Martynov [Thu, 11 May 2017 03:02:59 +0000 (23:02 -0400)]
Do not try to establish DTLS on reconnect if it wasn't established before
Currently when TCP SSL fails reconnect attempt happens. This attempts tries to establish DTLS connection regadless if it existed before. Code ends up in infinite loop doing that.
This changes fixes this by disabling DTLS at startup if DTLS connection cannot be established.
Also change ESP handling code to not reenable DTLS on ESP close.
Signed-off-by: Nikolay Martynov <mar.kolya@gmail.com> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Piotr Kubaj [Fri, 12 May 2017 13:24:37 +0000 (14:24 +0100)]
Fix build with LibreSSL 2.5.1 and higher.
We don't actually care if we use the read or write state; we're only
calculating the cipher/protocol overheads which are the same in both
directions.
In LibreSSL they were all removed in
https://github.com/libressl-portable/openbsd/commit/122ecd906da7
and the read side was restored in
https://github.com/libressl-portable/openbsd/commit/0d7a7d5f5a44
so just use that.
Signed-off-by: Piotr Kubaj <pkubaj@anongoth.pl> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
David Woodhouse [Wed, 14 Dec 2016 20:30:47 +0000 (20:30 +0000)]
Rely on SoftHSM being installed correctly with a p11-kit .module file
I don't actually remember why I added my own; it *ought* to be installed
correctly by the distribution's packaging of SoftHSM.
There was a brief discussion about my hard-coded version being
Fedora-specific, followed by a suggestion that I could pick up the
proper path from and existing module file, followed by the realisation
that said existing module file would suffice anyway. So just require it.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Janne Juntunen [Tue, 29 Nov 2016 22:37:22 +0000 (22:37 +0000)]
Add support for Google Authenticator 2fa on Juniper VPN
We resently changed our Juniper VPN from SMS 2fa to use Google
Authenticator instead. Before it worked perfectly with "openconnect
--juniper" switch, but after the change all we got was:
Unknown form ID 'frmTotpToken'
and a dump of the form.
I spent some time debugging the issue, and managed to write a very
simple fix for it.
Signed-off-by: Janne Juntunen <janne.juntunen@hermanit.fi> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Mike Miller [Wed, 14 Dec 2016 18:02:13 +0000 (10:02 -0800)]
tests: avoid using eval with variable assignments
For shell portability, avoid using eval with variable assignments to set
openconnect's environment. Shell implementations vary on whether
variable assignments in front of eval are marked as environment
variables or just treated as ordinary shell assignments.
Every call to $OPENCONNECT already has LD_PRELOAD=libsocket_wrapper.so
in front of it, so the "eval LD_PRELOAD=libsocket_wrapper.so" was
redundant anyway.
Signed-off-by: Mike Miller <mtmiller@debian.org> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Nikolay Martynov [Thu, 17 Nov 2016 03:26:17 +0000 (22:26 -0500)]
IPv6 packet size field doesn't include header size, take this into account
IPv6 packet's 'length' field contains length of payload excluding headers.
Header's length (40) needs to be added to that to get complete packet length.
This patch seems to be fixing random VPN drops.
Signed-off-by: Nikolay Martynov <mar.kolya@gmail.com> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Dan Lenski [Sun, 16 Oct 2016 01:56:30 +0000 (18:56 -0700)]
Correctly handle IPv4 route specified as either 10.1.2.0/255.255.255.0 or 10.1.2.0/24
The existing process_split_xxclude() only handles IPv4 routes
formatted as "10.1.2.0/255.255.255.0", not those formatted as
"10.1.2.0/24".
It's possible to unambiguously distinguish the two and handle the
latter case correctly, because no IPv4 netmask address can possibly
have a decimal integer value <= 32.
Signed-off-by: Daniel Lenski <dlenski@gmail.com> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Daniel Lenski [Sat, 15 Oct 2016 01:46:34 +0000 (18:46 -0700)]
Unset got_cancel_cmd after reacting to it, as is already done for got_pause_cmd
Per David Woodhouse (http://lists.infradead.org/pipermail/openconnect-devel/2016-October/004034.html):
> I think it's probably OK to set vpninfo->got_cancel_cmd=0 in the mainloop
> right before calling proto->vpn_close_session. If we get cancelled
> *again* then we'll give up on that too.
Without this fix, do_https_request() can't be used to close the
session — it interrupts itself as soon as it sees that got_cancel_cmd is
set.
Signed-off-by: Daniel Lenski <dlenski@gmail.com> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Daniel Lenski [Sun, 16 Oct 2016 19:37:58 +0000 (12:37 -0700)]
Make buf_append_urlencoded() percent-encode fewer characters.
Per RFC 3986, the characters '-', '_', '.', '~' don't need to be
percent-encoded anywhere in a URL or query string.
Removed special case for ' ' → '+' to prevent incompatibility with ocserv:
http://lists.infradead.org/pipermail/openconnect-devel/2016-October/004042.html
/* else if (c==' ')
buf_append_bytes(buf, "+", 1); */
Signed-off-by: Dan Lenski <dlenski@gmail.com> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
David Woodhouse [Tue, 13 Dec 2016 11:36:15 +0000 (11:36 +0000)]
Stop using deprecated LZ4 functions
../cstp.c:865:3: warning: ‘LZ4_compress_limitedOutput’ is deprecated: use LZ4_compress_default() instead [-Wdeprecated-declarations]
ret = LZ4_compress_default((void*)this->data, (void*)vpninfo->deflate_pkt->data,
^~~
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Nikos Mavrogiannopoulos [Tue, 1 Nov 2016 08:32:31 +0000 (09:32 +0100)]
openconnect_check_peer_cert_hash: allow partial server hash matches
That is allow the user specifying a small part of the hash (e.g., 'sha256:6429')
in order to be able to connect. This is to ease test connections, when copy-paste
is not possible.
[dwmw2: Fix man page to say 'at least 4 characters' not 'more than']
Signed-off-by: Nikos Mavrogiannopoulos <nmav@redhat.com> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
David Woodhouse [Tue, 4 Oct 2016 22:26:33 +0000 (23:26 +0100)]
Don't resume OpenSSL DTLS session for PSK-NEGOTIATE
Now that we are using a custom extension instead of the session-id
hack, we no longer need to pretend to resume a session. It was causing
a session-id of 32 zeroes to be included in the ClientHello. With
OpenSSL 1.1+, that was causing fragmentation which ocserv couldn't
cope with.
Perhaps ocserv *should* have coped with that fragmentation, and perhaps
we should increase our initial idea of the MTU to avoid the fragmentation.
But certainly we shouldn't be including an all-zero session-id for
resumption either.
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
David Woodhouse [Sun, 25 Sep 2016 19:32:17 +0000 (20:32 +0100)]
Fix openssl dependency in openssl.pc
When we discover a native system OpenSSL without pkg-config, don't
require openssl in openconnect.pc; instead add $OPENSSL_LIBS to
Libs.private. Only when we found it automatically though; when we
use --with-openssl=/where/I/built/openssl then we build statically
anyway so there's no need.
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
David Woodhouse [Sun, 25 Sep 2016 19:12:13 +0000 (20:12 +0100)]
Fix pcsclite dependency in openconnect.pc
On Windows and OSX, the PCSC support is provided by the system and not
a separate installation of libpcsclite. So don't require the pcsclite
package in the openconnect.pc file; instead add the appropriate thing
to Libs.private.
Reported-by: Björn Ketelaars <bjorn.ketelaars@hydroxide.nl> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Björn Ketelaars [Sun, 25 Sep 2016 15:02:59 +0000 (17:02 +0200)]
Small error in openconnect.8
openconnect.8 discusses 'basemtu' as option. Unfortunately this option is not
recognized. A quick glance in the source learned that 'base-mtu' should be
used.
Signed-off-by: Björn Ketelaars <bjorn.ketelaars@hydroxide.nl> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
David Woodhouse [Fri, 23 Sep 2016 14:29:25 +0000 (15:29 +0100)]
Limit netmask on Windows TAP setup to 255.255.255.254
This makes a start on the problems with point-to-point configurations,
discussed in https://github.com/openconnect/openconnect-gui/issues/132
Some work is required in vpnc-script-win.js to make the routing do
anything useful, but at least it's not now *impossible* to persuade
it to pass any traffic.
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
David Woodhouse [Fri, 23 Sep 2016 13:56:17 +0000 (14:56 +0100)]
Attempt to re-open CONIN$ if stdin has been redirected on Windows
This should hopefully fix the problem with --passwd-on-stdin, described
in https://github.com/openconnect/openconnect-gui/issues/101
It doesn't actually work for me in wine, as I get 'Access Denied' when
trying to use ReadConsoleW() on the resulting handle. But wine is strange,
and this at least shouldn't make things any *worse*.
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
projects / users / dwmw2 / openconnect.git / log