This is a major bug as global blocks don't apply on meta...

Do you know if the range block does not work (i.e. users from this range
can edit) or it's just not displayed in the Special:BlockList output?
Special:Contributions suggest that the address range is blocked indeed.

I know it's not working sadly. Again, for the most recent example. 2605:8900:5000:1001:6:0:E:2 was the underlying IP of this vandal account -> https://meta.wikimedia.org/wiki/Special:Contributions/Mo%C3%ACraMo%C3%ACraMo%C3%ACra (used on 5 Nov 2012 and the IPv6 range was blocked on 1 Nov 2012)

(In reply to comment #0)

The local IPv6 range block is working on nlwiki and globally:
But it's not working on meta:

Sounds rather like an issues with the servers than MediaWiki software to me. Moving from Mediawiki product to Wikimedia.

<saper> andre__: re https://bugzilla.wikimedia.org/show_bug.cgi?id=41778 I am not sure it's "site config" thing... my wild guess is the order the blocks are checked when GlobalBlock comes into play

Hence moving back.

I think we can mark this as a dup of https://bugzilla.wikimedia.org/show_bug.cgi?id=37481

In addition, I do think this does have something to do with GlobalBlocking. Before I started using GlobalBlocking on my own (private) wikis, local rangeblocks were effective.

(In reply to comment #6)

I think we can mark this as a dup of
https://bugzilla.wikimedia.org/show_bug.cgi?id=37481

Well, then you say...

(In reply to comment #7)

In addition, I do think this does have something to do with GlobalBlocking.
Before I started using GlobalBlocking on my own (private) wikis, local
rangeblocks were effective.

Before (at bug 37481 comment 3), you said...

[...]

I doubt GlobalBlocking is the problem here. I don't know if I can reproduce it
on my own wikis since they don't use 1.20wmf5.

So, no, I don't think we can safely mark as a dupe right now. You seem a bit conflicted about where the problem is and the symptoms seem distinct.

Regarding this particular bug, I thought there was some kind of historical exemption for global blocks for Meta-Wiki so that Meta-Wiki could act as a court of last resort or something. Am I wrong about that? It may end up meaning more work for stewards, but I'm not sure global blocks not applying at Meta-Wiki (in particular as it's a global hub wiki) is a bug, per se.

(In reply to comment #8)

(In reply to comment #6)

I think we can mark this as a dup of
https://bugzilla.wikimedia.org/show_bug.cgi?id=37481

Well, then you say...

(In reply to comment #7)

In addition, I do think this does have something to do with GlobalBlocking.
Before I started using GlobalBlocking on my own (private) wikis, local
rangeblocks were effective.

Before (at bug 37481 comment 3), you said...

[...]

I doubt GlobalBlocking is the problem here. I don't know if I can reproduce it
on my own wikis since they don't use 1.20wmf5.

So, no, I don't think we can safely mark as a dupe right now. You seem a bit
conflicted about where the problem is and the symptoms seem distinct.

---

Regarding this particular bug, I thought there was some kind of historical
exemption for global blocks for Meta-Wiki so that Meta-Wiki could act as a
court of last resort or something. Am I wrong about that? It may end up meaning
more work for stewards, but I'm not sure global blocks not applying at
Meta-Wiki (in particular as it's a global hub wiki) is a bug, per se.

(I'm rescinding my previous statement with that comment)

(In reply to comment #8)

Regarding this particular bug, I thought there was some kind of historical
exemption for global blocks for Meta-Wiki so that Meta-Wiki could act as a
court of last resort or something. Am I wrong about that? It may end up meaning
more work for stewards, but I'm not sure global blocks not applying at
Meta-Wiki (in particular as it's a global hub wiki) is a bug, per se.

Or even more than a court of last resort, really: if you globally block a range like this, where do people report issues or errors with the block?

This bug is currently marked high importance, major bug, but I'm not sure there's any evidence of that. Is there any evidence of edits or actions post-local Meta-Wiki block on this range?

Global blocks are not supposed to apply at Meta-Wiki. So that's not really a bug. But if, after you also locally blocked the range, there are edits, that would be a major bug. I haven't seen any evidence of this.

I _think_ there's a generic issue here where blocked individual IPv6 (and maybe v4 as well) addresses don't "know" or don't _report_ that they're blocked everywhere you might check. But, again, if it's just a reporting issue and there the local block is working as expected (and the global block is also working as expected for that matter), then the priority/importance of this bug can be dramatically lowered.

(In reply to comment #6)

I think we can mark this as a dup of
https://bugzilla.wikimedia.org/show_bug.cgi?id=37481

I'm not sure about that. Of course, it's possible. But I had the impression that local IPv6 blocks ánd global blocks were working; only on meta I saw problems.

(In reply to comment #11)

This bug is currently marked high importance, major bug, but I'm not sure
there's any evidence of that. Is there any evidence of edits or actions
post-local Meta-Wiki block on this range?

Global blocks are not supposed to apply at Meta-Wiki. So that's not really a
bug. But if, after you also locally blocked the range, there are edits, that
would be a major bug. I haven't seen any evidence of this.

I _think_ there's a generic issue here where blocked individual IPv6 (and maybe
v4 as well) addresses don't "know" or don't _report_ that they're blocked
everywhere you might check. But, again, if it's just a reporting issue and
there the local block is working as expected (and the global block is also
working as expected for that matter), then the priority/importance of this bug
can be dramatically lowered.

Actually, it is a major bug. I saw it happening multiple times and I can give you the evidence if you want. To proceed with the original example of the abuse of IPv6 address 2605:8900:5000:1001:6:0:E:2. Here's the timeline:

• 1 Nov 2012 12:40-12:42 - he vandalized on meta with 2605:8900:5000:1001:6:0:10C:2 (edits hidden) and therefore I decided to locally block the IPv6 range on meta -> http://meta.wikimedia.org/wiki/Special:Contributions/2605:8900:0:0:0:0:0:0/32 (this range was already globally blocked by Jyothis in July 2012 for a year)
• 5 Nov 2012 10:34-10:39 - he continued on meta with the account "MoìraMoìraMoìra" (https://meta.wikimedia.org/wiki/Special:Contributions/Mo%C3%ACraMo%C3%ACraMo%C3%ACra); a checkuser looked at the underlying IP and it turned out to be 2605:8900:5000:1001:6:0:E:2 (which falls in the /32 range I already blocked on 1 Nov 2012). It was a hardblock, so in theory no one should be able to create an account and use it on meta... it did happen though.

I have no evidence that it happened on other projects outside meta, but it's not impossible of course. And yes, the rule still stands that meta is the only project not affected by global blocks, but as I locally blocked this range and the vandal was still able to create and use accounts... that's just wrong.

(In reply to comment #12)

(In reply to comment #6)

I think we can mark this as a dup of
https://bugzilla.wikimedia.org/show_bug.cgi?id=37481

I'm not sure about that. Of course, it's possible. But I had the impression
that local IPv6 blocks ánd global blocks were working; only on meta I saw
problems.

True, global blocks appear to be working. However, my experiment on testwiki shows that it isn't limited to Meta only.

ipb_range_start and ipb_range_end have the wrong field size on 675 out of 863 wikis, and metawiki happens to be one of those 675. They seem to be using varbinary(8).

I'm not sure how the field came to be so small. It was introduced as varchar(32), and expanded to tinyblob in MW 1.8.

Added Asher to the CC list.

I'm writing a script to fix this.

Fixed.

afeldman wrote:

(In reply to comment #16)

Added Asher to the CC list.

FWIW, the only migrations I ran to prep for enabling ipv6 traffic were against SecurePoll, GlobalBlocking, and recentchanges, from working off of http://www.mediawiki.org/wiki/IPv6_support_roadmap.

(In reply to comment #19)

(In reply to comment #16)

Added Asher to the CC list.

FWIW, the only migrations I ran to prep for enabling ipv6 traffic were against
SecurePoll, GlobalBlocking, and recentchanges, from working off of
http://www.mediawiki.org/wiki/IPv6_support_roadmap.

I also thought you ran migrations in ipblocks per http://wikitech.wikimedia.org/view/Server_admin_log/Archive_20#May_16