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
===
e...@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?
_______________________________________________
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"
