March 2023 - Bird-users - Mailing Lists

Route attributes available when using export tables
by Hugo Slabbert 17 Mar '23

17 Mar '23

Hi folks, On bird 2.0.7. We've been debugging some export behaviour (ref subject "BIRD continues exporting routes but reports no exports"), and enabled export tables on ipv4 and ipv6 channels for some of our BGP sessions. When we did that, we found that the MED we were applying in our export filters were no longer being stamped on export. We're setting route preference on locally defined static routes, and then setting MED at export based on that route preference. Since the preference order is flipped between MED and BIRD's route preference (higher preference is better; lower MED is better), we transform that and bank it around 100, e.g. preference 100 -> MED 100; preference 99 -> MED 110, etc: ``` function preference_to_med () int tier; { tier = 100 - preference; return 100 + (tier * 10); } ``` Best I can tell, it appears that the `preference` attribute is not available on routes when they're passed through export tables. I tried instead to just stamp igp_metric on the static routes right when they are defined, to the same value as we would have for the MED, and then just doing `bgp_med = igp_metric` in the export filter, but that also did not work as MED was still not being stamped on export. We can and do also set `bgp_med` on the static routes right at their initial definition time. But, they are defined in a different table and being pulled into the source table for the exports through a pipe (so e.g. defined in MY_CUSTOM_TABLE with bgp_med set, then imported via pipe to master4, and exported from master4 via BGP), and it appears that operation means the initial MED defined on the route is not retained on export after passing through the pipe and needing to be set again explicitly. Are these types of BIRD "internal" route attributes, e.g. preference, igp_metric, not present on routes when they're passed through export tables? I suppose we could instead use BGP communities on the route, and extract the value portion of the community, but we were trying to keep things to a native metric type value. I.e. we want to just pass this across the BGP session as something like MED rather than making the far end apply a function to extract a value from a community. We could still use communities purely *within* the local BIRD instance for that, using the function only locally and still stamping MED on export; I'm just trying to determine if that's the best path, as it feels a bit clunky to need to use communities for something that is only locally significant within the local BIRD instance.

5 7

BIRD continues exporting routes but reports no exports
by Hugo Slabbert 15 Mar '23

15 Mar '23

