Re: r289932 causes pf reversion - breaks rules with broadcast destination

Tom Uffner wrote:
> Commit r289932 causes pf rules with broadcast destinations (and some but not
> all rules after them in pf.conf) to be silently ignored. This is bad.

> I do not understand the pf code well enough to see why this change caused
> the breakage, but I suspect that it might expose some deeper problem and
> should not simply be reverted.

OK, so here is why I don't want to simply back this out and have a "working"
firewall again:

Apparently PF_ANEQ was prone to false positives when comparing IPv4 addrs.
This is what r289932 and r289940 fixed. For IPv4 it does not matter where
in bits 32-127 the address mismatch occurs or what order the garbage data
is tested. That is all the paren fix in r289940 changes. It might be relevant
for v6, but doesn't matter here.

So, if my rule was "working" due to false positive in a comparison that has
now been fixed, how many other address comparisons were affected by this
error?

There are 36 occurrences of PF_ANEQ in pf.c and 2 in if_pfsync.c

About half of them appear to be testing IPv4 addresses. How many of them may
have been influenced by uninitialized data returning a false positive result?