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.
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) ...
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!
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 15fec92ed7
(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!
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.
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.
Alexander Barton