Good to know, thank you for posting your findings.

I would find it really cool if module (re)loading could be done through the cli at runtime and the modules to load would be stored in the configuration instead of passing them in at startup time via argument. I think it should be possible if the module load statements are written out very early in the config, e.g. after the frr version/default statement, but I guess it night make config parsing slightly harder since registered commands might change in a relevant​ way while processing it.

-Chris

On Apr 16, 2017 1:14 AM, "Rodny Molina" <rodnymolina@gmail.com> wrote:
Found the missing piece :-)

/usr/lib/frr/zebra -s 90000000 --daemon -A 127.0.0.1 -M fpm

/Rodny


On Apr 15, 2017, at 3:48 PM, Rodny Molina <rodnymolina@gmail.com> wrote:

Hi folks,

I’ve noticed that since fpm was converted to a module (couple of weeks ago), I’m not able to establish any fpm connection. Looks like this is a consequence of fpm-module not being initialized. Am i missing something here? (yes, I’m building with —enable-fpm).

(gdb) bt
#0  frr_init () at libfrr.c:345
#1  0x00005555555671fd in main (argc=7, argv=0x7fffffffece8) at main.c:293

(gdb) p frrmod_list
$20 = (struct frrmod_runtime *) 0x7ffff7dd5ac0 <frrmod_default>

(gdb) p *frrmod_list
$21 = {
 next = 0x5555557b3480 <_frrmod_this_module>,
 info = 0x7ffff7dd5ec0 <frrmod_default_info>,
 dl_handle = 0x0,
 finished_loading = true,
 load_name = 0x0,
 load_args = 0x0
}

(gdb) p *frrmod_list->next
$22 = {
 next = 0x0,
 info = 0x5555557b2000 <_frrmod_info>,
 dl_handle = 0x0,
 finished_loading = true,
 load_name = 0x0,
 load_args = 0x0
}

Also, CLI doesn’t like this instruction anymore:

lnos-x1-mellonox-up(config)# fpm connection ip 127.0.0.1 port 2620
% [ZEBRA] Unknown command: fpm connection ip 127.0.0.1 port 2620

Thanks.

/Rodny


_______________________________________________
dev mailing list
dev@lists.frrouting.org
https://lists.frrouting.org/listinfo/dev