search

netoptimizer / IPTV-Analyzer

Fast MPEG2 Transport Stream Analyzer, based on Netfilter kernel module
www.iptv-analyzer.org
GNU General Public License v3.0
97 stars 55 forks source link

Add IPv6 support #20

Open plajjan opened 9 years ago

plajjan commented 9 years ago

This is my first stab at adding IPv6 support to IPTV-Analyzer. I've tried to keep down the amount of duplication for IPv4 and IPv6 and instead use as much common code as possible but it's somewhat difficult.

I've verified it's working for both IPv4 and IPv6 streams but there might be corner cases that aren't covered.

plajjan commented 9 years ago

NIP6 seems to be deprecated in favour of %pI6 that was introduced with 2.6.29. Do we care about backwards compatibiltiy that far? Should I use %pI6 instead?

netoptimizer commented 9 years ago

I think we/you should use %pI6, I don't think we need backward compat with 2.6.29.

I'm thinking of doing a release, before we start adding IPv6 support. This will give users a more clear picture, and allow us to relax on compat change in development git tree.

plajjan commented 9 years ago

On 2015-02-13 00:24, Jesper Dangaard Brouer wrote:

I think we/you should use %pI6, I don't think we need backward compat with 2.6.29.

Ok, I'll fix that.

I'm thinking of doing a release, before we start adding IPv6 support. This will give users a more clear picture, and allow us to relax on compat change in development git tree.

Alright!

plajjan commented 9 years ago

Is there anything I can do to help get this merged? You mentioned doing a pre-IPv6 release, perhaps I can help out with that somehow? Are there other things you want me to fix with this patch before we can merge it?

netoptimizer commented 9 years ago

I did a release (0.9.4), so it will be easier to distinguish when IPv6 support gets added.

We/you still have to fix up the match struct (mpeg2ts_stream_match), so we don't introduce a potential performance regression for IPv4, before I'm going to take these changes.

plajjan commented 9 years ago

Thanks for putting together that release! :)

I suppose the fix up refers to the introduction of the new "version" in the match struct, correct? As I mentioned before, I don't see how one can determine the type that is currently stored in a union, so short of adding "version" in the struct I suppose the only other method would be to pass an argument through all the function calls to notify each function if an IPv4 or IPv6 struct is being passed. Would this align with your view or do you see another way of doing it?

netoptimizer commented 9 years ago

Look at how the "xt_hashlimit" module does this split, I think we should use that model.

See code at: https://git.kernel.org/cgit/linux/kernel/git/davem/net-next.git/tree/net/netfilter/xt_hashlimit.c