On Fri, Mar 03, 2017 at 03:01:57PM +0100, Phil Sutter wrote: > On Thu, Mar 02, 2017 at 10:25:22PM +0100, Pablo Neira Ayuso wrote: > > On Thu, Mar 02, 2017 at 10:01:29PM +0100, Pablo Neira Ayuso wrote: > > > On Thu, Mar 02, 2017 at 08:56:52PM +0100, Phil Sutter wrote: [...] > > > If the problem is the inet chain, I would prefer we request explicit > > > dependencies for ah so we generate the right bytecode depending on the > > > family. Yes, I mean we would need two different rules for each case by > > > now. > > Well, in bison there would have to be a common entrance point, which > checks the scope and then generates either payload expr, exthdr expr or > an error depending on what it is. Correct? That's right. > > > On top of that, do you have a real usecase having both AH traffic for > > > IPv4 and IPv6 traffic? If you don't I would prefer you just fix what > > > we have and focus on a different task, we have plenty of work to do > > > ahead. We can hand over you more useful tasks. > > Not sure if I understand you correctly, but the use-case is matching on > some AH header field in IPv6 traffic? But sure, if you think that's too > exotic I could maybe just add some check somewhere which causes an error > if the family is not specified or not IPv4 and ah expression is being > used. As you indicate the AH handling in nft is inconsistent, just like it happens in iptables and ip6tables, look: 1) in iptables we can do -p ah, then use an extension to match AH header from transport. 2) in ip6tables we cannot do -p ah. We use a specific ah extension for IPv6 that uses ipv6_find_hdr(). This is a mess. Please, develop your hybrid idea. -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
