Technology Archive

Chamberlain MyQ Garage Door Opener Testing

Posted November 27, 2016 By Landis V

Got a great deal on some Chamberlain MyQ wifi garage door openers recently.  As I’m setting them up, I really want to see what kind of conversations they have, so I’ll be making a few notes.  As usual, I’ll be working with my VM setup, using Kali in this case.

I have a Netis WF2120 USB wireless adapter that I’ll be using under Kali.  The vendor/product code is 0bda:8176.  Planning to use Kali as an AP.  I installed hostapd on Kali with ‘apt-get install hostapd’.  Added a USB filter to pass the Netis through to the guest with ‘vboxmanage usbfilter add 2 –target kali –name NetisWIFI –vendorid 0x0bda –productid 0x8176’.  After shutting down and restarting the VM, my wireless adapter was available as wlan0.

Enabled root login for SSH on my Kali box as VRDE… sucked.  Slow and very unresponsive.

Created /etc/hostapd/hostapd.conf with approximately the following contents:
ssid=TheSSIDOfYourChoiceWillEndYourLifeTonight
wpa_passphrase=YeahPostThat
ctrl_interface=/var/run/hostapd
interface=wlan0
driver=rtl8192cu
channel=1
wpa=2
wpa_key_mgmt=WPA-PSK

Edited /etc/default/hostapd and configured ‘DAEMON_CONF=”/etc/hostapd/hostapd.conf”‘.

Attempted to start the hostapd service, got “Line 5: invalid/unknown driver ‘rtl8192cu'”.

Tried editing NetworkManager.conf and adding a keyfile configuration to exclude the MAC of the device, followed by restarting /etc/init.d/network-manager, without much success.  Yielded same error.

Ran a ‘modprobe -r rtl8192cu’ and attempted to restart the hostapd service with the same error.  Tried changing the “driver=” line to ‘driver=rtl871xdrv’ with the same results as well.

Remarked the “driver=” line in hostapd.conf and attempted to restart the service; got a little further, but still did not seem to start.

Went back to the instructions at https://bogeskov.dk/UsbAccessPoint.html.  The ‘apt-get install linux-headers’ was not successful on my platform, so ran ‘apt-get install linux-headers-4.6.0-kali1-amd64’ instead, which was already installed in my case.  Created and cd’ed to an rtl directory, then ran ‘git clone https://github.com/dz0ny/rt8192cu.git’.  Attempt to make drivers failed.

Ran an ‘apt-get update’ and ‘apt-get upgrade’ to see if I could get around the issue.  Seem to be issues with the 4.8.x kernel on Kali as well; system fails to boot using that kernel.  Have to come back to this one later, will create another post for hostapd with the rtl8192cu and see if I can come up with a better way to work around that problem.

Might be useful to take a look for the referenced article on burp from http://cybergibbons.com/security-2/quick-and-easy-fake-wifi-access-point-in-kali/ once I get hostapd on solid footing on its own (which is getting closer).

Additional Links

Be the first to comment

I hate it when I’m away from home and either the ISP or some of my equipment glitches, necessitating a reboot or two.  I have enough systems in place that I should be able to automate this process.  To do so, I need to get some remotely controllable equipment, create the state diagram (not good if I power cycle one of the network components required to reach the remote switch and it doesn’t come back up!), and write the scripts to run the logic.

I’d also like to have easily accessible power switches in my data closet so I can power cycle the devices without having to pull them down and unplug the power from the back of them.

Hardware components I’ve looked at

SainSmart 16 channel web relay – at Amazon.  This could work if installed between the transformer block and the switches.

Ethernet relay on eBay, claims to be AC250V @ 10A, though that would probably be pushing it.  Would have to look up the specs on the relays they used.  For the watt draw on the AC, depending upon the size, might be able to install it inside a large surge protector housing and wire the outlets through it.

Controllable Four Outlet Power Relay Module – at Adafruit.  Not network connected, and would require some other device to control it.  But most likely UL listed and designed to handle AC.

