From nobody@FreeBSD.org Tue Aug 10 12:45:45 2010 Return-Path: Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A9F501065674 for ; Tue, 10 Aug 2010 12:45:45 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (www.freebsd.org [IPv6:2001:4f8:fff6::21]) by mx1.freebsd.org (Postfix) with ESMTP id 99C668FC16 for ; Tue, 10 Aug 2010 12:45:45 +0000 (UTC) Received: from www.freebsd.org (localhost [127.0.0.1]) by www.freebsd.org (8.14.3/8.14.3) with ESMTP id o7ACjjTB073320 for ; Tue, 10 Aug 2010 12:45:45 GMT (envelope-from nobody@www.freebsd.org) Received: (from nobody@localhost) by www.freebsd.org (8.14.3/8.14.3/Submit) id o7ACjjof073317; Tue, 10 Aug 2010 12:45:45 GMT (envelope-from nobody) Message-Id: <201008101245.o7ACjjof073317@www.freebsd.org> Date: Tue, 10 Aug 2010 12:45:45 GMT From: Eugenijus To: freebsd-gnats-submit@FreeBSD.org Subject: 8.1-release, problem with fxp driver X-Send-Pr-Version: www-3.1 X-GNATS-Notify: >Number: 149497 >Category: kern >Synopsis: [fxp] 8.1-release, problem with fxp driver [regression] >Confidential: no >Severity: serious >Priority: medium >Responsible: yongari >State: closed >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Tue Aug 10 12:50:02 UTC 2010 >Closed-Date: Mon Aug 16 17:25:13 UTC 2010 >Last-Modified: Mon Aug 16 17:25:13 UTC 2010 >Originator: Eugenijus >Release: 8.1-RELEASE >Organization: >Environment: FreeBSD ftp.jucom.lv 8.1-RELEASE FreeBSD 8.1-RELEASE #0: Tue Aug 10 13:59:23 EEST 2010 root@ftp.jucom.lv:/usr/src/sys/i386/compile/KRN20100810002 i386 >Description: When I was running this hardware under FreeBSD 7.0 control, everything was ok. Problem accured when I installed FreeBSD 8.1 on the same hardware with same kernel and configuration. I have rules in my /etc/ipf.rules: pass out quick on fxp0 all pass in log quick on fxp0 proto tcp from any to any port = 80 block in log first quick on fxp0 all in this case ipmon shows: .. fxp0 *@0:1 p *xx.xx.xx.xx -> xx.xx.xx.xx,80 PR tcp len ... that is OK now I change second rule to: pass in log quick on fxp0 proto tcp from any to any port = 80 flags S keep state because I want to use statefull firewall ofcourse in this case ipmon shows: .. fxp0 *@0:2 b* xx.xx.xx.xx -> xx.xx.xx.xx,80 PR tcp len ... and that is NOT OK As I figured out problem root is in this log: ipmon[508]: 17:21:14.434180 fxp0 @0:1 p yyy.yyy.yyy.yyy,3843 -> xxx.xxx.xxx.xxx,80 PR tcp len 20 48 -S IN bad May be problem is in the checksum or somethik similar When I installed another interface with Rhino III chipset, problem dissapear. So I believe, that problem is somewhere in drivers. >How-To-Repeat: Install an Intel interface, supported by fxp and see the ipmon output, I believe problem will be out there. >Fix: I think, the way to fix this problem is to create somekind of patch, if it does not exist yet... >Release-Note: >Audit-Trail: Responsible-Changed-From-To: freebsd-i386->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon Aug 16 04:13:05 UTC 2010 Responsible-Changed-Why: reclassify. http://www.freebsd.org/cgi/query-pr.cgi?pr=149497 State-Changed-From-To: open->closed State-Changed-By: yongari State-Changed-When: Mon Aug 16 17:24:31 UTC 2010 State-Changed-Why: Not a fxp(4) bug. This issue was caused by a bug in ipfilter's checksum offloading handling. Consumer grade fxp(4) controllers support simple RX checksum offloading capability and fxp(4) started to use that feature. However ipfilter's checksum offloading logic has a bug such that it incorrectly computes checksum of received frame and dropped the frame. See the kern/106438 for more details and possible fix. You can disable RX checksum offloading of fxp(4) as temporary workaround. #ifconfig fxp0 -rxcsum Responsible-Changed-From-To: freebsd-net->yongari Responsible-Changed-By: yongari Responsible-Changed-When: Mon Aug 16 17:24:31 UTC 2010 Responsible-Changed-Why: Track. http://www.freebsd.org/cgi/query-pr.cgi?pr=149497 >Unformatted: