Some code to append "domain" from /etc/resolv.conf to unqualified names (for
server connections) erroneously applied to names from reverse DNS lookups as
well.
The effect was that "domain" from /etc/resolv.conf was appended to
"localhost", even though the DNS server intended "localhost" to be a fully
qualified name.
This fixes a compiler warning. The necessary fields of the struct sigevent
were initialized so there was no problem.
Submitted by: Aaron (via IRC)
Reviewed by: Attila
The last byte of balloc.c's block pointer could be changed from 10 or 13 to
0. On amd64, this is not possible. On i386, this is possible and usually
causes a crash soon.
Hybrid 6 is old enough that the conversion tools can go away now.
They are for I and K lines; the ircd.conf converter was already removed.
This removes compiler/analyzer warnings about these tools.
When bandb sends the ban list, it first sends 'C', then all bans and
finally 'F'. Only when 'F' is sent is ircd supposed to apply the bans.
Because of a missing break, 'C' also did 'F', clearing the ircd active
permanent bans until bandb sent 'F'.
The effect is pretty limited because having bandb send the ban list via
/rehash bans is uncommon and most bans will be enforced when reset.
This check was erroneously removed when fixing /mode #channel f when +f is
mlocked. Mlock checks were restricted to the places requiring chanops
(other than viewing +eI lists); cmode +L/+P do not require chanops, but
still constitute a mode change that must be checked against mlock.
When receiving bans from a bursting server, if kline_delay is set to 0
(the default), rb_event_addonce will be called to schedule an event for
0 seconds in the future. While this works fine for the fallback
rb_event_run function, the epoll implementation ends up scheduling a
timerfd for the event in the past, which is then never executed.
While fixing this, I also made rb_event_add and rb_event_addonce reject
attempts to add events scheduled for 0 seconds in the future; they're
instead rewritten to run 1 second in the future.
After a change for dynamic server capabilities, the code to send out mode
changes was changed to use the capabilities belonging to the last mode
being sent out. This does not make sense; therefore, just use no
capabilities and remove supporting infrastructure.
The code to send each channel mode only to servers supporting it was
broken a while ago and was not very useful anyway. Therefore, require
all connecting servers to support all standard channel modes.
