There's nothing that can be done here with an error. Try to make
Coverity understand that this is intentional.
(I don't know if the `(void)` will actually fix the coverity warning,
but I don't really have a better way to figure it out beyond just
getting this merged and waiting for a result...)
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Issue: Crash observed when LSAs are removed from LSDB after max age
when there is no area configured.
(gdb) bt
0 raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
1 0x00007fdb190548bc in core_handler (signo=6, siginfo=0x7ffdd2f5a470, context=<optimized out>) at lib/sigevent.c:262
2 <signal handler called>
3 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
4 0x00007fdb185ad921 in __GI_abort () at abort.c:79
5 0x00007fdb1907f199 in _zlog_assert_failed (xref=xref@entry=0x55f30902aa20 <_xref.21999>, extra=extra@entry=0x0) at lib/zlog.c:581
6 0x000055f308dc4f78 in ospf6_asbr_lsa_remove (lsa=0x55f30a7546d0, asbr_entry=0x0) at ospf6d/ospf6_asbr.c:696
7 0x000055f308dd8f0d in ospf6_lsdb_remove (lsa=0x55f30a7546d0, lsdb=lsdb@entry=0x55f30a73d300) at ospf6d/ospf6_lsdb.c:166
8 0x000055f308dd9701 in ospf6_lsdb_maxage_remover (lsdb=0x55f30a73d300) at ospf6d/ospf6_lsdb.c:376
9 0x000055f308dee724 in ospf6_maxage_remover (thread=<optimized out>) at ospf6d/ospf6_top.c:603
10 0x00007fdb1906520d in thread_call (thread=thread@entry=0x7ffdd2f5ae90) at lib/thread.c:1919
11 0x00007fdb19023e48 in frr_run (master=0x55f30a569b70) at lib/libfrr.c:1155
12 0x000055f308dc09b6 in main (argc=6, argv=0x7ffdd2f5b198, envp=<optimized out>) at ospf6d/ospf6_main.c:235
(gdb)
Steps to reproduce the issue:
1. router ospf6
2. redistribute static
3. ipv6 route 1::1/128 Null0
4. no redistribute static
5. wait for Max aged LSA to flush
6. Check DB, crash occurs.
RCA:
Crash occurred while accessing listgetdata(listhead(ospf6->area_list))
When there is no area attached to any of the interface listhead(ospf6->area_list)
is NULL. Therefore it crashed due to NULL access.
Fix:
Check before accessing null pointer.
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
The debuild command fails when we are doing source package only build
because it expects the arch-dependent .changes file to be present. Thus
in the instructions we switch to using dpkg-buildpackage directly and
add a note about using debuild in more complicated scenarios.
Signed-off-by: Ondřej Surý <ondrej@sury.org>
In the CI, it's better to build the source package only once and then
instead of checking out the whole repository, only distribute the source
packages to the individual jobs.
Signed-off-by: Ondřej Surý <ondrej@sury.org>
The Debian autopkgtest would fail with new PAM introduced in Debian bullseye.
Add a little loop to wait a little longer for the changes to propagate.
Signed-off-by: Ondřej Surý <ondrej@sury.org>
Basically, this is handled by JSON-C library. I've compiled with the
latest release of json-c and it works well.
Didn't test with various distribution versions, but this change is kinda
dependend from the json-c lib version the distra has.
Before:
```
"192.168.100.1\/32":[
{
"prefix":"192.168.100.1\/32",
```
After:
```
"192.168.100.1/32":[
{
"prefix":"192.168.100.1/32",
```
Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
New peers should be initialized with a usual max packet size and later
determined on OPEN messages.
Testing with different peers supporting/not supporting extended support.
2021/07/02 13:48:00 BGP: [WEV7K-2GAQ5] u2:s2 send UPDATE len 8991 (max message len: 65535) numpfx 1788
2021/07/02 13:48:03 BGP: [WEV7K-2GAQ5] u3:s3 send UPDATE len 4096 (max message len: 4096) numpfx 809
2021/07/02 13:48:03 BGP: [WEV7K-2GAQ5] u3:s3 send UPDATE len 4096 (max message len: 4096) numpfx 809
Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
This should be garuanteed that we create a separate update-group if
bgp max packet size differs.
Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
