Test for sockaddr_in.sin_len and initialize it to the correct value
which some systems (notably Mac OS X) require.
Note: this code path is only relevant when not using getaddrinfo().
Both getaddrinfo() and getnameinfo() are now used always when available, and
not only when compiling ngIRCd with support for IPv6.
This not only enables ngIRCd to handle multiple addresses per hostname when
compiled without support for IPv6, but fixes binding ngIRCd to IP addresses
on Mac OS X (and probably other BSD-based systems) as well: these systems
require that sockaddr_in is zeroed out and sockaddr_in.sin_len is set to
sizeof(sockaddr_in) like that:
src/ipaddr/ng_ipaddr.c, line 54:
assert(ip_str);
+ memset(addr, 0, sizeof *addr);
+ addr->sin4.sin_len = sizeof(addr->sin4);
addr->sin4.sin_family = AF_INET;
But this would break all the systems not using sockaddr_in.sin_len, for
example Linux -- so we assume that all these systems provide getaddrinfo()
and use that for now.
A configured server could have been removed while a connection apptempt
is still in progress. So the cb_connserver() callback has to test if the
server configuration record is still valid.
fix the following warning generated by valgrind if ipv6 is enabled:
Syscall param write(buf) points to uninitialised byte(s)
at 0x4000982: (within /lib/ld-2.9.so)
by 0x80681A8: Resolve_Name (resolve.c:477)
by 0x805439F: Conn_Handler (conn.c:1658)
by 0x804AA7C: main (ngircd.c:331)
The warning is because ng_ipaddr_t can be a union, and only the
necessary parts are initialised. The callers know what part
of the union is valid, so this is not a bug.
if more than one ip address is returned for a single host
name, ngircd is supposed to try other addresses in case
connect() to the first address returned fails for some
reason.
Alexander Barton noticed that this did not work at all,
as the additional results were not stored.
This patch fixes --with-openssl and --with-gnutls and enables both to
accept path names, so that you can use "./configure --with-XXX=/path".
All the other --with-XXX parameters support this already.
Cosmo Kastemaa reported that its impossible to create an ssl-only setup,
as ngircd binds to port 6667 by default, even if setting "Ports =".
Only add the default port if _both_ "Ports" and "SSLPorts" are
unspecified.
Fixes bugzilla #98.
Starting with GNU automake 1.11 "AM_SILENT_RULES([yes])" is available to
make the build process less verbose ("Linux 2.6 style") which helps to
spot warning and error messages.
So we use it if it is available.
This patch fixes the following silly log messages:
'ID "XXX" already registered (on connection -1)!'
If the ID is already registered on a local connection, the local
connection ID is printed; and if the ID is connected via a remote
server, "via network" is displayed.
reported on #ngircd: pasting lots of lines into a channel can kill off
many people on the channel if the read buffer is drained quickly enough
and the client-side TCP can't keep up with the incoming data.
This implements a throttling scheme:
- an irc client may send up to 3 commands per second before a one second
pause is enforced.
- an irc client may send up to 256 bytes per second before a one second
pause is enforced.
After discussion with Alexander Barton, server <-> server links are
treated specially: There is no artificial limit on the number of bytes
sent per second, and up to 10 commands are processed per second before
a pause is enforced.
It may be neccessary to make those limits tuneable to accomondate larger
networks, but for now they are compile time values.
New_Server() can call Conn_Close() in its error paths,
but that function decrements the number of current active
connections. Thus we need to increment it earlier.
When a server is running with SSL/TLS support compiled in,
it is trivial to crash the server by sending an MOTD request
via another server in the network.
- ONLY servers without ssl/tls support compiled in are not affected.
Disabling SSL in the configuration (no ssl listening ports, etc)
does NOT help.
- servers that are running standalone (i.e., not connected to any
other servers) are not affected, either.
This affects all ngircd releases since ngircd 13 (earlier versions
have no SSL/TLS support).
In addition to the "ngircd" and "ngircd-full" packages a new package named
"ngircd-full-dbg" is build: this package contains all the features of the
"full" package but includes debug code and both the --debug and --sniffer
options and the resulting binaries are _not_ stripped.
When ngircd announces the list of currently known servers
to a new (connecting) server, it sent the introducer of
the servers instead of the top server.
Assuming this network:
irc1.example.com
|--irc2.example.com
| `--irc3.example.com
| `--irc4.example.com
`--irc5.example.com
When irc4 connects to irc3, irc3 tells irc4 that irc5 was
connected to irc2. (irc2 had introduced irc5 to irc3; but thats
not what ngircd should have sent to the new server).
This also placed users on the wrong servers.
that code does not really make sense -- the info
text is freely cofngiureable and des not follow a specific
format.
Also, that "+2" might have caused invalid memory accesses.
