This is correctly handled by ipaddr/ng_ipaddr.h today, and the check
in tool.h isn't required any more -- and caused errors on OpenBSD 5.0:
In file included from ./../tool/tool.h:23:
/usr/include/arpa/inet.h:74:
warning: "struct in_addr" declared inside parameter list
This flag indicates, that the server supports the enhanced "xop channel
user modes", like channel owner, admin, and halfop. This information is
used to make sure that no unsupported CHANINFO commands are sent to
servers not supporting such mode prefixes, for example.
Starting with Anope 1.9.8, the ngIRCd protocol module is included in the
Anope distribution, so there's no longer any need to support our own (but
now heavily outdated!) patches. Therefore remove them.
Starting with Anope 1.9.8, the ngIRCd protocol module is rewritten from
scratch by "DukePyrolator" and included in the Anope distribution. So no
patching is required any more, yeah!
Drawback: Anope 1.9.8 is in development and not yet released ...
Use "METADATA host" commands to let servers supporting this command
know which (possibly cloaked) hostname is in effect for a specific
client. This prevents "double cloaking" of hostnames and even cloaked
hostnames are in sync on all servers supporting "METADATA" now.
A client for which a METADATA command has been received from one of
its peers got the client flag "M" set. So it's safe to assume that
such a client gets "METADATA host" commands for its cloaked hostname
and the server must not cloak the hostname on its own, even when the
client mode "+x" is set.
The METADATA command can be used by other servers to update "metadata"
of registered clients, like the client info text ("real name"), user
name, and hostname:
:<prefix> METADATA <target> <key> :<value>
It is distributed in the network, unknown <key> names are silently ignored
and passed on, too. This allows for further extensions.
If PredefChannelsOnly is enabled, and if someone tries to create
a channel which does not exist, then the error message is a 474.
The 474 Error message changed recently and does not match anymore:
'Cannot join channel (+b) -- You are banned'.
Changed the error message to numeric 403 'No such channel'.
Bug introduced by commit 9a82304a.
(cherry picked from commit 2c2e08f34187a33c1da745995c5f213e33a91410)
Now NICK commands are always generated using the prefix of the target
user, even when the nickname change has been initiated by some other
(pseudo) server or using the SVSNICK command. In this case, the prefix
of the initiator has been used, but this isn't compatible with clients
(at least weechat and irssi don't handle such NICK commands correctly).
The SVSNICK command allows other servers (and services on
"pseudo-servers") to forcefully change nicknames of remote users.
Syntax: ":<from> SVSNICK <oldnick> <newnick>"
The SVSNICK command itself doesn't change the nickname, but it becomes
forwarded to the server to which the user is connected to. And then this
server initiates the real nickname changing using regular NICK commands.
This allows to still run networks with old servers not supporting the
SVSNICK command, because SVSNICK commands for nicknames on such servers
are silently ignored and don't cause a desync of the network.
This reverts a not intentional code change and fixes the following compiler
warning message (tested with gcc 4.4.5):
irc-server.c: In function "IRC_SERVER":
irc-server.c:142: warning: suggest parentheses around operand of "!"
or change "&" to "&&" or "!" to "~"
Add randomly up to 15 seconds to the reconnect delay for outgoing server
links when the connection has been "short" and therefore the "ConnectRetry"
delay is being enforced.
This should make it even more unlikely that two servers deadlock each
other when both are trying to connect to the other one at the same time,
for example in test environments.
If two servers try to link each other, there was a time frame that
could result in one connection overwriting the other, e. g. the incoming
connection overwriting the status of the outgoing one. And this could
lead to all kind of weirdness (even crashes!) later on.
So now such incoming connections are dropped. But this most probably
prevents the two servers from linking until timing changes somehow
(network latency?) because each server drops the incoming connection of
the other one, so no connection survives in the end.
But this has to be addressed by an other patch ...
This is how ngIRCd up to release 19.2 behaved; "bug" introduced by commit
67e882, "configure.in: require autoconf 2.67 and automake 1.11", which
changed the "PACKAGE_NAME" to "ngIRCd"; so use "PACKAGE" which still is
the lowercase version for initializing syslog logging.
Remote servers are always allowed to change all channel topics,
and IRC Operators are allowed to change all channel topics if the
configuration option "OperCanUseMode" is enabled.
Bug introduced by commit 7b01bb8 and reported by DNS777.
Currntly ngIRCd supports 13 user and 15 channel modes, because there
have been quite a few additions since our last release. But our data
structures can only hold 15 user and -- even worse! -- only 9 channel
modes! So enlarge the buffers to 20 bytes (actually 21 including NULL)
to allow storing of all mode characters and to have some space left
for more modes to come ...
(cherry picked from commit 8996d777621d88d4bcc439ab4792b2814920687f)
Replaced error message for channel mode +M with ERR_NEEDREGGEDNICK_MSG
(used by Bahamut, inspircd, ircu & Unreal too) and using numeric 477
and the msg simliar like inspircd.
Replaced the error message ERR_CANNOTSENDTONICK_MSG for user mode +b
with ERR_NONONREG_MSG and using numeric 486, similar like unrealircd.
(cherry picked from commit 55a61ab17f63a9e757b7c7598c31b98ce5a132e8
and commit 3737d9ab7da1ea0485cefc07c65dc5308bf0db02)
Don't abort on "single user operating systems" that don't know more than
one user account and therefore can't change user and group IDs.
Currently, the only such system supported by ngIRCd is Haiku, a BeOS
clone.
When a user has set mode "b", all private messages and notices to this
user are blocked if they don't originate from a registered user, an IRC Op,
server or service. The originator gets an error numeric sent back in this
case, ERR_CANNOTSENDTONICK_MSG(976), which is/was(?) used by KineIRCd, too.
This closes bug #144.
This error message is not only used if one can not send to a channel
because it is moderated, but for _all_ reasons when a message can not
be delivered (moderated, banned, no external messages, ...), so strip
the "(+m) -- Moderated" part of the error message again.
Bug introduced by commit 9a82304a.
Not only show RPL_WHOISHOST_MSG to local IRC opreators, but show
it to all IRC operators in the network. And don't show it to anybody
if the "more privacy" configuration option is enabled.
This closes bug #134.
Implement numeric RPL_WHOISMODES_MSG(379) and show user modes in the
reply of the WHOIS command for the user himself or, if MorePrivacy
isn't set, for request initiated by an IRC operator.
Numeric 379 is used by Unreal and InspIRCd for this purpose, too.
Closes bug #129.
If the new channel mode "V" is set, the INVITE command becomes invalid
and all clients get the new ERR_NOINVITE_MSG(518) reply.
Unreal and InspIRCd uses this mode, too.
This closes bug #143.
