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.
The name of the Config_Error() function is misleading: it is not only
used to show configuraton errors, but all messages shown during normal
operation as well as for "config testing": it takes care of the correct
formatting of the messages (syslog, forground logging, config testing).
This fixes commit bb1d014aba.
This is required because the PING can be received quite a bit earlier
than it is actually handled, for example during "server burst" or other
heavy operations:
So the times won't match and PING-PONG logic would become garbled,
because we test for "last ping > last data" to determine if a PING
already was sent or not.
bash(1) is required to handle the forking and output redirection
connectly, sh(1) -- at least dash(1) on Debian -- fails ...
This fixes the last commit, 14777c18c.
Remove legacy configuration options and related functions that have
been marked for removal for some time:
- PredefChannelsOnly (v22)
- NoticeAuth (v24)
- NoXXX (v19)
- Old '[GLOBAL]' section handling (v19)
This applies the same logic we have for write buffers to distinguish
between server and client connections and sets the maximum buffer size
accordingly. As a result peering with servers with many GLINE/KLINEs
does not kill the connecting server connection anymore.
Depending on the stack size, too many clients on the same channel
quitting at the same time would trigger a crash due to too many
recursive calls to Conn_Close().
This requires keeping track of currently active certificates, so those
are stored separately, along with a reference counter, and discarded
when they are no longer in use.
Fix the handling of legacy "Key" and "MaxUsers" [Channel] settings:
- Activate them before evaluating the "Modes" parameter, to allow the
latter to override those legacy options.
- Enforce setting the respective +k/+l mode(s) to support the legacy
"Mode = kl" notation, which was valid but is an invalid MODE string:
key and limit are missing! So set them manually when "k" or "l" are
detected in the first MODE parameter.
- Sort modes +kl alphabetically, adjust test suite accordingly.
Fix the following Clang "LeakSanitizer" error (which isn't quite
relevant in this test program, but anyway):
ERROR: LeakSanitizer: detected memory leaks
Direct leak of 7 byte(s) in 1 object(s) allocated from:
#0 0x7f8c4d022810 in strdup (/lib/x86_64-linux-gnu/libasan.so.5+0x3a810)
#1 0x5601a801491a in Check_strtok_r (/net/arthur/home/alex/Develop/ngIRCd/ngIRCd.git/src/portab/portabtest+0x291a)
#2 0x5601a8014d77 in main (/net/arthur/home/alex/Develop/ngIRCd/ngIRCd.git/src/portab/portabtest+0x2d77)
#3 0x7f8c4c69009a in __libc_start_main ../csu/libc-start.c:308
SUMMARY: AddressSanitizer: 7 byte(s) leaked in 1 allocation(s).
FAIL: portabtest
