This seems pretty straighforward, I'll give it a try. Thanks, man!
On Tue, May 20, 2014 at 2:59 PM, Alfredo Cardigliano <[email protected]>wrote: > Hi Randy > what about patching pf_ring.ko to set in a new field of the packet header > the id of the matching rule? > > Regards > Alfredo > > On 20 May 2014, at 14:11, Randy Eisenbart <[email protected]> > wrote: > > > Hi folks, > > > > I'm trying to find a possibility to filter incoming packets in PF_RING > (using hash or wildcard rules, or BPF, doesn't matter) and then relay the > packets that pass the filter to my userspace application. However, inside > the application I need to know which rule has caused the packet to be > relayed. So basically I'm looking for a functionality like NFQUEUE. > > > > Looking through the PF_RING documentation, I see only 2 possibilities, > either of which I would describe as a hack: > > > > - register a number of almost identical plugins with a number of > filtering rules, with the difference being that each plugin somehow adds > its respective ID to the packet before forwarding to userspace > > - implement filters in userspace, basically filtering again after the > packet has already been relayed > > > > Can anyone think of a better way? Am I missing something? > > > > Cheers, > > Randy > > > > _______________________________________________ > > Ntop-misc mailing list > > [email protected] > > http://listgateway.unipi.it/mailman/listinfo/ntop-misc > > _______________________________________________ > Ntop-misc mailing list > [email protected] > http://listgateway.unipi.it/mailman/listinfo/ntop-misc >
_______________________________________________ Ntop-misc mailing list [email protected] http://listgateway.unipi.it/mailman/listinfo/ntop-misc
