ngircd/src, branch rel-26.1ngircd with make
http://git.nakidai.ru/ngircd/atom?h=rel-26.12021-01-01T14:38:26+00:002021! :-)2021-01-01T14:38:26+00:00Alexander Bartonalex@barton.de2021-01-01T14:38:26+00:00urn:sha1:2ff76d7f480b87e811af81cf9eaa9822b77863c4
Happy new year!
Explicitely cast Conf_MaxPenaltyTime (time_t) to "long"2020-12-29T20:45:09+00:00Alexander Bartonalex@barton.de2020-12-29T20:45:09+00:00urn:sha1:f3c89af845ede2dd2e1ccc5e9f1bfdc036409b88
This fixes the following compiler warning, for example on OpenBSD:
conf.c: In function 'Conf_Test':
conf.c:391: warning: format '%ld' expects type 'long int', but argument
2 has type 'time_t'
Thanks to Götz Hoffart for reporting this!
Don't set AI_ADDRCONFIG, even when it exists2020-12-29T20:12:43+00:00Alexander Bartonalex@barton.de2020-12-29T20:12:43+00:00urn:sha1:d777ce6600825208cca21b97fd3ab55385de3424
Basically, the issue described in #281 is that the test suite uses the
IPv4 address 127.0.0.1 on an IPv6-only host. But this is the "safest"
thing to do in (almost) all other setups: relaying on DNS host names
makes things even more complex, as different systems map 127.0.0.1
differently (including the reverse lookup; that's why we switched to
127.0.0.1 back in 2014, see commit 3f807e10457).
But with AI_ADDRCONFIG set, on an IPv6-only host, we prevent 127.0.0.1
to get translated properly, even when the loopback interface has this
address configured! So don't set it any more.
The drawback is that the resolver possibly returns more addresses now,
even of an unsupported/not connected address family; but this shouldn't
do much harm in practice, as ngIRCd iterates over all returned addresses
while trying to establish an outgoing connection.
Closes #281.
Fix typo in comment: operaor -> operator2020-11-02T11:13:02+00:00Rolf Eike Beereike@sf-mail.de2020-11-01T17:00:22+00:00urn:sha1:c7781cf7eff5e199fce2b4a7babad0b59d7b315eRevert "Show allowed channel types in ISUPPORT(005) numeric only"2020-11-02T10:45:41+00:00Alexander Bartonalex@barton.de2020-11-02T10:45:41+00:00urn:sha1:2056de82ae47a9128e857bb32313f9106b1c3f0f
The ISUPPORT(005) numeric lists only channel prefixes which are listed
in the "AllowedChannelTypes" configuration option. And if this is the
empty string ("") for example, this now results in IRC clients assuming
"oh, no channel prefix characters at all, so no channels at all, so no
PRIVMSG can go to any channel" -- which is not the case when there are
pre-defined channel set up or other servers still having channels!
So "allowed channel types" != "supported channel types", and we always
have to list all supported ones in the ISUPPORT(005) numeric!
This reverts commit 4b7e8db418340576c95f1edad8470b66d6fe886d.
Closes #285.
Test suite: Wait 2 seconds after reloading the daemon2020-11-01T16:25:39+00:00Alexander Bartonalex@barton.de2020-11-01T16:25:39+00:00urn:sha1:5cf0eabd841b644eef8022dad97fa96aa3661c6a
On reload, all listening ports are closed, configuration updated, and
then opened again. Which leads to subsequent tests running while the
daemon isn't listening on any ports, and that's why the tests fail.
The "proper" way whould be to loop and check for open ports, but waiting
is what the start-server.sh script does right now, so stick with this in
reload-server.sh for now as well.
This fixes the issue, at least on my RaspberryPi ...
Closes #280.
Don't send invalid CHANINFO commands when no key is set2020-06-11T14:45:30+00:00Alexander Bartonalex@barton.de2020-06-11T14:45:30+00:00urn:sha1:07cb8ed9ae14307b7b9335faa957baa340632e57
It can happen that a channel is +k, but no key is set: for example by
misconfiguring a pre-defined channel. In this case, ngIRCd sent an
invalud CHANINFO command ("CHANINFO #test +Pk 0 :'", note the unset
key represented by the two spaces) to its peers.
Fix this and enhance the CHANINFO documentation.
IRC_SQUIT(): Fix use-after-free when unregistering the sending client2020-05-25T22:05:22+00:00Alexander Bartonalex@barton.de2020-05-25T22:05:22+00:00urn:sha1:d697de31862bc659461498bb5169e7a9bdd525b2IRC_SERVER: Make sure that the client sent a prefix2020-05-25T21:51:00+00:00Alexander Bartonalex@barton.de2020-05-25T21:43:29+00:00urn:sha1:02cf31c0e267a4c9a7656d43ad3ad4eeb37fc9c5
The SERVER command is only valid with a prefix when received from other
servers, so make sure that there is one and disconnect the peer if not
(instead of crashing ...).
This obsoletes PR #275.
Thanks Hilko Bengen (hillu) for finding & reporting this as well for the
patch & pull request! But I think this is the "more correct" fix.
Enhance debug logging for PONG commands2020-05-25T21:30:07+00:00Alexander Bartonalex@barton.de2020-05-25T21:30:07+00:00urn:sha1:430bb223765281487e5c6d415a8efb91e2bf3320
Distinguish between expected and unexpected PONG commands.