info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Re: maybe bug in version 4.1.28
8 views
Skip to first unread message
Fbsd8
May 3, 2012, 11:36:51 AM5/3/12
to
Darren Reed wrote:
>
> I almost certainly guarantee you that this is to do with the different
> NIC chips having different capabilities such as hardware checksum
> and that these are interfering with ipfilter.
>
> Darren
>
Ok I believe you that is the cause of the problem.
So this is really a bug in ipfilter that needs correction.
Since this was not the case in the past when motherboards
did not have built in Nics and since the pc manufactures have
standardized on including nics on motherboards that offload some
processes to the chip hardware for better performance, It seems only
logical that ipfilter needs to be updated to be aware of these hardware
process and take the correct action so the reported error condition does
not occur any more. This problem is a SHOW STOPPER.
Are you going to address this?
>
> I almost certainly guarantee you that this is to do with the different
> NIC chips having different capabilities such as hardware checksum
> and that these are interfering with ipfilter.
>
> Darren
>
Ok I believe you that is the cause of the problem.
So this is really a bug in ipfilter that needs correction.
Since this was not the case in the past when motherboards
did not have built in Nics and since the pc manufactures have
standardized on including nics on motherboards that offload some
processes to the chip hardware for better performance, It seems only
logical that ipfilter needs to be updated to be aware of these hardware
process and take the correct action so the reported error condition does
not occur any more. This problem is a SHOW STOPPER.
Are you going to address this?
Jim Klimov
May 4, 2012, 12:03:54 PM5/4/12
to
(sorry, I had no other emails from this thread for context),
and ended up disabling the HW checksum offload.
I am not sure how ipfilter or other firewalls can properly
deal with packets mangled outside their control. Maybe it
is possible, and Darren did put this off for a while ;)
Do you know a working solution (perhaps in other BSD filters)?
Do you care to port and test it? ipfilter is a sourceforge
project, you can send up a patch ;)
Sorry I can't help much,
//Jim
Michael T. Davis
May 4, 2012, 12:17:26 PM5/4/12
to
At 11:57:21.06 on 4-MAY-2012 in message
<31404_1336146947_4FA3FC02_3...@a1poweruser.com>,
Fbsd8 <fb...@a1poweruser.com> wrote:
>Darren Reed wrote:
>>
>> I almost certainly guarantee you that this is to do with the different
>> NIC chips having different capabilities such as hardware checksum
>> and that these are interfering with ipfilter.
>>
>> Darren
>>
>
>Ok I believe you that is the cause of the problem.
>So this is really a bug in ipfilter that needs correction.
>Since this was not the case in the past when motherboards
>did not have built in Nics and since the pc manufactures have
>standardized on including nics on motherboards that offload some
>processes to the chip hardware for better performance, It seems only
>logical that ipfilter needs to be updated to be aware of these hardware
>process and take the correct action so the reported error condition does
>not occur any more. This problem is a SHOW STOPPER.
>
>Are you going to address this?
>
>
Where might we find the full thread of this topic? Reading between
>Darren Reed wrote:
>>
>> I almost certainly guarantee you that this is to do with the different
>> NIC chips having different capabilities such as hardware checksum
>> and that these are interfering with ipfilter.
>>
>> Darren
>>
>
>Ok I believe you that is the cause of the problem.
>So this is really a bug in ipfilter that needs correction.
>Since this was not the case in the past when motherboards
>did not have built in Nics and since the pc manufactures have
>standardized on including nics on motherboards that offload some
>processes to the chip hardware for better performance, It seems only
>logical that ipfilter needs to be updated to be aware of these hardware
>process and take the correct action so the reported error condition does
>not occur any more. This problem is a SHOW STOPPER.
>
>Are you going to address this?
>
>
the lines, is it recommended that we should not enable NIC-based offload
processing under ipfilter?
Regards,
Mike
Jim Klimov
May 4, 2012, 12:52:54 PM5/4/12
to
2012-05-04 20:17, Michael T. Davis wrote:
> Where might we find the full thread of this topic?
+1
> Where might we find the full thread of this topic?
> Reading between
> the lines, is it recommended that we should not enable NIC-based offload
> processing under ipfilter?
many hits on "dohwcksum ipfilter" keywords, including PhilDev's
IPFilter FAQ. And yes, the problem is very old:
http://www.phildev.net/ipf/IPFsolaris.html#solaris15
http://mail.opensolaris.org/pipermail/networking-discuss/2005-September/000192.html
http://mail.opensolaris.org/pipermail/networking-discuss/2006-March/000953.html
http://comments.gmane.org/gmane.comp.security.firewalls.ipfilter/6026
"As is known, ipfilter NAT does not work correctly with hardware
checksumming."
http://www.colby.edu/personal/j/jaearick/sysadmin/sol10.ipfilter.upgrade
We could go on and on :)
//Jim
Manuel Kasper
May 4, 2012, 2:00:02 PM5/4/12
to
On 03.05.2012, at 17:36, Fbsd8 wrote:
> Ok I believe you that is the cause of the problem.
> So this is really a bug in ipfilter that needs correction.
Here's a patch for FreeBSD 8.2/8.3 that fixes two different hardware checksumming problems with ipfilter:
> Ok I believe you that is the cause of the problem.
> So this is really a bug in ipfilter that needs correction.
http://svn.m0n0.ch/wall/branches/freebsd8/build/patches/kernel/ip_fil_freebsd.c.patch
(it's simply Pyun's patch from <http://www.freebsd.org/cgi/query-pr.cgi?pr=106438> combined with a patch for another HW checksum issue on UDP packets from <http://www.freebsd.org/cgi/query-pr.cgi?pr=166372>)
- Manuel
0 new messages