Ended up finding a Digital Loggers LPC-3 on eBay for $57 shipped that should do the job nicely.  Manual is here.

Be the first to comment

More 434MHz stuff to look at later

Posted August 20, 2016 By Landis V

Acurite #0899 self emptying rain gauge – at Amazon

Blog post on reversing the signal from Acurite temperature sensors; may be similar for the rain gauges.  Also mentions the RTL SDR.  Probably wouldn’t be bad to have.

Another blog post regarding reading the Acurite 5n1 station.  Possible that part of this will already cover the rain gauge.  Also discusses SDR and mentions the rtl_433 tool.

This blog post looks like rtl_433 supports the Acurite 896 decode natively, so if the protocol is similar or the same it may be simple.

RTL Software Defined Radio – at Amazon – seems like it’s probably a decent model, some good reviews.  Looks like there’s a little more to it than just “buy this and set up the software”.

Bought a cheap receiver off of eBay from Hong Kong for $7.31 (original listing).

Also, here was an Instructable about making a cheap combination RF/Bluetooth/433 MHz remote using an Arduino.

Additional Links

Be the first to comment

On Networks N150R Routers

Posted June 13, 2016 By Landis V

Picked up a couple of these from Newegg for free plus a couple of bucks shipping after rebate.  Figured that in combination with a couple of relays on the GPIOs, I could probably use them for switches or work with the serial port for a sensor connection.  Just a few notes on them.

OpenWRT 15.05 Chaos Calmer patched to expose the GPIOs:  https://micu.webserwer.pl/pmwiki/pmwiki.php?n=OpenWRT.Downloads

Forum thread on not flashing direct to 15.05.1; I went to 14.07, then to 15.05.  https://forum.openwrt.org/viewtopic.php?id=51576

OpenWRT Wiki page with device info including GPIOs https://wiki.openwrt.org/toh/netgear/wnr612v2

Controlling the GPIOs

From here, the simple way to control the GPIOs natively is with the “brightness” value for the LEDs.  By example for the LAN1 LED (others are in the same path):

root@OpenWrt:~# echo 0 > /sys/class/leds/netgear\:green\:lan1/brightness
root@OpenWrt:~# echo 1 > /sys/class/leds/netgear\:green\:lan1/brightness

Update 9/18/2016

Finally got the LAN2 LED peeled off of the board, had a heck of a time with it.  After doing so, I discovered that I only get ~2.5v across the pins when the GPIO is active… not enough to drive my 3.3v relays.  I assume they are probably using a voltage divider here.  Measuring the resistance between the positive and negative ends of the LED without power applied, I get about 1580 ohms one direction, and 670 in the other.  There appears to be a ~960 ohm resistor at CA111, but I haven’t figured out exactly how this ties in.

Update 10/9/2016

Spent some time with this again over the past couple of days.  I removed the resistor at CA111, but apparently it is not a divider.  May need to spend some time to see if I can make something work with a 2N7000 MOSFET or something like that, but I’m pretty novice so that will take some effort.

I did test out my 433MHz ASK receiver on the TTL serial port, but without much luck.  This OpenWRT page was helpful in getting stty installed and setting the baud rate on the serial port,

‘stty -F /dev/ttyS0 9600 clocal cread cs8 -cstopb -parenb’ to set the config, and
‘stty -F /dev/ttyS0 -a’ to verify the config

but still didn’t get any output.  I’ll have to give it a shot with my Raspberry Pi just to see if I can get anything out of there.

Be the first to comment

Purpose

I recently purchased an Ivation barbecue thermometer which is supposed to be a pretty decent similar build to the Maverick 733 (I believe).  Of course, one of the first things that comes to mind is how to tie this in to some type of IP connected system so I don’t have to rely upon the included receiver and its limited range, and can instead take advantage of wifi, Internet, and the smartphone I always have with me.  Turns out it should be pretty feasible in conjunction with the Raspberry Pi I already have plans to set up as a sort of garage controller.  That device will be connected by ethernet and will have a constant and reasonably close proximity to my smoker and grills already.  This post is for my notes on links that will be useful when (if?) I actually get around to making this work.

