For some series of calls in FREEBSD setting the SO_RCVBUF size will
always fail under freebsd. This is no bueno since the
setsockopt_so_recvbuf call goes into an infinite loop.
(gdb) bt
0 setsockopt () at setsockopt.S:4
1 0x0000000083065870 in setsockopt_so_recvbuf (sock=15, size=0) at lib/sockopt.c:26
2 0x00000000002bd200 in ospf_ifp_sock_init (ifp=<optimized out>, ifp@entry=0x8d1dd500) at ospfd/ospf_network.c:290
3 0x00000000002ad1e0 in ospf_if_new (ospf=0x8eefc000, ifp=0x8d1dd500, p=0x8eecf1c0) at ospfd/ospf_interface.c:276
4 0x0000000000304ee0 in add_ospf_interface (co=0x8eecbe10, area=0x8d192100) at ospfd/ospfd.c:1115
5 0x00000000003050fc in ospf_network_run_interface (ospf=0x8eefc000, ifp=0x8d1dd500, p=0x80ff63f8, given_area=0x8d192100)
at ospfd/ospfd.c:1460
6 ospf_network_run (p=0x80ff63f8, area=0x8d192100) at ospfd/ospfd.c:1474
7 ospf_network_set (ospf=ospf@entry=0x8eefc000, p=p@entry=0x80ff63f8, area_id=..., df=<optimized out>) at ospfd/ospfd.c:1247
8 0x00000000002e876c in ospf_network_area (self=<optimized out>, vty=0x8eef3180, argc=<optimized out>, argv=<optimized out>)
at ospfd/ospf_vty.c:560
9 0x0000000083006f24 in cmd_execute_command_real (vline=vline@entry=0x8eee9100, vty=vty@entry=0x8eef3180, cmd=<optimized out>,
cmd@entry=0x0, up_level=<optimized out>) at lib/command.c:978
10 0x0000000083006b30 in cmd_execute_command (vline=0x8eee9100, vty=vty@entry=0x8eef3180, cmd=cmd@entry=0x0, vtysh=vtysh@entry=0)
at lib/command.c:1037
11 0x0000000083007044 in cmd_execute (vty=vty@entry=0x8eef3180, cmd=cmd@entry=0x8eefb000 "network 192.168.64.0/24 area 0.0.0.0",
matched=0x0, vtysh=0) at lib/command.c:1203
12 0x000000008307e9cc in vty_command (vty=0x8eef3180, buf=0x8eefb000 "network 192.168.64.0/24 area 0.0.0.0") at lib/vty.c:594
13 vty_execute (vty=vty@entry=0x8eef3180) at lib/vty.c:1357
14 0x000000008307ce40 in vtysh_read (thread=<optimized out>) at lib/vty.c:2365
15 0x0000000083073db0 in event_call (thread=thread@entry=0x80ff88a0) at lib/event.c:1965
16 0x000000008302c604 in frr_run (master=0x8d188140) at lib/libfrr.c:1214
17 0x000000000029c330 in main (argc=6, argv=<optimized out>) at ospfd/ospf_main.c:252
(gdb)
Force the setsockopt function to quit when the value we are passing no
longer makes any sense.
Fixes: #14790
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
`nb_cli_apply_changes` can be called with base xpath which should be
prepended to xpaths of every change in a transaction. This base xpath is
respected by regular northbound CLI but not by mgmtd. This commit fixes
the problem.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
- Cannot have 2 cmd_node's with same .node number. Install the mgmtd
client library debug nodes (client frontend and client backend) using
new unique node numbers. Fixes memleaks.
- Fix "debug mgmt client backend" to generate correct config (and not
for frontend).
Signed-off-by: Christian Hopps <chopps@labn.net>
mgmtd frees all non-NULL change->value variables at the end of every
commit. We shouldn't assign change->value with data returned by libyang
to prevent freeing of library-allocated memory.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
We cannot build on apple machines at all due
to our usage of some gcc extensions that will
probably never see the light of day again.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
The headers associated with netlink code
really only belong in those that need it.
Move these headers out of lib/zebra.h and
into more appropriate places. bgp's usage
of the RT_TABLE_XXX defines are probably not
appropriate and will be cleaned up in future
commits.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
This also avoids a bug in the workaround function if the set variable
wasn't set to NULL the Debug version of libyang would sigsegv.
Signed-off-by: Christian Hopps <chopps@labn.net>
- move from client id indexed array of uints for register info
per client to a u64 bitmask.
- add bit walking FOREACH macro
Walk the client IDs whose bits are set in a mask.
Signed-off-by: Christian Hopps <chopps@labn.net>
As with "prefixptr"/"prefixconstptr", this allows function prototypes to
say "just give me any sockaddr" typing-wise, without having the compiler
complain that a "struct sockaddr_in" is not a "struct sockaddr".
(Split off from other changes that start using this.)
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
About to use this for sockunion, which is not a prefix. `uniontype`
makes more sense, the macros are for defining transparent unions after
all.
(clang-format off thrown in as it otherwise wrecks formatting.)
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
These enum's have been around since 2005 and FRR
still does not have any users of these particular
values. After almost 20 years, let's simplify the
code slightly and remove them.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
buffer.h -> Bring up to our standard
if.h -> Bring up to our standard
workqueue.h -> expand documentation slightly
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
...so that multiple functions can be subscribed.
The create/destroy hooks are renamed to real/unreal because that's what
they *actually* signal.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Modify empty json object to take input obj
instead of allocating always one.
There are situation where in error condition or no data
case print empty json (`{}`) with already allocated
Signed-off-by: Chirag Shah <chirag@nvidia.com>
This was true when we had only a CLI for configuration. Now mgmtd has a
public frontend interface that can be used by external applications, and
they can send invalid requests that lead to errors.
This is still true for CLI though, so the same comment still stays in
`nb_cli_apply_changes_internal`.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
The routing table numbers are specific to linux builds, and the
RT_TABLE_xxx are usually defined in linux headers. The bsd builds
do not benefit from this definition: some RT_TABLE_xxx defines
are missing for those builds.
Fix this by appending RT_TABLE_LOCAL define for bsd headers.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Add a new kind of redistributed route that helps to import entries
that are not copied in the default routing table. Contrary to the
'redistribute table' feature, the entries are directly obtained from
the zebra appropriate routing table.
The 'table-direct' naming expresses the direct redistribution of
the routes, without having to copy the route entries in the default
routing table.
The distance value for this route is 14. Such route entries will
be prioritary compared to 'table' and 'ebgp' route entries type.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
The config is always applied fully, all batches are included. There's no
need to pass a list of applied batches as it always contains all of
them.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
Also:
- replace all /* fallthrough */ comments with portable fallthrough;
pseudo keyword to accomodate both gcc and clang
- add missing break; statements as required by older versions of gcc
- cleanup some code to remove unnecessary fallthrough
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
Running ping/traceroute/etc. (any kind of commands that use execute_command()
suffer with this kind of warnings.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
Currently when one interface changes its VRF, zebra will send these messages to
all daemons in *order*:
1) `ZEBRA_INTERFACE_DELETE` ( notify them delete from old VRF )
2) `ZEBRA_INTERFACE_VRF_UPDATE` ( notify them move from old to new VRF )
3) `ZEBRA_INTERFACE_ADD` ( notify them added into new VRF )
When daemons deal with `VRF_UPDATE`, they use
`zebra_interface_vrf_update_read()->if_lookup_by_name()`
to check the interface exist or not in old VRF. This check will always return
*NULL* because `DELETE` ( deleted from old VRF ) is already done, so can't
find this interface in old VRF.
Send `VRF_UPDATE` is redundant and unuseful. `DELETE` and `ADD` are enough,
they will deal with RB tree, so don't send this `VRF_UPDATE` message when
vrf changes.
Since all daemons have good mechanism to deal with changing vrf, and don't
use this `VRF_UPDATE` mechanism. So, it is safe to completely remove
all the code with `VRF_UPDATE`.
Signed-off-by: anlan_cs <anlan_cs@tom.com>
The code doesn't work at all. It tries to use libyang operation
metadata in a regular (not diff) data tree, and regular data trees
don't provide this data. Also, for destroy operations, it searches
for nodes in the running config, which may not have the deleted nodes
if we're not using implicit commits.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
