[Openswan dev] [PATCH] Incorrect automatic route via ipsec0
Bart Trojanowski
bart at jukie.ca
Sat Oct 23 14:01:26 EDT 2010
Hi,
Sorry to be *so* a late joining in on the fun.
The proposed patch defeats the intent of the code it modifies. I
don't quite understand why the metric bumping code is triggering at
all.
The 'phys_otheraddr' variable should only be set by the
getinterfaceinfo() function, if the physical interface is a
point-to-point device (like ppp for example). Is that the case for
you?
If the physical device is a regular ethernet device -- as I think
yours is based on the eth1 name -- then the code you modified should
never execute since the 'maxmetric=$()' line will run:
ip route show $phys_otheraddr/$phys_mask
... and regardless of what the mask is, as long as otheraddr is an
empty string, then ip will halt with an error printed to stderr.
So, I am confused why the change you proposed makes a difference.
Maybe I falsely expect ip to fail when given bad input parameters.
Can you help me out? Could you revert your _startklips to the
published code, add a "set -x" at the top of the script, and run ipsec
setup --start ?
I'd also need the output of your 'ip ad' and 'ip ro' commands, from
before ipsec setup runs.
Thanks in advance.
-Bart
PS: I propose we do something like the attached patch instead. But I
have to test it with a pppoe setup to make sure the original
workaround is still doing what it was intended to do.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-be-extra-careful-when-adjusting-the-peer-route-in-st.patch
Type: text/x-patch
Size: 2325 bytes
Desc: not available
Url : http://lists.openswan.org/pipermail/dev/attachments/20101023/0974744c/attachment.bin
More information about the Dev
mailing list