From owner-freebsd-ipfw@FreeBSD.ORG  Thu Jul 16 19:50:53 2009
Return-Path: <owner-freebsd-ipfw@FreeBSD.ORG>
Delivered-To: freebsd-ipfw@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id BDFF6106568C
	for <freebsd-ipfw@freebsd.org>; Thu, 16 Jul 2009 19:50:53 +0000 (UTC)
	(envelope-from dima_bsd@inbox.lv)
Received: from smtp2.apollo.lv (smtp2.apollo.lv [80.232.168.229])
	by mx1.freebsd.org (Postfix) with ESMTP id 4B13B8FC1D
	for <freebsd-ipfw@freebsd.org>; Thu, 16 Jul 2009 19:50:53 +0000 (UTC)
	(envelope-from dima_bsd@inbox.lv)
X-Cloudmark-Score: 0.000000 []
X-Virusscan: Clamd
Received: from [87.110.108.74] ([87.110.108.74] verified)
	by smtp2.apollo.lv (CommuniGate Pro SMTP 5.2.10)
	with ESMTP id 455753913; Thu, 16 Jul 2009 22:50:52 +0300
From: Dmitriy Demidov <dima_bsd@inbox.lv>
To: Chuck Swiger <cswiger@mac.com>
Date: Thu, 16 Jul 2009 22:50:51 +0300
User-Agent: KMail/1.9.10
References: <200907142355.34973.dima_bsd@inbox.lv>
	<200907162219.04986.dima_bsd@inbox.lv>
	<2CE3CD12-D430-4378-92C1-591227888428@mac.com>
In-Reply-To: <2CE3CD12-D430-4378-92C1-591227888428@mac.com>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200907162250.51585.dima_bsd@inbox.lv>
Cc: freebsd-ipfw@freebsd.org
Subject: Re: ipfw nat and localy initiated UDP traffic (bad udp cksum)
X-BeenThere: freebsd-ipfw@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFW Technical Discussions <freebsd-ipfw.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw>,
	<mailto:freebsd-ipfw-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-ipfw>
List-Post: <mailto:freebsd-ipfw@freebsd.org>
List-Help: <mailto:freebsd-ipfw-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw>,
	<mailto:freebsd-ipfw-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 16 Jul 2009 19:50:54 -0000

On Thursday 16 July 2009, Chuck Swiger wrote:
> On Jul 16, 2009, at 12:19 PM, Dmitriy Demidov wrote:
> > Update about this issue.
> > There is somthing wrong with UDP pass through - ipfw nat makes it
> > "bad cksum".
>
> tcpdump receives local network traffic before the checksums are
> computed (especially if hardware checksums are enabled); this is a non-
> issue, although you could confirm by sniffing the traffic from an
> external machine like a laptop.
>
> Regards,

Wow! :) Thank you Chuck for this hint! I catch the problem!
My em0 have offload options on, so I turned them off and now all is working as 
expected.


before:
===
em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=9b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM>
        ether 00:20:ed:91:97:93
        inet 87.110.108.74 netmask 0xfffffe00 broadcast 255.255.255.255
        media: Ethernet autoselect (100baseTX <full-duplex>)
        status: active
===


after:
===
em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=98<VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM>
        ether 00:20:ed:91:97:93
        inet 87.110.108.74 netmask 0xfffffe00 broadcast 255.255.255.255
        media: Ethernet autoselect (100baseTX <full-duplex>)
        status: active
===


dmesg | grep em0
===
em0: <Intel(R) PRO/1000 Network Connection 6.9.6> port 0xa000-0xa03f mem 
0xdb100000-0xdb11ffff irq 21 at device 9.0 on pci2
em0: [FILTER]
em0: Ethernet address: 00:20:ed:91:97:93
===


pciconf -lv
===
em0@pci0:2:9:0: class=0x020000 card=0x30138086 chip=0x100e8086 rev=0x02 
hdr=0x00
    vendor     = 'Intel Corporation'
    device     = 'Gigabit Ethernet Controller (82540EM)'
    class      = network
    subclass   = ethernet
===



Do this looks like a bug (em drivers, nat, etc...) or not?
Should I make new PR for this problem?