vpnc-script fix for changed iproute output with newer kernels
Subsystems (2)
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 19 lines · Justin Bronder
From
0a1c10c83f2043f00793c166ad351dc643bcefe3Mon Sep 17 00:00:00 2001
From: Justin Bronder <[email protected]>
Date: Wed, 27 Jul 2011 22:10:06 -0400
Subject: [PATCH] fix for newer kernelsnewer kernels have added expires and mtu to the ip route output
--- vpnc-script | 8 +++++++- 1 files changed, 7 insertions(+), 1 deletions(-)vpnc-script +0
-1@@ -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'
vpnc-script destroy_tun_device() { · line 151
Quoted 10 lines
vpnc-script +7
-0+ 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?
Signature · 1 line
dwmw2
David Miller
maintainerFrom: David Woodhouse <[email protected]>
Date: Fri, 29 Jul 2011 13:33:11 +0100
Quoted 1 line
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.
Quoted 8 lines · David Miller
From: David Woodhouse <[email protected]>
Date: Fri, 29 Jul 2011 13:33:11 +0100Quoted 1 line
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.
Quoted 4 lines
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.
Signature · 1 line
dwmw2
Quoted 8 lines · David Woodhouse
Quoted 3 lines
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:
vpnc-script +2 -1
@@ -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 64Signature · 1 line
dwmw2