When ip nhrp map multicast is being used, this is usually accompanied by an
iptables rule to block the original multicast packet. This causes sendmsg to
return EPERM.
Signed-off-by: Reuben Dowle <reuben.dowle@4rf.com>
Currently if the sysctl net.ipv4.raw_l3mdev_accept is 1, packets
destined to a specific vrf also end up being delivered to the default
vrf. We will see logs like this in ospf:
2021/02/10 21:17:05.245727 OSPF: ospf_recv_packet: fd 20(default) on interface 1265(swp1s1.26)
2021/02/10 21:17:05.245740 OSPF: Hello received from [9.9.36.12] via [swp1s1.26:200.254.26.13]
2021/02/10 21:17:05.245741 OSPF: src [200.254.26.14],
2021/02/10 21:17:05.245743 OSPF: dst [224.0.0.5]
2021/02/10 21:17:05.245769 OSPF: ospf_recv_packet: fd 45(vrf1036) on interface 1265(swp1s1.26)
2021/02/10 21:17:05.245774 OSPF: Hello received from [9.9.36.12] via [swp1s1.26:200.254.26.13]
2021/02/10 21:17:05.245775 OSPF: src [200.254.26.14],
2021/02/10 21:17:05.245777 OSPF: dst [224.0.0.5]
This really really makes ospf unhappy in the vrf we are running in.
I am approaching the problem by just dropping the packet if read in the
default vrf because of:
commit 0556fc33c7
Author: Donald Sharp <sharpd@cumulusnetworks.com>
Date: Fri Feb 1 11:54:59 2019 -0500
lib: Allow bgp to always create a listen socket for the vrf
Effectively if we have `router ospf vrf BLUE` but no ospf running
in the default vrf, we will not have a listener and that would
require a fundamental change in our approach to handle the ospf->fd
at a global level. I think this is less than ideal at the moment
but it will get us moving again and allow FRR to work with
a bunch of vrf's and ospf neighbors.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Change thread_cancel to take a ** to an event, NULL-check
before dereferencing, and NULL the caller's pointer. Update
many callers to use the new signature.
Signed-off-by: Mark Stapp <mjs@voltanet.io>
Description:
1. Skipping inactivity timer during graceful restart to make
the RESTARTER active even after dead timer expiry.
2. Handling HELPER on unplanned outages.
Signed-off-by: Rajesh Girada <rgirada@vmware.com>
OSPFD sends ARP proactively to speed up convergence for /32 networks
on a p2p connection. It is only an optimization, so it can be disabled.
It is enabled by default.
Signed-off-by: Jakub Urbańczyk <xthaid@gmail.com>
Remove mid-string line breaks, cf. workflow doc:
.. [#tool_style_conflicts] For example, lines over 80 characters are allowed
for text strings to make it possible to search the code for them: please
see `Linux kernel style (breaking long lines and strings)
<https://www.kernel.org/doc/html/v4.10/process/coding-style.html#breaking-long-lines-and-strings>`_
and `Issue #1794 <https://github.com/FRRouting/frr/issues/1794>`_.
Scripted commit, idempotent to running:
```
python3 tools/stringmangle.py --unwrap `git ls-files | egrep '\.[ch]$'`
```
Signed-off-by: David Lamparter <equinox@diac24.net>
Fix
- Modulo check on data length not inclusive enough
- Garbage heap read when bounds checking
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
ospf_opaque_self_originated_lsa_received decrements refcount which can
result in a free, this is followed by a call to ospf_ls_ack_send which
accesses the freed LSA
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
Line break at the end of the message is implicit for zlog_* and flog_*,
don't put it in the string. Mid-message line breaks are currently
unsupported. (LF is "end of message" in syslog.)
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
We actually don't validate the IHL field, although it certainly looks
like we do at a casual glance.
This patch saves us from an assert in case we actually do get an IP
packet with an incorrect header length field.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
We test nbr->oi in a couple of places for null, but
in the majority of places of the nbr->oi data is being
used we just access it. Touch up code to trust this
assertion and make the code more consistent in others.
Found in Coverity.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The indentation level for ospf_read was starting to be pretty
extremene. Rework into 2 functions for improved readability.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Read in up to 20(ospf write-multipler X) packets, for handling of data.
This improves performance because we allow ospf to have a bit more data
to work on in one go for spf calculations instead of 1 packet at a time.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Turning on packet debugs and seeing a header dump that is 11
lines long is useless
2019/11/07 01:07:05.941798 OSPF: ip_v 4
2019/11/07 01:07:05.941806 OSPF: ip_hl 5
2019/11/07 01:07:05.941813 OSPF: ip_tos 192
2019/11/07 01:07:05.941821 OSPF: ip_len 68
2019/11/07 01:07:05.941831 OSPF: ip_id 48576
2019/11/07 01:07:05.941838 OSPF: ip_off 0
2019/11/07 01:07:05.941845 OSPF: ip_ttl 1
2019/11/07 01:07:05.941857 OSPF: ip_p 89
2019/11/07 01:07:05.941865 OSPF: ip_sum 0xcf33
2019/11/07 01:07:05.941873 OSPF: ip_src 200.254.30.14
2019/11/07 01:07:05.941882 OSPF: ip_dst 224.0.0.5
We already have this debugged, it's not going to change and the
end developer can stick this back in if needed by hand to debug
something that is not working properly.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
This commit has:
The received packet path in ospf, had absolutely no debugs associated with
it. This makes it extremely hard to know when we receive packets for
consumption. Add some breadcrumbs to this end.
Large chunks of commands have no ability to debug what is happening
in what vrf. With ip overlap X vrf this becomes a bit of a problem
Add some breadcrumbs here.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
We have a bunch of places that look for ORIGINAL_CODING. There is
nothing in our configure system to define this value and a quick
git blame shows this code as being original to the import a very
very long time ago. This is dead code, removing.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Recently Lot of issues are seen in OSPF adjacnecy establishements,
sessions was tear down because of DD Sequence Number mismatch.
adding Debugs to capture Master & slave generated sequence numbers.
Signed-off-by: Satheesh Kumar K <sathk@cumulusnetworks.com>
When OSPF receives a Database description packet and is in
`Down`, `Attempt` or `2-Way` state we are creating a warning
for the end user.
rfc2328 states(10.6):
Down - The packet should be rejected
Attempt - The packet should be rejected
2-Way - The packet should be ignored
I cannot find any instructions in the rfc to state what the operational
difference is between rejected and ignored. Neither can I figure
out what FRR expects the end user to do with this information.
I can see this information being useful if we encounter a bug
down the line and we have gathered a bunch of data. As such
let's modify the code to remove the flog_warn and convert
the message to a debug level message that can be controlled by
appropriate debug statements.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
This looks like a finish up of the partial cleanup that
ocurred at some point in time in the past. When we
alloc oi also always alloc the oi->obuf. When we delete
oi always delete the oi->obuf right before.
This cleans up a bunch of code to be simpler and hopefully
easier to follow.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
I am rarely seeing this crash:
r2: ospfd crashed. Core file found - Backtrace follows:
[New LWP 32748]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/aarch64-linux-gnu/libthread_db.so.1".
Core was generated by `/usr/lib/frr/ospfd'.
Program terminated with signal SIGABRT, Aborted.
2019-08-29 15:59:36,149 ERROR: assert failed at "test_ospf_sr_topo1/test_memory_leak":
Which translates to this code:
node = listhead(ospf->oi_write_q);
assert(node);
oi = listgetdata(node);
assert(oi);
So if we get into ospf_write without anything on the oi_write_q
we are stopping the program.
This is happening because in ospf_ls_upd_queue_send we are calling
ospf_write. Imagine that we have a interface already on the on_write_q
and then ospf_write handles the packet send for all functions. We
are not clearing the t_write thread and we are popping and causing
a crash.
Additionally modify OSPF_ISM_WRITE_ON(O) to not just blindly
turn on the t_write thread. Only do so if we have data.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
ospfd: Remove redundant asserts
assert(oi) is impossible all listgetdata(node) directly proceeding
it already asserts here, besides a node cannot be created
with a null pointer!
If list_isempty is called directly before the listhead call
it is impossilbe that we do not have a valid pointer here.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
no router ospf triggers to cancel all threads
including read/write (receive/send packets) threads,
cleans up resources fd, message queue and data.
Last job of write (packet) thread invoked where the
ospf instance is referenced is not running nor
the socket fd valid.
Write thread callback should check if fd is valid and
ospf instance is running before proceeding to send a
message over socket.
Ticket:CM-20095
Testing Done:
Performed the multiple 'no router ospf' with the fix
in topology where the crash was seen.
Post fix the crash is not observed.
Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>
While fragmenting ospf ls packets, before appending the link state info,
wrong value is checked to see if current packet can fit in another ls info.
Because of this, when a lower mtu is configured, it couldn't fit in even 1
ls ack, which tries to send all the available ls ack in the list in loop.
This keeps allocating memory to send the packet and ends up putting the
packet buffer without ls-ack into deferred send que(ospf_ls_ack_send_delayed).
This infinite loop causes infinite memory being allocated in a loop causing
system to be unstable. This commit takes care of calculating the right value
to compare for checking oif this buffer can fit in more.
Signed-off-by: Saravanan K <saravanank@vmware.com>
Based on the vulnerability mentioned in 793496 an attacker can craft an
LSA with MaxSequence number wtih invalid links and not set age to MAX_AGE
so the lsa would not be flush from the database.
To address the issue, check incoming LSA is MaxSeq but Age is not set
to MAX_AGE 3600, discard the LSA from processing it.
Based on RFC-2328 , When a LSA update sequence reaches MaxSequence
number, it should be prematurely aged out from the database with age set
to MAX_AGE (3600).
Ticket:CM-18989
Reviewed By:
Testing Done:
Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>
Ospfd cored because of an assert when we try to write more than the MTU
size to the ospf packet buffer stream. The problem is - we allocate only MTU
sized buffer. The expectation is that Hello packets are never large
enough to approach MTU. Instead of crashing, this fix discards hello and
logs an error. One should not have so many neighbors behind an
interface.
Ticket: CM-22380
Signed-off-by: Nitin Soni <nsoni@cumulusnetworks.com>
Reviewed-by: CCR-8204
This reverts commit 48944eb65e.
We're using GNU C, not ISO C - and this commit triggers new (real)
warnings about {0} instead of bogus ones about {}.
Signed-off-by: David Lamparter <equinox@diac24.net>
When the ospf->oi_write_q is not empty that means that ospf could
already have a thread scheduled for running. Just dropping
the pointer before resheduling does not stop the one currently
scheduled for running from running. The calling of thread_add_write
checks to see if we are already running and does the right thing here
so it is sufficient to just call thread_add_write.
This issue was tracked down from this stack trace:
Oct 19 18:04:00 VYOS-R1 ospfd[1811]: [EC 134217739] interface eth2.1032:172.16.4.110: ospf_check_md5 bad sequence 5333618 (expect 5333649)
Oct 19 18:04:00 VYOS-R1 ospfd[1811]: message repeated 3 times: [ [EC 134217739] interface eth2.1032:172.16.4.110: ospf_check_md5 bad sequence 5333618 (expect 5333649)]
Oct 19 18:04:00 VYOS-R1 ospfd[1811]: Assertion `node’ failed in file ospfd/ospf_packet.c, line 666, function ospf_write
Oct 19 18:04:00 VYOS-R1 ospfd[1811]: Backtrace for 8 stack frames:
Oct 19 18:04:00 VYOS-R1 ospfd[1811]: [bt 0] /usr/lib/libfrr.so.0(zlog_backtrace+0x3a) [0x7fef3efe9f8a]
Oct 19 18:04:00 VYOS-R1 ospfd[1811]: [bt 1] /usr/lib/libfrr.so.0(_zlog_assert_failed+0x61) [0x7fef3efea501]
Oct 19 18:04:00 VYOS-R1 ospfd[1811]: [bt 2] /usr/lib/frr/ospfd(+0x2f15e) [0x562e0c91815e]
Oct 19 18:04:00 VYOS-R1 ospfd[1811]: [bt 3] /usr/lib/libfrr.so.0(thread_call+0x60) [0x7fef3f00d430]
Oct 19 18:04:00 VYOS-R1 ospfd[1811]: [bt 4] /usr/lib/libfrr.so.0(frr_run+0xd8) [0x7fef3efe7938]
Oct 19 18:04:00 VYOS-R1 ospfd[1811]: [bt 5] /usr/lib/frr/ospfd(main+0x153) [0x562e0c901753]
Oct 19 18:04:00 VYOS-R1 ospfd[1811]: [bt 6] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5) [0x7fef3d83db45]
Oct 19 18:04:00 VYOS-R1 ospfd[1811]: [bt 7] /usr/lib/frr/ospfd(+0x190be) [0x562e0c9020be]
Oct 19 18:04:00 VYOS-R1 ospfd[1811]: Current thread function ospf_write, scheduled from file ospfd/ospf_packet.c, line 881
Oct 19 18:04:00 VYOS-R1 zebra[1771]: [EC 4043309116] Client ‘ospf’ encountered an error and is shutting down.
Oct 19 18:04:00 VYOS-R1 zebra[1771]: client 41 disconnected. 0 ospf routes removed from the rib
We had an assert(node) in ospf_write, which means that the list was empty. So I just
searched until I saw a code path that allowed multiple writes to the ospf_write function.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
In all but one instance we were following this pattern
with ospf_lsa_new:
ospf_lsa_new()
ospf_lsa_data_new()
so let's create a ospf_lsa_new_and_data to abstract
this bit of fun and cleanup all the places where
it assumes these function calls can fail.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The following types are nonstandard:
- u_char
- u_short
- u_int
- u_long
- u_int8_t
- u_int16_t
- u_int32_t
Replace them with the C99 standard types:
- uint8_t
- unsigned short
- unsigned int
- unsigned long
- uint8_t
- uint16_t
- uint32_t
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
- ospfd/ospf_opaque.c: Update issue #1652 by introducing a new
function 'free_opaque_info_owner()' to clean list of callback owner
and call this function in appropriate place where 'listdelete_and_null'
is not used.
- ospfd/ospf_packet.c: In case of crash, ospfd is not been able to
flush LSA. In case of self Opaque LSA, when restarting, ospfd crash
during the resynchronisation process with its neighbor due to an
empty list of LSA to flood. Just add a control on the list count
in 'ospf_ls_upd_queue_send()' to escape the function and avoid the
problem.
Signed-off-by: Olivier Dugeon <olivier.dugeon@orange.com>
Some of the deprecated stream.h macros see such little use that we may
as well just remove them and use the non-deprecated macros.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
Router-ID change or ospf instance going down,
send LS-Upd with MAXAGE to self origintated LSAs to
all ospf neighbors.
Ticket:CM-1576
Testing Done:
Bring R1 - R2, Change Router-ID on R2, restart frr on R2
Validated R1 ospf LSDB for max aged 3600 LSA from R2.
Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>
list_free is occassionally being used to delete the
list and accidently not deleting all the nodes.
We keep running across this usage pattern. Let's
remove the temptation and only allow list_delete
to handle list deletion.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Convert the list_delete(struct list *) function to use
struct list **. This is to allow the list pointer to be nulled.
I keep running into uses of this list_delete function where we
forget to set the returned pointer to NULL and attempt to use
it and then experience a crash, usually after the developer
has long since left the building.
Let's make the api explicit in it setting the list pointer
to null.
Cynical Prediction: This code will expose a attempt
to use the NULL'ed list pointer in some obscure bit
of code.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Change all callers of IPV4_ADDR_SAME() to pass a pointer to a struct in_addr
Use assignment and comparison instead of memcpy() and memcmp(). Avoids function
calls. Faster.
Signed-off-by: Jorge Boncompte <jbonor@gmail.com>
This reverts commit c14777c6bf.
clang 5 is not widely available enough for people to indent with. This
is particularly problematic when rebasing/adjusting branches.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
log.c provides functionality for associating a constant (typically a
protocol constant) with a string and finding the string given the
constant. However this is highly delicate code that is extremely prone
to stack overflows and off-by-one's due to requiring the developer to
always remember to update the array size constant and to do so correctly
which, as shown by example, is never a good idea.b
The original goal of this code was to try to implement lookups in O(1)
time without a linear search through the message array. Since this code
is used 99% of the time for debugs, it's worth the 5-6 additional cmp's
worst case if it means we avoid explitable bugs due to oversights...
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
The FSF's address changed, and we had a mixture of comment styles for
the GPL file header. (The style with * at the beginning won out with
580 to 141 in existing files.)
Note: I've intentionally left intact other "variations" of the copyright
header, e.g. whether it says "Zebra", "Quagga", "FRR", or nothing.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Pass pointer to pointer instead of assigning by return value. See
previous commit message.
To ensure that the behavior stays functionally correct, any assignments
with the result of a thread_add* function have been transformed to set
the pointer to null before passing it. These can be removed wherever the
pointer is known to already be null.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
The way thread.c is written, a caller who wishes to be able to cancel a
thread or avoid scheduling it twice must keep a reference to the thread.
Typically this is done with a long lived pointer whose value is checked
for null in order to know if the thread is currently scheduled. The
check-and-schedule idiom is so common that several wrapper macros in
thread.h existed solely to provide it.
This patch removes those macros and adds a new parameter to all
thread_add_* functions which is a pointer to the struct thread * to
store the result of a scheduling call. If the value passed is non-null,
the thread will only be scheduled if the value is null. This helps with
consistency.
A Coccinelle spatch has been used to transform code of the form:
if (t == NULL)
t = thread_add_* (...)
to the form
thread_add_* (..., &t)
The THREAD_ON macros have also been transformed to the underlying
thread.c calls.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
This ditches tv_add, tv_sub, tv_cmp, etc. in favour of
monotime{,_since,_until}() which actually makes the code much more
readable in some locations.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
This reverts commit b7fe4141, which introduced a logic where the OSPF
send buffer size was dynamically updated to reflect the maximum MTU
of the OSPF enabled interfaces (this was done to make ospfd work with
interfaces configured for jumbo frames).
Since commit a78d75b0, this is not necessary anymore because
ospf_sock_init() now sets the OSPF send buffer size to a very high value
(8MB). Also, the previous logic was broken because it didn't account
for run-time interface MTU changes.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
We can't use if_lookup_prefix() in rip_update_process() because this
function uses prefix_cmp() internally to try matching an interface
address to a static neighbor's address.
Since prefix_cmp() tries to match exact prefixes, if_lookup_prefix()
was always returning NULL.
What we really need here is to use prefix_match(), which checks if
one prefix includes the other (e.g. one /24 interface including a /32
static neighbor's address). The fix then is to replace the call to
if_lookup_prefix() and use if_lookup_address() instead, which uses
prefix_match() internally.
Fixes IxANVL RIP test 17.1
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
NOTE: I am squashing several commits together because they
do not independently compile and we need this ability to
do any type of sane testing on the patches. Since this
series builds together I am doing this. -DBS
This new structure is the basis to get new link parameters for
Traffic Engineering from Zebra/interface layer to OSPFD and ISISD
for the support of Traffic Engineering
* lib/if.[c,h]: link parameters struture and get/set functions
* lib/command.[c,h]: creation of a new link-node
* lib/zclient.[c,h]: modification to the ZBUS message to convey the
link parameters structure
* lib/zebra.h: New ZBUS message
Signed-off-by: Olivier Dugeon <olivier.dugeon@orange.com>
Add support for IEEE 754 format
* lib/stream.[c,h]: Add stream_get{f,d} and stream_put{f,d}) demux and muxers to
safely convert between big-endian IEEE-754 single and double binary
format, as used in IETF RFCs, and C99. Implementation depends on host
using __STDC_IEC_559__, which should be everything we care about. Should
correctly error out otherwise.
* lib/network.[c,h]: Add ntohf and htonf converter
* lib/memtypes.c: Add new memeory type for Traffic Engineering support
Signed-off-by: Olivier Dugeon <olivier.dugeon@orange.com>
Add link parameters support to Zebra
* zebra/interface.c:
- Add new link-params CLI commands
- Add new functions to set/get link parameters for interface
* zebra/redistribute.[c,h]: Add new function to propagate link parameters
to routing daemon (essentially OSPFD and ISISD) for Traffic Engineering.
* zebra/redistribute_null.c: Add new function
zebra_interface_parameters_update()
* zebra/zserv.[c,h]: Add new functions to send link parameters
Signed-off-by: Olivier Dugeon <olivier.dugeon@orange.com>
Add support of new link-params CLI to vtysh
In vtysh_config.c/vtysh_config_parse_line(), it is not possible to continue
to use the ordered version for adding line i.e. config_add_line_uniq() to print
Interface CLI commands as it completely break the new LINK_PARAMS_NODE.
Signed-off-by: Olivier Dugeon <olivier.dugeon@orange.com>
Update Traffic Engineering support for OSPFD
These patches update original code to RFC3630 (OSPF-TE) and add support of
RFC5392 (Inter-AS v2) & RFC7471 (TE metric extensions) and partial support
of RFC6827 (ASON - GMPLS).
* ospfd/ospf_dump.[c,h]: Add new dump functions for Traffic Engineering
* ospfd/ospf_opaque.[c,h]: Add new TLV code points for RFC5392
* ospfd/ospf_packet.c: Update checking of OSPF_OPTION
* ospfd/ospf_vty.[c,h]: Update ospf_str2area_id
* ospfd/ospf_zebra.c: Add new function ospf_interface_link_params() to get
Link Parameters information from the interface to populate Traffic Engineering
metrics
* ospfd/ospfd.[c,h]: Update OSPF_OPTION flags (T -> MT and new DN)
* ospfd/ospf_te.[c,h]: Major modifications to update the code to new
link parameters structure and new RFCs
Signed-off-by: Olivier Dugeon <olivier.dugeon@orange.com>
tmp
HAVE_OPAQUE_LSA is used by default and you have to actively turn it off
except that OPAQUE_LSA is an industry standard and used pretty much
everywhere. There is no need to have special #defines for this anymore.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
(cherry picked from commit 36fef5708d074a3ef41f34d324c309c45bae119b)
When considering small networks that have extreme requirements on
availability and thus convergence delay, the timers given in the OSPF RFC
seem a little “conservative”, i.e., the delay between accepted LSAs and the
rate at which LSAs are sent. Cisco introduced two commands 'timers throttle
lsa all’ and 'timers lsa arrival’, which allow operators to tune these
parameters.
I have been writing a patch to also support 'timers lsa arrival’ fully and
‘timers throttle lsa all’ (without the throttling part) also in quagga.
* ospf_opaque.c: (ospf_opaque_adjust_lsreq) Odd hack to general OSPF
database exchange but made to act only on opaque LSAs. It's either covering
up bugs in the flooding code or its wrong. If it's covering up bugs, those
would affect all LSAs and should be fixed at a lower layer in ospfd, indeed
perhaps those bugs are long fixed anyway (?). Alternatively, it's just plain
wrong. Nuke.
(ospf_opaque_exclude_lsa_from_lsreq) helper to above, nuke.
* ospf_packet.c: Nuke call to ospf_opaque_adjust_lsreq.
Tested-by: olivier.dugeon@orange.com
* Opaque support contains some kind of hack/optimisation to
origination/flooding to suppress some origins/floods until an opaque LS
Acks are received. Previous versions of the code have already been shown
to have bugs in them (see e16fd8a5, e.g.). It seems over-complex and fragile,
plus its conceptually the wrong place to try implement flooding hacks that,
AFAICT, do not depend particularly on the semantics of opaque LSA.
Nuke.
Tested-by: Olivier Dugeon <olivier.dugeon@orange.com>
On higher warning levels, compilers expect %p printf arguments to be
void *. Since format string / argument warnings can be useful
otherwise, let's get rid of this noise by sprinkling casts to void *
over printf calls.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
If opaque-capability is enabled, we must set the O-bit in
the option field of all DD packets. Changing the option
field of DD packets may cause the peer to reset the state
back to ExStart.
Signed-off-by: Feng Lu <lu.feng@6wind.com>
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
(cherry picked from commit 86ce951e349fd08d1ba2c66f5f6d07756689422a)
This looks fishy in ospf_make_md5_digest()
if (list_isempty (OSPF_IF_PARAM (oi, auth_crypt)))
auth_key = (const u_int8_t *) "";
...
MD5Update(&ctx, auth_key, OSPF_AUTH_MD5_SIZE);
auth_key points to a "" string of len 1 which is a lot
smaller that OSPF_AUTH_MD5_SIZE. Is this intentional to
get some random data or just a plain bug?
Anyone using MD5 should have a closer look and decide
what to do.
Acked-by: Feng Lu <lu.feng@6wind.com>
(cherry picked from commit ea2a598411cc7bd20456849e56bbc9e93c9916e7)
Two issues:
1) nbr->oi->ifp->name is an array it would
always evaluate to true.
2) There exist a code path where addr
would be used without initialization.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Reviewed-by: Daniel Walton <dwalton@cumulusnetworks.com>
