- dev - lists.frrouting.org

New Defects reported by Coverity Scan for freerangerouting/frr
by scan-admin＠coverity.com 05 May '21

05 May '21

Hi, Please find the latest report on new defect(s) introduced to freerangerouting/frr found with Coverity Scan. 1 new defect(s) introduced to freerangerouting/frr found with Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 1 of 1 defect(s) ** CID 1504610: Uninitialized variables (UNINIT) ________________________________________________________________________________________________________ *** CID 1504610: Uninitialized variables (UNINIT) /zebra/connected.c: 437 in connected_down() 431 * one. 432 */ 433 for (ALL_LIST_ELEMENTS_RO(ifp->connected, cnode, c)) { 434 struct prefix cp; 435 436 PREFIX_COPY(&cp, CONNECTED_PREFIX(c)); >>> CID 1504610: Uninitialized variables (UNINIT) >>> Using uninitialized value "cp.family" when calling "apply_mask". 437 apply_mask(&cp); 438 439 if (prefix_same(&p, &cp)) 440 count++; 441 442 if (count >= 2) ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

1 0

New Defects reported by Coverity Scan for freerangerouting/frr
by scan-admin＠coverity.com 04 May '21

04 May '21

Hi, Please find the latest report on new defect(s) introduced to freerangerouting/frr found with Coverity Scan. 1 new defect(s) introduced to freerangerouting/frr found with Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 1 of 1 defect(s) ** CID 1504585: Insecure data handling (TAINTED_SCALAR) /ospfclient/ospf_apiclient.c: 334 in ospf_apiclient_send_request() ________________________________________________________________________________________________________ *** CID 1504585: Insecure data handling (TAINTED_SCALAR) /ospfclient/ospf_apiclient.c: 334 in ospf_apiclient_send_request() 328 /* Wait for reply */ /* NB: New "msg" is allocated by "msg_read()". */ 329 msg = msg_read(oclient->fd_sync); 330 if (!msg) 331 return -1; 332 333 assert(msg->hdr.msgtype == MSG_REPLY); >>> CID 1504585: Insecure data handling (TAINTED_SCALAR) >>> Using tainted variable "reqseq" as a loop boundary. 334 assert(ntohl(msg->hdr.msgseq) == reqseq); 335 336 msgreply = (struct msg_reply *)STREAM_DATA(msg->s); 337 rc = msgreply->errcode; 338 msg_free(msg); 339 ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

1 0

PATHD installation question
by Борис Хасанов 29 Apr '21

29 Apr '21

2 2

Annulé : FRR Telco meeting
by olivier.dugeon＠orange.com 28 Apr '21

28 Apr '21

Quand : mercredi 28 avril 2021 16:00-17:00. (UTC+01:00) Bruxelles, Copenhague, Madrid, Paris Où : BlueJean https://bluejeans.com/377688464 *~*~*~*~*~*~*~*~*~* Hi all, This is the invite for the regular be-weekly Telco's meeting for 2021. NOTE: THE MEETING ID CHANGE. Please use https://bluejeans.com/377688464 for the next Telco meetings Regards Olivier _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.

1 0

Logging changes for __FUNC__, errno and debug guards
by David Lamparter 21 Apr '21

21 Apr '21

Hi again all, while the previous logging changes I've been working on have all been non-intrusive - i.e. no touching any zlog_* or flog_* lines - there are a few things I'd like to do at some point that do touch a lot of the zlog_* lines: - "factor out" strerror() / errno printing. This is why "flog_err_sys" exists, it currently does the exact same thing as "flog_err" but the idea is that "flog_err_sys" is used when there's some system error and errno is valid. The logging code would print strerror() automatically without this being a parameter. And we can put errno into a keyword, like systemd-journald has with "ERRNO=". flog_err_sys is already being used in quite a bit of the code, but this would need some double checking, and the strerror() argument would be removed. - "factor out" the __FUNC__ argument used on a lot of debug calls. The logging code can prefix *all* debug messages with the calling function name, without this being an extra parameter to the call. Also, RFC5424 and journald log targets can include the file/line/func information in the message metadata. - the debug guards could use a dump of massage units too - assimilating the if() into the macro and getting rid of the indentation level. We already have DEBUG*() in lib/debug.h plus debugf() in nhrpd/debug.h & babeld/util.h. These 3 should be unified and zlog_debug() marked deprecated (i.e. warning on any unguarded debugs) A particular consideration for this last item is the "parametrized debugs", e.g. "debug bgp neighbor-events <A.B.C.D|X:X::X:X|WORD>" A lot of this stuff can be done with coccinelle, but it'll be a large and annoying change, so I'd like to discuss *what* and *when* to do it here. (For starters, the 2nd and 3rd thing should happen at the same time since it's affecting most/all zlog_debug() calls.) None of this is "urgent" and a lot could also be done in smaller steps, e.g. converting babeld & nhrpd first. I'd also make these non-breaking changes as much as possible, i.e. have old & new forms both work for some period of time. Opinions & Comments? -David

2 1

DockerHub FRR images cleanup warning
by Quentin Young 14 Apr '21

14 Apr '21

