Ed I have removed most of the history as I think this is not necessary. I still have to remove extra code that is not needed, but until now I focuses on making ndpi reentrant (I.e. multithreaded apps can now use it safely) and more memory friendly.
Once ndpi has detected a protocol, that's all it needs to do. This is in order to have good speed, and save memory. Can you please explain why you need that? About kernel filtering, I think that the kernel is a bit too hard I use it as I would like. I think that new challenges such as BYOD require flexibility that the kernel can hardly offer. Can you list your requirements on this matter? What would you like to do ultimately? Thanks Luca Sent from my iPad (sorry for typos) On 01/ott/2012, at 23:45, Ed W <[email protected]> wrote: > On 01/10/2012 19:36, Luca Deri wrote: > >> I have committed your patches: many thanks. Can we also merge your work on >> the opendpi module? Of course if I have changed something that broken your >> work we can fix it. If you want write commit on the SVN repository please >> let me know > >> and also I need a prototype for "ndpi_int_add_connection()" (in fact could >> the whole removal of the prototypes in ndpi_protocol_history.h be reverted >> and they be all left in for use by external modules?) > > Hi, what do you think about reverting the complete set of prototypes in > ndpi_protocol_history? I just added in that one quick stub because I needed > it, but previously there was a suite of functions - could someone else want > access to them? > > https://github.com/thomasbhatia/OpenDPI/blob/master/src/lib/ipq_protocol_history.h > > > > Note, my updates to the netfilter module are here: > https://github.com/ewildgoose/ndpi-netfilter > > At present it "compiles", but I can't test it because I need my machine with > netlink conntrack support, so currently the module fails to insert because I > can't call nf_conntrack_register_notifier on my kernel (already grabbed > by the conntrack netlink module). > > I'm pondering how I can possibly work around this... Thoughts on how to > decouple this from conntrack appreciated? (Not least because there is a risk > of leaks, conntrack doesn't always track every flow you think it should, as I > already discovered..) > > > Anyone a netfilter expert..? > > Ed W > _______________________________________________ > Ntop-dev mailing list > [email protected] > http://listgateway.unipi.it/mailman/listinfo/ntop-dev
_______________________________________________ Ntop-dev mailing list [email protected] http://listgateway.unipi.it/mailman/listinfo/ntop-dev
