On 11 February 2012 11:00, Tomas Bodzar <tomas.bod...@gmail.com> wrote:
> On Sat, Feb 11, 2012 at 12:43 PM, Insan Praja SW <insan.pr...@gmail.com>
> wrote:
>> Hi Misc@,
>>
>> Could someone elaborate me with this tcpdump I had? After nat-ing,
checksum
>> error shows, on the same packet..
>>
>> rule 173.home.8/(match) [uid 0, pid 9731] pass in on vlan516:
>> 172.16.33.254.64264 > 188.255.110.14.51413: S [tcp sum ok]
>> 260322197:260322197(0) win 8192 <mss 1436,nop,nop,sackOK> [tos 0x28] (ttl
>> 126, id 5689, len 48)
>> rule 173.home.13/(match) [uid 0, pid 9731] pass out on vlan500: [orig src
>> 172.16.33.254:64264, dst 188.255.110.14:51413] 202.90.195.234.59074 >
>> 188.255.110.14.51413: S [bad tcp cksum f54!] 260322197:260322197(0) win
> 8192
>> <mss 1436,nop,nop,sackOK> [tos 0x28] (ttl 125, id 5689, len 48, bad cksum
>> 2d4b!)
>
> from man tcpdump
>
> IP Checksum Offload
> Some network cards support IP checksum offload. Packet headers for
such
> interfaces erroneously indicate a bad checksum, since the checksum is
> not
> calculated until after tcpdump sees the packet.
>
> so maybe related to your case
>>
I think that is not the case here, by default we do not enable em(4)
checksumming offload.
Just to make sure, can you give me the output of 'if config
em{0,1,2,3} hwfeatures' ?
I think pf is not recalculating the checksum after nating, not sure if
it should, henning ?
