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;
This header defines the TCP_NODELAY flag, which this compilation
unit uses.
Other C libraries implicitly include this header from some other
header we are using (I have not investigated which), but musl's
system headers do not, which breaks building on musl.
Reported-by: 0x5c <dev@0x5c.io>
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.
Loose port of 6ea60b2297948211925e22bd1f284179d680b4ae. I've chosen to
reduce indentation where it's convenient, and I'm allowing >-[0-9] as a
way of specifying a minimum of 0 because... I don't know, it just seems
neater to me.
* and ? are valid characters for channel names on IRC, and ELIST M gives
no way to distinguish between `LIST #foo-*` that's meant to search for
channels beginning `#foo-` and `LIST #foo-*` that's meant to list one
channel named literally `#foo-*`.
In order to deal with this, we will always assume a name with wildcards
is a mask. If it's also a channel name, that will be listed first.
