Support default route with non-default attributes

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



It makes sense that a lower metric should work, and as you say that
then relieves the burden of saving/restoring the original route. One
thing that is not clear to me in this regard is the relationship, if
any, between metric and protocol...should the new route in any case be
marked as "protocol static"?

I'm happy to test any changes, so let me know if I can help.

[ On a related note, since I originally reported this issue, I have
found that more-or-less consistently, my attempt to set the new route
*from the script* simply fails. I invariably end up setting it by hand
once vpnc has finished the setup. Since I can set the new route by
hand, it seems like a race, but adding delays here and there into the
script seemed to make no difference. I cannot think why this should
be...my kernel is whatever kernel Ubuntu "wily" thinks it should
be...but I mention it here in case it is somehow relevant ].

Thanks, Shaheed

On 6 April 2016 at 12:10, David Woodhouse <dwmw2 at infradead.org> wrote:
> On Fri, 2016-02-12 at 20:43 +0000, Shaheed Haque wrote:
>> [ This report concerns a defect originally reported at
>> https://bugs.launchpad.net/ubuntu/+source/vpnc-scripts/+bug/1544802 ]
>>
>> Bug Description
>>
>> The /usr/share/vpnc-scripts/vpnc-script handles updates to the
>> default
>> route using two different codepaths. In one codepath, the command "ip
>> route replace" is used to update the original default route with new
>> one (and to restore it later). The replace command in the update case
>> does not work if the original route default route has non-standard
>> attributes.
>
> Hi Shaheed, thanks for looking at this.
>
> I wonder if it might be better just to *leave* the original default
> route in place. Just add the new default route with a lower metric, so
> the old route doesn't get used?
>
> Then we don't have to worry about preserving the details of the old
> route at all, do we? Or the fact that there might be *multiple* default
> routes pre-existing? All we need to do is ensure that our new default
> route has a lower metric than any which already existed.
>
> --
> David Woodhouse                            Open Source Technology Centre
> David.Woodhouse at intel.com                              Intel Corporation
>



[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux