Los 433 MHz y el software libre. Parte 4

viernes, 4 de agosto de 2017


Lo que nunca se debe hacer
Tras un breve vistazo se puede apreciar la gran cantidad y variedad de proyectos de Software Libre o de Código Abierto publicados bajo diferentes licencias, mediante las cuales los desarrolladores conservan sus derechos de autor, proporcionándoles una garantía legal de protección ante apropiaciones ilegitimas o que restrinjan las libertades a otros usuarios.

Son innumerables los casos de éxito de software licenciado bajo GNU/GPL, como sonados los procesos en los que se detectó una violación o incumplimiento de la licencia y el fabricante se vio obligado a publicar el código fuente, retirar en producto, o dejar de distribuirlo. Apple, Microsoft, Cisco, Asus, VMware y otras muchas compañías de primer orden han tenido que ceder ante las reclamaciones y demandas de la FSF (Free Software Fundation), que según sus propias cifras, tramitan más de 50 grandes casos cada año.

Por tanto, lo que nunca se debe hacer es utilizar Software Libre en un proyecto que no vaya a ser a su vez Software Libre. Y mucho menos apropiarse del código fuente y atribuirse su autoría.

Desgraciadamente, también hay ejemplos de estos casos. Es precisamente lo ocurrido con el proyecto Nodo, un excelente desarrollo domótico, que implementa una interface Serial/USB vía Arduino a múltiples protocolos de radiofrecuencia en codificación ASK/OOK, tanto para emisión como para recepción. Muy versátil gracias a su particular confección mediante plugins; la ultima versión liberada v3.7 disponía de 34 plugins, y comenzaba a esbozar soporte para protocolos de radiofrecuencia a 2.4 GHz, almacenamiento en tarjetas SDcard y conectividad de red vía Ethernet.

Publicado en 2013 por Paul Tonkes bajo licencia GNU GPL v3, el proyecto Nodo ha sido usurpado por un grupo que se hace llamar Stuntteam, los cuales distribuyen desde la web un software que denominan RFLink Gateway, esencialmente igual al proyecto Nodo, pero solo como un binario precompilado para Arduino Mega, infringiendo  cuarta sección de la licencia GNU GPL v2 y la decimoséptima sección de la GPL v3, las cuales exigen que los programas distribuidos como binarios precompilados estén acompañados de una copia de su código fuente.

RFLink debió ser más abierto en sus orígenes, ya que existen repositorios de código, tanto en SourceForge , como en GitHub, pero actualmente ambos repositorios se encuentran vacíos. Si bien es cierto que está disponible para su descarga una versión antigua (R33-2015) del código fuente desde una compartición en Google Drive, esta ya incluye un estrambótico licenciamiento, donde a pesar de reconocer la autoría de Paul Tonkes, obvian cualquier referencia al Software Libre y su licencia GNU GPL v3 original, y por el contrario, añaden indignantes clausulas totalmente contrarias al espíritu del Software Libre; citando textualmente:

“No se permite descompilar, desensamblar o realizar ingeniería inversa de ninguna parte del programa precompilado”.

Predicando con el ejemplo
Para predicar con el ejemplo, no hay mejor forma que desarrollar un proyecto a modo de prueba de concepto (PoC), que haga uso de Software Libre, y que por tanto, deberá quedar publicado igualmente como Software Libre.

La PoC propuesta será un dispositivo IoT que actúe como interface de transmisión de varios protocolos de radiofrecuencia ASK/OOK en la banda ISM de 433MHz, a una conexión de red TCP/IP, para poder utilizarse tanto localmente como desde Internet.

Para simplificarla al máximo y hacerla lo más accesible posible, se ha elegido como plataforma de desarrollo un Arduino UNO R3, junto con la Shield Ethernet W5100. Ambos elementos estándar, muy económicos y fáciles de conseguir; incluso disponiendo de una caja específica para el conjunto con espacio suficiente para alojar componentes adicionales.

