ALARM (Fast Response System) - Versionsgeschichte

Codecivil: /* Securing the system */

2019-01-31T00:43:41Z

Securing the system

Codecivil: /* Securing the system */

2019-01-31T00:42:56Z

Securing the system

Codecivil: /* Securing the system */

2019-01-31T00:39:52Z

Securing the system

Codecivil: /* What are the components? */

2019-01-31T00:34:30Z

What are the components?

Codecivil: /* What are the components? */

2019-01-31T00:34:00Z

What are the components?

Codecivil am 31. Januar 2019 um 00:30 Uhr

2019-01-31T00:30:39Z

Codecivil: /* Preparing the hardware */

2019-01-31T00:25:48Z

Preparing the hardware

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

2019-01-30T19:59:48Z

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

Codecivil: /* Ha! This is just a DOS attack! */

2019-01-30T19:55:43Z

Ha! This is just a DOS attack!

Codecivil: Explain ALARM

2019-01-30T19:47:43Z

Explain ALARM

Neue Seite

The '''A'''mazing '''L'''inux based '''A'''ccelerated '''R'''esponse '''M'''esh 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

==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. So here you have your mesh.

==Ha! This is just a DOS attack!==
No, of course the notification stops. At the moment 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 then the APs 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 linearly with the network size in reality which is optimal, of course.

=Preparing the hardware=
=Getting the software=
=Installation=
=Configuration=

@@ Zeile 47: / Zeile 47: @@
 =Securing the system=
 * 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

@@ Zeile 47: / Zeile 47: @@
 =Securing the system=
 * hide the essid of your AP
 * enable mac filtering to only allow the buttons to connect to the AP via wifi

@@ Zeile 47: / Zeile 47: @@
 =Securing the system=
 * hide the essid of your AP
-* enable mac filtering to only allow the buttons to connect to the AP
+* enable mac filtering to only allow the buttons to connect to the AP via wifi

@@ Zeile 38: / Zeile 38: @@
 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. 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.
+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.
@@ Zeile 45: / Zeile 45: @@
 =Installation=
 =Configuration=

@@ Zeile 18: / Zeile 18: @@
 * 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 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?==

@@ Zeile 29: / Zeile 29: @@
 =Preparing the hardware=
 =Getting the software=
 =Installation=
 =Configuration=

@@ Zeile 23: / Zeile 23: @@
 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. So here you have your mesh.
+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!==

@@ Zeile 26: / Zeile 26: @@
 ==Ha! This is just a DOS attack!==
-No, of course the notification stops. At the moment 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 then the APs 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 linearly with the network size in reality which is optimal, of course.
+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=