Justify wheel re-invention

fixme: cookies

Bugger it. Own HTTP parsing

Start of code to use neon. This doesn't work either.

Maybe I will just fall back to doing the bloody http parsing for myself.

Switch to using Neon for XML parsing.

Use SecurID based login to retrieve webvpn cookie

fixme: redirects happen

Look up hosts in XML config file

Remove a bunch of stuff from TODO

Make cert and key options a little saner

doh. Fix latency fuckup

Clean up exit handling a little

Enable compression by default, allow DTLS to be disabled

Change name of MTU environment variable

fix up server verification a bit

Add server cert verification

handle SIGHUP too

Clean up messages a little

Clean up CSTP option handling

admit what we know about xml download

Add comments on OpenSSL patches

Tidy up option handling a little

Add capability to use vpnc's route mangling script

set up for invoking script for config

FD_CLOEXEC

Remove the 'FIXME: keepalive' comment. I implemented that already

Implement DTLS rekey

Start of DTLS rekey support, clean up comments about protocol

Add OpenSSL patches

Use SSL_OP_CISCO_ANYCONNECT option to match the patch I sent upstream

commit makefile hacks for openssl testing

Latency will be a lot better if we actually select on the right fd

Use explicit numbers for DTLS1_BAD_VER and DTLS1_VERSION

That way it can build against either 0.9.8e or 0.9.8f

Set MTU too.

From the server's response, rather than what we asked the server for.

Set default UI method so it works for PEM passphrases too.

Looks like this means we can't set the UI userdata to vpninfo,
unfortunately.

fixme for cert passphrase

Demonstrate how to do callback for TPM password; proper UIs will need this

Take TPM SRK password on command line too, optionally

The callback does seem to work; a GUI client might want something more
special.

Use OpenSSL TPM engine

quieter

Make interface name configurable

Add IPv4 address and netmask configuration

silence warnings, and output

Add cookie fetching code, given a certificate. This bit sucks

Another response seen in the wild

fix curl_err uninitialised

Remove abstraction crap

Fall back to SSL if DTLS dies

Sort out DPD and Keepalive

This could be cleaner -- and shared between DTLS and SSL. But this seems
to work...

one fewer FIXME...

check DPD config

tidy up, add DPD

macros for packet types

data transport over DTLS working

don't send data over SSL while DTLS active

attempt actual data transport over DTLS. Not working yet

fix typo

wheee. dtls works... at least with their library

Add readahead to UDP socket, to avoid throwing away ends of packets.

Still doesn't work though -- but it's the same failure mode as when I run
the Cisco client with my own build of OpenSSL.

Attempt DTLS setup. Broken.

connect in separate func

Start on DTLS setup

move DTLS comments

document ssl packetisation

quit cleanly when receive unknown packet

simplify payload_len handling

a little more debug

move inflate_and_queue_packet() into ssl.c

split out queue_packet()

server cert check in TODO

add todo list

Add compression support

oops, anyconnect.h too

actually send BYE packet on exit

Add bye handling, not that it's used yet

oops, forgot mainloop.c

Drop wrong-length packets now that we don't see them

Implement CSTP keepalive

fix typo in DTLS failure warning

Comment on write queue full situation

Add comment about poll() handling

First attempt at a mainloop

Rename cisco.c to main.c, and output program to anyconnect

fix up makefile

Restructure somewhat

Add licence boilerplate.

I'd prefer to use GPLv2, but that isn't compatible with either OpenSSL
(which is required; GNUTLS doesn't do DTLS), or lwip. And it's not as if
people are massively likely to 'steal' it for commercial products
without contributing back.

get connect/response handling working

Initial attempt at using cURL.

This is probably just going to be too much of a pain in the arse -- it's
going to be complex to handle the CONNECT request, and even harder
dealing with the TPM -- we don't know what SSL engine cURL will be
compiled with. And we have to be linked against OpenSSL _anyway_.

The only thing cURL buys us, really, is the redirect handling and HTTP
response parsing -- and most of that is trivial enough anyway.

Left here just in case I change my mind when it comes to actually
submitting the forms...

Try using OpenSSL directly

Add simple makefile

First import of test code