Software/code links and notes will come later, after I actually get the equipment to start testing.

About the BBQ thermometers

The Maverick (and presumably Ivation) transmit on the 433.92MHz frequency using OOK.  The Hackaday link to Bob Blake’s article below describes the communications protocols and encoding.

Links

 

Update 10/9/16

Spent some time trying to get this working with my On Networks N150R over the past couple of days without much luck.  May have to give it a try with one of my Raspberry Pi’s and see if I can get it working there, if for no other reason than to verify that the receiver module I purchased is functional and/or that I have it wired somewhat properly.

Be the first to comment

Setting up a PPPoE headend

Posted May 23, 2016 By Landis V

May come in handy.

http://packetlife.net/blog/2009/apr/20/configuring-pppoe/

Be the first to comment

More Pogoplug E02 uBoot Work

Posted April 30, 2016 By Landis V

I’ve written a few times about configuring Pogoplug devices to work with uBoot and Linux.  Recently I’ve run into some problems with one of my Pogoplug E02 devices, where it would no longer boot to the attached USB drive, and didn’t seem to be booting properly to the native firmware either.  Finally got around to looking at that a little bit in the past couple of days.

Since I wasn’t able to SSH to the device, I had to open it up and connect to the internal serial console.  I had already purchased a USB to TTL serial cable adapter based on the PC-PL2303HX chipset (similar to these), so I opened up the Pogoplug and modified a CD-ROM audio cable I had laying around to connect between the TTL adapter cable and the serial port on the board (opening and serial connection documentation here).

Once I was able to get consoled in, I determined that my USB drive was only being detected properly on a soft boot.  So pulling the power cable was doing me no good as far as getting it to boot, but if I issued a reset or reboot from the failed boot environment, it would detect the USB device correctly and boot up.  While the reset command was functional, it was not practical, as it would have required a perpetual serial connection and for me to issue a reset every time it lost power before it would come up properly.  I want it to reload to normal running state automatically.

I played around with the firmware environment variables for a bit before going ahead with an upgrade of my uBoot environment (I was on a 2011 version).  I followed most of the instructions including flashing the default uBoot environment variables.  I was still having some issues with the USB drive not being detected from a cold boot, but modifying the “scan_disk” environment variable appeared to provide a resolution.  I changed the “scan_usb” portion of the command from “usb start” to “usb start; sleep 3; usb reset”, and thereafter I was able to successfully boot from both a cold start and a warm start.  The full variable after changes was as follows:

scan_disk=echo running scan_disk ...; scan_done=0; setenv scan_usb "usb start; sleep 3; usb reset"; setenv scan_ide "ide reset"; setenv scan_mmc "mmc rescan"; for dev in $devices; do if test $scan_done -eq 0; then echo Scan device $dev; run scan_$dev; for disknum in $disks; do if test $scan_done -eq 0; then echo device $dev $disknum:1; if ext2load $dev $disknum:1 0x800000 /boot/uImage 1; then scan_done=1; echo Found bootable drive on $dev $disknum; setenv device $disknum:1; setenv bootdev $dev; fi; fi; done; fi; done

Finally, I made some modifications to allow the default Pogo OS to load in the event a drive with a “rootfs” label was not present.  I added a “pogo_bootcmd” environment variable and modified the “bootcmd_exec” as in the following.  This appears to be allowing the device to boot the defacto Pogo OS in the event the rootfs drive is not present, though I still had difficulties SSH’ing in with my Pogo portal configured account.

pogo_bootcmd=if fsload uboot-original-mtd0.kwb; then go 0x800200; fi
bootcmd_exec=mw 0x800000 0 1; run load_uimage; if run load_initrd; then if run load_dtb; then bootm 0x800000 0x1100000 0x1c00000; else bootm 0x800000 0x1100000; fi; else if run load_dtb; then bootm 0x800000 - 0x1c00000; else if bootm 0x800000; then echo Booting; else run pogo_bootcmd; fi; fi; fi
Be the first to comment