Hi folks, We're seeing an issue where BIRD is reporting one thing for BGP route exports (via `show route export <protocol>`) but actually doing something different. We see this when we change some of the conditions around export. Our export filters include a function that evaluates as either true or false, for a global toggle of whether we should proceed on with any exports to relevant peers. Roughly it looks like this: ``` function do_export () bool DRAIN_NODE; bool HEALTHY; { DRAIN_NODE = false; HEALTHY = false; include "includes/birdwatch/*"; return HEALTHY && !DRAIN_NODE; } ``` That function is then included as the first term in relevant export filters, e.g.: ``` filter PUBLIC_EXPORT_v4 { if !do_export() then reject; # other export terms here } ``` We have external programs that monitor for whether the host is indicated as drained, or if the process that's handling traffic for the box is healthy. If those conditions change, they add or remove config snippets at the ` includes/birdwatch/` directory to change the values of the DRAIN_NODE or HEALTHY bools, and we then call `birdc configure` to reload the config and pick up the change to either stop exports or proceed on with them. Doing the common trick of adding/removing /32s from loopbacks or such for DIRECT export don't fit our use case, so this method provides external programs control over global export state for those filters. This has worked cleanly for us so far. But, recently we've hit an issue. Assuming we start in a "non-drained" state where DRAIN_NODE is false and HEALTHY is true, so we're exporting routes as expected, we then: * toggle DRAIN_NODE to be true * execute `birdc configure` to reload the configuration When we look at exported routes, e.g. `show route export <bgp peer protocol>`, BIRD shows no routes exported, as expected. However, those BGP peers definitely do still see routes advertised from BIRD. We are also using https://github.com/czerwonk/bird_exporter, and the `bird_protocol_prefix_export_count` metrics for exported routes for the drained host remain at their previous levels. In other words: * birdc says nothing is being exported * but peers still are seeing prefixes from BIRD * and bird_exporter still shows prefixes being exported from BIRD Effectively, the `birdc show route export` output is lying. We've tried adding a sleep between when the include snippet that changes the DRAIN_NODE value is written and when we hit `birdc configure`, but that doesn't appear to make any difference. If we execute `birdc configure` *twice*, though, everything's fine: The actual exports are stopped. That's true without any sleep or break between running configure as well; literally just `birdc configure` back to back in the script that manages this. We do not see any indication of issues in the `birdc configure` runs or in BIRD's logs. The reverse also does occur, where if we start with the DRAIN_NODE set to true and are exporting nothing, then unset DRAIN_NODE and hit `birdc configure`: `show route export` shows things being exported, but neighbours actually don't hear any routes. We have not seen this occur in our smaller dev environment, but it has shown up in our more scaled environment. The relevant hosts have a couple of upstream v4 and v6 peers feeding them defaults, with: Import: * 1x IPv4 default route per BGP upstream peer, 2x total * 1x IPv6 default route per BGP upstream peer, 2x total Export: * 1-5 IPv4 /24s per BGP upstream peer * 0-1 IPv6 /48s per BGP upstream peer They have a larger number of downstream BGP peers, currently around 138 but that number can fluctuate. Each of those peers have an IPv4 and IPv6 channel, running over an IPv6 transport (`extended next hop on` for the ipv4 channel). At the moment those have: Import: * 2x IPv6 routes per peer (one /48, one /128) * 63x IPv4 routes per peer (all /24s) Export: * 21x IPv6 routes per peer (all /128s) * 1-5x IPv6 routes per peer (all /24s) So this does end up with the boxes have ~290 BGP "protocols", between v4 and v6 channels combined, ~9300 routes imported (between v4 and v6, multiplied by peers), and ~3,100 routes exported (between v4 and v6, multiplied by peers). Any thoughts on what could be causing BIRD to fail to apply the policy properly on the first `birdc configure` but succeeding on the second? Or why the route export output is incorrect after the first `birdc configure` but the metrics exporter being correct? Is `show route export` showing what BIRD *thinks* should be exported based on current filters, or what it's actively sending to those peers? Or any thoughts on how we can further debug or trace this to figure out what's confusing BIRD?

4 10

Extended communities ASN wildcard.
by Ochalski, Radoslaw 13 Mar '23

13 Mar '23

Hi, I was wondering if there is a way to match extended communities via all ASNs wildcard? As per https://bird.network.cz/?get_doc&v=16&f=bird-5.html, it’s not possible: EC sets use similar expressions like pair sets, e.g. (rt, 123, 10..20) or (ro, 123, *). Expressions requiring the translation (like (rt, *, 3)) are not allowed (as they usually have 4B range for ASNs). This is kind a surprising, however maybe I am missing something? Cheers, Radek

2 1

Re: Radv proto sending adverts on wrong interface
by Daniel Gröber 13 Mar '23

13 Mar '23

Hi Kees, On Mon, Mar 13, 2023 at 07:23:17AM +0100, Kees Meijs | Nefos wrote: > About VLAN configuration: I guess one should never ever use VLAN_DEFAULT > c.q. VLAN 1 at all. Vendors often think differently about this case, > sometimes allowing to have a .1Q tag, sometimes not. Or sort of "both" as > well. In combination with protocols such as LACP or (variations on) STP > resulting in great fun, which of course is very sarcastic. I changed the default using `default-vlan-id 4095` for that very reason. Perhaps this is still a default vid related bug. I'll see if I can reproduce this with some other vid. > My two cents after opening up a box with a new switch, starting your > configuration: explicitly disable VLAN1 and continue using others. Same goes > for VLAN > 4090 by the way. These numbers are sometimes "reserved". The brocade docs list the reserved vlans (4091, 4092) explicitly and allow to change them like the default vid. The 4095 default vid I'm using is the example they use in the docs so I'd be surprised if that's broken. Using such low vlan ids is a holdover from using some ath9k wifi APs that only supported 4-bit vids so we had to make every number count ;) I'll definetly reconsider that in the future haha. Thanks, --Daniel

