Since starting to fly FPV drones about two years ago I steadily upgraded my gear. I settled on ExpressLRS for my radio link because of the superb featureset, speed and range as well as a super low price for individual components. One of the features that ExpressLRS offers is the support of so called Backpacks, that integrate the video receiver with the system to enable automatic band and channel switching.
In the last blog post (from over two years ago!) I had a first look at the protocol that is used to control cheap action cameras via their corresponding smartphone apps. It turns out that this protocol is used by many similar cameras without any modifications and any app can be used for any camera.
I’ve been contacted by several people that had problems using the example code that I provided, written in Node.JS and there have been several issues, like delays and crashes, that I simply couldn’t fix without having a camera available for testing.
A friend of mine baught a cheap Action Camera through Amazon a few days ago. He asked me to take a look at the mobile app to see if it was possible to stream the live preview to a PC or a RaspberryPi to use it as a cheap surveillance camera. The camera is running Android and it’s possible to connect to ADB though USB.
The first step was to make it easier to connect to the camera. When using the mobile application, you have to be connected to the cameras
own WiFi access point. To be usable as a network surveillance camera, the camera has to connect to an existing WiFi network.
Using adb shell, I started to explore the camera to be greeted with this prompt:
In my post Securing the Blog with TLS, I created my TLS certificate using certbot and provided all options as command line parameters. Using this approach it is cumbersome to add new domain names to an existing certificate and it’s not easy to renew your certificate. At least not easy enough for me. After the second expiration notice, kindly provided by the Let’s Encrypt Expiry Bot, I wanted to simplify this task as much as possible. Certbot accepts a configuration file using the -c parameter.
Shortly after setting up my server I noticed increasing amounts of authentication log data. The files contained many thousand lines of failed password attempts for the root user account. The attempts not only put my system at risk but also clogged up the log files and introduced stress on the small server instance.
Nov 13 20:20:06 v36436 sshd[7001]: Failed password for root from 116.31.116.36 port 12984 ssh2
Nov 13 20:20:10 v36436 sshd[7001]: message repeated 2 times: [ Failed password for root from 116.31.116.36 port 12984 ssh2]
Nov 13 20:20:11 v36436 sshd[7001]: Received disconnect from 116.31.116.36 port 12984:11: [preauth]
Nov 13 20:20:11 v36436 sshd[7001]: Disconnected from 116.31.116.36 port 12984 [preauth]
Nov 13 20:20:11 v36436 sshd[7001]: PAM 2 more authentication failures; logname= uid=0 euid=0 tty=ssh ruser= rhost=116.31.116.36 user=rootOn Ubuntu 16.04 installation is as simple as apt-get install fail2ban.
When an application successfully established an ApplicationSession with a Switching Function there will mostly be silence on the wire, except for your regular ResetApplicationTimer request to keep the session alive. The first thing a Computing Function might want to do is discover what devices are available on the target system. Some applications implement a scraping function that requests device details for every possible identifier they can come up with (or the administrator specified), others implement the GetSwitchingFunctionDevices request. In the latter case, the Switching Function will answer with a GetSwitchingFunctionDevicesResponse, containing a list of available extensions. The Computing Function may then use this list to query the Switching Function for details.
What does it take to connect to a communications system using CSTA? What does it take to implement the service provider side of CSTA communications? What exactly is CSTA and what purpose does it serve? As for all questions, lets have a look at the Wikipedia article.
Computer Supported Telecommunications Applications (CSTA) is an abstraction layer for telecommunications applications. It is independent of underlying protocols. – Wikipedia
CSTA is used to connect applications to PBXs to be able to control the connected phones, control the routing of calls and monitor events happening inside the PBX. CSTA applications range from simple CTI (Computer Telephony Integration) to automatic call distribution (think call centers) solutions.
Using HTTPS on every HTTP-based system seems like a good idea, but the cost of trusted certificates has been a deterrent for many non-commercial blog authors and open source projects. For some time now letsencrypt offers a free and secure alternative to the costly certificate authorities. I wanted to secure this blog using HTTPS too and went through the Let’s Encrypt certification process.
Let’s Encrypt uses the ACME Protocol to verify that you are the owner of the domain name you are requesting a certificate for. To get a certificate issued by Let’s Encrypt, you have to use an ACME compatible client. The EFF provides an ACME compatible client named Certbot that is easy to use and well documented. Certbot is especially well suited for deploying certificates to web servers like Apache or nginx.
I planned to setup a blog to keep track of some projects and learnings for quite some time now. I’ve worked with Wordpress a couple of times before and I didn’t like the idea of this much overhead for a mostly single-author site. I stumbled upon Julia Evans Blog a while ago and added her to my feed-reader, thats where I first heard of Hugo. Julia was Switching to Hugo and I read up on static site generation and Hugo. I also looked at Jekyll but I didn’t like the idea of dealing with Ruby for such a small project at all.