Op wo, 11-06-2008 te 08:14 +0200, schreef Patrick McHardy: > Ben Gamsa wrote: > > I'm using version 0.0.3-3 of arptables (curently with a 2.6.20 kernel, soon > > to be upgraded) and it seems like explicit and implicit RETURNs are not > > working. > > What I believe is happening is that arptables includes its own version of > > arp_tables.h (actually, two identical copies), with a definition for > > ARPT_RETURN. > > Specifically, it defines it as: > > > > #define ARPT_RETURN (-NF_MAX_VERDICT - 1) > > > > while the kernel defines it as XT_RETURN, which in turn defines it as > > > > #define XT_RETURN (-NF_REPEAT - 1) > > > > The end result seems to be that rules that explicitly or implicitly use the > > target RETURN actually end up with the target STOP, and so returns from > > chains don't work. Changing the definition of ARPT_RETURN in arptables to > > match the definition of XT_RETURN appears to fix the problem. > > > I think the error is in userspace, it shouldn't define the value > dependant on a non-fixed value. If the kernel did this as well > before the intoduction of x_tables (which defined ARPT_RETURN > to XT_RETURN), compatibility was already broken by the introduction > of NF_STOP a long time ago. So I think the correct fix is to > resync the arp_tables userspace header files with the kernel. Things compile fine from CVS using the KERNEL_DIR directive with your favorite kernel source. I'm having more trouble than I like getting things to compile by just also including x_tables.h in the local arptables directory (__be16 isn't defined). I guess my /usr/include/linux directory isn't up-to-date. Is there any directive about this? How does iptables cope with this? cheers, Bart -- 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
