[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