Terminal 28

Ave! This is the concluding part of the ESPeriments with Nginx series, where we’ll talk about testing out the HTTPS bits and wiring things up on the ESP8266 end to use HTTPS also. First off, we’ll need to test out the HTTPS API endpoint. Before doing this, I’ll assume the server (web) app is running and the Nginx proxy has been suitably configured (and includes the HTTPS directives as discussed in the previous post). Essentially, we’ll need to simulate HTTP and HTTPS requests to the API endpoint and see the response behavior and codes. There are an eclectic mix of tools to do this sort of work (e.g Postman, etc), but we’ll be using Fiddler by Telerik, which (IMHO) is a solid piece of kit. We’ll use Fiddler’s Composer tab to create a suitable request to the API endpoint. Essentially, the server (web) app is designed to receive a POST request whose payload is the JSON representation of a request object – which should contain a field called “Tag” for purposes of illustration. Here’s a

Aaaaaaand we’re back! Right, so we’ll kick off from the last post, where we’d gotten the basic stuff up and running. The next thing to do was to secure the server with SSL. This was necessary because it was necessary to bulletproof some parts of the system,specifically the API endpoint. A hypothetical attacker could seek to compromise the API-bound authentication process by performing a man-in-the-middle (MITM) attack where he’d/she’d have a machine pretend to be the auth server, and would configure the fake machine to respond favorably to any tag of their choice, and possibly even deny other tags. With SSL, the client would be able to verify the identity of the remote auth server, which would be a huge plus. Note that there are other ways of attacking such a system, but I will not enumerate them here. This scenario naturally provided two salient points: one, the API endpoint absolutely needs SSL. It then stood to reason that (at least initially) the API endpoint would need to be con

*rises from coffin* I have returned from the dead insanely-busy (I know that’s not a real word) ! Hope you guys have had a swell time. Been doing lots of work on stuff,  both personal and professional so I’ve had very little time to settle down and write. Luckily I just completed a milestone project so I had some time to kill. *sips Pina Colada* Today’s post will be a bit lengthy – to make up for lost time . But first, some context. I spent most of January working on a small IoT sort of solution. I won’t go into specifics, but the salient points involved using an ESP12-E module to make requests to a local server (a server on a local network not the internet). For the uninitiated, the ESP12-E module is a cheap (~$3) WiFi-enabled microcontroller…thing. It runs at 80MHz, has up to 4MBytes of flash space and has ~8 GPIOs. It is also Arduino-compatible, so you can get up to speed fairly quickly with it. There are excellent guides on the net describing how to wire the thing up, how to c

Hail, people! Continuing on from last time, I had a little time to muck about with the IoT pHAT to try to get a general idea of how well it worked. What I did was to test out WiFi only, BT only, then WiFi + BT. I’ve described them as Tests 1, 2 and 3 respectively below. These tests were carried out on a Raspberry Pi Model B+ running the 2016-11-25 version of the Raspbian Jessie Lite distribution. Test 1 For the WiFi only test, I placed the pHAT on a B+ and edited the /etc/wpa_supplicant/wpa_supplicant.conf file to (auto)connect to my home WiFi network. Did a reboot, and voila, the ‘raspberrypi’ entry showed up in the router’s DHCP table. I was able to login via SSH and transfer a few files using WinSCP. Overally it performed flawlessly here – the connection was rock solid and performed satisfactorily. I didn’t run any iperf tests though – this is because I don’t intend to use the pHAT for any applications where throughput is an issue anyway. But I don’t expect it to be (signific

Howdy, folks. Hope everyone has been okay and has had a good week. Its Friday again! So my first proper post of 2017 is about the IoT pHAT from RedBearLab, which (if you can recall) I was supposed to review. Due to issues with the HAT firmware that was not possible for quite some time. In the early hours of January 12th, a firmware update was made available which purportedly fixed the issues. On testing it myself, I found this to be the case. So let’s talk about how to get up and running with it. Typically, you’d want to start at this page , but there’s alot of information in there, some of which (thus far) doesn’t seem necessary anymore, so I’m going to try to keep it as linear as I can. First off, you’ll need an IoT pHAT – not surprisingly. I backed their crowdfunding campaign, but you can now buy one on the RedBearLab store if you don’t already have one. You can get one of two versions – one with headers presoldered and one without headers presoldered. I chose the former version.

Hello there! Its been a while. Happy New Year everyone! Here’s wishing us all a happy, healthy and prosperous one. I’m sorry I’ve been gone for so long. Got tied up with a thousand and one things, and time just got away from me. As part of my catch-up efforts, The fourth Element14 post is up and is available here . In addition, I have a small hardware project in the works and should be talking about that soon. I’m also expecting some new hardware and will likely be talking about that quite a bit in the weeks to come. All in all, I’m excited about 2017 and I hope you are too. Once again, Happy New Year! See you shortly..