[hybrid] throttled posting - is there a crapflood throttle setting?

[Michael Wobst]

What is general::no_oper_flood set to?

Note: I'm not talking about general::true_no_oper_flood.

If 'no_oper_flood' isn't enabled, setting 'true_no_oper_flood' to 'yes' 
doesn't have any effect at all.
Due to a logic error which I just found, it's necessary to enable 
'no_oper_flood' if you want to get auth{can_flood=yes}; to work.

BTW: You can leave general::client_flood as it is. Changing this value 
doesn't help in your case.

Regards
Michael


Jeff schrieb:
> Hi Kevin,
>
> Thanks for your pointer - I'm not having much luck though. I already had...
>
> general {
>      true_no_oper_flood = yes;
> }
>
> I added can_flood to the existing auth "*@*" section which now looks like:
> auth {
>      user = "*@*";
>      class = "users";
>      have_ident = no;
>      can_flood = yes;
> };
>
> bounced ircd... (confirmed the ircf process had gone before restarting)
> Same behaviour... each line is still posted with a delay.
>
> We run debian-stable and our sec policy precludes a custom compile
> without serious justification.
>
> I left the client_flood=2000; as the comment above says:
>      /* client flood: maximum number of lines in a clients queue before
>       * they are dropped for flooding.
>       */
> and the original value as installed by debian was 20.
>
> Any further help greatly appreciated.
>
> Regards
> Jeff
>
>
> On 18/08/2012 00:51, Kevin Easton wrote:
>> Quoting Jeff <irc at aquabolt.com>:
>>
>>> Folks,
>>>
>>> I am running: ircd-hybrid 1:7.2.2.dfsg.2-6.2on Debian stable on a
>>> intranet.
>>>
>>> Apologies in advance for a newbie question - yes I have read the
>>> INSTALL and README and searched for ircd-hybrid documentation and
>>> irdc configuration in general. I think that my problem is that the
>>> terminology is unfamiliar, and so I am not certain which search terms
>>> are appropriate.
>>>
>>> On our intranet, when a user posts several (e.g. 20 ) lines of text
>>> in a single post, they are delivered one line at a time, with a 1
>>> second delay between each line.
>>>
>>> I assume this is some form of 'crapflood' throttle / protection. I
>>> would like to reduce / remove the throttle, or raise the threshold at
>>> which it kicks in.
>>
>> This is the most basic level of flood protection kicking in, which
>> limits the rate at which lines are accepted from a client.
>>
>>> I have the following settings:
>>>     default_floodcount = 1000;
>>
>> This affects a different kind of flood protection, which limits
>> messages directed at a single client.  It's the one that results in a
>> "*** Message to foo throttled due to flooding" message to the flooder,
>> and it drops messages on the floor rather than delaying them.
>>
>>>     client_flood = 2000;
>>
>> This is actually smaller than the default value, and is the size of
>> the unparsed message queue for a client in bytes.  If this is
>> exceeded, the client connection is dropped with an "Excess Flood"
>> message.  I would recommend leaving this at the default value.
>>
>>> Any help / pointer greatly appreciated.
>>
>> To increase the particular limit you're running into you'd need to
>> recompile hybrid after changing the value of MAX_FLOOD in
>> include/packet.h (default is 5, which means that a client can "burst"
>> 5 lines before being limited to 1 per second).
>>
>> Alternately you can disable the limit entirely for particular classes
>> of users with just a configuration change:
>>
>>  - In the "general {}" block, set true_no_oper_flood = yes
>>  - In the "auth {}" block for the users you want to be able to flood,
>> give them the "can_flood" flag.
>>
>>     - Kevin
>>
>>
>
>