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.
