Date: Thu, 30 Mar 2006 01:22:03 +0300 (EEST) From: Dmitry Pryanishnikov <dmitry@atlantis.dp.ua> To: Luigi Rizzo <rizzo@icir.org> Cc: FreeBSD-ipfw@freebsd.org Subject: Re: IPFW1->2 regression: "in/out/via any" ignored Message-ID: <20060330005657.K11119@atlantis.atlantis.dp.ua> In-Reply-To: <20060323065729.C67264@xorpc.icir.org> References: <20060323133729.D63213@atlantis.atlantis.dp.ua> <20060323060006.A66681@xorpc.icir.org> <20060323162418.S45142@atlantis.atlantis.dp.ua> <20060323065729.C67264@xorpc.icir.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Hello! On Thu, 23 Mar 2006, Luigi Rizzo wrote: >>> For locally generated packets i admit 'recv any' may be of some use, >>> and this is unsupported. There are probably workaround such as 'src-ip me' >> >> Oops! How can one know that feature which is documented from the beginning, >> which worked in ipfw1 - became 'unsupported' in ipfw2? It's clearly a >> regression to me, given that I can't use ipfw1 with modern RELENGs. > > it's a bug, never seen one before ? :) Yes, "shit happens" (tm) ;) What surprised me is that such an obviuos bug hasn't been detected yet. It seems to me that people either seldom use "recv any" or (rather) seldom analyze whether it works correctly. > I repeat - it's a bug. I'ts probably trivial to fix, but at the > moment i don't have the time to work on it. > > If you want, the places to touch are: > sbin/ipfw/ipfw2.c the two places which parse TOK_RECV and O_RECV, > should be enabled to deal with 'any' as an interface name and encode > it somewhere in the instruction (see function fill_iface(), at the > moment 'any' is interpreted as NULL, it could become some magic > value e.g. 0x1 or the like) > sys/netinet/ip_fw2.c in function iface_match(), you should check > whether this magic value is present in the instruction and then > return 0 or 1 depending on whether or not the 'ifp' argument is non-null. Thank you for this useful info, it helped a lot. I've created and tested a patch which fixes the problem, see PR kern/95084. After looking at code I've decided not to invent "magic constant" for cmd->o.len, but rather use functionally equivalent to "any" string "*". Hovewer this causes fnmatch() invocation which could add a significant overhead, so I've added simple optimization for this case (I hope that 2 comparisons don't hurt significantly because of fnmatch() complexity). The patch works correctly for me, please review it and commit if it's OK. Sincerely, Dmitry -- Atlantis ISP, System Administrator e-mail: dmitry@atlantis.dp.ua nic-hdl: LYNX-RIPE
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060330005657.K11119>