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

[Neil Brown]

On Saturday January 31, freerunner at newkirk.us wrote:
> 
> 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...)  

I've never played with ip_queue so I cannot say.  You may well be
right that a solution lies that way as well.
However if I understand it correctly, it relies on the kernel
retransmitting packets after the new routes are set up.  I think that
is likely to introduce more delay that might be acceptable.  As soon
as the link come up we really want to re-introduce all packets that
were captured so that the network seems as responsive as possible.
Though I may be misunderstanding you suggestion.

There is an interesting complication that I was reminded of when I
tried to knock up a quick-and-dirty proof of concept.

An important aspect of any solution is that you need to set up
masquerading (or Source NAT) so that packets from the internal address
get the source address re-written on the way out.
However SNAT mapping are set up when the first packet in a connection
is seen.
So if we capture the first packet of a connection, then set up an
external interface, it is now too late to do source NAT for that
connection.  It can work for new connections without trouble, but that
first connection is stuck.

I think(hope?) it might be possible to use the "NOTRACK" target in
iptables to exempt all packets from connection tracking until the
external like is up and the default route and been redirected.
I only learned about NOTRACK today and have not experimented with it
so I cannot be sure, but it does seem to be a perfect fit for this
problem.

> 
> 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)

Yes, being selective about which packets can trigger a network
connection would be a valuable feature.

NeilBrown