Hi, I think a lot of people are looking for this script, because bot gets d/c with "Max sendQ exceeded" msg when some idiot try to flood the bot with "MSG/NOTICE/CTCP FLOODS" with 100+ different ip', and the same time use join-part floods as well. Sentinel is very helpfull but i heard only Silence command can help more to block these floods since mostly IRCD support this command, I'll apprecite if any coder has some time for this? if some idiot send 5+ msgs/CTCPS/NOTICES in LESS than 10 seconds, set "silence +*!*@*" and then remove "silence -*!*@*" after few mintues.
thanks
This is the new home of the egghelp.org community forum.
All data has been migrated (including user logins/passwords) to a new phpBB version.
For more information, see this announcement post. Click the X in the top right-corner of this box to dismiss this message.
All data has been migrated (including user logins/passwords) to a new phpBB version.
For more information, see this announcement post. Click the X in the top right-corner of this box to dismiss this message.
silence command for a bot
Stop posting the same question (true, with different words) on different sections. Just wait for an answer forum other users.
On Undernet I know there is a usermode +d (deaf mode) where you won't see any channel text at all. Check this page for more info.
On Undernet I know there is a usermode +d (deaf mode) where you won't see any channel text at all. Check this page for more info.
Once the game is over, the king and the pawn go back in the same box.
Hi caesar, Sorry about that, i thought this is more scripting question so i've posted here, oh +d mode doesn't block /msg, /ctcp, /notice..its only deaf to channel chat.
my concern is bots.
bot's are getting d/c because flooders are using over 100 different IP's and flooding bots with "msg flood", "ctcp flood" , and notice flood. and then they use channel flood with join-part floods. only silence commands blocks private floods.
i know you guys are the best so this script will be very usefull for many many users on different networks since mostly ircd support silence command.
thanks again
my concern is bots.
bot's are getting d/c because flooders are using over 100 different IP's and flooding bots with "msg flood", "ctcp flood" , and notice flood. and then they use channel flood with join-part floods. only silence commands blocks private floods.
i know you guys are the best so this script will be very usefull for many many users on different networks since mostly ircd support silence command.
thanks again
MM
Don't know what other scripts you may have loaded.. as for ctcps just "set ctcp-mode 1" in your .conf file. If is a flood on the channel then lock it with what modes the network you sit on supports or use the default ones (+mi) to lock it.
slennox's sentinel.tcl script should do fine agains a lot of types of flood..
slennox's sentinel.tcl script should do fine agains a lot of types of flood..
Once the game is over, the king and the pawn go back in the same box.
Well, i am using netbots 4.09, sentinel is excellant but when they use over 100 different ip's and do "msg flood/ctcp flood, notice flood" to the bot then bot's get disconnect with "Max sendQ exceeded" message then i think /silence is the only solution. I have tried every possible thing before posting here and i have tested /silence using .dump command that works perfectly. so that's why i have requested. oh set ctcp-mode 1 setting is there.
thank you .
thank you .
MM
Not tested... checks for 5 msg, notice, ctcp in 10 seconds and sends silence for 2 minutes. Change values to your preference.
Code: Select all
bind notc - * add1
bind msgm - * add1
bind ctcp - * add1
bind ctcr - * add1
set counter_val 0
set counter_time 0
proc add1 {args} {
global counter_val counter_time in_silence
if {[expr [clock seconds] - $counter_time] > 10} {
set counter_time [clock seconds]
set counter_val 0
}
incr counter_val
if {$counter_val > 5 && ![info exists in_silence]} {
set in_silence 1
putquick "SILENCE +*!*@*" -next
utimer 120 undo_silence
}
return 0
}
proc undo_silence {} {
global counter_time in_silence
putquick "SILENCE -*!*@*"
set counter_time 0
unset in_silence
}
Not quite... Imagine this: add1, 9 sec pause, add1*4 within 1 second, expired, add1*5 - now you've done add1 9 times within ~1 second and nothing happenedstdragon wrote:checks for 5 msg, notice, ctcp in 10 seconds
A lil tip about if/expr: if IS expr, so you don't need to nest expr's within ifs to do calculations
Have you ever read "The Manual"?
The "problem" is actually related to the Nyquist Theorem, which you may have heard of if you do much with mp3s: the highest frequency you can reliably monitor digitally is 1/2 of your sampling frequency. In this case, the sampling frequency is 1/10 hz. So the best we can reliably monitor is 1/20 hz, which translates to a period of 20 seconds rather than the 10 specified.
Unfortunately this is a "hard limit" that you can't break, you can only approach. For instance, if you altered the algorithm to store the incoming times of messages using [clock seconds], you would think that you could detect floods to within 1 second rather than 10 seconds. However this falls victim to the same thing as user pointed out with mine: sometimes a few messages will come in at t = 1.9, and a few more at t = 2.0, thus surpassing what is considered a flood "within 1 second" without being punished.
This is a fact of life and there's not much to be done about it! However, note that this algorithm still detects floods according to the rule "2X messages in 2Y seconds". For instance, in user's example, if even one more message is sent in 9 seconds, the flood will be detected. If, on the other hand, every time the attackers send a few messages they have to wait 9 seconds, then it's not a flood.
Also, it is exactly the same as the algorithm eggdrop uses internally to detect floods, so if you haven't run into huge problems with that, you won't with this either!
I suppose the clearest way to say it would have been, "checks for a long-term average of at least 5 msg, notice, ctcp in discrete groupings of 10 seconds" but most people aren't so precise. I'll have to remember to be more careful when user is around!
Unfortunately this is a "hard limit" that you can't break, you can only approach. For instance, if you altered the algorithm to store the incoming times of messages using [clock seconds], you would think that you could detect floods to within 1 second rather than 10 seconds. However this falls victim to the same thing as user pointed out with mine: sometimes a few messages will come in at t = 1.9, and a few more at t = 2.0, thus surpassing what is considered a flood "within 1 second" without being punished.
This is a fact of life and there's not much to be done about it! However, note that this algorithm still detects floods according to the rule "2X messages in 2Y seconds". For instance, in user's example, if even one more message is sent in 9 seconds, the flood will be detected. If, on the other hand, every time the attackers send a few messages they have to wait 9 seconds, then it's not a flood.
Also, it is exactly the same as the algorithm eggdrop uses internally to detect floods, so if you haven't run into huge problems with that, you won't with this either!
I suppose the clearest way to say it would have been, "checks for a long-term average of at least 5 msg, notice, ctcp in discrete groupings of 10 seconds" but most people aren't so precise. I'll have to remember to be more careful when user is around!