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

[Joel Newkirk]

On Sat, 31 Jan 2009 11:34:42 +1100 (EST), "NeilBrown" <neilb at suse.de>
wrote:
> 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.

What about (which I expect will not be a candidate for an 'official'
solution;)

get frameworkd talking to ip_queue or netlink.  For example, we could:

Create a lowest-priority default route that hits lo, like:
route add default gw 127.127.127.127 dev lo metric 100

use ip_queue.ko.  Write a userspace handler for the iptables QUEUE target.
(It's been a few years but I've written a couple, in c, use libipq - pretty
simple)  The handler will receive every packet that is sent to it with a
firewall rule like:
iptables -A INPUT -d ! 127.0.0.0/8 -i lo -m limit --limit 1/sec -j QUEUE 
iptables -A INPUT -d ! 127.0.0.0/8 -i lo -j DROP

Now whenever another route doesn't exist, the kernel presents outbound
packets to the queue handler. (up to one per second, and unspecified
--limit-burst is 5 - the second rule drops what doesn't get queued)  The
handler gets to tell the kernel whether to accept or drop the packets, in
this case it'd be simplest probably to drop them.  In the meantime,
however, it can tell the network manager (or whatever mechanism) to try to
bring up an interface.  If that's successful then its newly-created route
takes precedence. (providing it has a lower metric than 100...)  

It can also take a moment to examine the packets it's handed and decide -
based on whatever criteria desired - if it really needs to bring up an
interface or not.  Like "if it's DNS fire it up, but if it's broadcasts
just ignore it".  (those criteria could be handled in iptables actually,
but others would be harder, the things that frameworkd can offer like "is a
voice call in progress?" [if so, forget gprs] or "am I preparing to
suspend?", etc)

j

-- 
Joel Newkirk
http://jthinks.com      (blog)
http://newkirk.us/om (FR stuff)