1 0

Radv proto sending adverts on wrong interface
by Daniel Gröber 13 Mar '23

13 Mar '23

Hi, I'm using bird as a replacement for radvd since the latter has a longstanding issue with sending adverts on unconfigured interfaces under complex conditions. Turns out bird has a similar issue :) Looking at the code, when opening the socket for an interface in radv_sk_open we set sk->iface as you'd expect, which should cause packets to be sent directly via this interface. However radv sends packets to the all-nodes multicasts address for periodic adverts, see radv_send_ra. This then calls sk_send_to which (eventually) calls sockaddr_fill6. Here rther we find this code: if (ifa && ipa_is_link_local(a)) sa->sin6_scope_id = ifa->index; This would seem to be the problem to me, since a=ff02::1 doesn't pass this check so the sendmsg call goes out without the interface-index being communicated to the kernel. It looks like that causes it to just pick a random interface though I would expect it to just multicast this. Not sure why that is but it's broken on our side either way. I'd add a check here for whether the saddr is link-local too. That should cover this case. Any comments/objections? Thanks, --Daniel

5 7

Is there a way to clear sessions created by «neighbor range» option?
by Valery Lutoshkin 12 Mar '23

12 Mar '23

Hi, I use Bird 2.0.9 to spread a special list of prefixes via BGP to an unknown list of users, so I use “neighbor range 0.0.0.0/0 external;” and a passive mode. In this situation, there are some dynamic protocols created by port scanners or some other one-time connections. It is not a big deal, but after some time the “show protocol” output looks huge, and I presume Bird eats more memory with several thousand connections. The only way I found to clear those dynamic protocols was to restart Bird, but this affects real users of the service. Is there another way to clear unsuccessful dynamic protocols? I can parse the list of it, but still I didn’t find a way to clear a specific protocol, like “clear protocol dynbgp2049” or smth. The best way would be to clear “all protocols in the start state”, but AFAIK right now there is no command like that in Birdc. Best regards, Valery

2 2

Comments on CVE-2021-26928?
by Robert Scheck 09 Mar '23

09 Mar '23

Hello, with https://bugzilla.redhat.com/show_bug.cgi?id=2176483, Red Hat pointed me today to CVE-2021-26928. https://nvd.nist.gov/vuln/detail/CVE-2021-26928 contains a reference to BIRD 2.0.7, but no link related to BIRD upstream. Do you see any chance for some comments on it (at least here)? Not sure if MITRE adds it then as references at CVE-2021-26928. Thank you. Regards, Robert

6 6

Expiration for ROA tables until when the VRP is valid?
by Robert Scheck 07 Mar '23

07 Mar '23

Hello all, rpki-client recently implemented the "expires" instruction for roa-sets that OpenBGPD provides [1][2]. As of writing, BIRD does not seem to have something similar...any chance for it? From my understanding this only applies to included ROA files with VRP, not to RTR. [1] https://man.openbsd.org/bgpd.conf#roa-set [2] https://github.com/rpki-client/rpki-client-openbsd/commit/7bf63da6ec80f37bd… Kind regards Robert Scheck

3 7

[PATCH] Babel: add RFC9229 (v4 via v6) support
by andreas＠rammhold.de 06 Mar '23

06 Mar '23

