IMA4 2017/2018 P6

Présentation générale

Introduction

On estime à 20 milliards le nombre d’objets connectés d’ici 2020. Parmis ces objets, un grand nombre d’entre eux feront parti de ce qu’on appelle l’Internet des Objets (IoT) permettant de bâtir les villes et bâtiments connectés. La technologie LoRa (Long Range) est une des technologie permettant de créer des réseaux pour ces objets connectés.

Description

Cette technologie s’appuie sur la modulation LoRa (une modulation à étalement de spectre, bande fréquence 868Mhz), couche physique du modèle OSI créé par la startup francaise Cycléo, racheté par la société Semtech en 2012. La technologie LoRa permet de créer des réseaux sans fils sécurisés longue portée (2km en ville, 15km en campagne) et basse consommation.

Le protocole LoRaWAN constitue les couches supérieures du modèle OSI est est développé par l’alliance LoRa qui compte plus de 100 membres (des sponsors comme Semtech, IBM, Cisco, des contributeurs comme Microchip, des revendeurs comme IMST). Il utilise la bande radio libre ISM (Industrielle, Scientifique & Médicale) pour connecter les objets embarquant des radios LoRa reliés au réseau par le biais de concentrateurs.

Un réseau LoRaWAN est composé de 4 éléments :

• Les appareils (End Devices) : Équipé de capteurs et d’une radio LoRa, communiquent avec les concentrateurs via le protocole LoRaWAN transmis par modulation LoRa. La spécification LoRaWAN distingue plusieurs classes d’appareils :
  • Classe A : Les appareils peuvent communiquer à tout moment avec le serveur. Le serveur ne peut cependant communiquer avec les appareils que lorsqu’ils ouvrent leur fenêtre de réception (pendant un court instant après l’envoi de données au serveur). C’est la classe qui permet d’assurer une très basse consommation de l’appareil (>8 ans moyenne).
  • Classe B : Extension de la classe A, les appareils ouvrent leur fenêtre de réception périodiquement.
  • Classe C : Extension de la classe A, les appareils ont leur fenêtre de réception ouverte en permanence (sauf lorsqu’ils émettent). Cette classe permet d’assurer le moins de latence possible, c’est toutefois la plus énergivore.
• Les passerelles (GateWay) composées d'un concentrateur lora et d'une machine hôte sur laquelle est installé un "packet forwarder" permettant de centraliser les données des appareils LoRa et de les convertir en paquets UDP. Ces paquets seront transmis à une machine serveur (Network Server).
• Le serveur LoRaWAN gère la réception des paquets de données et les convertit pour les envoyer à l’application de l’utilisateur. Il permet également d’adapter dynamiquement le débit de données et d’assurer les respect du temps d’utilisation de la bande radio (Duty Cycle)
• Le serveur d’application (Application Server) : Objectif final du réseau, permet d’exploiter les données reçues par les capteurs via une page web par exemple.

Objectifs

Développer un réseau LoRaWAN "maison" et évaluer les possibilités d'attaques.

Analyse du projet

Positionnement par rapport à l'existant

De nombreux projets utilisent déjà la technologie LoRa mais se basent sur le serveur public The Thing Network. On fait ici le choix d'utiliser un serveur privé (sous forme d'un simple ordinateur) afin de contrôler au mieux la sécurité des données. (cryptées en AES-128 de bout en bout) Le but de ce projet sera également de concevoir des appareils de coût relativement faible, le plus petit possible.

Analyse du premier concurrent

A l'heure actuelle, le seul vrai concurrent de LoRa en terme de possibilités est Sigfox, créé en 2009. LoRa arrive donc 3 ans plus tard, mais les nombreux avantages par rapport à son concurrent lui permettent de s'immiscer sur le marché : Taille maximale des messages : 242 octets (12 pour Sigfox) Nombre de messages par jour illimités (à condition de respecter le duty-cycle) (140 msg/jour pour Sigfox) Immunité contre les interférence élevé grâce à la modulation à étalement de spectre (basse pour Sigfox) Coût d’installation et de maintenance faible (Sigfox nécessite un abonnement) Open Source du moment qu’on achète les puces (Sigfox est propriétaire)

Analyse du second concurrent

La 5G déjà en développement pourrait prendre un certain temps avant d'être courant sur le marché. Cependant, Orange à lancé la LTE-M, une évolution de la G spécialement dédié au objets connectés.

LTE-M proposera des débits allant jusqu'a 10Mb/s et bénéficiera de l'itinérance puisqu'ils se base sur le réseau 4G existant.

Scénario d'usage du produit ou du concept envisagé

Dans le cadre de sa politique d’amélioration continue, l’école Polytech Lille déploie un réseau LoRaWAN dans son établissement. Ce réseau longue portée et faible consommation permet l’installation de petits appareils dotés de capteurs dans les salles de classe permettant d’obtenir divers informations sur les salles pour réduire la consommation en énergie ou connaître l’occupation des salles. Des capteurs de luminosité sont installés dans les salles et permettent de repérer les endroits où les lumières sont allumées. Des capteurs de température permettent de contrôler la température des salles. Des capteurs de contact installés sur les fenêtres permettent de détecter les fenêtres ouvertes. Des capteurs de présence permettent de savoir si la salle est occupée.

