On Sunday 02 April 2006 07:45, Adam McDougall wrote: > I have been using 'ls' on a directory to test my ruleset and effects > of scrubbing rules. My latest discovery is if I use 'scrub .... fragment > reassemble', the packet on the outgoing interface will have a wildly > incorrect IP checksum (ethereal says 0x7b49 should be 0x688d for example).
Is this ethereal on the sending or on the receiving side? Note that with hardware checksums (as em(4) usually does) you will see corrupted checksums in ethereal as it is computed by the hardware later on. Please verify that you are seeing corruption on the receiving side or turn off the hardware checksum calculation (ifconfig em0 -txcsum) > I am using pf over a bridge with two 'em' interfaces, and encountered > other code paths in the recent past in pf_norm.c that did not recalculate > the checksum for changes it made, but in essence I think this time pf is > generating this packet as a reassembly of 5 fragments (total size 6296) > and doesn't seem to be applying a correct ip header checksum. The > header checksum is not even similar to the checksum of the last fragment > when entering the firewall (0xbfa4). Right now, I increased the outgoing > em1 interface to mtu 8000 just so the outgoing nic will not get wedged in > OACTIVE with 100% reproducability (more on that later). Can you give us a more detailed overview of your scenario and testcase? I am not quite sure what you are trying to do and how it fails. Also, which type of bridge are you using? > Can someone take a look and help me out, or let me know how I can help? > Thanks. -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News
pgpVv6oL0NOyI.pgp
Description: PGP signature
