Due to [1], linking with SCTP sometimes does not multi-home correctly.
This is triggered by the rand() on the lines immediately above these.
The connect{} blocks already support an `aftype` parameter to instruct
IRCd to prefer IPv4 or IPv6. This commit additionally ensures that the
other structure is always populated with the other address (if any) if
this parameter is specified.
This will allow SCTP server-linking users to work around the bug and
ensure that it always multi-homes by setting `connect::aftype` to IPv4.
Without this commit, that would cause Solanum to not include the IPv6
addresses (if any) in the connect block in its SCTP setup.
If there isn't a valid IP address in the other sockaddr, this should be
of no consequence, because it will not be used by rb_connect_tcp(), and
both rb_connect_sctp() and rb_sctp_bindx_only() already verify that
there is a valid IP address in the sockaddr before making use of it.
[1] https://marc.info/?l=linux-sctp&m=165684809726472&w=2
the logic for trying to detect the maximum value of time_t was broken;
since we target a lower maximum time anyway, just use that for the
overflow check
While working on reproducible builds for openSUSE, I found that
our package varied even when building in clean VMs
with as little non-determinism as possible.
This was because of
+++ solanum-0~ch560/ircd/version.c.last
@@ -25,7 +25,7 @@
#include "serno.h"
#include "stdinc.h"
-const char *generation = "6";
+const char *generation = "5";
const char *creation = "1653004800";
const char *ircd_version = PATCHLEVEL;
const char *serno = SERNO;
I think this was always pretty questionable. You can set redundant bans
in various ways anyway, and preventing all of them would only make the
situation worse, as wide temporary bans would destroy narrow permanent
ones, for example.
Also, ignore a connect block that requests certfp authentication
without setting the ssl flag, as it will then go on to fail anyway.
Finally, correct an erroneous error message about class blocks.
This was introduced in commit bde6442c47 but the rationale for it is
pretty shaky. No other non-Charybdis-derived servers send it and the
features the original commit claims it can be used to detect all have
their own methods of detection. The concept of "core capabilities" and
versioned releases was also dropped by IRCv3 many years ago in favour
of living specifications.
