On Tue, 5 May 2015 10:20:32 +0200
David Lamparter <[email protected]> wrote:
> On Wed, Apr 29, 2015 at 09:49:54AM -0400, Donald Sharp wrote:
> > As an aside. Is there a particular reason we have 5 different "set
> > metric" command handlers in the code base?
>
> Not really... just the usual spaghetti code :(
>
> > sharpd@monster-01:~/quagga-2$ find . -name '*.c' -print | xargs
> > grep "DEFUN (set_metric"
> > ./bgpd/bgp_routemap.c:DEFUN (set_metric,
> > ./ospf6d/ospf6_asbr.c:DEFUN (set_metric,
> > ./ospfd/ospf_routemap.c:DEFUN (set_metric,
> > ./ripd/rip_routemap.c:DEFUN (set_metric,
> > ./ripngd/ripng_routemap.c:DEFUN (set_metric,
> >
> > This causes issues with what is actually called due to the way the
> > cli is created in vtysh/extract.pl since it doesn't have anything
> > to differentiate what actual function to call. I added debugs to
> > my version and noticed that the ospfd version is the one that is
> > called(instead of all of them). While it's ok or the normal 'set
> > metric' command, bgp depends on the set metric +/- command and it
> > does not get parsed.
>
> Hm, the +/- metric looks rather broken to begin with, the DEFUN says:
> "set metric <+/-metric>"
> which is simply a 'syntax error' for the CLI parser - aka, there's
> simply no such syntax. We might want to fix that...
>
> The commands that do work ("set metric 999", "set metric +999") seem
> to work on all daemons though. Negative numbers get rejected by the
> CLI code though. Is it possible you only logged calls to the
> +/-metric version in bgpd? Seems it's the "absolute" version that
> gets called...
No. I did not test the existing "+/-<number>" syntax. Sounds like it's
broken.
> (Haven't looked at behaviour after the patch, this is all before/on
> current master)
I tested the "+/-rtt" variant, and it worked as expected.
_______________________________________________
Quagga-dev mailing list
[email protected]
https://lists.quagga.net/mailman/listinfo/quagga-dev