The Rinnai Control-R WiFi Module Sort of Sucks (and here's how to make it work)

At home we recently switched to a tankless water heater and we went all out on a fancy Rinnai RUR199IN condensing tankless heater with Control-R WiFi module.

The unit itself is great! Easy install, works amazingly, fantastic instructions, etc. The Control-R WiFi module though? WOW - that's some trash!

The main problem I had was getting the damn thing to stay on the WiFi network. I ended up with a blinking or solid purple light every time. I tried everything and resigned myself to the fact that I'd probably have to call support when I tried one last thing - and it worked.

Here's what didn't work:

• Shouting and cursing
• Searching for other solutions online
• Disabling my Pi-Hole
  
• Changing network settings, checking firewall ports
• Allowing full access to my network
• Creating a dedicated, unauthenticated 2.4GHz WiFi network to test
• Praying to jeebus
• Resetting the module like 100x
  

Here's what did work:

 I created a new 2.4GHz WiFi network (I'm using TP-Link APs with their EAP Controller software), applied the same policy I apply for all IoT-only networks which allows internet, but no local LAN access (other than the pi-hole DNS server), and selected "TKIP" for encryption rather than "auto" or "AES". THAT WAS IT!

Seriously - there's obviously a bug in the WiFi module that can't actually use AES encryption and it needs to be forced to a TKIP-only system. Annoying, but given that this will be the only thing on this network in my house and I can now restrict that network to just that MAC address, I'll consider it 'safe enough' to not really care about. ...frustrating though!

TL;DR

The Control-R WiFi module only works with TKIP encryption. It's stupid and Rinnai should feel bad about this.

I recommend putting it on a dedicated 2.4GHz network as I noticed they have an 'alternate setup page' that uses http (yeah, no TLS) and it asks for your WiFi password. Clearly, security isn't a priority for Rinnai :-S

Resolving "Key not valid for use in specified state" Error When Importing Registered Servers In SSMS

I love SQL Server Management Studio (SSMS). Is it the best tool out there? Debatable. But when you add SSMS Tools Pack and SQL Sentry Plan Explorer it's pretty hard to beat IMO. It's also usually pretty stable and reliable for me and since I spend most of my day with it open I can't complain. ...but then I re-imaged my work box.
It was time to upgrade to the latest OS and Visual Studio editions at work so why not start over clean, right? Right.
After backing up everything I needed I was off and running and re-loading all my beloved tools when it came time to import my old registered servers list. I thought I was clever; I backed it up "with login and password info" to make life easier. All was well until I imported the file and got the dreaded error message: "Key not valid for use in specified state"
Oh. No.

Of course, the servers then showed up but on closing and re-opening SSMS (2008 R2) my registered server list was blank. CRAP!

Luckily I knew where this info was stored and I navigated to %appdata%\Microsoft\Microsoft SQL Server\100\Tools\Shell\RegSrvr.xml
Upon opening the file in Notepad++ I jumped found the servers that had been setup with SQL Logins and started modifying...

1. I removed the encrypted password and uid=xxx bits from the "ConnectionStringWithEncryptedPassword" element.
2. I added "trusted_connection=true;" to the connection string modified in step 1
3. I changed "PersistLoginNameAndPassword" to "PersistLoginName" in the "CredentialPersistenceType" element.
4. I saved the file and crossed my fingers...

Success! I opened SSMS and had no error. My registered server list was intact and all was right with the world. Of course, the login info for a few servers will need to be corrected, but that's much less work than re-registering a pile of servers.

I hope this info will help others in the same boat :)

-A

SQL Permissions - The Case of the "Token-based server access violation"

I managed to create and then fix my own PEBKAC issue today and I thought I'd share the resolution in case it helps someone else out there Google-ing/Bing-ing for the solution.

The problem is failed logins and in your SQL error log you'll see entries like this:
Login failed for user 'DOMAIN\user'. Reason: Token-based server access validation failed with an infrastructure error. Check for previous errors. [CLIENT: xxx.xxx.xxx.xxx]
Error: 18456, Severity: 14, State: 11.

You might see these sorts of errors when you've got domain problems or kerberos issues, but that's not the case here. You can eliminate those issues if others can log in or if the broken user/users work when you grant them sysadmin server role membership.
Since granting anyone sysadmin (even on a dev box) just isn't acceptable in my world I had to dig deeper. It turns out that the real problem was that at some point I had denied CONNECT SQL to the DOMAIN\Domain Users group. DOH!
Probably not a common thing to do but this problem would manifest itself if you had done the same thing on other groups. Maybe you have a group of accountants you don't want poking around in the db, or a group of nosy developers and you revoke CONNECT to their AD group. Then the exception arises and someone needs access but they just can't connect despite you granting them permission. Look for that deny setting and you'll be all set.

Cheers!

-A

A little C++ Never Hurt Anybody

As a good friend of mine would agree to, C and I had have a rocky past. I'm still not sure I like C/C++ and all it's nasty pointers and buffers, but I absolutely do respect it. I just find it convoluted and annoying to read personally and love how easy C# makes things. I'll take C# over C++ any day of the week and twice on Sundays... :p

Anyway, there comes a time in every tech geeks life when they go to use a FOSS product and realize it doesn't do quite what they need. This recently happened to me with a very cool media centre project - OpenELEC.
It's a really, really quick booting stripped down Linux based XBMC setup that's optimized for different platforms (like x64 Atom CPU and Nvidia ION graphics). The whole install is ~90MB and it'll run of a MicroSD card, USB, stick, etc. I'm very impressed with it and recommend anyone who likes XBMC check it out. I digress.

So OpenELEC is great and all, but I'm still a huge fan of using an Xbox 360 wireless remote to control things and this is where it fell down. The Linux xpad kernel driver isn't the best, and the SDL joystick code in the XBMC version that ships with OpenELEC is straight up broken when it comes to the 360 wireless controller.
This is where my old friend C and I met again. In digging through event captures, debug logs, and source code I was able to find the code that was causing my problem. Then I got rough. I cut out blocks of code that weren't called, I stubbed out procedures that weren't needed, and I hack-hack-hacked my through some changes to produce a file that not only compiled, it worked!

All in all it was a great learning experience both for working with Linux systems as well as C++ and I can honestly say I enjoyed it. And because I fixed this myself the victory is that much sweeter.
If anyone is interested I shared the changes here on the OpenELEC forums. Now excuse me, I've got some stunning HD content to watch on my now fully functional Asus 1012p EeeBox media centre. ;)

-A