:: Ideas and Suggestions

The time is now Thursday, April 7th, 2022, 12:25pm


		Forum Index :: Ideas and Suggestions :: Recognize netsplits / add a splitlist :: Reply to this topic

Author
agonizer		Posted :: 4:49am, Thu, Dec 9, 2004 Subject :: Recognize netsplits / add a splitlist

Posts: 54		To prevent ugly (mass) deops after a netsplit->rejoin, let the bot remember who had op before. This list needs to time out after a time (1800 seconds = 30 minutes). If those users rejoin and get server-op'd just do not deop them if SD is set. Let the bot remember the time of the last split for information purposes <Icks> .splits <X-Damage> <X-Damage> Last netstplit detected 03:06:27 Dec 09 2004 (0 days 02:41:06 ago) <X-Damage> <X-Damage> The splitlist for channel #agotest is empty (Otherwise users who're gone in a netsplit would be listed)
proton		Posted :: 5:50am, Thu, Dec 9, 2004

Posts: 165		On undernet its impossible to reliably detect netsplits. Any system can be fooled. /pro
agonizer		Posted :: 6:36am, Thu, Dec 9, 2004

Posts: 54		Dont know for undernet, but new upcoming ircd-2.11 (IRCnet) puts the quit message in "" (quotes) when its user generated. If quotes are missing, its a server- generated message. Also i wasn't able to generate a faked split-quit message with other ircd. If i try, then the server adds an space to the msg and it's not recognized as a netsplit. Why should an user fake a quit message and abuse the bot this way? If the (ab)user has already op, then he doesn't need to fake a quit... If a user doesn't have op, then he wont get added to the splitlist on any type of quit (only opped and unknown users get into the split list).
proton		Posted :: 8:11am, Thu, Dec 9, 2004

Posts: 165		There is a lot of "sane" stuff a bot could do when it assumes a netsplit is going on, like stopping +l updating, not server-deopping, yadda yadda Things that would be easy for a non-user to abuse. /pro
agonizer		Posted :: 9:12am, Thu, Dec 9, 2004

Posts: 54		Morning :-) Well, i can't imagine how those 'sane' stuff could work with the current mech. The solution for the +l problem is simple: If the server issues a '+l xxx' on a netjoin, the bot issues a -l and later on a correct +l. The non server- deopping cannot be abused because the abuser need to have already op before the split occures (so the bot see him opped (in the aChanUser record) AND netsplit- quit). Dont know if there are other possible problems.