I participate in Dogecoin mining, and at one point tried Bitcoin mining (in earlier days) but decided it wasn’t worth the tradeoff (electricity in Silicon Valley is expensive). Regardless of which “coin”, the overall problem I’m about to discuss is the same.
EDIT: As of 10:48 PDT, things seem back online (and reliably at that). I strongly doubt there will ever be mention of this outage publicly.
EDIT #2: Imagine that! Assuming you’re actually able to log in to Diablo 3 (not sure about other battle.net services), there is an incredibly (and obviously intentionally) vague message about “a problem”. I’ve included it here as a screenshot. I love the use of the phrase “the parties involved”; wouldn’t want to name any names and risk holding a provider responsible for the problem, would we? US politics, what a disgrace.
EDIT #3: mtr now shows what appears to be a great improvement; it looks to me like there was a network-level problem within AT&T’s own network near/around Salt Lake City that caused this. Of course, I would still love to know why my packets bound for the NS-WEST.CERF.NET nameserver go from the Bay Area to Los Angeles to Salt Lake City to Los Angeles to San Diego. Asymmetry doesn’t explain this either. Obviously AT&T has some kind of networking issue that they tried to route around (which caused this entire ordeal) but failed miserably. Wouldn’t be the first, 2nd, or even 10th time I’ve seen AT&T fail at this. Welcome to the Internet: it’s broken 24x7x365, no exaggeration.
Not sure when this issue began today, but I was able to confirm its existence around 09:45 PDT (that’s 9:45am Pacific).
None of Blizzard’s sites — including blizzard.com, battle.net, diablo3.com, as well as any subdomain under those — are resolving. I imagine this would affect any game or service Blizzard offers which uses DNS for resolution; hard-coded IP addresses (which I believe WoW uses for its server list) would not be affected, of course, but I believe WoW does use DNS for some portion of its authentication mechanism. In the case of Diablo 3, the behaviour is amusing — you might see a strange GDI-based “Checking for updates” box, then get the usual launcher dialog with no details in it, with “Play” greyed out. (Note to Blizzard: you should really improve the error handling in the D3 Launcher. The way this manifested itself, from a UI / end-user perspective, is absolutely atrocious!)
Today I was reviewing CVS commits to
ports, and I saw this flow across my screen:
Edit ports/security/unssh/Makefile Add delta 1.4 2011.10.18.22.35.18 pav Edit ports/security/unssh/distinfo Add delta 1.3 2011.10.18.22.35.18 pav Delete ports/security/unssh/files/extra-patch-unssh.sh.in
I immediately wondered what unssh was. Apparently it’s a shell script that modifies (removes lines from) your
~/.ssh/known_hosts file when run with the same arguments as
This immediately made me think “why is this even necessary when OpenSSH has framework to already accomplish this task”? Just edit your
~/.ssh/config and enter the following:
Host gw StrictHostKeyChecking no
The only difference here is that this will never remove the outdated (“offending”) entry in
~/.ssh/known_hosts and you will continue to see the nasty man-in-the-middle warning every time you SSH to the host “gw”. However, you’ll be able to connect regardless of the warning.
There’s really no harm in ignoring the nastygram when connecting to a machine you know is going to change its SSH identity keys all the time. Really — the person SSH’ing there will already be aware of that (the fact they would go and find/use unssh is proof of that).
Sadly there is no
-q equivalent in ssh_config(5), otherwise
StrictHostKeyChecking no and
Quiet yes would be a great combination for this exact situation.
The statement comes from Rob Pike, so I’m inclined to believe it.
If you’re a programmer and don’t know who Dennis Ritchie is, then you should have your programming license revoked permanently.
RIP, dmr. You will never be forgotten.
Since switching to Firefox many years ago I’ve had to deal with the idiocy that is the lack of “Print” and “Print Preview” context menus. For those not familiar with the term “context menu”, I’m referring to what you see when you right-click somewhere on a web page that isn’t a link; you know, Back, Forward, Reload, Stop, Bookmark This Page, etc… Some of the Firefox developers feel that Control-P is sufficient (possibly the same developers who though removing Control-E to switch text input focus to the Search Bar was an intelligent idea?).
Every time there’s a release I have to go through the annoyingly repetitious process of finding an Addon that addresses the lack of said context menu. With the release of Firefox 5, there are absolutely none which work with it — except one, which I’ll save for last.
Well this sure explains why Firefox is claiming the redirection will result in an infinite loop…
$ curl -i -s -S <b>http://get.adobe.com/reader/</b> HTTP/1.1 301 Moved Permanently Server: Apache/2.0.63 (Unix) <b>Location: http://get.adobe.com/reader/</b> Keep-Alive: timeout=5, max=500 Content-Type: text/html; charset=iso-8859-1 Accept-Ranges: bytes Connection: Keep-Alive Date: Thu, 09 Sep 2010 04:47:10 GMT Age: 248 Content-Length: 236
But every so often, you’ll get back something that works…
$ curl -i -s -S <b>http://get.adobe.com/reader/</b> HTTP/1.1 302 Moved Temporarily Date: Thu, 09 Sep 2010 04:47:11 GMT Server: JRun Web Server Content-Type: text/html; charset=UTF-8 Cache-Control: private, no-store, no-cache Content-Language: en-US Content-Language: en-US <b>Location: /reader/otherversions/</b> Set-Cookie: SETTINGS.LOCALE=en%5Fus;domain=.adobe.com;expires=Sat, 01-Sep-2040 04:47:11 GMT;path=/cfusion/ Set-Cookie: READER_HTTPREFERER=;domain=.adobe.com;path=/ Content-Length: 0 Connection: close
At Adobe, web services are hard. I wonder if they’ve been replacing their system administrators with monkeys.
Keep trying, guys. You’ll get it right eventually. Web services in 2010 are hard.
$ date Tue 31 Aug 2010 06:53:37 PDT $ curl -v -i http://www.facebook.com/ * About to connect() to www.facebook.com port 80 (#0) * Trying 184.108.40.206... connected * Connected to www.facebook.com (220.127.116.11) port 80 (#0) > GET / HTTP/1.1 > User-Agent: curl/7.20.1 (amd64-portbld-freebsd8.1) libcurl/7.20.1 OpenSSL/0.9.8n zlib/1.2.3 > Host: www.facebook.com > Accept: */* > * Closing connection #0 * Failure when receiving data from the peer curl: (56) Failure when receiving data from the peer
Hmm, what’s happening on a TCP level?
# tcpdump -p -i em0 -l -n -s 8192 "port 80" listening on em0, link-type EN10MB (Ethernet), capture size 65535 bytes 06:55:33.380449 IP 192.168.1.51.50324 > 18.104.22.168.80: Flags [S], seq 2661770843, win 65535, options [mss 1460,nop,wscale 3,sackOK,TS val 2499401659 ecr 0], length 0 06:55:33.482251 IP 22.214.171.124.80 > 192.168.1.51.50324: Flags [S.], seq 1390727061, ack 2661770844, win 4380, options [mss 1460,nop,wscale 0,nop,nop,TS val 3362678839 ecr 2499401659,sackOK,eol], length 0 06:55:33.482285 IP 192.168.1.51.50324 > 126.96.36.199.80: Flags [.], ack 1, win 16471, options [nop,nop,TS val 2499401761 ecr 3362678839], length 0 06:55:33.482416 IP 192.168.1.51.50324 > 188.8.131.52.80: Flags [P.], ack 1, win 16471, options [nop,nop,TS val 2499401761 ecr 3362678839], length 148 06:55:33.585188 IP 184.108.40.206.80 > 192.168.1.51.50324: Flags [R.], seq 1, ack 149, win 4528, length 0
Oh, TCP RST + ACK. Nice.