projects | pushover | github | twitter | rss | contact
September 2012

An Update on Pushover

posted to writings on sep 23rd, 2012 with tags android, ios, iphone, pushover, and superblock

It's been a little over 6 months since I released Pushover, the notification service with Android and iOS apps. I've been asked to post an update on how things have been going since then.

Shortly after the initial release, I received some great feedback from Chad Etzel, one of the creators of Notifo, the notification service that I used until it was shut down (which prompted me to create Pushover in the first place). Chad asked for Pushover to support sending messages with URLs that can open external apps, and Pushover soon gained supplementary URL support which required changes in the API and on both Android and iOS apps.

Continue reading 1,720 words...

March 2012

Building Pushover

posted to writings on mar 16th, 2012 with tags android, ios, iphone, pushover, ruby, and superblock

On March 7th, 2012, I announced the launch of Pushover, a simple mobile notification service with device clients available for Android and iOS. I kept some notes during the development process, which mostly occurred in the evenings and weekends around my other work.

I had been using Notifo for a year or so to receive push notifications on my phone from my custom network monitor, but last year the free service announced it was shutting down. When I switched back to my Android phone a few months ago, I was unable to download Notifo's Android app which never made it out of beta.

Continue reading 4,047 words...

April 2010

Properly stopping a SIP flood

posted to writings on apr 11th, 2010 with tags asterisk, openbsd, ruby, security, superblock, voip, and work

At about 9am yesterday morning, I noticed on the monitor that the CPU utilization of one of my servers was abnormally high, in addition to a sustained 1mbit/sec of inbound traffic and 2mbits/sec of outbound traffic. syslog messages from Asterisk showed it to be a SIP brute force attack, so I dropped the offending IP (an Amazon EC2 instance IP) into /etc/idiots to block it and went back to my work.

A while later, I noticed the traffic still hadn't died down, so I reported the incident to Amazon and my server's network provider. No luck on either front; Amazon just sent back a form reply stating the incident was forwarded to the EC2 instance's owner (yeah, seriously) and the network provider said they wouldn't bother adding an ACL to their border equipment unless it was needed to protect their entire network. With the IP blocked on my server, the CPU utilization had died down and it was no longer sending out reply traffic, but I was worried about the inbound garbage traffic counting towards the server's monthly bandwidth cap.

Continue reading 831 words...