ngircd with make http://git.nakidai.ru/ngircd/atom?h=rel-19.2 2012-06-19T09:47:15+00:00 2012-06-19T09:47:15+00:00 Alexander Barton alex@barton.de 2012-06-19T09:47:15+00:00 urn:sha1:b9e6cb3e556730f74464026a33d6904ffd340874 2012-06-13T10:19:56+00:00 Alexander Barton alex@barton.de 2012-06-13T10:19:56+00:00 urn:sha1:dffe5a9d6049609cfa02f44d978feef295c215d8 2012-06-13T09:40:24+00:00 Alexander Barton alex@barton.de 2012-06-13T09:40:24+00:00 urn:sha1:d7eb343ea03e404ee2ca086e570216ee824598d4 2012-06-11T08:44:28+00:00 Alexander Barton alex@barton.de 2012-06-11T08:44:02+00:00 urn:sha1:bf5610a3b9ceef67da9777c5f4a72b9733124a33 * bug124-CloakHostModeX: Describe "CloakHostModeX" in sample-ngircd.conf an ngircd.conf(5) Rename "CloakModeHost" option to "CloakHostModeX" Introduce new configuration option "CloakModeHost" This closes bug #124. 2012-06-09T10:53:44+00:00 Alexander Barton alex@barton.de 2012-06-09T10:53:44+00:00 urn:sha1:7bce6780ca0099f38efc801a7e613939cb90c99a 2012-06-09T00:04:50+00:00 Alexander Barton alex@barton.de 2012-06-09T00:04:50+00:00 urn:sha1:bf121ae95fa352d74ec710fda33c08148562a52c 2012-06-08T23:58:40+00:00 Alexander Barton alex@barton.de 2012-06-08T23:57:17+00:00 urn:sha1:7b6b492bdd259c25c4477e33392510872107ca6a 2012-06-08T23:58:25+00:00 Christoph Biedl ngircd.anoy@manchmal.in-ulm.de 2012-06-08T23:55:22+00:00 urn:sha1:aa7db2c0e9e1112591cbdb3d346342d34ca21a6a This closes bug #124. 2012-06-08T23:03:48+00:00 Alexander Barton alex@barton.de 2012-06-08T23:03:48+00:00 urn:sha1:684e50f0a4d827965b61c4b9feeda403ec3c3b87 Don't try to establish an outgoing server link after DNS lookup when this server re-connected on its own in the meantime. In addition, log a warning message if we try to update the connection index of an already connected server structure -- and ignore it. Up to now, both behaviour could lead to a race when the remote server connects to this daemon while it still prepares the outgoing connection: - The local server prepares the new outgoing connection ... - in the meantime the remote server becomes connected and registered. - Now the new outgoing connection overwrites the (correct) socket handle, - then the 2nd connection becomes disconnected: "already registered", - and the 1st connection becomes unhandled ("gets lost") because the configuration structure is reset because of the wrong socket handle. This patch hopefully fixes all these problems. 2012-06-08T20:08:52+00:00 Alexander Barton alex@barton.de 2012-06-08T20:08:52+00:00 urn:sha1:4a90959cb563e7c6ca57d32779074b448982c94f