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
