Re: vpnc-script fix for changed iproute output with newer kernels

On Thu, 2011-07-28 at 03:18 +0100, Justin Bronder wrote:

Thanks for this, Justin. But I'd really prefer not to do it this way.

This is the second time in as many kernel releases that this has broken;
we only added 'ipid' to that regex in May. If we have to keep doing this
dance, we are doing it *wrong*.

Stephen, what is the *right* way to do this?

This is for vpnc-script, as you ought to be able to tell from the patch
header. If we're adding routes to the newly-created VPN device, we first
have to ensure that the route to the VPN server *itself* doesn't change.

So effectively we want to do: 
 ip route add $(ip route get $VPNSERVER)

... except then we have to have that awful bunch of sed crap to make it
work right. I suppose we could at least make it opt-in, and include the
'via' and 'dev' and 'src' options and remove *everything* else? But that
doesn't really fill me with joy *either*.

Any suggestions that *aren't* going to be constantly broken?

-- 
dwmw2

From: David Woodhouse <dwmw2@infradead.org>
Date: Fri, 29 Jul 2011 13:33:11 +0100

Any suggestions that *aren't* going to be constantly broken?

You're going to have to be knowledgable about which attributes are
part of the route, whether you want to do this with iproute2 as a tool
or whether you do this directly with C code using netlink.

If you want to script this using iproute2, you should be grepping for
the attributes you want to keep rather then grepping for the
attributes you end up dropping.

iproute2 is never going to allow you to mirror "route get" outputs
into a "route add" call.  Because 'get' is going to always emit
metrics and other transient state, upon which we will always
potentially be buidling new items over time.

On Fri, 2011-07-29 at 05:46 -0700, David Miller wrote:

From: David Woodhouse <dwmw2@infradead.org>
Date: Fri, 29 Jul 2011 13:33:11 +0100

quoted

Any suggestions that *aren't* going to be constantly broken?

You're going to have to be knowledgable about which attributes are
part of the route, whether you want to do this with iproute2 as a tool
or whether you do this directly with C code using netlink.

I don't think I really want to try shipping vpnc-script with C code.

The 'opt-in' approach seems like the best one for now, then. I suppose
we want just the 'via' and 'dev' and 'src' attributes... anything else?

I'll see if I can come up with a regex that can parse that, in the
knowledge that the interface itself might actually be called "src" or
"dev" or "via".

This may make my brain hurt.

iproute2 is never going to allow you to mirror "route get" outputs
into a "route add" call.  Because 'get' is going to always emit
metrics and other transient state, upon which we will always
potentially be buidling new items over time.

An option to make 'ip route get' do exactly that would be massively
appreciated :)

Or an option to make 'ip route set' ignore the ones it doesn't like,
perhaps.

-- 
dwmw2

On Fri, 2011-07-29 at 13:57 +0100, David Woodhouse wrote:

quoted

You're going to have to be knowledgable about which attributes are
part of the route, whether you want to do this with iproute2 as a tool
or whether you do this directly with C code using netlink.

I don't think I really want to try shipping vpnc-script with C code.

The 'opt-in' approach seems like the best one for now, then. I suppose
we want just the 'via' and 'dev' and 'src' attributes... anything else?

This should do it for now, I suppose:

--- a/vpnc-script
+++ b/vpnc-script

@@ -139,8 +139,9 @@ destroy_tun_device() {
 
 if [ -n "$IPROUTE" ]; then
 	fix_ip_get_output () {
-		sed 's/cache//;s/metric \?[0-9]\+ [0-9]\+//g;s/hoplimit [0-9]\+//g;s/ipid 0x....//g'
+		sed -e 's/ /\n/g' | \
+		    sed -ne '1p;/via/{N;p};/dev/{N;p};/src/{N;p};/mtu/{N;p}'
 	}
 
 	set_vpngateway_route() {
 		$IPROUTE route add `$IPROUTE route get "$VPNGATEWAY" | fix_ip_get_output`

I'm still not happy with it, since I'm not 100% convinced I'm
preserving all the attributes that need to be preserved, and will need
to be preserved in future. I managed to keep 'src', but what else might
there be? I just don't want to have to know.

On trying to torture-test it, I also noticed that 'ip route get' doesn't
do what I'd want in the case of the following route:

default  src 90.155.92.214 
	nexthop via 81.2.98.173  dev eth1 weight 1
	nexthop dev ppp1 weight 1
[root@solos ~]# ip route get 131.111.8.42
131.111.8.42 via 81.2.98.173 dev eth1  src 90.155.92.214 
    cache  mtu 1500 advmss 1460 hoplimit 64


-- 
dwmw2