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

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

[David Woodhouse]

On Thu, 2011-07-28 at 03:18 +0100, Justin Bronder wrote:
> From 0a1c10c83f2043f00793c166ad351dc643bcefe3 Mon Sep 17 00:00:00 2001
> From: Justin Bronder <jsbronder@gmail.com>
> Date: Wed, 27 Jul 2011 22:10:06 -0400
> Subject: [PATCH] fix for newer kernels
> 
> newer kernels have added expires and mtu to the ip route output
> ---
>  vpnc-script |    8 +++++++-
>  1 files changed, 7 insertions(+), 1 deletions(-)
> 
> diff --git a/vpnc-script b/vpnc-script
> index e0140c5..b071e0b 100755
> --- a/vpnc-script
> +++ b/vpnc-script
> @@ -139,7 +139,13 @@ 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/cache//' \
> +            -e ';s/metric \?[0-9]\+ [0-9]\+//g' \
> +            -e 's/hoplimit [0-9]\+//g' \
> +            -e 's/ipid 0x....//g' \
> +            -e 's/expires [0-9]\+sec//g' \
> +            -e 's/mtu [0-9]\+//g'
>  	}
>  
>  	set_vpngateway_route() {

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

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

[David Miller]

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.

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

[David Woodhouse]

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

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

[David Woodhouse]

On Fri, 2011-07-29 at 13:57 +0100, David Woodhouse wrote:
> > 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