On Tue, Jun 26, 2018 at 03:54:51PM +0200, Máté Eckl wrote: [...] > Do you disagree with this solution in general or only in case of tproxy? > > In general, I think it is better to have explicit checks here as the error > message generated by the current solution may be misleading in a situation like > mine (basically every time trying ot evaluate an ipv4 address to a rule in inet > table). Please, don't do this character probing from the evaluation step. It's a hack. I would like not to see patches that address parser limitations from the evaluation phase. [...] > = Dependency = > > You mentioned some kind of dependency in some of your emails, but I don't know > what you think of. Could you describe what a dependency is in this context? Is > it in user- or kernelspace? > > For ip/ip6/inet tables isn't that default to process *only* packets with IPv4 or > IPv6 header? If it is default, I don't understand why any other dependency > should be generated, I can just check the family of the packet against the > family of the, can't I? I was refering to the inet family, specifically. > You bring bridge/netdev as examples, but tproxy is not supported in these tables > (refused from nft_tproxy_init in the kernel), so I don't see why we should > consider them. Regarding the address family detection, the evaluate_addr > function only cares about L3 addresses so bridge/netdev seems to be irrelevant > here, too. Right, there's no bridge/netdev in tproxy .I was arguing about the syntax for this command and commands that look similar, like dup and fwd. Never mind about the dependency, actually "Kernel, address family check" and "Dependency" are the same thing. > = Kernel, address family check = > > You had a comment in an email which I still don't really understand. > > I think your kernel patch is also lacking this, and a custom userspace > program may add a tproxy expression to deal with IPV6 traffic, which > may result in crashing the kernel. My point is: Just make sure that your code doesn't allow IPv6 packets to run through the IPv4 path, and the other way around. Please, just send a v2 of your patches that we can review, we can address your concerns in a follow up step. If there's any concern, we can revisit, don't worry. -- 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
