The client socket value can only be modified by the main thread.
Modifying the client socket from within the client I/O pthread
introduces race conditions.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
Socket should be closed in zserv_client_free() and nowhere else.
Credit to Mark Stapp for catching this one.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
Only frr-reload.py pulls in a python depenedency for frr, we can
reduce the size of the base frr package by a lot if we separate
out frr-pythontools. When we do this, we get a somewhat cryptic
error message when frr-reload.py is missing on frr reload.
Here, we pull the error message from frr-reload script, which is
much clearer.
Testing done:
frr reload both with and without the frr-reload.py script, see
the frr-reload message when missing and it runs frr-reload.py when
not missing.
Signed-off-by: Arthur Jones <arthur.jones@riverbed.com>
When a bgp instance is stopped, with a `no router bgp..`
make sure any timers associated with the instance are stopped
as well.
This issue was discovered when a customer issued a `no router bgp`
while a maxmed timer was operative. The max-med timer used the
`struct bgp *` as the passed in value for the thread. The
thread eventually popped after the cleanup and attempted to use
data off in lala land and crashed
Ticket: CM-21895
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Fix ripd crash of null pointer.
when authenticate a rip packet,
the key pointer or the key string pointer may be null,
the code have to return then.
Signed-off-by: lyq140 <34637052+lyq140@users.noreply.github.com>
The `type` parameter was not being compared with `cmsg_type`, so the
result of this function was always a pointer to the first header
matching the level.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
This fix a crash of null pointer.
when we don't add a key string or delete it,
the key is not null but key string is null,
so the code have to return.
Signed-off-by: lyq140 <34637052+lyq140@users.noreply.github.com>
During code inspection it was noticed that rip is not fully
using FRR memory code as it should.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The dn_count for dynamic Peers was not being updated when
using json output.
Signed-off-by: Dongling Duan <dlduan@amazon.com>
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Abstract the RPF change for upstream handling code so
that we do not have two copies of the code.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
After we have decided what has changed as part of a update
we need to send the j/p messages to our peers.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
* Rename some things to be less confusing
* Convert client close function to take a client struct rather than a
task
* Extern client close function and use it when handling SIGTERM
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
Options must be documented before they can be cross-referenced, and the
scope for configure options is not present in rpki.rst. Remove the
option role tag from the `-M` option to remove the build warning.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
show evpn mac vni all
show evpn mac vni x
does not display local svi and anycast mac into count.
Ticket:CM-20456
Testing Done:
Before:
TOR1# show evpn mac vni 1008
Number of MACs (local and remote) known for this VNI: 4
MAC Type Intf/Remote VTEP VLAN
44:38:39:00:6b:4c local vlan1008 1008
00:02:00:00:00:04 local hostbond5 1008
00:02:00:00:00:02 local hostbond4 1008
00:00:5e:00:01:01 local vlan1008-v0 1008
00:02:00:00:00:0c remote 27.0.0.15
00:02:00:00:00:0a remote 27.0.0.15
dell-s6000-07#
After:
TOR1# show evpn mac vni 1008
Number of MACs (local and remote) known for this VNI: 6
MAC Type Intf/Remote VTEP VLAN
44:38:39:00:6b:4c local vlan1008 1008
00:02:00:00:00:04 local hostbond5 1008
00:02:00:00:00:02 local hostbond4 1008
00:00:5e:00:01:01 local vlan1008-v0 1008
00:02:00:00:00:0c remote 27.0.0.15
00:02:00:00:00:0a remote 27.0.0.15
Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>
