ALARM (Fast Response System): Unterschied zwischen den Versionen

Aus codecivil
Zur Navigation springen Zur Suche springen
Zeile 47: Zeile 47:
=Securing the system=
=Securing the system=
* hide the essid of your AP
* hide the essid of your AP
* disable dhcp (so the buttons cannot acquire an IP address)
* disable dhcp on the AP (so the buttons cannot acquire an IP address)
* enable mac filtering to only allow the buttons to connect to the AP via wifi
* enable mac filtering on the APs wifi to only allow the buttons to connect

Aktuelle Version vom 31. Januar 2019, 02:43 Uhr

The Amazing Linux based Accelerated Response Mesh is a combination of hardware and software allowing for fast notification of a local network (or VPN) about certain trigger events and thus for fast responses. The trigger events are usually pushes of Amazon Dash Buttons but could be configured to be something entirely different.

What is this?

How does the system work in general?

When a dash button is pushed, a signal is sent to every Linux device in the local network where the signal is translated into an alarm notification on screen stating the time and button id of the alarm. It can be accompanied by an alarm sound. The alarm can be deactivated by those devices in the local network designated to belong to the dash button. In this way, a button should be identified with the location of the corresponding devices (and be available at the same location).

What are the components?

The system comprises of the following hardware:

  • Access points with a slightly customised version of OpenWRT
  • Amazon Dash Buttons
  • The local network to be notified
  • A designated device in the local network with maximal expected uptime; called CENTRAL in the following.

Correspondingly, the software comprises of three packages:

  • alarm-ap: the additional software for the access points
  • alarm-central: the software responsible for fast distribution of the alarms
  • alarm-client: the software displaying, deactivating and configuring alarm notifications on the Linux boxes of the local network; and for fast distribution of the alarms

Didn't you say 'mesh' in the acronym? Why then is there a CENTRAL?

Well, CENTRAL is kind of a workaround for the following problem: in an ideal world, the APs would transmit the alarm signal directly to all members of the network, and so they do, but only in consecutive way. If you would rely on this way of notification alone, the system would not scale well: the last notification in a network of 20 devices would reach the device after about 20 seconds. This is too late for the objective of this project. What you want to have is a parallel kind of notification, and in fact, there is a solution: parallel-ssh.

Alas, I could not find a way to cross compile the package to fit into the embedded Linux of an OpenWRT access point. Installing python and then parallel-ssh via pip would take about 15MB. This would be ok for modern devices but not for most of the devices supporting OpenWRT currently. On all other devices in the network parallel-ssh is available, of course. So the workaround is: the AP first notifies a "parallel-ssh-proxy", CENTRAL, which then in turn parall-sshs the rest of the network. At the same time, the AP continues to inform the rest of the network and the devices of the network already notified notify the other peers via parallel-ssh. In this way, the system continues to work even if some network routes are blocked or CENTRAL is down. So here you have your mesh.

Ha! This is just a DOS attack!

No, of course the notification stops. The alarm signal is tagged with the source device. Only if the source device is the AP, the signal is transferred further. This sounds like a quadratic growth of notifications with the network size, but in reality parallel-ssh is so much faster than the APs, and the velocity almost independent of the network size, that the AP has informed only a few devices before parallel-ssh of CENTRAL or other devices has taken over. So the number of notifications grows only a bit more than linearly with the network size which is almost optimal, of course.

Preparing the hardware

First of all, you need the access points. The reach of the WLAN of the APs determines the number you need of them to cover your locations. The APs should

  • allow for an installation of OpenWRT
  • have at least 8MB RAM

My personal favorite is the TP-Link TL-WR-1043-ND. Before you install OpenWRT (currently 18.06) you should customise the image a bit. Use the Quick Builder with the following packages and configuration:


Once you flashed the image, you have first to configure the device as a router with active wlan and connect it to your internet.

Now you need the buttons. Just order the required amount from Amazon. You will need to become a Prime member for this. Once they were delivered you have to register them with the APs in range. Currently I do not know about any way how to fake the registration process so as to keep all traffic inside your LAN. At this point you have to register with the Amazon App on a mobile device. You start with My Account > Dash Buttons > register new dash buttons. During registration your (later) AP should be the only active router of the LAN. Otherwise the Amazon app might throw errors. You are done as soon as you are asked to choose a product. Stop registration at this point and repeat the process for every dash button you want to use. I think you can register a button with several APs, but I did not test this thoroughly.

Now remove your internet access data from the device and reconfigure it as an access point of your LAN. Make sure your actual router blocks internet traffic from the AP, since otherwise Amazon will bug you with urges to finish the configuration of the buttons every time you press them.

Getting the software



Securing the system

  • hide the essid of your AP
  • disable dhcp on the AP (so the buttons cannot acquire an IP address)
  • enable mac filtering on the APs wifi to only allow the buttons to connect