Gergo Szakal wrote:
Matthew Dillon wrote:
My guess is that they were bogus packets generated from a particular
source, either accidently or intentionally corrupted packets.
Think you should mark this irreproducible or so, if there are no such
messages within a few days.
Sorry for the suggestion, but could it be bad hardware?
I'm saying that because of the pfr_update_stats problem
that you also have. This assertion mean the following:
1) you've a block rule with table.
table foo { 127/8 10/8 127/12 192.168 }
block on $ext_if from <foo>
2) a packet like 10.0.0.1 arrive on ext_if.
3) PF select the block rule, and drop the packet
4) PF call pfr_update_stats, to increase the packet
counter of the selected block, in that case 10/8.
5) For some reason, the packet does NOT fine any
matching block, as if 10/8 has been removed from
the table between step 3 and 4.
There could be 4 reasons to that actually:
a) Bug in PF. but other people should see that too.
Are there other people still seeing that?
b) Race condition: incorrect locking in PF port to DFly
causing table changes to occur in the midst of pf_test().
But you say that you didn't change table content anyway.
c) Memory corruption due to bad hardware.
d) Memory corruption due to unrelated OS bug.
Cedric