Arduino UNO R3, Shield Ethernet W5100 y carcasa para el conjunto

Como transmisor de RF 433MHz AM (ASK/OOK) es posible utilizar cualquiera de los comentados anteriormente, ya que el rendimiento en transmisión es adecuado en todos ellos. No obstante, y pese a tratarse de una prueba de concepto, se ha empleado una antena comercial estándar, junto con un transmisor Aurel/Cebek C-0507 que puede alcanzar los 400mW funcionando a 12v, aunque alimentado a 5v no supera 100mW; respetando así la  regulación de la banda ISM. Su conexión es muy sencilla, ya que tan solo emplea un PIN de comunicación con Arduino, y únicamente se ha añadido un condensador para absorber posibles picos de consumo durante los instantes de transmisión.   
 
 
PoC interface RF 433MHz ASK/OOK a TCP/IP vía Ethernet 


Los protocolos a manejar serán los tres más comunes utilizados en interruptores inalámbricos tipo plug (enchufe), pero que también se encuentran en otros formatos para incorporar a la instalación eléctrica y actuar sobre cualquier elemento conectado; estos son:
  • Flamingo 500: con codificación pseudo-rolling-code, es utilizado por los interruptores inalámbricos HomeEasy-Smartwares y sus variantes de Elro, AB440S, etc.
  • FHT-7901: utilizado por los veteranos interruptores inalámbricos configurables por micro switchs. De origen chino, introducidos por Kjell & Company, son comercializados bajo múltiples marcas como Bricolux, Avidsen, Impuls, etc. a precios muy económicos. 


Como interface al protocolo TCP/IP se ha optado por una API REST sobre un servidor Web (HTTP), la cual garantiza la interoperabilidad con cualquier sistema domótico, frontal web, o aplicación móvil, de forma extremadamente sencilla, ya que tan solo hay que realizar una petición Web (HTTP GET) para emitir un comando de radiofrecuencia codificado en el protocolo deseado.

Además de las librerías estándar de Arduino, licenciadas bajo GNU LGPL, se emplearan librerías licencias con GNU GPL v3, MIT y BSD, por lo que todo el proyecto en su conjunto se publicará bajo la licencia GNU GPL v3.

El código generado es valido para cualquier plataforma Arduino con arquitectura AVR: Uno, Mini, Nano, Leonardo, Mega, etc., aunque con algunos ajustes se podría adaptar a otras plataformas como Due, M0, MKR1000, ESP8266, etc.

Su funcionamiento es muy sencillo; todas las tareas relacionadas con la conexión a la red están incluidas en la librería estándar de Arduino para la Shield Ethernet con el chipset de WIZnet W5100 Ethernet.h. Pese a soportar DHCP, en la PoC se utiliza direccionamiento IP estático, indicándole todos los parámetros necesarios, IP, MASK, GW, e incluso DNS, junto con la MAC Ethernet, que es obligatoria en cualquier caso. Esta librería implementa también el servidor web (HTTP) necesario para atender las peticiones web.
La API REST se implementa en la librería aREST, creada por Marco Schwartz para mapear de forma sencilla las entradas y salidas de Arduino, pero en este caso no se utiliza dicha característica, y si sus facilidades para crear llamadas a funciones previamente definidas, a las que incluso les puede hacer llegar algunos parámetros de la petición HTTP GET.

Se ha definido una función específica de transmisión para cada uno de los tres protocolos a manejar, los cuales están implementados en sendas librerías: FlamingoSwitch de Karl-Heinz Wind para Flamingo 500, NewRemoteSwitch para NewKAKU, y RemoteSwitch para FHT-7901, estas dos últimas desarrolladas por Randy Simons.

