UnrealIRCd Forums

need Help. I have two bots (who are global ircop) that spams something (one in query and one in chan) to about 100 or more users. They systematly go down for excess flood. I try anything I know in the config, can you help me to understand why they still disconnect ?

Perhaps I got it.

Just so this thread can have a solution: He needed to increase the class block's recvq for the bots.

class staff
{
pingfreq 90;
maxclients 10;
sendq 200000000;
recvq 800000000;
};
allow {
ip *@*;
hostname *@*;
class staff;
password "********";
maxperip 10;
};


No chance, the bots Always go down for excess flood (the bots are global ircop)

[19:46:17] PoLaRiS «********@*****-C4C9E6E.*******» has Quit iRC (Excess Flood) «99 people»

When the bots reconnect, does the connection notice say they're being put into the class staff? Also, the oper block needs to have class staff

Stealth wrote:When the bots reconnect, does the connection notice say they're being put into the class staff? Also, the oper block needs to have class staff

Uh, connection notice ? I don't know where to look.

The Oper Block have the class staff :

oper PoLaRiS {
class staff;
from {
userhost *@*;
};
password "*****";
flags
{
get_umodew;
global;
get_host;
};
};

Let's also remember that allow blocks are read from the bottom up so more restrictive blocks need to be on the bottom of the list as the ircd will "drop" the user into the first matching block.

To see user connections you need snomask +c for local connections and snomask +F for remote connections: /mode your-nick +s +cF

Allow Block are at the top of the unreal config. I have both c and F as snowmask, but ever didn't see connection notice.

these are my snomask
+s +kcfFjveGnNqSoT

this an example of connection notice
[06:52:07] [***] *** Notice -- Client connecting at Staff.***.Org: Azrael ([email protected])
[06:52:08] [***] Azrael ([email protected]) [Azrael] is now an operator (O)

I say again, more restrictive allows blocks need to be on the BOTTOM as the user is dropped into the FIRST class they match.

katsklaw wrote:I say again, more restrictive allows blocks need to be on the BOTTOM as the user is dropped into the FIRST class they match.

Uhm, now I am confused. I have only one Allow Block, but I have two class block.

One is staff and the other is server class.

What exactly do you mean with "need to be on the bottom" ?

PM me your network and I'll come to you for live support.

katsklaw wrote:PM me your network and I'll come to you for live support.

This is not a good idea. I manage my network now since 2005 and never I have had such a problem. I tought that a O-Line would be enaugh for a bot to not disconnect for excess flood....
Anyway, I thank you but I don't want live support. Please explain me, if you want, what you mean with "at the bottom".

At the bottom means if you have more than 1 allow block that the more restrictive blocks, password protected for example is listed below all other allow blocks.

For example: In the above example, the password protected allow block is evaluated first and if the user meets the criteria the use is assigned the "staff" class when they connect and the "users" class allow block is ignored. Conversely, if the user doesn't supply a password at connection, the "staff" block is bypassed and the ircd evaluates the second block, then the third and so on until the user matches. Once the user matches, all other blocks are ignored and the user is assigned to that respective class.

If your bot is in the "staff" class, then it is still exceeding it's sendQ and you should throttle how fast the bot sends messages or raise the sendQ value.

Hope that helps.

Yes that helps a lot. Bot now, since a few days, I have only one allow block and two class:

class staff
{
pingfreq 90;
maxclients 10;
sendq 200000000;
recvq 800000000;
};

class servers
{
pingfreq 120;
maxclients 25; /* Max servers we can have linked at a time */
sendq 1000000;
connfreq 100; /* How many seconds between each connection attempt */
};

allow {
ip *@*;
hostname *@*;
class staff;
password "*****";
maxperip 10;
};