If you’re playing Hackaday Buzzword Bingo, today is your lucky day! Because not only does this article contain “Pi 3” and “IoT”, but we’re just about to type “ESP8266” and “home automation”. Check to see if you haven’t filled a row or something…
Seriously, though. If you’re running a home device network, and like us you’re running it totally insecurely, you might want to firewall that stuff off from the greater Interwebs at least, and probably any computers that you care about as well. The simplest way to do so is to keep your devices on their own WiFi network. That shiny Pi 3 you just bought has WiFi, and doesn’t use so much power that you’d mind leaving it on all the time.
Even if you’re not a Linux networking guru, [Phil Martin]’s tutorial on setting up the Raspberry Pi 3 as a WiFi access point should make it easy for you to use your Pi 3 as the hub of your IoT system’s WiFi. He even shows you how to configure it to forward your IoT network’s packets out to the real world over wired Ethernet, but if you can also use the Pi 3 as your central server, this may not even be necessary. Most of the IoT services that you’d want are available for the Pi.
Those who do want to open up to the world, you can easily set up a very strict firewall on the Pi that won’t interfere with your home’s normal WiFi. Here’s a quick guide to setting up iptables on the Pi, but using even friendlier software like Shorewall should also get the job done.
Still haven’t filled up your bingo card yet? “Arduino!”
There’s a great game of capture-the-flag that takes place every year at HITCON. This isn’t your childhood neighborhood’s capture-the-flag in the woods with real flags, though. In this game the flags are on secured servers and it’s the other team’s mission to break into the servers in whatever way they can to capture the flag. This year, though, the creators of the game devised a new scoreboard for keeping track of the game: a lightsaber.
In this particular game, each team has a server that they have to defend. At the same time, each team attempts to gain access to the other’s server. This project uses a lightsaber stand that turns the lightsabers into scoreboards for the competition at the 2015 Hacks In Taiwan Conference. It uses a cheap OpenWRT Linux Wi-Fi/Ethernet development board, LinkIt Smart 7688 which communicates with a server. Whenever a point is scored, the lightsaber illuminates and a sound effect is played. The lightsabers themselves are sourced from a Taiwanese lightsabersmith and are impressive pieces of technology on their own. As a bonus the teams will get to take them home with them.
While we doubt that this is more forced product integration advertisement from Disney, it certainly fits in with the theme of the game. Capture-the-flag contests like this are great ways to learn about cyber security and how to defend your own equipment from real-world attacks. There are other games going onall around the world if you’re looking to get in on the action.
There seems to be a hacker maxim that whatever gadget you are working with, it would be better to have several of them running together. That might explain the ESP8266 web server farm that [Eldon Brown] has built. Yup, a web server farm made from three of everyone’s favorite WiFi dongle, the humble ESP8266.
His page isn’t anything too fancy but it is impressive considering it is running on about $30 worth of hardware, including the breadboard it is wired into. The page includes dynamically-generated graphics and some back-end stuff. I don’t think that it will replace any LAMP servers anytime soon (the ESP8266 took about 2.6 seconds to generate the page below), but it is an impressive hack. [Eldon] has made the full code of the web server that is running the pages available. So, lets add web server farm to the list of things that this neat little device can handle, next to plant weigher, Bitcoin price tracker, MP3 player and many more…
We were delighted at a seeing 96 MacBook Pros in a rack a couple of days ago which served as testing hardware. It’s pretty cool so see a similar exquisitely executed hack that is actually in use as a production server. imgix is a startup that provides image resizing for major web platforms. This means they need some real image processing horsepower and recently finalized a design that installs 44 Mac Pro computers in each rack. This hardware was chosen because it’s more than capable of doing the heavy lifting when it comes to image processing. And it turns out to be a much better use of rack space than the 64 Mac Minis it replaces.
Racking Mac Pro for Production
Each of the 11 R2 panels like the one shown here holds 4 Mac Pro. Cooling was the first order of business, so each panel has a grate on the right side of it for cold-air intake. This is a sealed duct through which one side of each Pro is mounted. That allows the built-in exhaust fan of the computers to cool themselves, pulling in cold air and exhausting out the opposite side.
Port access to each is provided on the front of the panel as well. Connectors are mounted on the right side of the front plate which is out of frame in this image. Power and Ethernet run out the back of the rack.
The only downside of this method is that if one computer dies you need to pull the entire rack to replace it. This represents 9% of the total rack and so imgix designed the 44-node system to deal with that kind of processing loss without taking the entire rack down for service.
Why This Bests the Mac Mini
Here you can see the three different racks that the company is using. On the left is common server equipment running Linux. In the middle is the R1 design which uses 64 Mac Minis for graphic-intensive tasks. To the right is the new R2 rack which replace the R1 design.
Obviously each Mac Pro is more powerful than a Mac Mini, but I reached out to imgix to ask about what prompt them to move away from the R1 design that hosts eight rack panes each with eight Mac Minis. [Simon Kuhn], the Director of Production, makes the point that the original rack design is a good one, but in the end there’s just too little computing power in the space of one rack to make sense.
Although physically there is room for at least twice as many Mac Mini units — by mounting them two-deep in each space — this would have caused several problems. First up is heat. Keeping the second position of computers within safe operating temperatures would have been challenging, if not impossible. The second is automated power control. The R1 racks used two sets of 48 controllable outlets to power computers and cooling fans. This is important as the outlets allow them to power cycle mis-behaving units remotely. And finally, more units means more Ethernet connections to deal with.
We having a great time looking that custom server rack setups. If you have one of your own, or a favorite which someone else built, please let us know!
[Chris] has been playing with the Amazon Echo. It’s sort of like having Siri or Google Now available as part of your home, but with built-in support for certain other home automation appliances like those from Belkin WeMo and Philips. The problem was [Chris] didn’t want to be limited to only those brands. He had other home automation gear that he felt should work with Amazon Echo, but didn’t. That’s when he came up with the clever idea to just emulate one of the supported platforms.
The WeMo devices use UPnP to perform certain functions over the network. [Chris] wanted to see how these communications actually worked, so he fired up his laptop and put his WiFi adapter into monitor mode. Then he used Wireshark to start collecting packets. He found that the device detection function starts out with the Echo searching for WeMo devices using UPnP. The device then responds to the Echo with the device’s URL using HTTP over UDP. The Echo then requests the device’s description using that HTTP URL. The description is then returned as an HTTP response.
The actual “on/off” functionality of the WeMo devices is simpler since the Echo already knows about the device. The Echo simply connects to the WeMo over the HTTP interface and issues a “SetBinaryState” command. The WeMo then obliges and returns a confirmation via HTTP.
[Steve] was able to use this information to set up his own WeMo “virtual cloud”. Each virtual device would have its own IP address. They would also need to have a listener for UDP broadcasts as well as an HTTP listener running on the WeMo port 49153. Each virtual device would also need to be able to respond to the UPnP discovery requests and the “on/off” commands.
[Chris] used a Linux server, creating a new virtual Ethernet interface for each virtual WeMo switch. A single Python script runs the WeMo emulation, listening for the UPnP broadcast and sending a different response for each virtual device. Part of the response includes the device’s “friendly name”, which is what the Echo listens for when the user says voice commands. Since the virtual WeMo devices are free, this allows [Chris] to make multiple phrases for each device. So rather than be limited to “television”, he can also make a separate device for “TV” that performs the same function. [Chris] is also no longer limited to only specific brands of home automation gear.
There’s still a long way to go in hacking this device. There’s a lot of hardware under the hood to work with. Has anyone else gotten their hands (and bench tools) on one of these?
If you’re looking to build the next creepy Halloween decoration or simply thinking about trying out OpenCV for the first time, this next project will have you covered. [Glen] made a pair of giant googly eyes that follow you around the room using some servos and some very powerful software.
This part of the project is arguably the most interesting if you’re new to OpenCV; [Glen] uses this software package to recognize different faces. From there, the computer picks out the most prominent face and sends commands to the Arduino to move the eyes to the appropriate position. The project goes into great detail, from Arduino code to installing Ubuntu to running OpenCV for the first time!
We’ve featured some of [Glen]’s projects before, like his FPGA-driven LED wall, and it’s good to see he’s still making great things!
[Gnif] had a recent hard drive failure in his home server. When rebuilding his RAID array, he decided to update to the ZFS file system. While researching ZFS, [Gnif] learned that the file system allows for a small USB cache disk to greatly improve his disk performance. Since USB is rather slow, [Gnif] had an idea to try to use an old i-RAM PCI card instead.
The problem was that he didn’t have any free PCI slots left in his home server. It didn’t take long for [Gnif] to realize that the PCI card was only using the PCI slot for power. All of the data transfer is actually done via a SATA cable. [Gnif] decided that he could likely get by without an actual PCI slot with just a bit of hacking.
[Gnif] desoldered a PCI socket from an old faulty motherboard, losing half of the pins in the process. Luckily, the pins he needed still remained. [Gnif] knew that DDR memory can be very power-hungry. This meant that he couldn’t only solder one wire for each of the 3v, 5v, 12v, and ground pins. He had to connect all of them in order to share the current load. All in all, this ended up being about 20 pins. He later tested the current draw and found it reached as high as 1.2 amps, confirming his earlier decision. Finally, the reset pin needed to be pulled to 3.3V in order to make the disk accessible.
All of the wires from his adapter were run to Molex connectors. This allows [Gnif] to power the device from a computer power supply. All of the connections were covered in hot glue to prevent them from wriggling lose.