I owe Optus an apology

We just switched our Optus Cable service across to their "speed pack" which supposedly gives us 10x the bandwidth.  To do so, we needed to upgrade the modem from the old Motorola Surfboard 3100 to a Netgear CG3000 which has a built-in router and does Wifi.

Our home network is more complicated than normal but I copied across all the appropriate config, rebooted all the computers and it all just worked.  Well, almost all.

For some reason, Pauline's email would not connect.  Nor would Catriona's.  It didn't matter how I tried, it just wouldn't work.  When I tried configuring new accounts, they wouldn't work either.

I probably spent half an hour (over a few nights) ranting to the guy on support that "I do networking for a living, I can see that its your mail server not responding to POP/SMTP when I use TELNET to the appropriate servers and do the protocol by hand".

Today, sheepishly, I realise that "hmmm, the IP address we are using is a class-B, but the subnet mask we have configured is a class-C".  Surely that couldn't cause this symptom, it didn't upset the old modem.  Hmmm, this is a modem *and* a router.  Oh dear...

So, I fixed our network config to use legitimate class C IP addresses, Pauline pushed the Get Mail button and down came her mail.  Problem solved.

My only excuse is that my old router allowed me to configure a proper class-B subnet mask - the Netgear has the subnet mask locked at class C, but I didn't pay attention when I was entering the numbers. Tomorrow, when Optus Support rings me back, I have to take hat in hand and admit my error.

The moral: if you want to use anything other than the default 192.168.1.* network that your modem manufacturer, or your ISP expects you to use, make triply sure that you have configured it right.  Because getting it wrong is hellishly difficult to debug, especially for the poor bastard at the other end of the phone that doesn't know how clever you think you've been.

unexpected precompiled header, simply rerunning the compiler might fix this problem

This post is about Microsoft's answer to the IT Crowd and their "did you try turning it off and on" running gag.

For years, we (at work) have been plagued with this particular error that seemed to happen spontaneously, hang around for a while then disappear, and today (with the help of Google) I've been able to track down an actual answer.

Microsoft explains the embarrassing truth here.

In a nutshell, precompiled headers are implemented cheaply as a straight memory dump complete with physical memory addresses.  When the compiler subsequently tries to read them back, ASLR has potentially scrambled it's little brain.

There are lots of fixes mentioned around the net, of varying levels of quality and security.  Microsoft has a hotfix but it only solves the problem for Visual Studio installs - we build using the Platform SDK.

For me, the sanest approach was:

• download and install EMET from here
• use EMET to disable "MandatoryASLR" and "BottomUpASLR" on the C compiler (cl.exe)

This leaves you with ASLR enabled for everything but the C compiler which doesn't cope.

Note, this has no impact on the output of the compiler - your programs will still be ASLR-enabled or not, depending on what switches you pass on the command line.  All we are doing here is fixing the actual compiler itself...

---

I hoped I'd never have to revisit this post, but today I had to. Looks like EMET can cause quite a bit of damage when you run it.

I tried using EMET 5.2 and it did resolve my problems with the C compiler.  As collateral damage, however, it took out Microsoft Office, AutoCAD 2011-2016, and even Internet Explorer.  Every one of them reported a vanilla error message "Attempt to access invalid address".

This looked to me to be related to either Data Execution Protection or perhaps to ASLR.  However, even though I completely disabled both of those features (through EMET), it didnt' help.  I've restarted so many times today you would not believe it.  Uninstalling EMET changed nothing.  I sat and manually uninstalled every Windows Update that had been applied in the last 48 hours and still no joy.

Eventually this post on the Microsoft Forums pointed me at an obscure registry entry and lo, it fixed the problem.  It would appear that EMET automatically puts in registry entries when it is installed, and does not remove them when it is uninstalled (no surprise there).

So, the fix was to go to

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options

and locate the application I was trying to use.  I removed the troublesome keys and voila, my apps work again.  (Actually, for many, I just removed the value for MitigationOptions which was 0x0000100)

Note: this is not something that you should attempt lightly.  No warranty implied or assumed.

---

Take Three.

It looks like the damage that EMET does is like herpes.  Every time I update Microsoft Office (ie, apply office updates), I need to go back in and patch up the registry settings again.  No idea why.  This must be that "my PC is so broken it needs to be reformatted and start again" that everyone talked about in the 80s.

Nexus 7 vs iPad Mini

Yet another comparison between the Nexus 7 and the iPad Mini. This is going to be my collection of notes to myself of stuff I notice as time goes by.

Physical Size

A number of people have commented that "its much bigger" (the iPad) seeing two devices side by side with their screens on, and it feels like the aspect ratio (width/height) of the iPad is more pleasing than the Nexus.

Screen

The screen on the iPad seems larger, which is no surprise because it is about 3cm wider and 2cm taller. However, I think the secret is that the iPad only shows 4 rows of 5 icons whereas the Nexus crams in 6 rows of 6 icons.

In terms of resolution, my old eyes aren't really picking a difference.

What is odd is that the iPad feels more natural to hold in landscape where the Nexus feels better in portrait.  Perhaps that's because it was only recently that Android coped properly with a portrait orientation launcher.  Or it could be the slight different in screen proportions.  The iPad Mini really feels like the bottom half of a "real" iPad, and for the most part, that feels like enough.

Keyboard

Both devices have context-specific keyboards that they flip in as required.  Only the Nexus is stupid enough to leave the '@' key off the URL keyboard, making it impossible to search for, say, steve@apple.com in the Google Chrome browser.  This is still true at Android 4.2

Maps+GPS

Big win for the Nexus - because it has a GPS chip on-board, and Google Maps can make large chunks of the mapbase available offline, you can prepare for a days walk around Paris by pre-caching the map, then relying on the on-board GPS to let you know where you are.

Stop press:  I took it out for a walk today and it looks like the offline'd maps had un-offlined themselves.  I stood in the Camberwell Market waiting for the Maps app to wake up, and it never did.

And it looks like Apple have done something spooky where they seem to be able to get location *without* a GPS chip onboard, if you are in sight of civilisation.  This probably depends on how well they have mapped the area you are in, but for wandering Paris, I'm wondering if the iPod Touch won't be sufficient.

Wifi

Comparing the iPad Mini against both my iPad1 and the Nexus, the Mini does not seem to have the same range as the others.  There are rooms in the house where the Mini sees no signal while the other two get enough to work.

Stop press: buying an Airport Extreme made it possible for the Mini to see the farther rooms in the house. However, the Nexus does not see the 5GHz bands, only the 2GHz ones, whereas the Mini is fine with both.

Calendar Application

To be fair, by the time I wrote this section, I don't own the Nexus any more, it moved on to my mother who is 80% happy with it, except when it goes stupid for no apparent reason.

iCloud synchronises all my contacts & calendars without causing any grief whatsoever across multiple devices. (iPod/iPad/iPad Mini)

Android has dropped all knowledge of Mums Google Calendar multiple times now, and Internet Wisdom™ suggests that the fix is to "delete the local calendar data, disconnect syncing, reconnect syncing and wait".  Not something that the novice user wants to do.  In fact, there are a disturbing number of posts that suggest that when these things go wrong, "reset the device and reinstall everything from scratch".

mDNSResponder running rampant

So, this morning I took at look at my Mac and noticed that Little Snitch shows that someone is doing almost constant network traffic out.  Looking in the Network Monitor, it appears that mDNSResponder is sending almost constantly to our DNS server.

Useful tip 1:  To debug what mDNSResponder is doing, use the following:

sudo killall -SIGUSR1 mDNSResponder

and then take a look in the Console log.  This is a toggle so do the same command to disable the extended logging.  (Thanks to http://krypted.com/mac-os-x/mdnsresponder-mdns-and-dns-sd/ - I could have just read the man page (man mDNSResponder) but who has time to read local documents when you have Google?)

Some internet pages suggest you can get this symptom if you have a misconfigured DNS server that does not report errors correctly. This does not appear to be the problem for my ISP (Optus).

In my case, the log showed messages like this:


26/01/13 9:55:50.819 AM mDNSResponder[40]:  24: DNSServiceQueryRecord(35000, 0, 1.0.0.127.in-addr.arpa., PTR) START PID[264](LogMeInGUI)
26/01/13 9:55:50.820 AM mDNSResponder[40]:  24: Error socket 72 closed  00000000 00001005 (0)
26/01/13 9:55:50.820 AM mDNSResponder[40]:  24: Error socket 72 created 00000000 00001006
26/01/13 9:55:50.820 AM mDNSResponder[40]:  24: DNSServiceQueryRecord(35000, 0, 1.0.0.127.in-addr.arpa., PTR) START PID[264](LogMeInGUI)
26/01/13 9:55:50.820 AM mDNSResponder[40]:  24: Error socket 72 closed  00000000 00001006 (0)

Hmmm, LogMeIn?  Don't I have that switched off?

I checked the LogMeIn control application and yes, it definitely shows as "Off" - that's the normal state for me.  On a hunch, I turned it "On" and immediately the mDNSResponder traffic ceased.  Turn if "Off" and mDNSResponder again starts sending.

So, LogMeIn, when turned off, generates more network traffic than when it is turned on and idle.

I've reported it to LogMeIn.com - we'll see what happens.  For now, I'll probably uninstall.