[guardian-dev] Fwd: Re: Orbot VPN service

[Nathan of Guardian]

On Sun, Oct 26, 2014, at 11:41 PM, Delyan Kratunov wrote:
> On Saturday, October 25, 2014 08:34:49 PM Nathan of Guardian wrote:
> > On Sat, Oct 25, 2014, at 05:47 PM, Delyan Kratunov wrote:
> > > > (adding /jni to git now)
> > > 
> > > Except, you're missing Android.mk from external/badvpn. :)
> > > 
> > > /home/delyan/dev/orbot/jni/Android.mk:2: ../external/badvpn/Android.mk:
> > > No
> > > such file or directory
> > 
> > Alright, looks like it is there now:
> > https://github.com/guardianproject/badvpn/commits/master
> 
> Also missing are SLF4J, appcompat's project structure and x86 binaries.
> I've 
> patched all of the above locally (the x86 is useful if you want to use an 
> emulator), so I am making some progress now. 

We don't generate x86 binaries yet for Orbot. That is an update we need
to make along with the new PIE work for Android L.

Once again, sorry for the bootstrapping misses on all these new
dependencies. I need to clear out my local Orbot repo folder, as its
full of a ton of untracked items, making it hard to see what is missing.
> 
> Unfortunately, this is harder than I originally envisioned. Between the 
> *hilarious* Android bug where the VPN service crashing means you can't 
> reestablish it (prepare() returns null, not sure if that means we can
> just 
> establish())

Yeah, I have noticed that - the fact that it crash without warning
(which does not fail "closed") and the fact you cannot re-establish. I
was thinking perhaps it may be due to a FileDescriptor being open still?

 and the hilarity of the
> my-process-gets-all-device-traffic-but-
> cannot-open-raw-sockets state of affairs, I'm mildly stuck atm. 

Oh, hmm.

> In particular, I can redirect DNS requests to Tor's resolver but that
> requires 
> opening a new socket from the tun2socks layer. This socket is to a
> loopback 
> address (Tor's resolver), so doesn't require whitelisting (good) but it
> can't 
> be raw since you need effective uid == 0 for that (bad). (If I could use
> raw 
> sockets, I could trick the resolver to pass the response to the original 
> request-er, skipping the translation layer on the way back.) The key 
> misunderstanding I had was that I thought writes to the tun device can
> also go 
> to loopback addresses. They can't. :/

Right.

> Which means I'll have to hold state in my little DNS layer, which means 
> separate threads so I don't stop the flow of the VPN traffic, which means 
> significant amounts of complexity. It'll take me a bit of time to come up
> with 
> all of this crap, errr... code.

Maybe using a local udpgw-client to a local udpgw daemon isn't looking
so bad now? 

> Userspace port forwarding. Definitely something I have not written
> before. 
> There's a first for everything, I guess.

Welcome to Orbot - the most important collection of useful mobile
network hacks on the planet!

Thanks for all the work and report back!

+n