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"