Cleaning up some VMs this evening and wanted to mount a RAW disk partition I’d been using with an old VM. Surprised to find that a simple ‘mount’ wouldn’t do the trick. Fortunately pretty easy thanks to the info at the following link – use parted to get the offset and add that as one of the mount options.
https://askubuntu.com/questions/236263/browse-img-without-mounting
While working with my Chamberlain MyQ Garage Door Opener the other day, I ran into issues getting hostapd to work on Kali with the chap ass Netis WP2120 nano USB adapter I had (based on the RTL8192cu chipset/driver). I need to clear off a few browser tabs and eventually see if I can get hostapd working with this adapter on a different box (VM) for testing. A few of the links I worked with unsuccessfully, but provide some useful information.
Installed usbutils for lsusb
Installed hostapd
Installed iw
Installed lshw
Ran through steps at https://adamscheller.com/systems-administration/rtl8192cu-fix-wifi/, minor issue with “linux-headers-generic”, skipped it for now.
Did receive a modprobe error, “could not insert ‘8192cu’: Device or resource busy”. lsmod shows the old rtl8192cu drivers active. Did a reboot. Correct driver modules now listed, though no device listing in ‘iw list’. Does appear in ‘lshw -c network’, and appears as wlan0 in ‘ip link list’.
Started in with hostapd steps from http://sarumait.blogspot.com/2013/11/ubuntu-wireless-hotspot-using-edimax-ew.html and from my previous testing on the Chamberlain page.
Attempted to start hostapd service which seemed to work, but didn’t see my SSID. Ran it interactive debug and got an “invalid/unknown driver ‘8192cu'”.
Instructions at https://github.com/pritambaral/hostapd-rtl871xdrv
Git cloned the above repository and the w1.fi repository listed. Got hostapd to build after installing dependencies (below).
apt-get install apt-file libnl-3-dev libnl-genl-3-dev pkg-config libssl-dev
apt-file not needed, but handy for looking up files that resulted in failures during make.
Ran the patch process noted at https://github.com/pritambaral/hostapd-rtl871xdrv
Ended up having some success after doing a ‘make dkms’ in the rt8192cu directory cloned from https://github.com/dz0ny/rt8192cu and setting the driver in my hostapd.conf to the rtl871xdrv
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).
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.
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
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
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.
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.
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.
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.
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.
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
You are currently browsing the archives for the Linux category.
