Re: pf log 'bad cksum 0!'

[James Affeld <jamesaffeld_(_at_)_yahoo_(_dot_)_com>]

Some follow-up:
tested this on 3.5 snapshot dated 29-3-2004, on an
intel box.  Same odd checksum logs.

Clarification: the ruleset is 

scrub in all
pass in log all

--- James Affeld <jamesaffeld_(_at_)_yahoo_(_dot_)_com> wrote:
> I have an inline/invisible/bridging pf setup.  With
> a
> simple setup:
> 
> scrub in all
> pass in all
> 
> Virtually every packet gets a log entry "bad cksum
> 0!"
> 
> I have a tcpdump log running on the other side, and
> the traffic gets a valid checksum.  Here is an
> example.
> 
> From pf.log
> 17:23:04.129436 X.Y.Z.20.80 > A.B.C.36.4373: .
> 139996:141456(1460) ack 608 win 17520 (DF) (ttl 54,
> id
> 1468, bad cksum 0!)
>   0000: 4500 05dc 05bc 4000 3606 0000 ...
> 
> from tcpdump on the inside of the fw:
> 
> 17:23:04.132826 X.Y.Z.20.80 > A.B.C.36.4373: .
> 139996:141456(1460) ack 608 win 17520 (DF) (ttl 53,
> id
> 1468)
>   0000: 4500 05dc 05bc 4000 3506 3c3a ...
> 
> If the bad ip checksum is an artifact of PF, or PF
> in
> bridging mode, why does it log?  
> 
> There is a router between the PF and the tcpdump
> log,
> which accounts for the TTL change.  It may be
> reconstructing the checksum.  But wouldn't the
> router
> drop the bad checksum'd packet? 
> 
> OpenBSD 3.4, Sparc64, Sun Ultra5. 
> 
> I could disconnect and insert the tcpdump log with a
> crossover cable, maybe, if anyone wants to see raw
> output directly outbound from the PF box.   
> 
> __________________________________
> Do you Yahoo!?
> Yahoo! Small Business $15K Web Design Giveaway 
> http://promotions.yahoo.com/design_giveaway/
> 


__________________________________
Do you Yahoo!?
Yahoo! Small Business $15K Web Design Giveaway 
http://promotions.yahoo.com/design_giveaway/