Here are some of the latest photos of the custom case that I made for the Smoothieboard. I didn’t like the old mounted system, so I decided to gut the entire case and create a new one. One of my buddies cut the aluminum rails (as he wanted to create a case for his CNC Mill’s computer as well), and I cut the plexiglass on the CNC table. The result wasn’t too bad.
Additionally, I printed a fan holder for the top of the case.
Here is the old case/holder for the Smoothie Board.
After some time, hacking the Wii U is finally possible. When I owned the original Wii with the old hacks on it, I could back up my games and play the copies from a hard drive. Now, you can do the same thing with the Wii U. Although I typically provide a walk through, I feel like this one isn’t going anywhere for a while. Follow the guide provided below for the steps on how to install Mocha CFW on the Wii U.
I just finished building my router table insert for combined workbench. The process was fairly simple. I used a jigsaw to cut the insert hole, and then used a router to create an inset pocket on the top to hold the Bench Dog router plate. To make sure that it was flush, I used the plate to set the depth of the router bit before cutting it out. The fence is still on the way, and I will need to create a pocket for the router bit. I decided to go with extruded aluminum from [8020.net](https://8020.net/shop/2040-s.html#). I will stack two of them and bore a hole through them so that I can mount that to the table surface and pivot on the right side. This will allow me to secure it from the other side, then open and close the fence as needed for cuts.
After installing a custom Android OS, I noticed that the tethering option was removed from the default WiFi menu. After doing a little reseach, I saw that some cell providers have also disabled this feature unless you “pay” for the service. In order to enable the WiFi tethering option again, all you have to do is add this line to your build.prop file. (I just downloaded a build.prop editor and you will need to be rooted)..
Save, then reboot and you will have the WiFi tethering option again.
We all suffer from crappy wireless reception in our homes. These days, too many people have WiFi and the airwaves are nothing shy of a horrible RF traffic jam. After doing some research, I decided to invest in the Google OnHub router. There were only a few things that I was looking for in the configuration; port forwarding being the top of my priority list. Google advertises that their product is a top of the line router… “Better. Faster. Router.” Although I don’t argue the fact that it’s an amazing piece of hardware, there are just a few things that you would expect in a router.
For starters; the setup was stupid simple. Simply plug it in, download the app and follow the very simple instructions. After about 10 minutes of updates and a few things to fill out, you are all set. There is on website to access, no 192.168.0(or 1).1, or other complicated setup procedures. If you want to change any of the settings, you simply can’t. It was designed so that your grandma could plug it in and get it working. Everything is in the cloud. The downfall is that, if you lose internet, you lose the ability to control your router…. even if you are home.
Here is where I realized that things weren’t right. My IP address for the internal network was 192.168.86.1. ???? 86? What is that? You can’t change it. My OCD was having a hard time dealing with that. Not a deal breaker though, I just had to go change ALL of my static IP assigned devices on the network to reflect the proper IP. And then I got to the port forwarding. So, I might be a bit lost here, but; if you have the ability to port forward, that would mean that you’s probably like to access something inside of your network from the outside (like a webserver, NAS drive, security cameras, etc.) For me, it was the web server. I get all of the port forwarding setup (which is weird, because the network inherently has DHCP, and the only way to have static is to setup DHCP IP reservations). Again, not a problem, easily accomplished with finding the device name and assigning an IP reservation to it. Once that’s done, you can configure port forwarding. Here is the catch. NAT loopback isn’t supported on the OnHub device. It took me a minute to realize what they’ve done here. Google has allowed port forwarding but disabled the ability for you to access your public IP address from within your own private network. (let that sink in). One of the MOST basic features of an stupid common and cheap router… NAT Loopback. So, in a nutshell, if you want to setup an awesome NAS drive, Plex Media server, in home security cameras, web server, or any other DDNS related hardware that would require your external IP address from within your network; you can’t. I’m sure I could try and access via a proxy server, but why? If I can’t access my own network from within my network, then that makes this awesome piece of hardware useless.
The plus side to this piece of hardware is that you can set it in bridge mode. After all of this, I disabled the wireless signals on my old Asus router and bridged the OnHub to be my wireless antenna. It’s not the best setup because I have two routers right now, but until Google fixes this, I don’t see a good future for the OnHub in my house.
After doing some research, I found that Google now offers a dynamic DNS service with their beta addition, ‘Domains‘. The transition was fairly simple, with a few minor hangups on some of the configuration. They have a fairly simplistic configuration page, but it’s highly customizable and clean. The only downfall is; there wasn’t a lot of documentation on the setup procedure and what was provided was didn’t cover a few topics that could make the process frustrating.
When reading about the DDNS setup, the guide refers to most everything with in the resource (www) as the subdomain. The guide alludes to the simplistic setup by adding an ‘@’ as in the sub domain block to setup the DDNS. After configuring your ddclient.conf and adding the domain name, you’ll notice that the update doesn’t work properly. Maybe it’s just me, but I don’t consider www as a sub domain (or maybe it’s all just a play on words in my own head). Anyway, to sum this part up, don’t use ‘@’; use www in the sub domain block to properly setup your DDNS configuration.
The configuration of ddclient.conf was another process all in itself. I am running my webserver on arch linux and maybe there hasn’t been a push for ddclient to have support for Google Domains yet. I tried using the recommended configuration for Google Domains, but that didn’t push any updates for DDNS to match my IP address. Long story short, I had to use the alternate configuration ‘without Google Domains support’ but making a slight modification to the use by adding the web for obtaining the IP address.
I had been receiving errors that I couldn’t get my IP address. Not sure if it was a local network NAT issue caused by my modem and router of if it was operator error, but regardless, the above configuration worked (sort of).
The last thing I noticed was; ddclient likes to have the password enclosed with the single quote marks. Note that all of the ddclient config examples (on their wiki and on Google Domains) doesn’t show these marks around the password. My recommendation is; add them! The end result of my configuration file for ddclient looked like this: