Sentinel Suggestion

[chrone]

Hi!

Yo slennox can you build your sentinel tcl to make a server ban not a bot ban list? it will help us much on server such DALnet. So if the host is ban once the bot won't kick the host again whenever s/he/it rejoin the channel after the ban removed.

One more thing about how to set the number:number on join-part flood on a big active join part channel which contains around 1000 users or above at the maximum peak and around 100 users or below at its miminum peak.

I wish you could add quit msg flood both on long text and exceeded control code on quit messege.

Best regards,

/chrone

[Fluffybunny]

I'd also love to see the quit-flood option, I'm on dalnet too, seems the flooders have gotten wise to the otherwise excellent flood prot on sentinel, getting the bots to recognise a /notice flood would be good too

[slennox]

I'd love to see server admins do something about the constant disconnecting and reconnecting that is required to perform an aggressive join-quit flood.

The problem with join-quit floods is that there's no way to tell the difference between such a flood and a bunch of netsplits. A pattern to match a typical netsplit, like "*.* *.*", could be used, but then flooders would simply put a fake netsplit message in their quit message. On some networks it may be possible to tell if a netsplit quit message is genuine (e.g. user quits may be preceded with a certain string), but I'm not willing to look at this unless it's possible on several major networks (that is, not just DALnet, as I'm tired of DALnet users wanting people like me who don't even use DALnet to fix DALnet's problems )

chrone, regarding the server ban only, I'm afraid this won't be possible. The next version of sentinel.tcl relies quite significantly on the bot's internal ban list for processing of bans. As for the join-part setting, simply make it less sensitive.. I don't have any plans to make flood settings that adjust themselves as the channel size varies

[Wcc]

If you're working on a new version, PLEASE consider per-channel settings. I can't even use the script due to a certian very-high traffic channel my bots are opped in.

Wcc

[slennox]

You're going to hate me for this, but http://www.egghelp.org/faq.htm#206

Configuring the settings based on the most active channel would be my standard recommendation.

[Wcc]

Yeah, I've read that before :\.. The traffic in that channel is almost equivilent to that of a medium-intensity flood. If I set it high enough not to trigger in there, it doesn't do anything for the other channels. Disabling on a channel would work for my needs, as this channel does not need flood protection to begin with.

Wcc

[[MaSteR]]

It would be nice if we could ignore a user with a certain flag from "flooding" that would help since normally +f flag would let you do the trick but since sentinel ignores such flags it makes it rather impossible to tell all the users to get ops through the bot. Also in certain cases a user isn't allowed to have ops but helps people out in the channel therefor causing a flood, which +f should be allowed to flood in my opinion. Yes I understand your point also why the user should be oped since that will put down on the protection but still some type of ignore should fit well. Thanks for making these scripts. /me kicks wcc sup man.

[chrone]

oh well slennox, thanks anyway. lol since you allow your tcl be used by public even for DALnet users. :p

oh yeah, i found my bot often flooded with multiple private messages. is sentinel do protect the bot itself from that kind of flood? i mean this private msg flooder use different ip address.

well keep on the nice job slennox. i'll be waiting for your new sentinel.tcl and keep editing those ban into server ban. :p

*tee hee

/chrone

[chrone]

oh yeah one more thing. i am just curious with that Voice and Master bellow your nick in this community.

What is Voice in here? and What is Master in here? are they a status you give yourself or by the admin of this php?

Thanks.

[ppslim]

It is base don the amount of posts you make to the forum.

The posts required for each level used to be available int eh FAQ, but this changed with the upgrade of the forum.

My post count got that high, I had to Kindly Request that a new one be added

[chrone]

oh okies thanks ppslim.

[z_one]

Chrone you can still make your Bot set itself as mode +R (on DALnet) as soon as it connects. To do this simply add the following line to the .conf file

Code: Select all

set init-server { putserv "MODE $botnick +iR-ws" }

Now only flooders with registered nicks can reach your bot (hopefully the number of reg. flooder nicks is considerably less that the unreg. ones).

The only problem this creates for you is that, when you're not identified you will have to connect to your bot through Telnet (using Putty for example) since the bot won't accept DCC requests from unidentified nicks on irc.

I do that and it works fine for me, my bots have never been flooded by private messages or notices so far

[Wcc]

I'd love to see server admins do something about the constant disconnecting and reconnecting that is required to perform an aggressive join-quit flood.

The problem with join-quit floods is that there's no way to tell the difference between such a flood and a bunch of netsplits. A pattern to match a typical netsplit, like "*.* *.*", could be used, but then flooders would simply put a fake netsplit message in their quit message. On some networks it may be possible to tell if a netsplit quit message is genuine (e.g. user quits may be preceded with a certain string), but I'm not willing to look at this unless it's possible on several major networks (that is, not just DALnet, as I'm tired of DALnet users wanting people like me who don't even use DALnet to fix DALnet's problems )

chrone, regarding the server ban only, I'm afraid this won't be possible. The next version of sentinel.tcl relies quite significantly on the bot's internal ban list for processing of bans. As for the join-part setting, simply make it less sensitive.. I don't have any plans to make flood settings that adjust themselves as the channel size varies

At least on DALnet, all *quits* are prefixed with "Quit:". You might could take advantage of that for networks that support it. As for the netsplits triggering it, the sign bind shouldn't trigger on netsplit until after split-wait or whatever that setting is. You could compare a raw quit bind to a sign bind to determine if the quit occurred at the same time as when the sign bind occurred. Just a thought..

Wcc

[ppslim]

At least on DALnet, all *quits* are prefixed with "Quit:". You might could take advantage of that for networks that support it.

I believe that the following applies, in regard to this.

Unless the big 4 (Dalnet, Efnet, Undernet and IRCnet) all support it, it will not be implimented.

Code should be consistant, to the point, that it works on all 4 networks, without using per network settings. (IE, 4 peice of code, one for each netowrk, and it depends what server you are on, as too which one is used)

As for the netsplits triggering it, the sign bind shouldn't trigger on netsplit until after split-wait or whatever that setting is.

Very true, however, each of the big 4 do not use the same method of displaying netsplits.

Due to this, a netsplit happens, but is not registered by eggdrop. Thus, making this addition usless.

You could compare a raw quit bind to a sign bind to determine if the quit occurred at the same time as when the sign bind occurred. Just a thought..

Again, as above.

On top of this, it's simple to fake a netsplit on some networks.

This leaves two major situations.
On one hand, genuine netsplits are not detected.
On the other, fake netsplits are detected.

[stdragon]

It's easy enough to add a config variable, like "set user_quit_prefix {Quit:}" and then on networks that don't have one, set it to blank {}.

Also, an easy way to accomplish some of the other requests, like protecting certain flags and doing server bans, would be to have a single proc that does the actual banning. Pass it the nick, uhost, hand, chan, msg, etc of the person you are banning. For the vanilla version, it would just pass it directly on to newchanban or whatever. But it would be easy to add a line that says "if {[matchattr $hand +f]} {return 0}" and ignore it. Also one could replace newchanban with putserv to make it a server ban.

Just a thought from the abstract programming department :)