| Age | Commit message (Collapse) | Author |
|---|
|
This prototype has been introduced by commit fa7bb279 in 2006,
but as far as I can see, this function never existed ...
|
|
- Check correct list for duplicates when adding items.
- Don't generate any messages when adding duplicates or removing
non-existing items (this is how ircd-seven and ircu behave).
- Code cleanup: Add_Ban_Invite(), Del_Ban_Invite().
|
|
|
|
Commit 565523cb allowed processing of further channel names given to the
JOIN command when a single name was invalid.
After this patch, the JOIN command handler continues to process channel
name lists even after errors like "channel is full", "too many channels",
and the like and generates appropriate error messages for all the
channels given by the client.
|
|
Don't check the channel limit and don't report "too many channels"
when trying to join a channel that the client is already a member of.
|
|
The daemon reported ERR_UMODEUNKNOWNFLAG(501), which is wrong.
|
|
|
|
Introduce new #define's MAX_RPL_LIST(100), MAX_RPL_WHO(25),
MAX_RPL_WHOIS(10), and MAX_RPL_WHOWAS(25).
|
|
It the limit is reached, a NOTICE is sent to the client and list
processing should stop.
|
|
|
|
|
|
To streamline naming, in preparation for MAX_RPL_WHO and MAX_RPL_WHOWAS :-)
|
|
|
|
"Maximum number of channel modes with parameter allowed per MODE command."
See <http://www.irc.org/tech_docs/005.html> for details.
|
|
This fixes 98493077.
|
|
Limit the MODE command to handle a maximum of MAX_CMODES_ARG (5) channel
modes that require an argument (+Ibkl) per call.
Please note: Further modes that require arguments are silently ignored
and end the handling of any further modes.
This is similar to the behavior of ircd2.11 (silently ignores but seems
to handle other modes) as well as ircd-seven (silently ignores but handles
some(!) other modes) ...
|
|
For example, don't generate wrong error messages when handling
"MODE #chan +IIIIItn *!aa@b *!bb@c *!cc@d *!dd@e *!ee@f".
|
|
The assert(client != NULL) got triggered during our tests, so there is
an error path that resulted in the connection being still established
(sock >= 0) but the client structure already freed.
So Conn_Write() should handle it!
|
|
It could be invalid when calling Proc_Close() a 2nd time, for exmaple,
which could happen when we hit a timeout doing IDENT requests :-(
|
|
And make sure that RPL_ENDOFWHOIS replies with the unmodified mask
like it has been received from the client.
|
|
Thanks to Cahata for spotting this!
|
|
Up to now, each reply for itself ended in RPL_ENDOFWHOIS and queries
for unknown nick names lacked the RPL_ENDOFWHOIS -- both is wrong.
|
|
The <mask> can be used to limit the servers shown in the listing.
|
|
|
|
This reduces the possibility of flooding channels with commands like
"PRIVMSG/NOTICE #a,#n,#c,... :message" a little bit.
Problem noticed by Cahata -- thanks!
|
|
Until now, the penalty time has only been set when longer as the
already set one, so it didn't accumulate.
And add documentation for and clean up code in Conn_SetPenalty() and
Conn_ResetPenalty() functions.
|
|
|
|
|
|
This partly closes bug #118. ngIRCd still starts up even when
Server{UID|GID} is invalid: then the daemon falls back to "nobody"
when running with root(0) privileges (as before).
|
|
|
|
|
|
|
|
commit 15fec92ed75c3de0b32c40d005e93e3f61aef77e
(Update list item, if it already exists) can make ngircd
crash because 'Reason' can be NULL, as reported by
Cahata on the ngircd mailing list.
Doesn't affect any released ngircd versions.
Also, make sure that we do not pass NULL as arguments
to a '%s' printf-like function.
|
|
When JOIN is received with more than one channel name, don't stop
processing on the first error (e.g. bad name, wrong channel key, ...)
but report an error and continue with the other given channel names.
Reported by Cahata -- thanks!
|
|
|
|
Reported by Cahata -- thanks!
|
|
|
|
This fixes:
irc-info.c: In function ‘IRC_WHO’:
irc-info:936:18: warning: variable ‘have_arg’ set but not used
|
|
When "PAMIsOptional" is set, clients not sending a password are still
allowed to connect: they won't become "identified" and keep the "~"
character prepended to their supplied user name.
|
|
Use the pointer of the password of the client directly.
Eventually we can get rid of the global password again ...
|
|
This fixes two bugs:
- "WHO <nick>" returned nothing at all if the user was "+i"
(reported by Cahata, thanks).
- "WHO <nick|nickmask>" returned channel names instead of "*"
when the user was member of a (visible) channel.
Clean up code and add documentation as well.
|
|
This fixes:
lists.c: In function ‘Lists_Check’:
lists.c:330:9: warning: variable ‘now’ set but not used
|
|
Thanks to Christoph Biedl!
|
|
Thanks to Christoph Biedl!
|
|
Rename Channel_Count() to Channel_CountVisible() and only count channels
that are visible to the requesting client, so the existence of secret
channels is no longer revealed by using LUSERS.
Reported by Cahata -- thanks!
|
|
|
|
Unknown user and channel modes no longer stop the mode parser, but are
simply ignored. Therefore modes after the unknown one are now handled.
This is how ircd2.10/ircd2.11/ircd-seven behave, at least.
Reported by Cahata -- thanks!
|
|
This fixes:
irc-oper.c: In function ‘IRC_xLINE’:
irc-oper.c:429: warning: ‘class’ may be used uninitialized in this function
irc-oper.c:430: warning: ‘class_c’ may be used uninitialized in this function
|
|
This updates the "validity" (timeout) as well as the "reason" text,
if given.
|
|
The old behavior of returning true/false is compatible to this change,
so there are no other code changes required.
|