From: Andreas Rammhold <andreas(a)rammhold.de> This implements [RFC9229] an IPv4 via IPv6 extension to the Babel routing protocol that allows annoncing routes to an IPv4 prefix with an IPv6 next-hop, which makes it possible for IPv4 traffic to flow through interfaces that have not been assigned an IPv4 address. The implementation is compatible with the current Babeld version (the relevant changes can be seen in the [babeld PR]). I've verified this with a few VMs in the following setup: Bird <- v4 only -> Bird <- v6 only -> Babeld <- v4 only -> Babeld Each routing daemon was running on their own VM and had L2 connectivity to only its direct neighbors. At the nodes at the edges v4 networks have been announced and full end-to-end communication was possible over the mixed AF network. The v6 only link between Babel and Bird (at the "center" of the above setup) did transport the v4 packets via the v6 link-local next hop addresses just as expected. Thanks to Toke Høiland-Jørgensen for early review on this work. [RFC9229]: https://www.ietf.org/rfc/rfc9229.txt [babeld PR]: https://github.com/jech/babeld/pull/56 Acked-by: Toke Høiland-Jørgensen <toke(a)toke.dk> --- This is a rebase of the patches from the previous two RFC rounds on this ML: * https://trubka.network.cz/pipermail/bird-users/2022-April/016046.html <20201215020627.30942-1-andreas(a)rammhold.de> * http://trubka.network.cz/pipermail/bird-users/2020-December/015082.html <20201215020627.30942-1-andreas(a)rammhold.de> I'd like to drive this to the finish goal soon. I've been using it ever since and know of other users as well. Is there anything that should still be changed? doc/bird.sgml | 6 +++ proto/babel/babel.c | 28 ++++++++--- proto/babel/babel.h | 3 ++ proto/babel/config.Y | 5 +- proto/babel/packets.c | 106 +++++++++++++++++++++++++++++------------- 5 files changed, 109 insertions(+), 39 deletions(-) diff --git a/doc/bird.sgml b/doc/bird.sgml index 50657ebf..a7cedaee 100644 --- a/doc/bird.sgml +++ b/doc/bird.sgml @@ -1934,6 +1934,7 @@ protocol babel [<name>] { algorithm ( hmac sha1 | hmac sha256 | hmac sha384 | hmac sha512 | blake2s128 | blake2s256 | blake2b256 | blake2b512 ); }; + ipv4 via ipv6 <switch>; }; } </code> @@ -2042,6 +2043,11 @@ protocol babel [<name>] { protocol will only accept HMAC-based algorithms or one of the Blake algorithms, and the length of the supplied password string must match the key size used by the selected algorithm. + + <tag><label id="babel-ipv4-via-ipv6">ipv4 via ipv6 <m/switch/</tag> + If enabled, Bird will accept and emit IPv4-via-IPv6 routes when IPv4 + addresses are absent from the interface as described in RFC9229. + Default: yes. </descrip> <sect1>Attributes diff --git a/proto/babel/babel.c b/proto/babel/babel.c index ecfd2763..52a27256 100644 --- a/proto/babel/babel.c +++ b/proto/babel/babel.c @@ -981,8 +981,17 @@ babel_send_update_(struct babel_iface *ifa, btime changed, struct fib *rtable) msg.update.router_id = e->router_id; net_copy(&msg.update.net, e->n.addr); - msg.update.next_hop = ((e->n.addr->type == NET_IP4) ? - ifa->next_hop_ip4 : ifa->next_hop_ip6); + if (e->n.addr->type == NET_IP4) { + /* Always prefer v4 nexthop if set */ + if(!ipa_zero(ifa->next_hop_ip4)) + msg.update.next_hop = ifa->next_hop_ip4; + + /* Only send v4-via-v6 if enabled */ + else if (ifa->cf->ip4_via_ip6) + msg.update.next_hop = ifa->next_hop_ip6; + } else { + msg.update.next_hop = ifa->next_hop_ip6; + } /* Do not send route if next hop is unknown, e.g. no configured IPv4 address */ if (ipa_zero(msg.update.next_hop)) @@ -1277,6 +1286,12 @@ babel_handle_update(union babel_msg *m, struct babel_iface *ifa) return; } + /* Reject IPv4 via IPv6 routes if disabled */ + if (!ifa->cf->ip4_via_ip6 && msg->net.type == NET_IP4 && ipa_is_ip6(msg->next_hop)) { + DBG("Babel: Ignoring disabled IPv4 via IPv6 route.\n"); + return; + } + /* Regular update */ e = babel_get_entry(p, &msg->net); r = babel_get_route(p, e, nbr); /* the route entry indexed by neighbour */ @@ -1682,7 +1697,7 @@ babel_iface_update_addr4(struct babel_iface *ifa) ip_addr addr4 = ifa->iface->addr4 ? ifa->iface->addr4->ip : IPA_NONE; ifa->next_hop_ip4 = ipa_nonzero(ifa->cf->next_hop_ip4) ? ifa->cf->next_hop_ip4 : addr4; - if (ipa_zero(ifa->next_hop_ip4) && p->ip4_channel) + if (ipa_zero(ifa->next_hop_ip4) && p->ip4_channel && !ifa->cf->ip4_via_ip6) log(L_WARN "%s: Missing IPv4 next hop address for %s", p->p.name, ifa->ifname); if (ifa->up) @@ -2074,8 +2089,8 @@ babel_show_interfaces(struct proto *P, const char *iff) } cli_msg(-1023, "%s:", p->p.name); - cli_msg(-1023, "%-10s %-6s %-5s %7s %6s %7s %-15s %s", - "Interface", "State", "Auth", "RX cost", "Nbrs", "Timer", + cli_msg(-1023, "%-10s %-6s %-5s %-12s %7s %6s %7s %-15s %s", + "Interface", "State", "Auth", "IPv4 via Ip6", "RX cost", "Nbrs", "Timer", "Next hop (v4)", "Next hop (v6)"); WALK_LIST(ifa, p->interfaces) @@ -2088,10 +2103,11 @@ babel_show_interfaces(struct proto *P, const char *iff) nbrs++; btime timer = MIN(ifa->next_regular, ifa->next_hello) - current_time(); - cli_msg(-1023, "%-10s %-6s %-5s %7u %6u %7t %-15I %I", + cli_msg(-1023, "%-10s %-6s %-5s %-12s %7u %6u %7t %-15I %I", ifa->iface->name, (ifa->up ? "Up" : "Down"), (ifa->cf->auth_type == BABEL_AUTH_MAC ? (ifa->cf->auth_permissive ? "Perm" : "Yes") : "No"), + (ifa->cf->ip4_via_ip6 ? "Yes" : "No"), ifa->cf->rxcost, nbrs, MAX(timer, 0), ifa->next_hop_ip4, ifa->next_hop_ip6); } diff --git a/proto/babel/babel.h b/proto/babel/babel.h index 8b6da3c8..034a17db 100644 --- a/proto/babel/babel.h +++ b/proto/babel/babel.h @@ -112,6 +112,7 @@ enum babel_ae_type { BABEL_AE_IP4 = 1, BABEL_AE_IP6 = 2, BABEL_AE_IP6_LL = 3, + BABEL_AE_IPV4_VIA_IPV6 = 4, BABEL_AE_MAX }; @@ -151,6 +152,8 @@ struct babel_iface_config { uint mac_num_keys; /* Number of configured HMAC keys */ uint mac_total_len; /* Total digest length for all configured keys */ list *passwords; /* Passwords for authentication */ + + u8 ip4_via_ip6; /* Enable IPv4 via IPv6 */ }; struct babel_proto { diff --git a/proto/babel/config.Y b/proto/babel/config.Y index 05210fa4..7190f099 100644 --- a/proto/babel/config.Y +++ b/proto/babel/config.Y @@ -25,7 +25,8 @@ CF_DECLS CF_KEYWORDS(BABEL, INTERFACE, METRIC, RXCOST, HELLO, UPDATE, INTERVAL, PORT, TYPE, WIRED, WIRELESS, RX, TX, BUFFER, PRIORITY, LENGTH, CHECK, LINK, NEXT, HOP, IPV4, IPV6, BABEL_METRIC, SHOW, INTERFACES, NEIGHBORS, - ENTRIES, RANDOMIZE, ROUTER, ID, AUTHENTICATION, NONE, MAC, PERMISSIVE) + ENTRIES, RANDOMIZE, ROUTER, ID, AUTHENTICATION, NONE, MAC, PERMISSIVE, + VIA) CF_GRAMMAR @@ -67,6 +68,7 @@ babel_iface_start: BABEL_IFACE->tx_tos = IP_PREC_INTERNET_CONTROL; BABEL_IFACE->tx_priority = sk_priority_control; BABEL_IFACE->check_link = 1; + BABEL_IFACE->ip4_via_ip6 = 1; }; @@ -143,6 +145,7 @@ babel_iface_item: | CHECK LINK bool { BABEL_IFACE->check_link = $3; } | NEXT HOP IPV4 ipa { BABEL_IFACE->next_hop_ip4 = $4; if (!ipa_is_ip4($4)) cf_error("Must be an IPv4 address"); } | NEXT HOP IPV6 ipa { BABEL_IFACE->next_hop_ip6 = $4; if (!ipa_is_ip6($4)) cf_error("Must be an IPv6 address"); } + | IPV4 VIA IPV6 bool { BABEL_IFACE->ip4_via_ip6 = $4; } | AUTHENTICATION NONE { BABEL_IFACE->auth_type = BABEL_AUTH_NONE; } | AUTHENTICATION MAC { BABEL_IFACE->auth_type = BABEL_AUTH_MAC; BABEL_IFACE->auth_permissive = 0; } | AUTHENTICATION MAC PERMISSIVE { BABEL_IFACE->auth_type = BABEL_AUTH_MAC; BABEL_IFACE->auth_permissive = 1; } diff --git a/proto/babel/packets.c b/proto/babel/packets.c index d4acc170..9a71673a 100644 --- a/proto/babel/packets.c +++ b/proto/babel/packets.c @@ -167,9 +167,11 @@ struct babel_parse_state { u64 router_id; /* Router ID used in subsequent updates */ u8 def_ip6_prefix[16]; /* Implicit IPv6 prefix in network order */ u8 def_ip4_prefix[4]; /* Implicit IPv4 prefix in network order */ + u8 def_ip4viaip6_prefix[4]; /* Implicit IPv4 prefix in network order */ u8 router_id_seen; /* router_id field is valid */ u8 def_ip6_prefix_seen; /* def_ip6_prefix is valid */ u8 def_ip4_prefix_seen; /* def_ip4_prefix is valid */ + u8 def_ip4viaip6_prefix_seen; /* def_ip4viaip6_prefix is valid*/ u8 current_tlv_endpos; /* End of self-terminating TLVs (offset from start) */ u8 sadr_enabled; u8 is_unicast; @@ -515,9 +517,6 @@ babel_read_ihu(struct babel_tlv *hdr, union babel_msg *m, msg->addr = IPA_NONE; msg->sender = state->saddr; - if (msg->ae >= BABEL_AE_MAX) - return PARSE_IGNORE; - /* * We only actually read link-local IPs. In every other case, the addr field * will be 0 but validation will succeed. The handler takes care of these @@ -530,13 +529,13 @@ babel_read_ihu(struct babel_tlv *hdr, union babel_msg *m, if (TLV_OPT_LENGTH(tlv) < 4) return PARSE_ERROR; state->current_tlv_endpos += 4; - break; + return PARSE_SUCCESS; case BABEL_AE_IP6: if (TLV_OPT_LENGTH(tlv) < 16) return PARSE_ERROR; state->current_tlv_endpos += 16; - break; + return PARSE_SUCCESS; case BABEL_AE_IP6_LL: if (TLV_OPT_LENGTH(tlv) < 8) @@ -544,10 +543,10 @@ babel_read_ihu(struct babel_tlv *hdr, union babel_msg *m, msg->addr = ipa_from_ip6(get_ip6_ll(&tlv->addr)); state->current_tlv_endpos += 8; - break; + return PARSE_SUCCESS; } - return PARSE_SUCCESS; + return PARSE_IGNORE; } static uint @@ -647,6 +646,47 @@ babel_read_next_hop(struct babel_tlv *hdr, union babel_msg *m UNUSED, return PARSE_IGNORE; } + +/* This is called directly from babel_read_next_hop to handle the ip4 address + compression state */ +static int +babel_get_ip4_prefix(struct babel_tlv_update *tlv, + struct babel_msg_update *msg, + u8 *def_prefix_seen, + u8 (*def_prefix)[], + ip_addr next_hop, + int len) +{ + if (tlv->plen > IP4_MAX_PREFIX_LENGTH) + return PARSE_ERROR; + + /* Cannot omit data if there is no saved prefix */ + if (tlv->omitted && !*def_prefix_seen) + return PARSE_ERROR; + + /* Update must have next hop, unless it is retraction */ + if (ipa_zero(next_hop) && msg->metric != BABEL_INFINITY) + return PARSE_IGNORE; + + /* Merge saved prefix and received prefix parts */ + u8 buf[4] = {}; + memcpy(buf, *def_prefix, tlv->omitted); + memcpy(buf + tlv->omitted, tlv->addr, len); + + ip4_addr prefix4 = get_ip4(buf); + net_fill_ip4(&msg->net, prefix4, tlv->plen); + + if (tlv->flags & BABEL_UF_DEF_PREFIX) + { + put_ip4(*def_prefix, prefix4); + *def_prefix_seen = 1; + } + + msg->next_hop = next_hop; + + return PARSE_SUCCESS; +} + /* This is called directly from babel_write_update() and returns -1 if a next hop should be written but there is not enough space. */ static int @@ -696,6 +736,7 @@ static int babel_read_update(struct babel_tlv *hdr, union babel_msg *m, struct babel_parse_state *state) { + int rc; struct babel_tlv_update *tlv = (void *) hdr; struct babel_msg_update *msg = &m->update; @@ -706,7 +747,6 @@ babel_read_update(struct babel_tlv *hdr, union babel_msg *m, /* Length of received prefix data without omitted part */ int len = BYTES(tlv->plen) - (int) tlv->omitted; - u8 buf[16] = {}; if ((len < 0) || ((uint) len > TLV_OPT_LENGTH(tlv))) return PARSE_ERROR; @@ -724,31 +764,20 @@ babel_read_update(struct babel_tlv *hdr, union babel_msg *m, break; case BABEL_AE_IP4: - if (tlv->plen > IP4_MAX_PREFIX_LENGTH) - return PARSE_ERROR; + rc = babel_get_ip4_prefix(tlv, msg, &state->def_ip4_prefix_seen, + &state->def_ip4_prefix, state->next_hop_ip4, + len); + if (rc != PARSE_SUCCESS) + return rc; - /* Cannot omit data if there is no saved prefix */ - if (tlv->omitted && !state->def_ip4_prefix_seen) - return PARSE_ERROR; - - /* Update must have next hop, unless it is retraction */ - if (ipa_zero(state->next_hop_ip4) && (msg->metric != BABEL_INFINITY)) - return PARSE_IGNORE; - - /* Merge saved prefix and received prefix parts */ - memcpy(buf, state->def_ip4_prefix, tlv->omitted); - memcpy(buf + tlv->omitted, tlv->addr, len); - - ip4_addr prefix4 = get_ip4(buf); - net_fill_ip4(&msg->net, prefix4, tlv->plen); - - if (tlv->flags & BABEL_UF_DEF_PREFIX) - { - put_ip4(state->def_ip4_prefix, prefix4); - state->def_ip4_prefix_seen = 1; - } + break; - msg->next_hop = state->next_hop_ip4; + case BABEL_AE_IPV4_VIA_IPV6: + rc = babel_get_ip4_prefix(tlv, msg, &state->def_ip4viaip6_prefix_seen, + &state->def_ip4viaip6_prefix, state->next_hop_ip6, + len); + if (rc != PARSE_SUCCESS) + return rc; break; @@ -761,6 +790,7 @@ babel_read_update(struct babel_tlv *hdr, union babel_msg *m, return PARSE_ERROR; /* Merge saved prefix and received prefix parts */ + u8 buf[16] = {}; memcpy(buf, state->def_ip6_prefix, tlv->omitted); memcpy(buf + tlv->omitted, tlv->addr, len); @@ -863,7 +893,11 @@ babel_write_update(struct babel_tlv *hdr, union babel_msg *m, } else if (msg->net.type == NET_IP4) { - tlv->ae = BABEL_AE_IP4; + if (!ipa_zero(msg->next_hop) && ipa_is_ip6(msg->next_hop)) + tlv->ae = BABEL_AE_IPV4_VIA_IPV6; + else + tlv->ae = BABEL_AE_IP4; + tlv->plen = net4_pxlen(&msg->net); put_ip4_px(tlv->addr, &msg->net); } @@ -931,7 +965,11 @@ babel_read_route_request(struct babel_tlv *hdr, union babel_msg *m, msg->full = 1; return PARSE_SUCCESS; + /* RFC9229 section 2.3: When receiving requests, AEs 1 (IPv4) and 4 + * (v4-via-v6) MUST be treated in the same manner. + */ case BABEL_AE_IP4: + case BABEL_AE_IPV4_VIA_IPV6: if (tlv->plen > IP4_MAX_PREFIX_LENGTH) return PARSE_ERROR; @@ -1032,7 +1070,11 @@ babel_read_seqno_request(struct babel_tlv *hdr, union babel_msg *m, case BABEL_AE_WILDCARD: return PARSE_ERROR; + /* RFC9229 section 2.3: When receiving requests, AEs 1 (IPv4) and 4 + * (v4-via-v6) MUST be treated in the same manner. + */ case BABEL_AE_IP4: + case BABEL_AE_IPV4_VIA_IPV6: if (tlv->plen > IP4_MAX_PREFIX_LENGTH) return PARSE_ERROR; -- 2.38.1

