Another question related to the same issue: I wonder why the design is that the application responsible for managing/allocating the rule_id, and not the infrastructure. I would expect the API just to ask to add a rule, and the infrastructure will return 2 parameters: 1. Success/Failure 2. The allocated rule_id in case of success (that will be used for removing the rule)
Thanks On Tue, Sep 12, 2017 at 8:34 PM, Amir Kaduri <[email protected]> wrote: > Hi, > > > > I would like to clarify a point regarding sw hash filtering rules and the > purge idle feature: > > In my application, I’m using sw hash filtering rules to block sessions. > For that purpose, I’m using the API pfring_handle_hash_filtering_rule() > to add and remove rules. > > When adding a rule with an ID of a rule that that has been already added, > this “add rule” action fails. This means that the application’s > responsibility to manage the rule IDs. > > In other words, the application’s responsibility to know which IDs are in > use and which are not, if it wants to avoid trial-and-error every time a > rule should be added. > > On the other hand, there is the API pfring_purge_idle_hash_rules() that > can assist in removing (purging) hash filtering rules that are inactive for > a while, automatically. > > So the situation is that pf_ring purges a filtering rule, and the > application is not aware of it. > > > For this reason: > 1. The application continues to keep the relevant rule-id, assuming > it’s still active. > 2. The application avoids using this rule-id for filtering other > sessions, since it assumes it’s still occupied. > 3. If the session suddenly revives after the purge period arrives, > the application is confused since it’s not clear to it how come packets are > forwarded while there is an active rule. > > The above happens since there is no notification mechanism to the > userspace application, that a rule has been purged (removed). > > > Is the description correct or maybe I miss something critical in the APIs > usage? > > > > Thanks, > > Amir >
_______________________________________________ Ntop-misc mailing list [email protected] http://listgateway.unipi.it/mailman/listinfo/ntop-misc
