Ban-Unban flood on small repeat floods

[OS2Warp]

My botnet, after a small repeat flood, has a strange behaviour:
*** user^ was kicked by netbot1 (stop repeating)
*** netbot2 sets mode: +b *!*@host
*** netbot3 sets mode: -b *!*@host
*** netbot4 sets mode: -b *!*@host
*** netbot5 sets mode: +b *!*@host

settings in netset.tcl are
# repeat.tcl settings
set nb_component(repeat) 1
set rp_chans ""
set rp_echans ""
set rp_efficient 1
set rp_exempt "o|o"
set rp_warning 0
set rp_kflood 4:60
set rp_kreason "stop repeating"
set rp_bflood 8:60
set rp_breason "repeat flood"
set rp_sflood 0:00
set rp_sreason "stop repeating"
set rp_slength 40
set rp_mtime 240
set rp_mreason "multiple repeat floods"
set rp_btime 40

I'd like to avoid this ban-unban flood, i.e. the netbots shouldn't clear the ban.
Thanks in advance.

[ppslim]

The only way I can see this happening, is if the channel is set -userbans, +dynamicbans and the botnet is lagged.

[OS2Warp]

Channel is both +dynamicbans and +userbans .
Maybe i should get another flood tcl :/

[slennox]

This is eggdrop's fault. Take at least three sharebots (the more the better) and enter the following at almost the same time in all bots:

.tcl newchanban #channel *!*@*.test.com niceguy "test ban"

This simulates the bots all setting a ban at the same time in response to a flood.

Watch as the bots go through a whole lot of "ban" / "cancel ban" silliness before they settle.

[mikec]

Does anyone know of the eggdrop source has been fixed for this? An author of another script put in a workaround for this problem of the bot sharing bans/unbans so it the script wouldn't be affected.

Or is there a chance netbots script can be edited to not be affected either?

[Petersen]

Its easy enough to work around that. Simply check for the existance of the ban in the internal banlist immediatly before issuing the newchanban.

ie

Code: Select all

	set isalreadyban 0
        foreach i [banlist $chan] {
        if {[string match $banmask [lindex [split $i] 0]]} {
        set isalreadyban 1
	break
	}
	}
	if {![set isalreadyban]} { 

          newchanban ......
}

trust me, it works. i had repeat4.1.tcl doing that manic +b-b [censored] untill i wrote that code, which stopped it.

[slennox]

That appears to be another trigger of the same problem in Eggdrop's ban sharing. When a newchanban is repeated over an existing ban, the bot itself acts as expected (keeps ban, activates it on the channel if it isn't present) but sharebots can receive a 'cancel ban' command from that bot, so they remove the ban, resulting in the +b-b silliness.

The latest repeat.tcl doesn't check if a ban exists before doing a newchanban, adding a check would probably reduce the problem (but fixing it in Eggdrop's code to avoid these workarounds would be better). However, there is still the other cause of multiple bots setting a ban simultaneously, which creates big problems for sentinel.tcl and can cause the same problem with repeat.tcl or any other script which uses newchanban.

[mikec]

Where does this code exactly go in the repeat tcl? I'm willing to try it as I actually did but I got errors, and I'm not a tcl coder so no idea where or how it should be implemented in the script.

[Petersen]

Around any instances of newchanban in your script.