DragonFly BSD
DragonFly bugs List (threaded) for 2006-11
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: bridge_pfil: m_pullup failed

To: Gergo Szakal <bastyaelvtars@xxxxxxxxx>
From: Cédric Berger <cedric@xxxxxxxxx>
Date: Fri, 03 Nov 2006 20:16:08 +0100

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 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.


[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]