6 16

[PATCH] Printf: libc independent I/O error test
by Petr Vaněk 06 Mar '23

06 Mar '23

Printf test suite fails on systems with musl libc because tests for "%m" and "%M" formats expect "Input/output error" message but musl returns "I/O error". Proposed change compares the printf output with string returned from strerror function for EIO constant. See-also: https://bugs.gentoo.org/836713 Signed-off-by: Petr Vaněk <arkamar(a)atlas.cz> --- lib/printf_test.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/lib/printf_test.c b/lib/printf_test.c index 47ea905d..ca278975 100644 --- a/lib/printf_test.c +++ b/lib/printf_test.c @@ -32,11 +32,14 @@ t_simple(void) BSPRINTF(1, "@", buf, "@", 64); BSPRINTF(1, "\xff", buf, "%c", 0xff); + const char * io_error_str = strerror(EIO); + const int io_error_len = strlen(io_error_str); + errno = 5; - BSPRINTF(18, "Input/output error", buf, "%m"); + BSPRINTF(io_error_len, io_error_str, buf, "%m"); errno = 0; - BSPRINTF(18, "Input/output error", buf, "%M", 5); + BSPRINTF(io_error_len, io_error_str, buf, "%M", 5); BSPRINTF(11, "TeSt%StRiNg", buf, "%s", "TeSt%StRiNg"); -- 2.39.2

2 2