Hi operators, For those of you who use our Docker images (https://hub.docker.com/r/frrouting/frr) you've probably noticed we have a bunch of messy tags on that repo. I'm planning on cleaning this up in a little while to delete unnecessary / unintentional tags. Tags corresponding to releases are named vX.Y.Z. So for example, the image with 7.5.1 is "frrouting/frr:v7.5.1". These won't be going anywhere. Neither will the "latest" tag - this tag is an automatic build off of our Git tree. (This also means you shouldn't be relying on it and should always be specifying a release tag, by the way). I'm going to delete the rest of the tags as they don't correspond to anything in particular. Specifically, I plan on deleting the following tags: frr-7.5.1 multiarch frr-7.3 base_7.3 I'm planning on deleting these tomorrow at 5pm EST. I see that frr-7.3 and frr-7.5.1 have been pulled recently. If you're pulling these tags please use tags v7.3.1 and v7.5.1 instead. Quentin

1 1

New Defects reported by Coverity Scan for freerangerouting/frr
by scan-admin＠coverity.com 14 Apr '21

14 Apr '21

Hi, Please find the latest report on new defect(s) introduced to freerangerouting/frr found with Coverity Scan. 1 new defect(s) introduced to freerangerouting/frr found with Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 1 of 1 defect(s) ** CID 1503803: Error handling issues (NEGATIVE_RETURNS) /nhrpd/linux.c: 75 in os_sendmsg() ________________________________________________________________________________________________________ *** CID 1503803: Error handling issues (NEGATIVE_RETURNS) /nhrpd/linux.c: 75 in os_sendmsg() 69 lladdr.sll_family = AF_PACKET; 70 lladdr.sll_protocol = htons(protocol); 71 lladdr.sll_ifindex = ifindex; 72 lladdr.sll_halen = addrlen; 73 memcpy(lladdr.sll_addr, addr, addrlen); 74 >>> CID 1503803: Error handling issues (NEGATIVE_RETURNS) >>> "os_socket()" is passed to a parameter that cannot be negative. 75 status = sendmsg(os_socket(), &msg, 0); 76 if (status < 0) 77 return -errno; 78 79 return status; 80 } ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

1 0

FlowSpec issue
by Birincsik Gábor 11 Apr '21

11 Apr '21

Hey Guy, I would need help. I got the following error message when I receive a flowspec update in our test env. I did not find solution for this. The iptables and ipset both are reachable for frr user. We are planning to implement flowspec in our system, but having trouble with it. Apr 10 20:24:59 test bgpd[399]: bgp_update_receive: rcvd End-of-RIB for IPv4 Flowspec from 10.1.0.13 in vrf default Apr 10 20:24:59 test bgpd[399]: BGP: adding FS PBR from 213.181.201.6/32 to 185.219.48.60/32, Apr 10 20:24:59 test bgpd[399]: bgp_send_pbr_ipset_match: name match0x5593c4adbfe0 type 1 1, ID 6 Apr 10 20:24:59 test bgpd[399]: bgp_send_pbr_ipset_entry_match: name match0x5593c4adbfe0 6 1, ID 6 Apr 10 20:24:59 test bgpd[399]: bgp_send_pbr_iptable: name match0x5593c4adbfe0 type 1 mark 0 1, ID 6 *Apr 10 20:24:59 test bgpd[399]: ipset_notify_owner: Received IPSET_FAIL_INSTALL** **Apr 10 20:24:59 test bgpd[399]: ipset_entry_notify_owner: Received IPSET_ENTRY_FAIL_INSTALL** **Apr 10 20:24:59 test bgpd[399]: iptable_notify_owner: Received IPTABLE_FAIL_INSTALL* I really hope you can help me, Gábor Birincsik CTO JZT Informatikai Kft

1 0

frr debian repo and frr-7.5.1
by Jan VECEK 01 Apr '21

01 Apr '21

Hello, please will be update FRR Debian repo https://deb.frrouting.org/ last 7.5.1 - https://github.com/FRRouting/frr/releases/tag/frr-7.5.1 ? Thanks Best, Jan

4 4

printfrr bikeshed color for [iana_][s]afi_t
by David Lamparter 01 Apr '21

01 Apr '21

Hi all, as I'm currently worming my way through the printfrr code, I'd like to add printfrr specifiers for afi_t/safi_t/iana_afi_t/iana_safi_t. However, unlike most other extension specifiers, there's no "obvious good" extension specifier for these, so here's a thread asking for suggestions. (extension specifier = "%pFX" & co.) For afi_t/safi_t/iana_afi_t/iana_safi_t the considerations are: - must start with "%d" or "%i" (if that eases a mnemonic, like with "%pFX", this might be a choice, but %i is probably better) - must then have one uppercase character, followed by one or more uppercase characters or digits, i.e. %i[A-Z][A-Z0-9][A-Z0-9]* - must not overlap with other extensions on a shorter length (i.e. no "%iAF" + "%iAFI") - this sequence must be different for all 4 AFI types for the typecheck to work correctly - should be short, the longest specifier currently existing is %pSG4 for "struct prefix_sg *", i.e. 3 characters after the %_ - needs to be not misunderstood for AF_INET type constants, so %iAF/%dAF is probably a bad choice - needs to be as understandable/obvious as possible Not adding an extension specifier for (some of) these types is also an option. Ultimatively the question is what makes the code the "nicest." The best I can come up with is: - %iFA (afi_t) - "F)rr A)fi" - %iFS (safi_t) - "F)rr S)afi" - %iIA (iana_afi_t) - "I)ana A)fi" - slight overlap with %pIA - %iIS (iana_safi_t) - "I)ana S)afi" But maybe something longer is better? Input requested! -David

2 1