Last modified: 2011-05-15 10:06:41 UTC
When an IP range has been blocked for whatever reason, it is virtually
impossible to find the status of an individual IP within that range.
The ipblocklist includes the data of the block, however starting from an
individual IP, it is a bit gambling to find the right lower range boundary
and if so, it is still difficult to find the range parm. In particular if
the ipblocklist consists of many pages.
A SQL query to resolve this (e.g. with an INNER JOIN xxx BETWEEN yy1 AND
yy2 construct), is quite expensive as far as cpu resources is concerned
(at least in a Microsoft environment). A solution could be a simple
additional table with 2 fields (range and each individual ip within that
range) which is UNION'ed to the already existing block table (I presume).
The issue has been triggered by an extensive project on nl:w to fight
trolls/sockpuppets working via open proxies. Recently one of those
appeared to use dynamic IP's for mobile internetting.
A related flaw, just discovered.
An IP range n1.n2.n3.n4/24 was blocked. Due to a bug in the bot, unblocking was
done on the base only n1.n2.n3.n4. The unblocking was successful.
However, querying the ipblocklist on n1.n2.n3.n4/24 returns that the range is
still blocked. The unblock log gives a successful unblock for the base address.
Example to be found on nl.wikipedia 126.96.36.199/24. I'll leave the inconsistent
state for a few days.
Note that, although it is nasty hackish use for this, CheckUser will list out blocks for users/IPs, included range blocks and autoblocks, linking to the log/ipblocklist respectively (autoblocks are not logged).
There is a tool which searches for blocks on all wikis, and will return rangeblocks which affect the given IP. On integrating this into core software, perhaps someone can see if the performance concerns mentioned in comment 0 are still correct?
I've changed the summary, since the old one was a bit hard to parse quickly for me.
(In reply to comment #1)
> A related flaw, just discovered.
> An IP range n1.n2.n3.n4/24 was blocked. Due to a bug in the bot, unblocking was
> done on the base only n1.n2.n3.n4. The unblocking was successful.
> However, querying the ipblocklist on n1.n2.n3.n4/24 returns that the range is
> still blocked. The unblock log gives a successful unblock for the base address.
> Example to be found on nl.wikipedia 188.8.131.52/24. I'll leave the inconsistent
> state for a few days.
If you can still replicate this, it'd be a separate bug.
As of at least r84534, this is fixed: Going to Special:BlockList/184.108.40.206 shows blocks on the IP 220.127.116.11, and all rangeblocks containing it.