Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

The website in question is Ingress Intel. You probably won't be able to access it unless you have been invited to Ingress, but you don't need to because I can relay all errors and problems here.

When I access the site on any version of linux, the underlying Google Map loads, but other server assets do not. The asset calls are ajax calls to the following url: and the full curl request is as follows:

curl "" -H "Accept: application/json, text/javascript, */*; q=0.01" -H "Referer:" -H "Origin:" -H "X-Requested-With: XMLHttpRequest" -H "User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.63 Safari/537.31" -H "X-CSRFToken: 8rL0UkKhAVDq1rjkUPyWZ69R6DAuHY9A" -H "Content-Type: application/json; charset=UTF-8" --data-binary "{\"method\":\"dashboard.getThinnedEntitiesV2\",\"minLevelOfDetail\":-1,\"boundsParamsList\":[{\"id\":\"01202303221220\",\"qk\":\"01202303221220\",\"minLatE6\":45367584,\"minLngE6\":14414063,\"maxLatE6\":45398450,\"maxLngE6\":14458008},{\"id\":\"01202303221222\",\"qk\":\"01202303221222\",\"minLatE6\":45336702,\"minLngE6\":14414063,\"maxLatE6\":45367584,\"maxLngE6\":14458008}]}"

Now, what happens is not an error - instead, the requests never complete. After a while they'll time out and change from pending to canceled, but essentially, no response is ever given in the browser.

enter image description here

Now, I say "in the browser", because when I curl that line up there, I get the following:

<!DOCTYPE html>
<html lang="en">
  <meta http-equiv="content-type" content="text/html; charset=utf-8">
  <meta name="robots" content="NONE,NOARCHIVE">
  <title>403 Forbidden</title>
  <style type="text/css">
    html * { padding:0; margin:0; }
    body * { padding:10px 20px; }
    body * * { padding:0; }
    body { font:small sans-serif; background:#eee; }
    body>div { border-bottom:1px solid #ddd; }
    h1 { font-weight:normal; margin-bottom:.4em; }
    h1 span { font-size:60%; color:#666; font-weight:normal; }
    #info { background:#f6f6f6; }
    #info ul { margin: 0.5em 4em; }
    #info p, #summary p { padding-top:10px; }
    #summary { background: #ffc; }
    #explanation { background:#eee; border-bottom: 0px none; }
<div id="summary">
  <h1>Forbidden <span>(403)</span></h1>
  <p>CSRF verification failed. Request aborted.</p>


<div id="explanation">
  <p><small>More information is available with DEBUG=True.</small></p>


This now, is where it gets interesting. This happens on every combination of linux and my internet connection. I tried loading it on a Macbook with OS X connected to my WiFi, on my desktop with Windows 7 connected via Ethernet, and it works. But if I try to open the site with either Ubuntu on the Macbook via WiFi, Mint on my laptop via WiFi, Mint on my desktop via Ethernet, or my Android phone - it suffers from the same problem again. This has been tested on IE, Chrome 26+, Firefox and Safari on all the systems (with IE having been tested on Win only).

If I take my linux machines anywhere else and use their connection, however, it works like a charm. If I tether my computers to my phone and use the mobile data connection, that works too. Only the very specific combination of Linux + my internet connection causes this problem. I even tried installing Windows7 and WindowsXP in a VM on the Mint laptop just to see if opening it from IE on the Windows VM would work, and it doesn't.

The router and firmware in question are these:

The issue has already been discussed somewhat here but to no avail.

I'm ready to test any feasible combination you can think of.

share|improve this question
up vote 2 down vote accepted

The 403 errors you're getting for your curl-based requests show that you're not hitting the same server code path; they're a bit of a red herring in that respect.

The behaviour looks as if there was a problem with PMTU discovery between and you; your request is making it out, but the responses are dropped. The easiest way to figure out whether this is the case is to drop the MTU for your Linux machine's interface; it's likely that 1492 will be fine, but it could be lower than that (less common but occurring values are 1480, 1460 and 1454) - start low, see if that works, then work your way back up until it stops working; then, use the value you've found in your standard config (distribution-dependent).

To set the MTU, sudo ifconfig eth0 mtu 1454 (using the correct interface name, of course).

If this fixes your issue, the exact cause depends on your router model and config and your iptables or other firewall(-like) rules.

share|improve this answer
Hmm, that command breaks my internet connection until a reboot. – Swader Apr 23 '13 at 23:52
It would have, sorry @Swader. Fixed the command. – Gabe Apr 24 '13 at 9:33
By the gods, it seems to work! I'll test for the day and mark as correct if it persists, but could you perhaps edit the answer explain why this happens and what MTU actually does that's so different on linux from other OS? I'm genuinely curious now – Swader Apr 24 '13 at 17:53

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .