[ircd-ratbox] Probably a design bug?

Jilles Tjoelker jilles at stack.nl
Thu Mar 26 23:38:55 UTC 2009

On Wed, Mar 25, 2009 at 08:04:55PM +0200, Narf wrote:
> Hello,
> An interesting situation happened today on a network, where we use a
> slightly modified versions of ircd-ratbox ...

> A server(using ircd-ratbox 3.0.0, and so does it's uplink) splits from
> the network and then tries to reconnect but it's timezone is
> incorrect(-2 hours difference) and therefore is being disconnected. Then
> one of our operators connects as a client on another of our
> servers(using ircd-ratbox 2.2.6) with the same nickname. On the next
> (auto)attempt for the first server to connect to the network, it's being
> disconnected again instantly.
> However, a nick collision occured and what was more tricky ... even if
> he reconnected with the same nickname, a collision would still be
> triggered each time his server tries to get back to the network as it
> was 2 hours behind the rest of the ircds and it's TS delta was "older"
> compared to the others.
> Of course ... the operator changed his nickname and situations like this
> probably happen once in a year(unless intended), but it's still a pretty
> interesting case. :)

> So, in my opinion the correct behaviour should be first to check if
> there's an acceptable difference(according to ts_max_delta) between the
> two servers, and _only_ after it's confirmed to be "ok" to process all
> other incoming data. Which means unnecessary collisions like the above
> wouldn't be possible.

It seems like it already works like you say it should work. After having
received SERVER, the ircd sends SVINFO (with its idea of the current
time) before sending any nicks/channels. If an SVINFO is received with a
time that is too far off, the connection is closed immediately.

The above issue could happen if the hub thinks the time is OK but the
leaf does not. This could be because ts_max_delta is configured
differently on both sides or because the time is wrong by a value close
to ts_max_delta and there is asymmetric lag.

Jilles Tjoelker

More information about the ircd-ratbox mailing list