cyanogenmod progress

[Jason]

On Sat, Jul 09, 2011 at 09:47:37PM +0100, David Woodhouse wrote:
> On Sat, 2011-07-09 at 15:29 -0400, Jason wrote:
> > On Sat, Jul 09, 2011 at 08:04:10PM +0100, David Woodhouse wrote:
> > > On Thu, 2011-07-07 at 17:51 -0400, Jason wrote:
> > > > 
> > > > for those following this, I just made my first connection from within CM
> > > > on the command line, in my phone.  I didn't even have a script, I had to
> > > > hand-jam the routes in to ping the other side.
> > 
> > I've modified a generic vpnc-connect.sh script and it works for my
> > limited experience.  It may even be suitable for upstreaming, as I
> > created separate *_resolvconf_android() functions and such.
> 
> How does this work for vpnc in Android? It should be exactly the same
> requirement, right?

Yep, just changing default $PATH, the first line, '#!/system/bin/sh',
and then the functions I mentioned.
 
> > > > There's still a lot of work to do.  But it does build inside of CM, and
> > > > I have a skeleton GUI in Settings -> Wifi/Networks -> VPN -> Add a VPN.
> > > > It's an exact copy of the openvpn options, but hopefully I'll have that
> > > > fixed in the next couple of days. 
> > 
> > I've started modification of the options, so I'm busy cussing out the
> > architects of Java/C++.
> > 
> > > You can start by just asking the user to enter the 'webvpn' cookie, but
> > > of course that's not a very user-friendly solution. They'd have to run
> > > 'openconnect --cookieonly' in a terminal to get it :)
> > 
> > The way James Bottomley wrote the openvpn client was to collect all the
> > options, then call the armel openvpn binary with the options appended
> > on the commandline.  I'm attempting to take the same approach here as
> > it's the simplest path to success.  Code reuse and all that...
> > 
> > My only snag is that openvpn has a management socket which Android polls
> > for status info and passes user/pw authentication info through.  I can't
> > find a clean way to pass the password to openconnect as there's no IO
> > piping from Java.  And I don't want to include it on the cmdline, not
> > that that's an option anyway.
> > 
> > Would you be opposed to me adding a management socket to openconnect?
> 
> Just checking: It's the *cookie* you need to pass, not a password. You
> need to have done the authentication to the server already, before you
> invoke openconnect to actually make the connection.
> 
> You can't pass all the arguments in advance; you don't *know* them. The
> server presents you with *arbitrary* forms to fill in. We have a
> 'username' and 'password' option which are a bit of a dirty hack to
> attempt to automatically do it in the simplest case, but we can't rely
> on that.

Ahhh... there was some critical info.  :-)  My little test setup worked
for 'openconnect -s /path/to/script -u jason https://url.local'  It
asked for a password, and everything went fine.  Looks like I'll need to
rethink it a little.

> As long as you have the cookie, you can just pass that to mtpd, which is
> C code, and then it can spawn openconnect to make the connection, can't
> it?

That is what currently happens, minus the cookie part.  After filling in
the arbitrary webform, what's the correct, or current, way to pass the
cookie back?

> I'm not sure I really see why a management socket is necessary. Even if
> it was, my first thought would be to do it in a wrapper (much like
> network-manager-openconnect wraps it and spawns openconnect).

Based on this new info, the only need for a management socket now would
be for status updates.  A simple ping of the remote side may fix that.
I'll look at how the other vpn types do it, as ipsec doesn't have a
management socket that I'm aware of.


Thanks for the help,

Jason.