Las llamadas a las funciones son muy parecidas, ya que los tres protocolos funcionan de forma muy similar; vía web requieren pasar los siguientes parámetros mediante la clausula  params separados por el carácter punto “.” y en este orden:
  • Comando de acción; es decir, el comando de actuación a emitir que será reconocido por el dispositivo emparejado. En Flamingo y NewKAKU puede ser “on” para encender, off para apagar y dim para indicar el valor de un rango definido en dispositivos regulables (dimmers) que permiten regular la intensidad de una luz, por ejemplo, y no solo apagarla o encenderla. FHT solo soporta “on” y “off”.
  • Identificador de controlador; es decir, el identificador de un mando original. En Flamingo y NewKAKU es numérico, y en FHT se define según la posición de los cinco micro switch del mando. Si no se dispone de un mando original, o no podemos leer su identificador, podemos elegir cualquiera al azar y emparejar los dispositivos con él.
  • Identificador de dispositivo; es decir, el identificador del botón de un mando original emparejado con un dispositivo. En Flamingo y NewKAKU podemos elegir cualquiera al azar, ya que los dispositivos tienen la capacidad de reconocer el identificador al emparejarse. Por el contrario, en FHT debe corresponderse con la letra seleccionada en el micro switch del dispositivo.

Adicionalmente a los elementos propios para el funcionamiento de la PoC, tan solo se ha añadido un watchdog timer como medida de protección ante un hipotético bloqueo del sistema (tras semanas de pruebas y uso intensivo no se ha dado el caso), y la impresión de mensajes de depuración por la salida Serie/USB de Arduino, tal y como se muestra a continuación:


Estos mensajes de depuración incluyen un identificador numérico negativo cuando se produce una condición de error, cuyo significado variará según sea el caso, por lo que hay que recurrir a los comentarios del código fuente para interpretarlo.
Dada la implementación de la API REST en la librería “aREST.h”, esta devolverá siempre un código de estado HTTP 200 OK, junto con una respuesta en formato JSON, ante cualquier petición web (HTTP GET) que se realice.

El array JSON de respuesta deberá contener siempre el elemento return_value con valor  cero “0” en caso de ejecución satisfactoria, o el valor negativo correspondiente al código de error producido en su defecto. La ausencia el elemento return_value puede considerarse también una condición de error, ya que indica que no se ha ejecutado ninguna de las tres funciones definidas para la transmisión de comandos de RF. A continuación se muestran los tres tipos de respuestas JSON citados:


Todo el código fuente de la PoC está publicado bajo licencia GNU GPL v3 en el siguiente repositorio de GitHub:

Se incluyen las partes utilizadas de todas las librerías necesarias, por lo que basta con clonar o descargarse el repositorio, y compilar el Sketch desde el IDE de Arduino, para comenzar a utilizarlo de forma tan sencilla como se muestra a continuación:


Este es el aspecto final del dispositivo IoT creado para la PoC propuesta:


Conclusiones
La gran mayoría de los sistemas IoT y Domóticos que hacen uso de la banda ISM de 433MHz en AM, lo hacen, por norma general, en ausencia de medidas de seguridad. No ofreciendo ninguna garantía de privacidad, autenticidad, o integridad; siendo posible interceptar y suplantar prácticamente cualquier comunicación.

No es necesario disponer de un costoso hardware específico; con tan solo unos económicos módulos genéricos y un Arduino o Raspberry PI, es suficiente para comenzar a experimentar en la banda.

Hay disponible una ingente cantidad de software que permite capturar las señales de radiofrecuencia, analizar los protocolos de comunicación, construir nuevos mensajes y emitirlos sin mayor dificultad.

Queda demostrado que la seguridad por oscuridad que persiguen algunos fabricantes no constituye una buena practica, siendo sobrepasada por la altruista práctica de compartir descubrimientos y código que realiza una amplia comunidad de desarrolladores.

Más información:
Los 433 MHz y el software libre. Parte 1.
Los 433 MHz y el software libre. Parte 2.
Los 433 MHz y el software libre. Parte 3.
Jorge Rivera 
CSA Global de ElevenPaths 

No hay comentarios:

Publicar un comentario