Project

General

Profile

Actions
Copy link

Bug #2892

closed

"pfblocker_Range2CIDR" function yields erroneous results (pfBlocker v1.0.2)

Added by B. Derman about 11 years ago. Updated over 9 years ago.

Status:
Resolved
Priority:
High
Assignee:
-
Category:
Country Block
Target version:
-
Start date:
03/20/2013
Due date:
% Done:

100%

Estimated time:
Plus Target Version:
Affected Version:
Affected Plus Version:
Affected Architecture:
i386

Description

E.G. the file
http://list.iblocklist.com/?list=bt_ads&fileformat=p2p&archiveformat=gz
on 2013-Mar-18 has/had an entry (on line 165):
---
ADC01/ADC06 ads:61.135.131.31-61.135.131.34

Using the "pfblocker_Range2CIDR" function contained in /usr/local/pkg/pfblocker.inc in pfBlocker v1.0.2 to convert the IP address range:
---
61.135.131.31 to 61.135.131.34

yields a CIDR represenation of:
---
61.135.131.27/30

but 61.135.131.24/30 "expands" to the 4 incorrect IP addressses:
---
61.135.131.24
61.135.131.25
61.135.131.26
61.135.131.27

... whereas, using the "ip_range_to_subnet_array" function contained in /etc/inc/util.inc in pfSense v2.0.2 to convert the IP address range:
---
61.135.131.31 to 61.135.131.34

yields CIDR represenations of:
---
61.135.131.31/32
61.135.131.32/31
61.135.131.34/32

which collectively "expand" to the 4 (correct) IP addresses:
---
61.135.131.31
61.135.131.32
61.135.131.33
61.135.131.34

Not sure why the existing pfSense function wasn't used, but it appears that the one in pfBlocker will, in some instances, will generate CIDRs that can cause "good guy" IPs to be blocked and "bad guy" IPs to remain unblocked. On the plus side, fixing the bug should be as easy as switching to the function supplied by pfSense.

Regardless, I certainly appreciate the pfBlocker package and will be sending a small donation in as soon as our PayPal account gets refilled.

Actions
Copy link

Also available in: Atom PDF