The following reply was made to PR kern/121743; it has been noted by GNATS.
From: Vadim Goncharov <[EMAIL PROTECTED]>
To: Alexander Zagrebin <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]
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 <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED]
[Moderator of RU.ANTI-ECOLOGY][FreeBSD][http://antigreen.org][LJ:/nuclight]
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
