Call the efunction from 005 introduction as well, so it uses the
batch, if needed. And yeah we opt to send the 005's always, even
if it was already sent in the handshake (or not).
Some re-indenting (spaces to tabs).
And call the efunction from VERSION as well.
For "VERSION remote.server" we don't send them in a batch as these
are not numeric 005 but 105. These are for information purposes only
and should not confuse the client (eg not to act upon).
The set_usermode() result is not used, so useless.
The if (themotd) motdline = ... makes no sense since themotd is
already dereferenced in the code above it (eg: themotd->last_modified.tm_year)
and consequently the motdline = NULL becomes useless too.
And this is easily mistaken with "REHASH -global" which rehashes all
the IRC servers on the network.
In fact, who knows some year(s) from now we may map "REHASH -all"
to "REHASH -global", but... not yet...
`PROTOCTL BIGLINES` is set. This will allow us to do things more
efficiently and possibly raise some other limits in the future.
This 16k is the size of the complete line, including sender,
message tags, content and \r\n. Also, in server-to-server traffic
we now allow 30 parameters (MAXPARA*2).
The original input size limits for non-servers remain the same: the
complete line can be 4k+512, with the non-mtag portion limit set
at 512 bytes (including \r\n), and MAXPARA is still 15 as well.
* I chose 16k because I don't want to first raise it to like 8k
and then realize later that 16k would be better and raise it again.
* To receive BIGLINES in a command, you need to `CommandAdd()` with
flags `CMD_BIGLINES`, without it you still get regular 512 max.
This is so, because a lot of the code does not expect longer than
512 bytes lines or in parameters, so we can gradually change that
(where needed).
due to flood attacks, back then we changed the argument silently to
point to our own server, eg 'INFO some.remote.server' ended up being
'INFO' (local server) when requested by non-IRCOps.
Now, we simply return "Permission denied" in such cases, which is
more clear and explicit.
Reported by progval in https://bugs.unrealircd.org/view.php?id=6004
is 2.13 or newer, as this requires jansson_version_str().
And no, we don't use macro's (eg JANSSON_MAJOR_VERSION). We never do that for
any of the displayed library versions (OpenSSL, libsodium, c-ares, curl, etc)
as macro's only reflect the compile-time library version and not runtime,
and thus are misleading... which can be especially problematic in case of a
security issue. So good that jansson added this function.
What is a SVSMOTD? The SVSMOTD are MOTD lines that are shown at the end of
an existing MOTD. These lines are added remotely through services.
Previously the SVSMOTD lines were never shown in the MOTD-on-connect, which
was a bug. We were only supposed to hide it if a short motd is in use.
Reported by Valware in https://bugs.unrealircd.org/view.php?id=6070
not a format string (eg ":%s LUSERS %s"). It now simply concats all parv[]'s.
That is, up to parc count. And it automatically does the :stuff for the
last parameter if it contains spaces or starts with a : etc.
This gets rid of a bit sketchy code with an arbitrary maximum etc.
Now it's just:
if (hunt_server(client, NULL, "REHASH", 1, parc, parv) != HUNTED_ISME)
return;
This has one side effect, though:
Previously we used the format string, so it may be possible for S2S
traffic to now have more arguments then before here and there.
Eg:
* It could be that the caller was using a format string to
intentionally cut off an extra parameter at the end.
You can still do that if you call with eg parc-1 instead of parc.
I don't think there were any such cases though, but hard to rule out.
* Extranous parameters may show up in S2S traffic where it was
previously unexpected.
This already found a few issues.
As a side-effect, this also means you can only use RPL_xxx and
ERR_xxx in the 2nd argument from now on. You can no longer use
a dynamic integer (eg 'reply') at runtime, since then the format
string cannot be checked.
More to follow, after making sure it works on Windows too.
It means you can no longer modify eg parv[1] in-place with strtoken and such.
The main reason for this is that as a command handler you have no idea
where the arguments may come from. It could be from a do_cmd() with
read-only storage (eg a string literal) and so on.
It started with an experiment of how far I could get and how annoying the
side-effects would be, but they seem to be quite managable, so I'm
committing this stuff.
Hopefully this catches/solves some stupid bugs somewhere :)
as it REQUESTS to rehash the server, but it may not be done immediately.
And making it void makes sure nobody relies on some sort of return
value which will differ between with vs without remote includes.
Also get rid of sig and loop.rehash_save_sig, as a NULL client
already indicates the same (or at least does so now).
If you don't indicate NEXTBANS support then we will send old fashioned
extended bans to you.
Note that eventually we will likely require named extended bans support,
but that will be UnrealIRCd 7 / 8.... ;)
IP address in the message. We now use ip:port from the link block
if we failed to connect, and otherwise we use the ip from the
connection if the connection is established (also because it
can be a remote connection, not linked directly to us)
just like client->user is set if the client is a user.
Rename client->srvptr to client->uplink: this is the uplink that the client
is connected to. If the client is a user then it is set to the server that
the client is connected to, if the client is a server then it is set to the
server that the server is connected to (the.. tadah.. uplink).
For local clients it is always set to &me.
for fake lag calculations only (well, except for 1 corner case).
As said, modules should use the new function:
void add_fake_lag(Client *client, long msec)
Bram Matthys