On Sun, May 15, 2022 at 10:35:43AM +0200, Mark Kettenis wrote:
> > From: "Ted Unangst"
> > Date: Sat, 14 May 2022 20:23:39 -0400
> >
> > The cpu hz sensor is more accurate and updates faster than than the value
> > currently used for hw.cpuspeed. So return that value (scaled).
> >
> > This
This diff replaces most of the rttimer with a timeout(9) call.
Instead of running a 1 second timer all the time it runs idividual
timeouts for each rttimer object.
rt_timer_remove_all() needs to be careful to not remove the rttimer object
while the timeout callback is running or up to be run.
It
On Thu, May 12, 2022 at 07:44:51PM +0200, Theo Buehler wrote:
> ip_addr_parse() sticks its fingers into undocumented API surface of
> libcrypto. What is true is that the unused bit count is in the lower
> three bits of p->flags, provided that ASN1_STRING_FLAG_BITS_LEFT is set.
> This is
On Thu, May 12, 2022 at 11:27:21AM +0200, Theo Buehler wrote:
> This aligns sbgp_ipaddrblk() with sbgp_assysnum(), giving it a similar
> treatment. We trade the reallocarray() per prefix or range with at most
> two recallocarray(). I took the liberty of trimming some RFC section
> numbers in
On Thu, May 12, 2022 at 10:17:30AM +0200, Theo Buehler wrote:
> Before refactoring the IP side, let's streamline the code a little.
> Populate struct ip in the leaf functions instead of handing it through
> several layers and copying it along the way. Pass in the afi instead of
> letting struct ip
I took the liberty and refactored the sbgp_assysnum() code a bit more.
Main goal is to replace the reallocarray() in append_as() with an upfront
calloc() call since now the size is known. Also I decided to collaps
sbgp_asnum() into sbgp_assysnum().
One could also inline the now very simple
On Wed, May 11, 2022 at 08:50:57AM -0600, Bob Beck wrote:
> yes makes sense
>
> ok beck@
agreed, ok claudio@
> > On May 11, 2022, at 07:53, Theo Buehler wrote:
> >
> > Some funky libcrypto business ahead.
> >
> > X509 API functions such as X509_check_ca() or X509_get_extension_flags()
> >
On Tue, May 10, 2022 at 08:43:45PM +0200, Theo Buehler wrote:
> The ASIdentifiers code is a bit strangely factored presumably due to
> constraints of the low-level shoveling. I kept the coarse structure
> of the code and left some house keeping for later. The changes in
> sbgp_asrange() and
On Tue, May 10, 2022 at 01:27:17PM +0200, Theo Buehler wrote:
> This is a straightforward conversion to letting libcrypto's RFC 3779
> code parse a cert's IPAddrBlocks. The magic happens in X509V3_EXT_d2i()
> in sbgp_ipaddrblk(). After that, we simply have to walk the returned
> structure. The
On Tue, May 10, 2022 at 01:47:44PM +0200, Theo Buehler wrote:
> In sbgp_asrange() and sbgp_addr_range(), the ASN1_SEQUENCE_ANY *seq is
> potentially leaked due to early return 0 instead of goto out. The last
> hunk collides with my IPAddrBlocks diff. Sending this out so I don't
> forget.
>
>
On Tue, May 10, 2022 at 08:38:32AM +0200, Theo Buehler wrote:
> On Tue, May 10, 2022 at 08:28:10AM +0200, Claudio Jeker wrote:
> > On Tue, May 10, 2022 at 08:05:00AM +0200, Theo Buehler wrote:
> > > This moves valid_filename() to validate.c and splits out a helper
> > >
On Tue, May 10, 2022 at 08:05:00AM +0200, Theo Buehler wrote:
> This moves valid_filename() to validate.c and splits out a helper
> portable_filename() which can be used from the RSC code. While moving
> valid_filename() is not necessary, I thought it makes sense to keep the
> two functions next
On Mon, May 09, 2022 at 01:07:17PM +, Job Snijders wrote:
> On Mon, May 09, 2022 at 12:11:22PM +0200, Claudio Jeker wrote:
> > why does the draft allow for optional filenames? What the heck is the
> > digest then covering some random gunk?
>
> Yes, that is entirely
On Mon, May 09, 2022 at 12:53:05PM +0200, Theo Buehler wrote:
> > As the various same-named-but-different 'parse' structs are not easily
> > interchangeable without more refactoring, I marked them "XXX:". Perhaps
> > we can work on that in tree?
>
> I'm fine with fixing that in-tree. Sorry about
On Sun, May 08, 2022 at 08:05:08PM +, Job Snijders wrote:
> Dear Theo, fellow developers,
>
> Many thanks for the first review pass, much appreciated.
>
> > This is a good first step. I have a few initial comments inline. Once you
> > fix
> > those, review of the rest will be easier.
> >
>
On Thu, May 05, 2022 at 11:37:24AM +0200, Claudio Jeker wrote:
> So most routing daemons and other network daemons like pppd do not allow
> 240/4 as IPs because they check the IP against IN_BADCLASS().
> I think it is time to remove this restriction.
>
> Now there is another
In total there are 6 rt_timer_queues in our kernel. 3 IPv4 and 3 IPv6.
That number may be increased to 8 if arp and nd would use these timers as
well. Because of this allocation the queue heads via pool(9) is overkill.
Switch rt_timer_queue_create to rt_timer_queue_init which just sets up the
So most routing daemons and other network daemons like pppd do not allow
240/4 as IPs because they check the IP against IN_BADCLASS().
I think it is time to remove this restriction.
Now there is another magical network 0.0.0.0/8 which is not allowed in
some but not all of the routing daemons. Not
On Thu, May 05, 2022 at 12:58:06PM +1000, Damien Miller wrote:
> On Wed, 4 May 2022, Seth David Schoen wrote:
>
> [snip]
>
> > Anyway, one thing we would like to propose that OpenBSD update is the
> > in_canforward treatment of 240/4 (former class E) addresses. Apparently
> > mainly as a result
On Wed, May 04, 2022 at 04:09:41PM +0200, Theo Buehler wrote:
> On Wed, May 04, 2022 at 04:03:21PM +0200, Claudio Jeker wrote:
> > On Wed, May 04, 2022 at 03:51:02PM +0200, Theo Buehler wrote:
> > > I had output from rpki-client -f something piped into less. After an
>
On Wed, May 04, 2022 at 03:51:02PM +0200, Theo Buehler wrote:
> I had output from rpki-client -f something piped into less. After an
> hour rpki-client couldn't take it any longer and decided to move on to
> a better place. It also left a residue via syslog on its way out. I
> don't think it
On Wed, May 04, 2022 at 12:14:01AM +0200, Alexander Bluhm wrote:
> Hi,
>
> We have one comment that locking for ratecheck(9) is missing. In
> all other places locking status of the struct timeval *lasttime
> is unclear.
>
> The easiest fix is a global mutex for all lasttime in ratecheck().
>
On Tue, May 03, 2022 at 02:08:33PM +0200, Alexandr Nedvedicky wrote:
> Hello
>
> On Tue, May 03, 2022 at 10:44:48AM +0200, Claudio Jeker wrote:
>
> >
> > The RFC does not use the usual MUST to enforce any of this.
> > So yes, we should probably not be too
Next stage of rttimer cleanup. Move the callback from the rttimer to the
rttimer_queue struct. The callback is always the same for a queue so there
is no need to define it on every call.
On top of that replace rt_timer_queue_destroy() with
rt_timer_queue_flush(). With this queues can no longer be
On Tue, May 03, 2022 at 12:05:06AM +0200, Alexander Bluhm wrote:
> On Mon, May 02, 2022 at 11:30:58PM +0200, Alexandr Nedvedicky wrote:
> > hello,
> >
> > bluhm@ has committed a fix [1] which makes pf to accept IGMP/MLD messages.
> > If I remember correct pf(4) was dropping those messages because
The callback currently uses struct rttimer as an argument but the code
only needs the rtt_tableid element from there. Change the callbacks to
be of the form void (*rtt_callback)(struct rtentry *r, u_int rtableid)
Also change the default rttimer callback (in case the function is NULL)
to only
On Thu, Apr 28, 2022 at 07:24:22PM +0200, Alexander Bluhm wrote:
> I still need an ok for this diff. It is the final step before we
> can run IP forwaring in parallel.
Fine with me. If it holds you back put it in OK claudio@
I will rip the rttimer code appart in the next days and make that API a
On Thu, Apr 28, 2022 at 05:51:57PM +0200, Alexander Bluhm wrote:
> On Wed, Apr 27, 2022 at 12:10:59PM +0200, Claudio Jeker wrote:
> > There is no need to have a rttimer queue per rdomain. The rttimer itself
> > is rdomain aware and so this just make everything more complicated
spec_close() does a fair bit of extra work around the xlock flag.
Now spec_close() is called via VOP_CLOSE and either the vnode has VXLOCK
set (because it is called via vclean()) or it does not. In either case
VXLOCK can not change during call (at least that was my conclusion looking
at the code).
This is just a mini cleanup. Switch from vgone() to vgonel() like it is
done a bit later already. vgone() is just a wrapper around vgonel() using
curproc (which is cached in vop_generic_revoke()).
--
:wq Claudio
Index: vfs_default.c
There is no need to have a rttimer queue per rdomain. The rttimer itself
is rdomain aware and so this just make everything more complicated for no
gain.
This diff just drops back to a single queue and initializes the queues in
ip_init() and the IPv6 counterpart. I have no mrouter setup to test
On Mon, Apr 25, 2022 at 11:31:22AM -0400, Bryan Steele wrote:
> On Mon, Apr 25, 2022 at 05:20:46PM +0200, Claudio Jeker wrote:
> > On Sun, Apr 24, 2022 at 07:06:19PM +0200, Claudio Jeker wrote:
> > > On Ryzen CPUs each CCD has a temp sensor. If the CPU has CCDs (which
> >
On Mon, Apr 25, 2022 at 05:22:51PM +0200, Hrvoje Popovski wrote:
> On 25.4.2022. 16:50, Hrvoje Popovski wrote:
> > On 25.4.2022. 16:19, Claudio Jeker wrote:
> >> After I sent out my ksmn(4) diff to include cpu frequency sensors dlg@
> >> told me that this is a generic wa
On Sun, Apr 24, 2022 at 07:06:19PM +0200, Claudio Jeker wrote:
> On Ryzen CPUs each CCD has a temp sensor. If the CPU has CCDs (which
> excludes Zen APU CPUs) this should show additional temp info. This is
> based on info from the Linux k10temp driver.
>
> Additionally use t
After I sent out my ksmn(4) diff to include cpu frequency sensors dlg@
told me that this is a generic way to find the cpu frequency on modern x86
cpus (both intel and amd support it).
So this diff cleans up the CPU frequency sensors and moves them to the
cpu(4). I had to split the sensor
On Sun, Apr 24, 2022 at 02:30:37PM -0400, Bryan Steele wrote:
> On Sun, Apr 24, 2022 at 07:06:19PM +0200, Claudio Jeker wrote:
> > On Ryzen CPUs each CCD has a temp sensor. If the CPU has CCDs (which
> > excludes Zen APU CPUs) this should show additional temp info. This is
> &g
On Ryzen CPUs each CCD has a temp sensor. If the CPU has CCDs (which
excludes Zen APU CPUs) this should show additional temp info. This is
based on info from the Linux k10temp driver.
Additionally use the MSRs defined in "Open-Source Register Reference For
AMD Family 17h Processors" to measure
On Fri, Apr 22, 2022 at 12:28:21AM +0200, Sebastian Benoit wrote:
> Claudio Jeker(cje...@diehard.n-r-g.com) on 2022.04.20 15:12:57 +0200:
> > On Wed, Apr 20, 2022 at 03:00:15PM +0200, Theo Buehler wrote:
> > > Found this when looking at the timezone issue a co
On Thu, Apr 21, 2022 at 03:25:03PM +0200, Alexander Bluhm wrote:
> Hi,
>
> As claudio@ wants to refactor router timer before making them MP
> safe, I would like to protect them with kernel lock. It should fix
> this panic.
>
> https://marc.info/?l=openbsd-tech=164038527425440=2
>
> I hope this
On Thu, Apr 21, 2022 at 02:08:01PM +0200, Theo Buehler wrote:
> On Thu, Apr 21, 2022 at 01:14:31PM +0200, Claudio Jeker wrote:
> > So here is the cleanup of filemode.c and also a bit of cleanup in parse.c
> > This should also fix a few bugs in parse_load_certchain() (main
So here is the cleanup of filemode.c and also a bit of cleanup in parse.c
This should also fix a few bugs in parse_load_certchain() (mainly
memleaks).
--
:wq Claudio
Index: cert.c
===
RCS file:
On Wed, Apr 20, 2022 at 08:12:51PM +0200, Alexander Bluhm wrote:
> Hi,
>
> mvs@ reminded me of a crash I have seen in December. Route timers
> are not MP safe, but I think this can be fixed with a mutex. The
> idea is to protect the global lists with a mutex and move the rttimer
> into a
On Wed, Apr 20, 2022 at 08:07:06PM +0200, Theo Buehler wrote:
> On Wed, Apr 20, 2022 at 07:14:23PM +0200, Claudio Jeker wrote:
> > The filemode code is enough different from the regular parser code that it
> > makes sense to totally split it out. Only proc_parse
ct filepath_tree *, char *);
Index: filemode.c
===
RCS file: filemode.c
diff -N filemode.c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ filemode.c 20 Apr 2022 16:47:12 -
@@ -0,0 +1,589 @@
+/* $OpenBSD: parser.c,v 1.70 2022/04/20 10:46:20 job Exp $ */
+/*
+ * Copyright
On Wed, Apr 20, 2022 at 03:00:15PM +0200, Theo Buehler wrote:
> Found this when looking at the timezone issue a couple of weeks back and
> then forgot about it:
>
> This setenv() + localtime() looks like a hack to me and I don't really
> understand why it should be preferable over using gmtime()
On Tue, Apr 19, 2022 at 10:49:44PM +0200, Alexander Bluhm wrote:
> Hi,
>
> I had a look in route timer queues in netinet and netinet6 and found
> some inconsistencies.
>
> - Timeout was a mixture of int, u_int and long. Make timeout
> int with sysctl bounds checking and make absolute time
On Tue, Apr 19, 2022 at 10:04:26PM +0200, Theo Buehler wrote:
> I first wanted to change the %i to a %d, then I noticed that timeout < 1
> can't be true since timeout != 0 and 0 <= timeout <= 24*60*60.
Makes sense. OK claudio@
> Index: main.c
>
On Tue, Apr 19, 2022 at 08:22:53PM +0200, Theo Buehler wrote:
> If the checks involving crlfile fail one way or the other, we'll leak
> crldp. Here's one way to fix it. We could also drop the free(crldp) in
> the body or add a free to the relevant conditional.
I think it would be better to only
On Tue, Apr 19, 2022 at 07:35:35PM +0200, Theo Buehler wrote:
> On Tue, Apr 19, 2022 at 07:24:04PM +0200, Claudio Jeker wrote:
> > I tripped over this and this optimisation hurts more then it helps.
> > So lets just create a new EVP_ENCODE_CTX for every base64_decode()
>
I tripped over this and this optimisation hurts more then it helps.
So lets just create a new EVP_ENCODE_CTX for every base64_decode()
call and cleanup at the end of the call.
--
:wq Claudio
Index: encoding.c
===
RCS file:
On Tue, Apr 19, 2022 at 06:53:28PM +0200, Alexander Bluhm wrote:
> On Tue, Apr 19, 2022 at 08:59:25AM +0200, Claudio Jeker wrote:
> > On Tue, Apr 19, 2022 at 01:44:40AM +0200, Alexander Bluhm wrote:
> > > Hi,
> > >
> > > Can we use a pool for rttimer_queue
On Tue, Apr 19, 2022 at 04:57:27PM +0200, Alexander Bluhm wrote:
> On Tue, Apr 19, 2022 at 08:46:06AM +0200, Claudio Jeker wrote:
> > On Tue, Apr 19, 2022 at 12:07:49AM +0200, Alexander Bluhm wrote:
> > > Hi,
> > >
> > > Instead of using a MP unsafe glob
If parse_filepath() is unable to locate the repository then fail hard.
It makes no sense to limp along in this case because something bigger is
broken and it is better to know about that early.
--
:wq Claudio
Index: parser.c
===
The code uses int for talid so there is no reason to use a size_t for the
talsz (which is the maximum talid). I also switched the type of i in
main.c to int which is used in for loops around talsz but also for NFDS.
Adjust the code in the output functions as well.
--
:wq Claudio
Index: extern.h
On Tue, Apr 19, 2022 at 01:44:40AM +0200, Alexander Bluhm wrote:
> Hi,
>
> Can we use a pool for rttimer_queue_pool?
Another option would be to use static rttimer_queues instead of allocating
them. Not that many timers are used. Requires additional changes in the
sysctl handlers (but that code
On Tue, Apr 19, 2022 at 12:07:49AM +0200, Alexander Bluhm wrote:
> Hi,
>
> Instead of using a MP unsafe global variable, just call rt_timer_init()
> from route_init().
>
> ok?
Wouldn't it be better to move this into rtable_init?
route_init() is called by domaininit() as the last init function
We have released OpenBGPD 7.3, which will be arriving in the
OpenBGPD directory of your local OpenBSD mirror soon.
This release includes the following changes to the previous release:
* Macro expansion in the config file is improved. It is now possible
to expand 'set large-community
Hit this on sparc64. io_read_ulong() calls io_read_int() which already
does the le32toh() call. So skip the 2nd le32toh() call here.
With this openrsync works a lot better.
--
:wq Claudio
Index: io.c
===
RCS file:
On Tue, Apr 12, 2022 at 09:58:21AM +0200, Theo Buehler wrote:
> We can generalize sbgp_sia_location() and reuse it for AIAs and CRLs.
> This makes the checks a bit more stringent, which seems to be fine in
> practice. It also ensures that there are no embedded NULs which came
> up recently. One
On Mon, Apr 11, 2022 at 07:37:51PM +0200, Theo Buehler wrote:
> On Mon, Apr 11, 2022 at 05:11:30PM +, Job Snijders wrote:
> > On Mon, Apr 11, 2022 at 06:46:20PM +0200, Theo Buehler wrote:
> > > Is this base64 blob really useful? The exact same thing is contained in
> > > a more readable
rpki-client starts a few processes and it can do this a bit more elegant
by factoring the common code out into process_start(). This makes the code
in main a fair bit shorter.
I decided to move all pledge calles into the individual processes. In my
opinion there is little benefit in keeping them
On Mon, Apr 11, 2022 at 11:37:11AM +0200, Theo Buehler wrote:
> This should be the last step. It inlines sbgp_sia_resource_entry() into
> sbgp_sia() and dedups the sbgp_sia_resource_{notify,mft,carepo}() using
> a new sbgp_sia_location(). Move the GEN_URI check to sbgp_sia_location()
> since that
On Mon, Apr 11, 2022 at 09:41:05AM +0200, Theo Buehler wrote:
> On Sun, Apr 10, 2022 at 12:40:08PM +0200, Claudio Jeker wrote:
> > This is a lot cleaner and indeed an improvement. I think some of the rc
> > handling can also be simplified. The code in sbgp_sia
On Mon, Mar 21, 2022 at 02:17:21PM +1000, David Gwynne wrote:
> in_pcbselsrc has this:
>
> ifp = if_get(mopts->imo_ifidx);
> if (ifp != NULL) {
> if (ifp->if_rdomain == rtable_l2(rtableid))
> IFP_TO_IA(ifp, ia);
>
On Tue, Apr 05, 2022 at 06:33:35PM +0200, Theo Buehler wrote:
> Instead of manually unpacking the SIA extension with super low-level
> ASN.1 fiddling, we can let the templated ASN.1 in libcrypto do this work
> for us, which makes the code quite a bit simpler. This resolves one
> FIXME and removes
On Mon, Apr 04, 2022 at 08:44:43PM +0200, Theo Buehler wrote:
> p->res->mft and p->res->repo are populated in sbgp_sia_resouce_entry().
> Nothing guarantees that the resources are present. With our current
> strstr() implementation we would let a cert with a missing mft through
> while we would
This was fixed in January. Now RRDP issues an RRDP_CLEAR to the parent
which in turns removes all files from the .rrdp cache dir.
--
:wq Claudio
Index: rrdp.c
===
RCS file: /cvs/src/usr.sbin/rpki-client/rrdp.c,v
retrieving revision
Kill a FIXME and simplify the logic around the process list by using a
static ids array on the stack.
Tested with and without -R.
--
:wq Claudio
Index: rsync.c
===
RCS file: /cvs/src/usr.sbin/rpki-client/rsync.c,v
retrieving
On Mon, Apr 04, 2022 at 01:33:18PM +0200, Theo Buehler wrote:
> We fixed this back in January when we added rtype_from_mftfile().
>
> Index: main.c
> ===
> RCS file: /cvs/src/usr.sbin/rpki-client/main.c,v
> retrieving revision 1.190
This diff alters the way rpki-client cleans up the cache directory.
While with rsync any file can be removed and on the next run it will be
fetched again RRDP has no such logic. It is a very fragile protocol and
only works if files are not removed by something else.
Until now files are just
On Fri, Apr 01, 2022 at 06:52:48PM +0200, Claudio Jeker wrote:
> On Fri, Apr 01, 2022 at 06:31:43PM +0200, Theo Buehler wrote:
> > On Fri, Apr 01, 2022 at 05:01:00PM +0200, Claudio Jeker wrote:
> > > cert_parse_inner() now only uses the ta flag to change behaviour of
> > &g
On Fri, Apr 01, 2022 at 06:31:43PM +0200, Theo Buehler wrote:
> On Fri, Apr 01, 2022 at 05:01:00PM +0200, Claudio Jeker wrote:
> > cert_parse_inner() now only uses the ta flag to change behaviour of
> > loading the various x509 extensions (AKI, SKI, AIA und CRL DP).
> >
cert_parse_inner() now only uses the ta flag to change behaviour of
loading the various x509 extensions (AKI, SKI, AIA und CRL DP).
This diff changes these functions to work always. Make AKI, AIA and CRL DP
optional and have the code calling those functions check if they must have
the extension.
I would like to get rid of the ta flag on cert_parse_inner() and only do
the basic cert parse bits there. Then cert_parse() and ta_parse() do the
other bits.
This moves the easy checks to the right place.
--
:wq Claudio
Index: cert.c
On Wed, Mar 30, 2022 at 03:10:58PM +0200, Theo Buehler wrote:
> On Wed, Mar 30, 2022 at 02:38:54PM +0200, Claudio Jeker wrote:
> > Change the code to use less goto and instead use a while loop.
> > I think the result is easier to understand.
>
> Yes this is clearer and preser
Change the code to use less goto and instead use a while loop.
I think the result is easier to understand.
OK?
--
:wq Claudio
Index: rde_update.c
===
RCS file: /cvs/src/usr.sbin/bgpd/rde_update.c,v
retrieving revision 1.138
diff -u
On Mon, Mar 28, 2022 at 04:38:33PM -0400, Demi Marie Obenour wrote:
> On 3/28/22 10:39, Mark Kettenis wrote:
> >> Date: Mon, 28 Mar 2022 09:51:22 -0400
> >> From: Demi Marie Obenour
> >>
> >> On 3/27/22 21:45, Damien Miller wrote:
> >>> On Fri, 25 Mar 2022, Demi Marie Obenour wrote:
> >>>
>
On Tue, Mar 22, 2022 at 06:35:47PM +0100, Alexander Bluhm wrote:
> On Tue, Mar 22, 2022 at 04:42:45PM +0100, Claudio Jeker wrote:
> > No but you push this layer into a specifc direction and by that make it
> > harder to fix the PCB tables in a different way. I just see peop
On Tue, Mar 22, 2022 at 02:56:43PM +0100, Alexander Bluhm wrote:
> On Tue, Mar 22, 2022 at 02:25:08PM +0100, Claudio Jeker wrote:
> > On Tue, Mar 22, 2022 at 02:09:51PM +0100, Alexander Bluhm wrote:
> > > Hi,
> > >
> > > syzkaller and witness found t
On Tue, Mar 22, 2022 at 02:09:51PM +0100, Alexander Bluhm wrote:
> Hi,
>
> syzkaller and witness found the same bug I introduced in UDP also
> for Raw IP. Fix it the same was for rip and rip6.
>
> https://syzkaller.appspot.com/bug?extid=9bac6356a881dc644265
>
On Tue, Mar 22, 2022 at 11:40:12AM +0100, Theo Buehler wrote:
> On Tue, Mar 22, 2022 at 10:55:48AM +0100, Claudio Jeker wrote:
> > As mentioned I need a TAILQ for the list of prefixes that belong to a rib
> > entry. Mainly because I need TAILQ_PREV. This diff does this replace
As mentioned I need a TAILQ for the list of prefixes that belong to a rib
entry. Mainly because I need TAILQ_PREV. This diff does this replacement.
I did not change the nexhtop LIST of prefixes to a TAILQ. Maybe something
to consider but there is no real need for that.
This is mostly a mechanical
On Tue, Mar 22, 2022 at 02:24:25PM +1000, David Gwynne wrote:
> i couldnt find any good examples of what to do when you wanted to
> receive multiple control messages from a single recvmsg call. the most
> interesting bit is how much space the buffer needs to be.
>
> if i struggled maybe someone
On Mon, Mar 21, 2022 at 05:51:36PM +0100, Theo Buehler wrote:
> On Mon, Mar 21, 2022 at 05:16:53PM +0100, Claudio Jeker wrote:
> > In struct rib_entry bgpd keeps the 'best' or active prefix cached.
> > Now to support more than one one prefix per path (for ECMP and add-path)
> &g
In struct rib_entry bgpd keeps the 'best' or active prefix cached.
Now to support more than one one prefix per path (for ECMP and add-path)
I need the ability to access the previous element. The currently used
LIST macros do not support that. So I want to switch that to TAILQ but
the TAILQ head is
On Mon, Mar 21, 2022 at 01:19:53PM +0100, Theo Buehler wrote:
> On Mon, Mar 21, 2022 at 12:24:33PM +0100, Claudio Jeker wrote:
> > During config reload the RIB may need to be resynced when the
> > 'no evaluate' setting changes.
> >
> > This changes the code to act
During config reload the RIB may need to be resynced when the
'no evaluate' setting changes.
This changes the code to actually flush the Adj-RIB-Out of affected peers
and then adjust the RIB in a 2nd step. That way there is no need to use
rde_generate_updates() to remove the prefixes one by one
On Mon, Mar 21, 2022 at 02:17:21PM +1000, David Gwynne wrote:
> in_pcbselsrc has this:
>
> ifp = if_get(mopts->imo_ifidx);
> if (ifp != NULL) {
> if (ifp->if_rdomain == rtable_l2(rtableid))
> IFP_TO_IA(ifp, ia);
>
This diff just renames F_CTL_ACTIVE and F_PREF_ACTIVE to the more correct
F_CTL_BEST and F_PREF_BEST. The flags are used to mark the one best path.
ACTIVE is not the right term here since with ECMP and add-path more than
one route can be active. I will probably add more flags to mark ECMP
On Thu, Mar 17, 2022 at 02:09:39PM +0100, Mark Kettenis wrote:
> > Date: Thu, 17 Mar 2022 13:24:24 +0100
> > From: Alexander Bluhm
> >
> > On Thu, Mar 17, 2022 at 08:24:10AM +0100, Claudio Jeker wrote:
> > > On Thu, Mar 17, 2022 at 12:47:15AM +0100,
On Thu, Mar 17, 2022 at 12:47:15AM +0100, Alexander Bluhm wrote:
> Hi,
>
> My previous atempt to add a mutex to in_pcb.h was reverted as it
> broke userland build.
>
> Is the correct fix to include sys/mutex.h in every .c file that
> includes netinet/in_pcb.h ? I made a release with it.
> Or
Currently EoR markers use a full byte in struct prefix what can be done in
a bit. Use the last flags field so that that 1 byte is available again.
I already have a need for that byte this is why I came up with this
change.
--
:wq Claudio
? obj
Index: rde.h
This diff just refactors the code by moving the alloc part up.
It makes the code a bit easier to read and more similar with other
prefix_adjout functions. Also I plan to pass the struct prefix in
as an argument and do the prefix_adjout_get() in the callee.
--
:wq Claudio
Index: rde_rib.c
On Thu, Mar 10, 2022 at 05:54:21PM +0100, Theo Buehler wrote:
> On Thu, Mar 10, 2022 at 05:51:46PM +0100, Claudio Jeker wrote:
> > On Thu, Mar 10, 2022 at 05:33:28PM +0100, Martin Vahlensieck wrote:
> > > Hi
> > >
> > > This pulls up and adjusts the c
On Thu, Mar 10, 2022 at 05:33:28PM +0100, Martin Vahlensieck wrote:
> Hi
>
> This pulls up and adjusts the check if i exceeds the bounds of pfds.
> Before it was technically wrong, as i > NPFDS means that the last
> write (i == NPFDS) was already out of bounds.
I see no reason to pull up the
On Tue, Mar 08, 2022 at 07:17:33PM +0100, Stefan Sperling wrote:
> On Tue, Mar 08, 2022 at 03:55:48PM +0100, Stefan Sperling wrote:
> > On Mon, Mar 07, 2022 at 03:04:06PM -0700, Theo de Raadt wrote:
> > > > For now, the structs are identical so the code copying data out is
> > > > kept simple.
> >
bgpd's parse.y uses a lot of STRING that is then further bisected in the
actual rule. One good example are all communities. Now if someone wants to
use macros in such arguments they do not work in all cases. e.g.
large-community $someas:1:2 works but large-community 1:$someas:2 does
not.
Right
On Tue, Mar 08, 2022 at 01:33:01PM +0100, Theo Buehler wrote:
> If the length checks trigger, roa is leaked. It makes more sense to me
> to copy the data into ip4 and ip6, check lengths and then calloc rather
> than the current order, so I moved the calloc down a bit. Alternatively,
> we could
Another day another cleanup.
This diff moves rde_send_kroute() out of rde_generate_update() and back
into prefix_evaluate(). rde_generate_update() should only track the RIBs.
rde_generate_update() is mainly called from prefix_evaluate().
The only other caller is in rde_softreconfig_sync_reeval()
struct kroute_full is the external representation of kroutes.
It includes the routing label as a string. For some reason there was also
a labelid field but that one is not used and needed, the labelid is an
internal id that has no value for any other process.
Just remove the field and the two
1 - 100 of 1703 matches
Mail list logo