Dialup On Demand (was: [SHR] Miscellanious minor issues)

[NeilBrown]

On Sat, January 31, 2009 2:55 am, Michael 'Mickey' Lauer wrote:
> Ok cool, but how does this work internally? We want the framework to be
> notified, not the ppp process (which we don't want to run all the time)

On demand network connection is awkward to do in a completely general way.

When an application makes a TCP connection, the kernel needs to choose a
local address for "this" end of the connection.  It chooses that
based on the IP address of whichever interface will be the first
hop of the outgoing connection.

If you don't have that interface established, then there is no address
or route, so the kernel will give up quite quickly - there is no where
for user-space to hook in and make things work.

One option is to always use a VPN through some base station.
I think you can get OpenVPN to establish a connection on demand.
So the kernel sees the OpenVPN interface and sends a packet to that.
OpenVPN then brings up whatever network can be found and forwards the
packet over the VPN and on the the Internet.

You could probably set up something vaguely similar that works
locally without needing a remove VPN server or even a VPN.

1/ open two TUN devices and configure them with very obscure private
   addresses with a PTP connection between them.  Maybe
      ifconfig tun0  127.0.0.10 pointopoint 127.0.0.11
      ifconfig tun1  127.0.0.11 pointopoint 127.0.0.10
   Doing this will require having a program that creates the devices
   and reads traffic from them.

2/ Add a default route out tun0, so all traffic will head that way.
3/ Use iptables to MASQuarade traffic arriving on tun1.

4/ Then your program gets a packet in on tun0 that it wants to send to
   the internet, it brings up a connection some how and fiddles the
   default route and writes the packet out to tun1.
   You then just need to copy traffic between the two interfaces.

There may be some subtleties in getting the routing set up correctly.
Once the Internet is available, you really want new connections to
go direct, but the original connection (while it lasts) will have to
go through the forwarding setup.
And you don't want packets that come out of tun1 to be routed back in
to tun0.
If anyone tries this and gets confused by the difficulty of routing
packets the right way, don't hesitate to ask - I am very confident that
it is a solvable problem.

NeilBrown