Le réseau est composé d'un concentrateur LoRa, relié à une RaspBerryPi3 (installé dans un local technique de l'école) embarquant un programme de conversion des paquets LoRa en paquets UDP. Les capteurs, associés à des micro contrôleurs de type Nucleo-F4 équipés de radios LoRa vont envoyer les informations au concentrateur. Celui-ci par le biais de la RaspBerryPi va envoyer les information sous forme de paquets TCP au serveur.

L’utilisateur ciblé est l’appariteur de l’école, il pourra contrôler depuis une page web les différentes statut des capteurs lors de la fermeture le soir : fenêtres fermées, lumières éteintes, chauffage baissé raisonnablement, salles vides.

Réponse à la question difficile

Quels sont les limites du sujet ?

Le sujet est très vaste, il est donc nécessaire d'établir des limites claires dans ce qui sera réalisé. En tout premier lieu, le but du projet sera de déployer un réseau LoRaWAN opérationnel. La passerelle sera d'abord déployée déployés. Ensuite, il faudra tester la communication d'un End Device équipé d'une radio LoRa avec le concentrateur. Puis le concentrateur devra être en mesure d'envoyer les paquets UDP à une machine (serveur, ici ce sera la raspberrypi) qui se chargera de les récupérer et d'extraire leur contenu par exemple sur une page web. Quand le système sera opérationnel pour un End Device, le test portera sur la mise en réseau de 2 End Devices.

Dans un deuxième temps, une étude de la certification LoRaWAN sera menée afin de déceler d'éventuelles failles pour mener une évaluation des différentes possibilités d'attaque sur le réseau.

Enfin, si le temps le permet, il sera intéressant de faire des tests sur les performances du réseau LoRa.

Quel tests seront effectués ?

Des tests de portée seront réalisés afin de déterminer la distance maximale de réception des données sur le réseau LoRa. Des tests de consommation énergétique seront menés afin d’estimer la durée de vie de la batterie ou des piles pour les End Devices.

Sous quelle forme se présenteront les End-Devices ?

Ce projet représentant une charge de travail conséquente, l'aspect esthétique des end-devices sera donc d'une priorité bien plus faible que faible priorité que la fonctionnalité du réseau. Ainsi, il n'y aura pas de capteurs, les données seront simulées par des valeurs aléatoires.

Préparation du projet

Cahier des charges

• Déployer une passerelle LoRaWAN
• Déployer des noeuds LoRa équipés de capteurs
• Déployer un serveur LoRaWAN
• Afficher les données des capteurs sur une page web

Choix techniques : matériel et logiciel

Choix Matériel

