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 87.79.3.0/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 87.79.3.0/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/1.2.3.4 shows blocks on the IP 1.2.3.4, and all rangeblocks containing it.
