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!
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 3f807e1045).
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.
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 4b7e8db418.
Closes#285.
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.
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.
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.
Prior to this commit, the PONG wasn't registered correctly, becauuse the
"last ping" time was set to time(NULL), which could be bigger than the
"last data" time stamp, for example when handling the read buffer took
more than 1 second -- and this resulted in the PONG time out kicking in
effectively disconnecting a newly linked server for example, because
ngIRCd thought it was still waiting for a PONG: last data < last ping.
Now the "last ping" value has three possible values:
0: new connection, no PING, no PONG so far.
1: got a PONG, no longer waiting for a PONG.
<t>: time stamp of last sent out PING command.
This patch completely broke the PING-PONG logic: now ngIRCd never
disconnects any stale peers but keeps sending out PINGs over and over
again ...
The real issue (server disconnects right after connect) will be fixed in
the next commit, but let's revert to the somewhat "half-broken but
'known' state" first ...
This reverts commit 79a917f954.
Change the line buffer in the Read_TextFile() function from 127 to
COMMAND_LEN (=512) bytes. Lines can't even get that long, because they
have to be prefixed before being sent to the client, so this is a sane
maximum.
This allows for even more "fancy" and "wider" MOTDs :-)
Closes#271.
Don't use the "standard" IRC SSL port 6697, as this easily collides with
real (ng)IRCd instances running on the same machine.
And by reusing port 6790, which is already used by the "test server #2",
we don't need any other port than the test suite already uses.
Not sure about the portability of strpbrk() in really ancient OS, and
this was the only place where it became used recently in ngIRCd ...
So let's play it safe! ;-)
There is no point in waiting up to one second for the network receiving
new data when there is still a read buffer holding at least one command;
we shouldn't waste time but handle it immediately!
If there are more bytes in the read buffer already than a single valid
IRC command can get long (513 bytes, COMMAND_LEN), wait for this/those
command(s) to be handled first and don't try to read even more data from
the network (which most probably would overflow the read buffer of this
connection soon).
This reverts commit c6e3c13f27.
This sounded like the right approach at first, but I'm not that sure
that it really makes sense to have different sizes of read buffers: the
per-connection read buffer only needs to keep data that is needed to
parse one full command, be it plain text, encrypted and/or compressed.
Then ngIRCd should handle this one command, move leftover data to the
beginning of the buffer and read the next chunk from the network that is
missing to get the next complete command (512 bytes at max).
So I revert this for now and try to fix the logic in Read_Request(),
which is broken nevertheless, as it results in servers becoming
disconnected during "server burst" when "big" lists are transferred.