Ce projet utilisera le concentrateur LoRa iC880A-SPI (http://shop.imst.de/wireless-modules/lora-products/8/ic880a-spi-lorawan-concentrator-868-mhz)

La machine hôte du concentrateur sera une RaspBerryPi3.

Les micro-contrôleurs seront des Nucleo-F401RE (http://www.st.com/en/evaluation-tools/nucleo-f401re.html)

Les modules radio seront des Shields I-NUCLEO-LRWAN1 (http://www.st.com/en/evaluation-tools/i-nucleo-lrwan1.html)

Choix Logiciel

Ce projet ne requiert pas de logiciel particulier.

le GitHub https://github.com/Lora-net contenant les implémentations de référence des différents éléments du réseau LoRa sera utilisé comme base pour programmer le concentrateur et les microcontrôleurs.

Liste des tâches à effectuer

1. Déployer le concentrateur LoRa (et son système hôte sur la RaspberryPi)

2. Mettre en place un End Devices et tester sa communication avec le concentrateur

3. Tester le packet forwarder présents ur la RaspBerry Pi afin de convertir les paquets LoRa en paquets TCP vers le serveur.

4. Analyser le processus de cryptage des données de bout en bout

5. Trouver d'éventuelles possibilités d'attaque sur le réseau

6. Tester les performance des éléments du réseau LoRaWAN

Réalisation du Projet

Feuille d'heures

Tâche	Prélude	Heures S1	Heures S2	Heures S3	Heures S4	Heures S5	Heures S6	Heures S7	Heures S8	Heures S9	Heures S10	Heures S11	Heures S12	Heures S13	Heures S14	Total
Analyse du projet	10															20
Découverte matériel		3														3
Passerelle (RaspberryPi)		10		6							2					18
Noeud (NucleoF4)			9	2	4	8	6								8	37
Serveur LoRaWAN (RaspberryPi)					5		2				4	4	8	4		27
Récupération des données								9	4	6						19
TOTAL																114

Semaine 1

Séance 1 - 15/01/18 - 3H

Cette première séance de projet à permis de découvrir le matériel.

• 

  Concentrateur LoRa IC880A-SPI

• 

  Microcontrôleur Nucleo-F401RE

• 

  Shield LoRa I-NUCLEO-LRWAN1

• 

  RaspBerryPi3

La première étape consiste à rendre le concentrateur IC880A-SPI opérationnel. Pour cela il faut le connecter en SPI à la machine hôte (RaspBerryPi) selon les instructions données dans le guide de démarrage du concentrateur. (https://wireless-solutions.de/images/stories/downloads/Radio%20Modules/iC880A/iC880A-SPI_QuickStartGuide.pdf)

On peut donc établir la correspondance de PIN suivante :

Correspondance des PINS IC880A-SPI <> RaspBerry3

21 (VDD)	2 (+5V)
22 (GND)	6 (GND)
14 (SPI_CLOCK)	23 (SPI0_CLOCK)
15 (SPI_MISO)	21 (SPI0_MISO)
16 (SPI_MOSI)	19 (SPI0_MOSI)
17 (SPI_NSS)	24 (SPI0_CE0)
13 (Reset)	11 (GPIO_17)

Séance 2 - 17/01/18 - 5H

L'objectif de cette séance était de rendre le rendre la RaspberryPi opérationnelle.

Comme préconisé dans le guide de démarrage du concentrateur LoRa, une Raspbian Jessie à été flashé sur la microSD de la RaspberryPi.

Cependant il était impossible de connecter la RaspberryPi en liaison série à l'ordinateur. Après avoir exploré plusieurs pistes, et demandé conseil aux professeurs qui m'ont dirigé vers le wiki du BE PeiP, j'ai compris que mon erreur venait du fait que la RaspberryPi, depuis sa version 3 ne prend plus en charge la communication série par défaut.

En effet, le Bluetooth est activé par défaut et monopolise les pins de la communication série. Il faut donc rentrer dans la partition boot de la microSD et ajouter ajouter enable_uart=1 à la toute fin du fichier config.txt.

Malheureusement, après cette manipulation, la communication série ne fonctionnait toujours pas. Vers la fin de la séance j'ai finalement testé un autre câble usb/série. Le premier câble était bel et bien défectueux.

Bien que le projet ai peu avancé durant cette séance, cela m'a permis d'acquérir un certain nombre de compétences qui me seront très utile par la suite. J'ai appris à installer un système d'exploitation sur RaspberryPi3. J'ai également appris à flasher une image sous linux et je suis parvenu à établir la connexion série sur la RaspberryPi3.

Séance 3 - 18/01/18 - 3H

Disposant maintenant d'une connexion série sur la RaspberryPi, cette séance avait pour objectif d'établir l'accès en SSH depuis l'ordinateur et de connecter la RaspberryPi à internet pour pouvoir télécharger les paquets nécessaires au fonctionnement du concentrateur LoRa.

Après avoir essayé plusieurs méthodes de connexion j'ai finalement choisi la connexion en ethernet sur la 2ème carte réseau des ordinateurs Zabeth. J'ai paramétré la connexion en DHCP, la Raspberry est capable de pinger la Zabeth mais pour le moment pas d'accès à internet, probablement à cause du proxy.

La connexion avec le hotspot de mon smartphone constitue une solution provisoire d'accès à Internet pour ma RaspberryPi. En effet, il sera nécessaire d'établir une connexion ethernet avec une Zabeth puisque cette dernière jouera le rôle de network server.

Séance 3BIS - 19/01/18 - 2H

Cette séance avait pour objectif de rendre le concentrateur opérationnel. Après avoir branché le concentrateur en SPI à la RaspberryPi, celui-ci refusait de lancer le programme de test.

L'erreur venait du fait qu'avant toute utilisation, le concentrateur doit se réinitialiser, par le biais d'un signal reset envoyé sur un GPIO de la RaspberryPi. Pour cela, j'ai utilisé le script disponible sur le git LoraNet de Semtech car l'extrait de code proposé dans le guide de démarrage du concentrateur ne semblait pas convenir.

A la fin de la séance le concentrateur parvenait à émettre grâce au programme de test util_tx_test.

• 

  Emissions de la passerelle

Bien que le projet ne requiert pas que le concentrateur émette vers les End Devices, ce test montre que l'accès SPI de la RasperryPi avec le concentrateur est fonctionnel.

Les séances de la semaine prochaine seront dédiées à la création d'un EndDevice sur NucleoF4.

Semaine 2

Séance 4 - 22/01/18 - 2H

Cette séance a permis de me familiariser avec le microcontrôleur NucleoF4.

J'ai choisi d'utiliser le compilateur en ligne d'ARM os.mbed.com puisqu'il ne nécessite aucune installation sur l'ordinateur, est gratuit et convient tout à fait à mon usage.

• 

  Compilateur en ligne os.mbed

Une fois le programme écrit et compilé, le site propose le binaire en téléchargement.

Selon le manuel d'utilisation il suffit de copier le binaire sur le NucleoF4, d'appuyer sur le bouton reset de celui-ci pour téléverser le programme.

Cependant, même en suivant les instruction à la lettre je n'ai pas obtenu de résultats satisfaisants. Les périphériques USB n'étant pas directement montés lors du branchement sur les Zabeth, il fallait le faire à la main. Le seul problème était qu'il fallait ensuite le démonter puis débrancher le microcontrôleur, et enfin le rebrancher pour que le programme prenne effet.

Je rechercherai donc une solution à ce problème pour la prochaine séance.

J'ai également profité de cette séance pour me documenter sur la shield LoRa I-NUCLEO-LRWAN1.

Cette shield est très peu documenté, les seules ressources que j'ai trouvé se trouvent sur le github https://github.com/USILoRaModule/USI_I-NUCLEO-LRWAN1 de la société USI qui commercialise ce produit.

Ceci m'a guidé vers le package I-CUBE-LRWAN distribué par ST.com Selon la documentation, ce package permet de créer une End Device de classe A sur NucleoLX et est compatible avec la shield I-NUCLEO-LRWAN1 de USI. Comme les série NucleoFX et NucleoFX sont assez semblables je pense que mon contrôleur NucleoF4 conviendra.

Séance 5 - 24/01/18 - 5H

J'ai commencé par chercher une solution à mon problème de téléversement sur le NucleoF4. Après recherches, j'ai trouvé l'utilitaire ST-Flash sur le github https://github.com/texane/stlink. Cet utilitaire permet de flasher la mémoire du NucleoF4 et après tests, convient parfaitement à mes attentes.

Mon objectif était ensuite de réussir à faire communiquer mon NucleoF4 avec mon concentrateur LoRa.

J'ai pour cela d'abord testé les implémentations de test fournies sur le github lora-net pour développer un end device de classe A.

Comme la radio LoRa de la shield est de type SX1272 j'ai utilisé le programme http://developer.mbed.org/teams/Semtech/code/LoRaWAN-demo-72/ fourni pour Semtech.

Je suis alors confronté à un problème : comment savoir si cette implémentation est adaptée pour ma shield lora ?

Séance 6 - 25/01/18 - 2H

Cette séance m'a permis de me documenter davantage sur la shield LoRa I-NUCLEO-LRWAN1.

J'ai trouvé des morceaux de codes pour ce module, dont un code de test "ping-pong" permettant à 2 appareils LoRa de communiquer entre eux (permet principalement de tester les modules). Cependant, je n'arrive pas à importer le projet sur os.mbed.

Je vais donc continuer de me documenter et essayer de travailler depuis un IDE afin de voir si j'obtiens de meilleurs résultats.

Semaine 3

Séance 7 - 29/01/18 - 2H

La mise en place d'un émetteur LoRa est plus longue que prévue, je suis bloqué depuis une semaine sur mon problème de shield LoRa très peu documentée.

Disposant du projet de test fourni pour ST j'ai essayé d'utiliser l'IDE gratuit basé sur Eclipse pour STM32 "System Workbench for STM32" proposé par http://www.openstm32.org/

Après avoir relu en détail les datsheets de I-CUBE-LRWAN j'ai finalement trouvé l'information qu'il me manquait.

Les projets disponibles dans le package I-CUBE contiennent en fait un projet ouvrable dans l'IDE SW4STM32 précédemment téléchargé.

Je vais donc pouvoir tester le "ping-pong" à la prochaine séance, et peut être même l'implémentation d'un End Device de classe A si tout se passe bien.

Séance 8 - 31/01/18 - 4H

Cette séance aurait du être consacrée intégralement à l'implémentation de mon End Device.

Cependant, en essayant de démarrer mon concentrateur en début de séance, celui-ci refusait de démarrer. J'avais déjà rencontré ce problème auparavant, mais je le résolvais en redémarrant la raspbery pi.

Les recherches ont mises en avant que le problème pouvait provenir de la version du noyau de ma distribution Raspbian. Apparemment, il y aurait un problème de communication en SPI entre la raspebrry et le concentrateur à cause d'une modification de la vitesse de transmission maximale en SPI autorisée par la raspberry.

J'ai donc tenté de changer ma distribution en prenant une Jessie plus ancienne, avec un noyau version 3, comme conseillé sur le guide du IC880A-SPI.

Cependant, la raspberrypi3 ne supporte visiblement pas les version plus ancienne du noyau, le système refusait de démarrer.

J'ai donc réinstallé une raspian version Stretch. Après avoir remis l'ensemble des librairies et l'implémentation du service pour le concentrateur, celui-ci était plus stable.

Le problème de connexion entre la raspberrypi et le concentrateur est donc résolu.

Séance 9 - 01/02/18 - 2H

J'ai consacré cette séance au paramétrage réseau de ma raspberrypi. En effet, la restauration du système m'ayant fait perdre toute mes configurations réseaux j'ai décidé de recommencer cela proprement. J'ai également choisi d'utiliser mon ordinateur personnel afin de gagner du temps lors des séances (notamment pour le paramétrage réseaux de ma raspberrypi, l'ip changeant d'un PC à un autre).

J'utilise donc la carte eth0 de ma raspberrypi que je relie par un pont à la carte wifi de mon ordinateur. De cette manière je peux quand même accéder à ma raspebrrypi en SSH même si mon ordinateur n'est pas connecté à Internet.

Ceci est primordiale puisque le serveur LoRaWAN sera déployé sur la raspberryPi.

Semaine 4

Séance 10 - 05/02/18 - 2H

Cette séance à encore été consacrée à tenter de déployer un émetteur LoraWAN. Je me suis re documenté au sujet de la Shield I-NUCLEO-LRWAN1, et j'ai découvert de nouveaux élements, des schematics fraichement rajoutées sur le github d'USI. Ceci m'a permis de mieux comprendre la manière dont est conçue la shield et de tester les AT Commands via la liaison série de la shield. Je suis parvenu à envoyer des packets LoRaWAN de cette manière, mon concentrateur les repère effectivement.

Cependant cette solution n'est pas viable puisque l'envoie des commandes est manuel.

Séance 11 - 07/02/18 - 5H

Après avoir passé de nombreuses heures à tenter de déployer ma node LoRaWAN en vain, j'ai décidé de faire une pause sur cette étape pour m'occuper du déploiement d'un serveur LoRaWAN. En effet, je dispose d'une node qui est tout de même capable d'envoyer des paquets LoRaWAN (de façon manuelle certes), ce qui est suffisent pour tester mon réseau.

J'ai choisi l’implémentation de serveur loraserver.io, une solution open-source pour déployer un serveur LoRaWAN privé. Ceci consiste en 3 modules : Le gateway bridge qui remplace le packet forwarder fournie pour Semtech et sera déployé sur le concentrateur, le server lorawan à proprement parler et le serveur applicatif, notamment utilisé pour l'administration. J'ai donc suivi la procédure d'installation, installé mosquitto (pour MQTT) et Postgresql et Redis.

Une fois les 3 service correctement paramétrés, je pouvais avoir accès au panneau d'administration depuis mon ordinateur, en me connectant à l'adresse https://192.168.43.75:8080

• 

  Interface LoRaserver

J'ai donc rapidement paramétré un end device de classe A en rentrant notamment l'EUI et les clefs de chifrementt et à la fin de la séance je suis parvenu à voir depuis mon panneau d'administration les packets envoyés par AT Command depuis mon end device.

Bien que le serveur LoRaWAN soit fonctionnel, il conviendra de s'attarder sur les différents points de configuration afin de peaufiner le paramétrage de celui-ci et également trouver une manière de récupérer les données des packets.

Séance 12 - 08/02/18 - 2H

Je suis donc retourné sur mon problème de Shield I-NUCLEO-LRWAN1. J'ai donc continué de me documenter et j'ai fini par comprendre que l'implémentation fournie sur le github d'USI est faite pour tourner sur le STM32 intégré dans la shield et non sur le NucleoF4.

En effet, ceci semble assez logique maintenant puisque les définitions des PINS coïncident avec les pins du microcontrôleur de la shield.

J'ai découvert qu'il fallait flasher ce microcontrôleur à l'aide d'une liaison série, SWD ou JTAG.

Disposant uniquement d'un câble USB -> Série, j'ai testé cette solution. Tout d'abord j'ai testé de sauvegarder le contenu du microcontrôleur pour pouvoir le restaurer en cas de problèmes.

J'ai donc testé l'outil fournie sur le github d'USI qui utilise OpenOCD. Cependant, celui-ci ne prend pas en charge la laison série pour la sauvegarde et le flashage du microcontrôleur.

Je vais donc essayer de me procurer un câble USB -> SWD ou USB -> JTAG pour pouvoir explorer cette piste, qui pourrait bien se révéler fructueuse.

Semaine 5

Séance 13 - 12/02/18 - 2H

Afin de ne pas perdre une séance, et dans l'éventualité que le flashage du microcontrôleur de la shield se révèle infructueux, j'ai consacré cette séance à l'étude du fonctionnement des entrées/sorties du Nucleo F4 sur https://os.mbed.com/platforms/ST-Nucleo-F401RE/

J'ai d'abord appris à utiliser la liaison série intégrée au câble USB puis j'ai essayé d'utiliser celle des autres UARTS.

Le Nucleo F401RE dispose de 6 UARTS. J'ai utilisé l'UART6 reliés aux pins PA11 et PA12 pour effectuer un simple printf.

Séance 14 - 14/02/18 - 4H

Durant cette séance j'ai récupéré un programmeur JTAG. J'ai donc testé la procédure indiquée dans ce document : https://github.com/USIWP1Module/USI_I-NUCLEO-LRWAN1/blob/master/preloaded_firmware/WM-SG-SM-42%20Update%20Preloaded%20AT%20Command%20FW%20Application%20Note%20rev.%201.2.pdf pour tout d'abord sauvegarder le microcontrôleur afin de pouvoir le remettre en état en cas de problèmes.

Seulement, en essayant de sauvegarder le firmware de la shield avec OpenOCD un message est apparu indiquant que la shield était protégée et que par conséquent toutes modifications entraînerait une remise à zéro du firmware. Ne voulant pas risquer d'endommager la shield (ce qui entraînerait une perte de l'EUI, un identifiant unique au produit, défini à sa sortie de l'usine) et après discussion avec les professeurs encadrants, nous avons choisi de piloter la shield par le biais des commandes AT, sans toucher au firmware de base permettant déjà la communication en LoRaWAN.

Séance 15 - 15/02/18 - 2H

Ayant décidé d'utiliser les commandes AT de la shield, il me fallait un moyen pour pouvoir automatiser l'envoie de ces commandes. J'ai donc décidé de brancher l'UART du microcontrolleur sur celle de la shield, en croisant Tx-Rx. De cette manière, en utilisant les serial printf de la librairie d'os mbed je serait en mesure d'envoyer les commandes AT depuis le Nucléo vers la shield.

Semaine 6

Séance 16 - 19/02/18 - 2H

Durant cette séance j'ai rencontré un problème, l'envoie de mes commandes AT semblait bien s'effectuer, mais en revanche, la shield ne semblait pas les prendre en compte. j'avais pourtant bien défini le baudrate du Nucleo sur 115200 pour correspondre à celui de la shield.

Je m'en suis aperçu en envoyant la commande pour changer la clé d'application (AK), en me reconnectant directement à la liaison série de la shield, la modification n'avait pas été prise en compte.

Il y avait en fait plusieurs causes à cela : d'abord je finissait mes requêtes par \n. En me documentant à ce sujet j'ai vu que bien souvent il faut terminer les requêtes par \r\n.

Cependant, même une fois cela réglé le problème n'était pas résolu. J'ai alors ajouté des délais par le biais de wait() après l'envoie de chaque commandes pour donner le temps à la shield de traiter les commandes, mais toujours sans succès.

Séance 17 - 21/02/18 - 4H

Après de nombreuses recherches, j'ai finalement décidé de tenter une mise à jour du firmware des Nucléo vers leur dernière version, par le biais de l'utilisateur disponible sur le site de ST (https://os.mbed.com/teams/ST/wiki/Nucleo-Firmware)

Après cette mise à jour, le programme que j'avais réalisé précédemment fonctionnait parfaitement.

Séance 18 - 22/02/18 - 2H

Cette séance m'a permis de me documenter davantage sur l'implémentation de serveur LoRaWAN loraserver.io

J'ai notamment testé l'envoie des messages uplink provenant des objets connectés vers un "testeur" de requêtes requestb.in

Je voyais bien apparaître le contenu du message LoRaWAN, en clair (mais toujours codé en base64) à la fin de la chaîne de transmission.

Semaine 7

Séance 19 - 05/03/18 - 2H

Pendant cette séance j'ai déployé un serveur web maison en C, permettant de traiter les requêtes GET.

Séance 20 - 07/03/18 - 5H

Changement de stratégie, le serveur web maison ne convenait pas au traitement des requêtes post, et ne pourrait pas accueillir PHP. J'ai alors installé Apache2 et PHP sur la RaspberryPi. N'ayant encore jamais utilisé PHP j'ai réalisé quelques tests afin de me familiariser avec l'outil. J'ai notamment réalisé un script réalisant la même fonction que requestb.in à savoir afficher sur une page web les requêtes POST reçues par une autre page de mon site. Le message est sous forme JSON, j'ai donc récupéré le champ 'data' correspondant aux véritable message (codé en base64), puis j'ai affiché le message en hexadécimal afin de retrouver le message original sur la page de mon site.

Cette séance à permis de faire un point avec les professeurs encadrants : - Site non sécurisé : il faudra passer en HTTPS - Problème d'authentification des requêtes POST, comment s'assurer qu'elles proviennent bien du loraserver ? - Trouver un moyen d'utiliser les capteurs présents sur la shield LoRa, afin de donner une utilité à l'application.

Séance 21 - 08/03/18 - 2H

Après la discussion de la séance précédente, j'ai décidé d'installer un certificat SSL sur mon site avec letsencrypt.

Le problème est qu'un certificat est lié à un nom de domaine, sans cela, mon certificat sera auto signé et n'aura donc aucune valeur. J'ai donc fais part à ce problème aux professeurs encadrants et il à été décidé d'attribuer à mon site un nom de domaine, on utilisera le domaine trappe.space

Semaine 8

Séance 22 - 12/03/18 - 2H

Cette séance m'a permis d'explorer les différents moyens d'intégration des données que propose loraserver. Il est possible de récupérer les données par le biais de requêtes POST comme testé précédemment, mais cela pose de grave problèmes au niveau de l'authenticité des requêtes.

Il existe également une autre solution. Les serveurs loraserver et lora-app-server communiquent par le biais du protocole de communication MQTT. Le protocole MQTT est un protocole basé sur TCP/IP. Les clients vont décider de s'abonner à des "sujets" sur un serveur. Lorsque d'autres clients enverrons des messages vers ces sujets, ils seront retransmis vers les clients abonnés. Ce protocole est très utilisé pour les objets connecté, la possibilité de l'utiliser en mode authentifié représente un réel atout pour garantir la sécurité des données.

Séance 23 - 14/03/18 - 2H

Après discussion avec les professeurs encadrants il a été décidé qu'il serait judicieux d’héberger le site web sur les serveurs de l'école. Il faut donc mettre en place une connexion sécurisée par SSL/TLS.

J'ai donc entrepris la procédure de génération de certificat letsencrypt en utilisant l'utilitaire certbot sur la machine virtuelle.

Ceci à permis de créer les différents fichiers nécessaires au chiffrement (clé privée & certificats). La procédure d'installation à également ajouté un hôte virtuel dans la configuration d'Apache2 sur le port 443.

Semaine 9

Séance 24 - 19/03/18 - 2H

J'ai finalement supprimé les fichiers de configuration d'Apache2 dans la machine virtuelle (relatifs au chiffrement), car toutes les redirection et les hôtes virtuels sont gérés sur par serveurs de Polytech.

Le site web trappe.space est maintenant consultable en https, si l'utilisateur tente d’accéder à http://trappe.space il est redirigé sur https://trappe.space/

Séance 25 - 21/03/18 - 4H

Cette séance m'a permis d'installer PHP sur la machine virtuelle afin de tester la récupération des requêtes POST (d'abord envoyés par le biais de l'utilitaire Curl pour les test). J'ai ensuite essayé de faire en sorte à ce que le serveur applicatif LoRaWAN renvoie les données sur https://trappe.space Pour cela j'ai d'abord connecté la RaspberryPi sur le réseau de l'école (sur la 2ème carte réseau d'une Zabeth), celle ci avait donc une IP du réseau, et après avoir correctement paramétré les proxys http/https, je suis parvenu à accéder à internet. J'ai donc testé mon réseau sur le serveur de l'école, mais ce fut un echec.

J'ai donc retenté sur mon propre réseau (mon PC), cette fois ci pas de problèmes... Il y a donc quelque chose de bloquant sur le réseau de l'école, mais j'ignore encore de quoi il s'agit.

Semaine 10

Séance 26 - 26/03/18 - 2H

J'ai consacré cette séance à ajouter de petites améliorations à ma RaspberryPi, l'objectif était d'automatiser le démarrage du packet forwarder lors du branchement de la RaspberryPi.

Le packet forwarder démarre également le concentrateur LoRa, assujetti au problème de liaison SPI depuis la nouvelle version du noyau (version 4) de la RaspberryPi d'après le guide démarrage d'IMST. Ceci requiert l’arrêt et le redémarrage du GPIO17 de la RaspberryPi relié au reset du concentrateur LoRa.

Cependant, même après cette manipulation, le démarrage du packet forwarder peut échouer jusqu'a 5 fois avant de démarrer avec succès.

J'ai donc conçu un script qui effectue le reset du concentrateur puis tente de lancer le packet forwarder jusqu'a ce qu'il réussisse.

J'ai ensuite voulu automatiser le démarrage de ce script avec la RaspberryPi, j'ai donc ajouté le script dans le .bashrc mais j'ai par la suite compris que ce fichier n'était exécuté que lors d'une connexion par un utilisateur.

J'ai donc ajouté la ligne de script dans le fichier rc.local mais le script ne s'est pas lancé avec la RaspberriPi, et tente maintenant de se lancer avec le passage en mode SU...

Ceci sera réalisé lors d'une séance ultérieure.

Séance 27 - 28/03/18 - 4H

Suite à mon problème de la semaine précédente j'ai décidé d'investiguer davantage. Après avoir examiné les logs du serveur LoRa j'ai remarqué que les join request de l'end device n'étaient plus acceptés car apparemment l'appareil avait déjà utilisé le même numéro de requête pour un ancien join request.

J'ai recherché les causes possibles de cette erreur. Celle ci se déclenche visiblement lorsqu'un end-device renouvelle sa join request avant d'avoir obtenu une réponse.

Pour lever toute ambiguïté, j'ai repris l'envoie manuelle de commandes AT par le port série de la radio LoRa.

Sur mon réseau personnel, pas de problèmes, la console indiquait bien "+JoinAccepted", idem lorsque la RaspberryPi n'était connecté à aucun réseau.

Mais dès lors qu'elle se trouvait sur le réseau de l'école, plus moyen d'obtenir le join accepted.

Après discussion avec le professeur encadrant, j'ai testé de me brancher directement sur une prise du mur (pour ne pas passer par le bridge de la Zabeth) mais sans succès, idem en testant avec d'autres câbles réseaux.

Semaine 11

Séance 28 - 03/04/18 - 4H

Après avoir passé beaucoup de temps à tenter de résoudre ce problème j'ai décidé de vérifier que je n'avais pas fait d'erreur dans la configuration du serveur LoRaWAN.

Je me suis alors rendu compte qu'une partie des fichiers de configuration était manquante... Ceci peut être du à une mise à jour incomplète du serveur ou à une autre fausse manipulation de ma part.

J'ai donc remis le serveur LoRaWAN à jour, ceci à d'abord provoqué un conflit de version avec la base de données Postgresql. J'ai donc supprimé totalement la base de données et suivie à nouveau les opérations indiqués dans le guide de démarrage de loraserver (qui avait évolué depuis ma première visite).

Le serveur refonctionne correctement, j'ai donc testé de rediriger les messages MQTT du loraserver vers un broker (serveur) situé sur la machine virtuelle

Echec, le problème serait-il lié à l'utilisation du port 1883 ?

Semaine 12

Séance 29 - 09/04/18 - 4H

Après discussion avec le professeur encadrant, le port 1883 était bel et bien fermé.

Après son ouverture le problème été résolu, et à l'aide d'un script PHP agissant comme un client MQTT se chargeant de réécrire ce qu'il reçoit dans un fichier, on reproduit la même fonctionnalité qu'avec les requêtes POST envoyés par le serveur LoRaWAN, mais cette fois ci, il y aura possibilité de le sécuriser par une authentification.

Séance 30 - 11/04/18 - 4H

Durant cette séance j'ai rencontré plusieurs problèmes. D'abord, le serveur applicatif LoRaWAN semblait indiquer que mes messages dataient d'une semaine... Ceci provoquait même un rejet de certains messages.

L'autre problème était le fait que lorsque mes 2 objets connectés envoient des messages sur le réseau, l'un d'entre eux semble "bloqué" c'est à dire que certains de ses messages sont refusés, pour cause d'un "dev-nonce" déjà utilisé, ou encore d'un mauvais "MIC or FCnt" (Code d'integrité du message, comme un checksum, et Conteurs de trames, pour éviter les replay-attacks)

Semaine 13

Séance 31 - 18/04/18 - 4H

Le problème de l'heure provenait du fait que ma RaspberryPi n'était relié à aucun serveur ntp, il est même étrange que ce problème ne survienne que maintenant. Avec l'aide du professeur encadrant la RaspberryPi est maintenant connectée au serveur ntp de Polytech, et les messages apparaissent bien à l'heure.

En revanche le problème de "dev-nonce" déjà utilisé est plus délicat, il apparaît que l'utilisation de la même clé d'application sur les 2 objets connectés puisse être la cause du problème, mais il n'est pas clairement indiqué dans la spécification LoRaWAN qu'il est obligatoire d'avoir une clé d'application différente sur chaque objet connecté au réseau...

Même en changeant la clé d'application sur l'un des 2 objets, le problème survient, de manière totalement aléatoire rendant cela particulièrement difficile à débugger.

Il reste la partie web, en HTML/CSS,PHP,JS à faire afin d'avoir une application utile. Ceci sera fait pendant les vacances car aucun matériel de polytech (mis à part les serveurs) n'est nécessaire.

Semaine 14

Séance 32 - 07/05/18 - 8H

Cette séance à permis de réaliser de nombreuses avancées sur le projet.

Un capteur de type DHT11 à été ajouté sur les objets connectés, ils renvoient maintenant la température et le taux d'humidité du milieu.

Ce capteur va récupérer les valeurs et les envoyer dans le message LoRa sur 3 octets : le premier correspond à l'identifiant du capteur, le second à la température et le dernier à l'humidité.

Ces données envoyées en LoRa sont récupérés par le broker MQTT et la page HTML permet de visualiser les données.

Un service systemd à été créé sur la raspberryPi (impossible d'utiliser rc.local) permettant de n'avoir qu'a la brancher (connectée au réseau de l'école) pour que la passerelle soit prête.

Enfin le broker MQTT à été sécurisé en interdisant les accès anonymes pour forcer l'authentification. Ainsi en définissant une liste des utilisateurs avec les mots de passe (chiffrés) sur le serveur du broker, et en indiquant les opérations (lectures/écritures) autorisées pour chaque utilisateur on restreint l'accès au broker.

Les fichiers de configuration du loraserver, lora-app-server, lora-gateway bridge ont également été modifiés en conséquence.

Le script PHP à lui aussi été modifié en faisant se connecter le client avant l'accès au broker.

Le projet est maintenant fonctionnel. Les graphiques des valeurs des capteurs sont disponibles sur http://trappe.space (protégé par un mot de passe)

Documents Rendus

Rapport de projet : File:Rapport_P6_LoRaWAN_-_Gosse_Antoine.pdf

Code : File:Code_P6_LoRaWAN_-_Gosse_Antoine.zip