Date: Mon, 17 Mar 2008 12:30:03 GMT From: Vadim Goncharov <vadim_nuclight@mail.ru> To: freebsd-ipfw@FreeBSD.org Subject: Re: kern/121743: ipfw in-kernel nat loses fragmented packets Message-ID: <200803171230.m2HCU3ST065036@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/121743; it has been noted by GNATS. From: Vadim Goncharov <vadim_nuclight@mail.ru> To: Alexander Zagrebin <alexz@visp.ru> Cc: bug-followup@freebsd.org Subject: Re: kern/121743: ipfw in-kernel nat loses fragmented packets Date: Mon, 17 Mar 2008 18:23:02 +0600 Hi Alexander Zagrebin! On Mon, 17 Mar 2008 12:10:02 GMT; Alexander Zagrebin <alexz@visp.ru> wrote: >>> --- sys/netinet/ip_fw2.c.orig 2008-02-28 11:28:09.000000000 +0300 >>> +++ sys/netinet/ip_fw2.c 2008-03-15 18:41:52.000000000 +0300 >>> @@ -3568,7 +3568,8 @@ >>> else >>> retval = >> LibAliasOut(t->lib, c, >>> MCLBYTES); >>> - if (retval != PKT_ALIAS_OK) { >>> + if (retval != PKT_ALIAS_OK && >>> + retval != >> PKT_ALIAS_FOUND_HEADER_FRAGMENT) { >>> /* XXX - should i >> add some logging? */ >>> m_free(mcl); >>> badnat: >> >> This is not so simple to fix as LibAlias API requires caller >> to save packet >> fragments somewhere and then at some time to feed them all >> back. And kernel >> infrastructure currently is not so suitable for that packet storage. > /sbin/natd doesn't use this method too. But it is in source tree and works. natd(8) relies on a divert(4) socket on doing reassembly, again in kernel - and ppp(8) actually use this method. > This patch will work at most cases. > It is better to work with a bad patch, than to not work absolutely. No, that's not FreeBSD way. Especially when you have workaround available. >> As a workaround you can currently send packets with some ipfw >> rule before NAT >> to a divert socket on wich ng_ksocket listens and returns >> packets back with >> ng_echo (thus packets won't leave kernel), as divert sockets do packet >> reassembly. > So ng_ksocket has kernel memory for fragmented packet's buffer, but libalias > not? :) Yes, because libalias(3) was developed more than 10 years for ppp(8), and was never ment to be ported to the kernel (it still has many-many quirks). Kernel sockets, and divert(4) as well, all use finite reassembly space for packets destined to this machine. This is not a problem with natd(8) as it is not so fast, but for more intensive solutions with in-kernel libalias a better solution should be found. -- WBR, Vadim Goncharov. ICQ#166852181 mailto:vadim_nuclight@mail.ru [Moderator of RU.ANTI-ECOLOGY][FreeBSD][http://antigreen.org][LJ:/nuclight]
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200803171230.m2HCU3ST065036>