ALARM (Fast Response System): Unterschied zwischen den Versionen

Aus codecivil
Zur Navigation springen Zur Suche springen
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.  
 
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!==
 
==Ha! This is just a DOS attack!==

Version vom 30. Januar 2019, 19:59 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

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

Getting the software

Installation

Configuration