Re-implemented PROTOCTL SERVERS= which nenolod ripped out (#4355).
Add 2nd argument to PROTOCTL EAUTH=servername,unrealprotocol
Change UnrealProtocol from 2350 to 2351
Added swhois_add / swhois_delete functions which also take care of broadcasting
New remove_oper_privileges() function, will move the rest to use this (svsnoop svsmode etc)
Not finished yet...
easily deal with "parameter eating" of unknown channel modes.
Now, 12 years later, finally added the code to do this.
This prevents some (serious) desynching if you have a parameter-eating
channel mode on one server and not on the other.
Obviously, you should always try to have the same featureset on all
servers, but sometimes this is not possible, like when upgrading..
* add general matching framework (aMatch type, unreal_match_xxx functions)
* change spamfilter { } block syntax
* add support for simple wildcard matching (non-regex, just '?' and '*')
This is the initial commit so the new lib is not in yet, 'regex' is not
functional (but 'posix' and 'simple' are working), linking has not been
fully tested and no warnings are printed yet. IOTW: work in progress!
This allows the IRCd to enforce MLOCKs that are set by services, which
eliminates clashes between users setting modes and services enforcing
it's mlock on channels. (#3055)
- IPv6: it seems some recent Linux dists decided to make IPv6 sockets
IPv6-only, instead of accepting both IPv4&IPv6 on them like until now.
FreeBSD (and other *BSD's) already did that move a few years back,
requiring server admins to sysctl.
We now make use of a new option to explicitly disable "IPv6-only".
This should work fine on Linux.
Whether it provides a complete solution for FreeBSD, I don't know, testing
is welcome! In theory setting net.inet6.ip6.v6only to 0 should no longer
be needed, but you might still need to enable ipv6_ipv4mapping.
- Fix stupid issue where current CVS would no longer link TO an earlier
Unreal server (eg: outgoing connect to a 3.2.8 hub). Reported by ohnobinki
(#0003901).
it to 'no', the default is 'yes' (on). Requested by Robin (#0003885) as
UHNAMES may increase the time of the nick list being loaded from 1 to 4
seconds when joining several channels with more than 1000 users. As this
problem is only present on some networks, we keep UHNAMES enabled by
default.
- Server protocol: added PROTOCTL EATH=servername, which allows us to
authenticate the server very early in the handshake process. That way,
certain commands and PROTOCTL tokens can 'trust' the server.
See doc/technical/protoctl.txt for details.
- Server protocol: between new Unreal servers we now do the handshake a
little bit different, so it waits with sending the SERVER command until
the first PROTOCTL is received. Needed for next.
- Server protocol: added PROTOCTL SERVERS=1,2,3,4,etc by which a server can
inform the other server which servers (server numeric, actually) it has
linked. See doc/technical/protoctl.txt and next for details.
- When our server was trying to link to some server, and at the same time
another server was also trying to link with us, this would lead to a
server collision: the server would link (twice) ok at first, but then a
second later or so both would quit with 'Server Exists' with quite some
mess as a result. This isn't unique to Unreal, btw.
This happened more often when you had a low connfreq in your link blocks
(aka: quick reconnects), or had multiple hubs on autoconnect (with same
connfreq), or when you (re)started all servers at the same time.
This should now be solved by a new server handshake design, which detects
this race condition and solves it by closing one of the two (or more)
connections to avoid the issue.
This also means that it should now be safe to have multiple hubs with low
connfreq's (eg: 10s) without risking that your network falls apart.
This new server handshake (protocol updates, etc) was actually quite some
work, especially for something that only happened sporadically. I felt it
was needed though, because (re)linking stability is extremely important.
This new feature/design/fix requires extensive testing.
This feature can be disabled by: set { new-linking-protocol 0; };
- When checking if a user is banned, we always check the cloakhost too. Previously we could
not do this if the user had a /VHOST (=a minority of the cases, but still...). In short,
this is some extra protection to combat ban evasion.
- Performance of is_banned() *slightly* improved (just 1-2 usec, but 7 usec if no bans).
- [Module coders] For extban routines, we now offer a routine extban_is_banned_helper(buf)
which can be used instead of the ban_realhost/etc static chars stuff, see
extban_modeq_is_banned for a (real-life) example of how this is used.
- [Services coders!] Added PROTOCTL CLK (requires NICKv2) which adds an extra field in the
NICK command (when a user connects) right before the infofield (gecos).
The added field contains the cloaked host, that is: the masked host if +x would have been
set. This field is ALWAYS sent, regardless of whether the user is actually +x or not.
Services can then store this field in memory, to know the host of the user if the user
is set +x (+x-t). This is a (better) alternative to PROTOCTL VHP, with no race conditions,
and avoids some other VHP problems.
VHP will stay supported though... so it's not mandatory to switch over.
- Modulized NAMES command (can now be upgraded on the fly, if ever needed).
- Added NAMESX support, seeing both mIRC (5.17) and XChat support this. What this does is
send all rights of all users on the channel in the NAMES reply (eg: @+Syzop if the user is +ov)
instead of only the highest one (@Syzop in previous example). We only do so if the client
explicitly requested this via a NAMESX in a PROTOCTL message (eg: 'PROTOCTL NAMESX').
Note that there is a glitch: since most clients only send the PROTOCTL NAMESX after they
see NAMESX listed in the 005 announce message this has the effect that if there are
set::auto-join channels present (where users are automatically joined to by the server) the
extended NAMES reply will not be sent for those channels, because from the IRC server' point
of view the join happened before the PROTOCTL and hence it does not know the client wanted
NAMESX at that point (the result is not catastrophic: the old-style NAMES is sent for those
channels). Anyway, for all non-autojoin channels this works great. So still worth adding IMO.
Originally suggested in #0000606.
Side note: this does not mean we dropped the idea of (also) having a challenge-response
system for good ;).
If 2 servers try to link and the allowed nick characters do not fully match, then
the link will be rejected. Note that this will not prevent you from 3.2.2<->3.2.3/CVS
charsets mistakes, but only with linking CVS/3.2.3+ servers. Suggested by Troco (#0002360)
This might need some additional testing, but initial results are positive :).
- Fixed a few wrong macro's (ircstrdup/ircfree) in s_conf.c causing
very weird behavior... This also fixes a bug where set::spamfilter::ban-reason
would have the value of ban-time.
- Improved spamfilter again.
- The new syntax is:
/spamfilter [what] [type] [action] [tkltime] [reason] [regex]
[tkltime] specifies the duration of any *lines placed by this rule.
[reason] specifies the *line, kill and/or block reason.. no spaces
allowed, but '_' will be escaped to a space.
In both cases you can simply use '-' to skip and use the default.
Ex: /spamfilter add p block - - Come watch me on my webcam
/spamfilter add p gline 3h Please_go_to_www.viruscan.xx/
nicepage/virus=blah Come watch me on my webcam
- A message is now shown if the msg/notice/dcc is blocked.
- There are 2 new spamfilter action types:
'dccblock' will mark the user so (s)he's unable to send any files by DCC.
'viruschan' will part the user from all channels and join
set::spamfilter::virus-help-channel (default: #help).
this action might be improved to do more later.
- Internal: added EXTTKL PROTOCTL, this determinates if 10 parameters
instead of 8 are supported for m_tkl (used by spamfilter add).
This new system needs some testing... :)
Bram Matthys