13 Dec 2015
Like most others, I treated Amazon’s dash button concept as a flight of fancy. Quickly dismissing it, I never bothered about the buttons. Until now!
Not long ago, I undertook the project of connecting my car garage to the internet. More than anything, it was to get my feet wet with the emerging IoT wave. After implementing it, I felt the need for a generic physical button to act as a trigger. I saw a few products online, but didn’t take the plunge due to the cost. Spending $40-80 for a button, didn’t seem right. Then I found an article, where someone had hacked the $5 Amazon Dash button and made it work as an IoT button. Voila!
I ordered one and followed the article to sucessfully set it up. The setup involves partially setting up the button and then detecting ARP probes.
I felt constant probe monitoring to be inefficient, so took a different approach to detect button presses. As I use Tomato firmware on my router, I was able to use the bundled DNSMASQ capability of script execution on probing. This has the advantage of running completely on the router without requiring a separate machine for probe program execution. I created firewall rules to reject DNS and HTTPS traffic generated by the button (REJECT instead of DROP, as button tries longer to get online with DROP). Dash button does not maintain persistent connections, instead upon pressing the button, it powers up and tries to connect to the Wifi. DNSMASQ detects this and using its dhcp-script option, I was able to trigger a custom shell script on this. The button tries to make internet connections, but the firewall rejects all such traffic.
One thing to notice is that the script trigger happens whenever DNSMASQ starts up, or the lease renews/expires. But as we are only interested in triggers when the button is actually pressed, we can employ the DNSMASQ_SUPPLIED_HOSTNAME environment variable to make this distinction. It is only supplied for actions when a host joins or resumes an existing lease, since this data is not held by dnsmasq’s lease database. So with this setup, I was able to use a push notification mechanism instead of the probe monitoring pull mechanism.
I’m happy with the functionality they provide for just $5. Give these little marvels a shot.
11 Sep 2014
The author of the famous LFTP tool, defines it as a sophisticated ftp/http client. After using it for a couple of months, I can now attest to that claim.
It is feature loaded and provide many niceties. Some of the features I use regularly are segmented downloads (splitting a file into parts and transferring those parts concurrently), queues,
directory download/upload and resume.
Quick reference:
Download a directory
mirror -c –use-pget-n=3 dir_name
c => resume
use-pget-n => segmented download with 3 chunks
Upload a directory
mirror -R -c –use-pget-n=3
Put current command in background
Ctrl-Z
Bring background job/command back
wait
Create an empty queue
queue stop
queue (if no queue exists)
Queue status (execute only if queue exists, otherwise it would create an empty queue)
queue
Add current executing command to queue
queue wait 0
Stop further queued actions (but keep current ones going)
queue stop
Start all stopped queues
Exit out of Lftp. Upon exit it automatically starts all stopped queues
It can use the SSH Agent to connect using already added keys. On my Raspberry Pi, I do the following for SFTP connection using SSH Agent
Start SSH agent
Add desired key to SSH agent (PS: On raspberry pi, need to execute ‘eval ‘$(ssh-agent)’)
lftp sftp://@
If it asks for password, hit ENTER. This should allow it to connect using the SSH agent.
08 Jun 2014
Discovered today that SSH reverse proxy option allows bypassing firewalls. It’s helpful in connecting to devices sitting behind a router with no port forwarding setup. E.g. If I need to SSH to my friend’s laptop, who has no port forwarding setup, I can ask him to SSH to my router using command:
ssh -NR 8000:localhost:22 root@MY-ROUTER-IP
Then I login to my router and the following command gives me shell access to his machine:
ssh -p 8000 root@localhost
Although, I setup SSH tunnel to my router in the example above, this is not required. This tunnel can be set up for any machine.
Please note that while using dropbear keys for password-less authentication between the two routers, the commands need to specify the dropbear identity key also.
30 May 2014
I use Gigaset C610-IP VOIP phone for my calling needs. I’ve hooked it up to Google Voice (using Simonics gateway) for free US calling. For my international (India) calling needs, I was using Localphone exclusively until recently. But as Localphone’s call quality decreased to sub par levels, I started looking around for alternatives. I could use Google Voice that cost just 2c/min but with Google declaring that they’ll shut down integration with 3rd parties, I looked around and settled on Callcentric. Callcentric costs 2.4c/min to India and the voice quality is excellent.
As both Google Voice and Localphone, support E.164 number format i.e. international code + area code + number, I never had the need to worry about dial plans and other stuff. I stored India numbers as 91xxxxxxxx and US numbers as either 1xxxxx or 10 digits directly without the 1. In dialing plans, I choose the setting – If number starts with 91 use Localphone, otherwise use Google Voice. This worked pretty well as Google Voice accepts 1xxxxx and 10 digit numbers for USA.
But with Callcentric added to the mix, I faced issues because it does not support ENUM format. Dialing 91xxxx, is not sufficient to call India! I must dial 01191xxxxx. Didn’t took long to figure that Gigaset offers very limited dial plan configuration options. But eventually, found a way to make it all work with the following settings:
Management > Local Settings: Choose country as USA and both international and local Code Number as 1. Select Yes for the option Predial long distance access code for VoIP calls.Telephony > Dialling Plans: Declare 2 dial plans i.e. 91 — Callcentric & 1 — Google Voice. Do not select Use Area Code option for both. Then under Code for VOIP line, enter 011 and choose Always.- Choose
Google Voice to be the default call out line.
What this accomplishes is that any dialed number starting with 91 or 1, gets 011 appended to it. 91xx to 01191xx helps to satisfy the Callcentric requirement, so India calling works fine. 1xx to 0111xx works fine as Google Voice accepts 011 + country code + number format. So, 0111<US 10 digit number>, works with Google Voice. You may be wondering that if area code is not to be selected then why did we use that option in 1. That option allows us to dial 10 digit US numbers i.e. without the 1 prefix and still make calls through Google Voice. The way it works is that seeing 10 digit number (not starting with 1), the area code triggers-in. So, it makes US 10 digit number 11 digit number by prefixing 1. Then the dial plan appends 011 to it, making it 0111<US 10 digit number>, which works with Google Voice!
Earlier I thought that due to the limitations of dial plan configuration, I’ll have to go the SipSorcery route. But this configuration works well for dialing international and US numbers (whether 1 prefixed or not). Happy with the current setup for now.
