Version du 9 avril 2018 à 17:26

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

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

Calendrier prévisionnel

Réalisation du Projet

Feuille d'heures

Prologue

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 :

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. 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.

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é 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éployer 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

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 documenté 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 don 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 [EN COURS DE RÉDACTION]

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 du 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.

Récupération du programmeur JTAG, tests avec OpenOCD, pas moyen de reprogrammer le processeur sans le réinitialiser Abandon de cette méthode puisque risque de bloquer le matériel en perdant les clés de sécurité intégrés dans le firmware.

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

Approfondissement du NucleoF4, nottament de la liaison série

Semaine 6

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

Recherches au sujet du problème de liaison série, tentative d'ajout de wait() pour ajouter du délai lors de l'envoi des commandes.

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

Solution au problème de liaison série pour la transmission des commandes AT : - Mise à jour du firmware à la dernière version

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

Lecture de documentation du loraserver, test de transmission des données uplink en HTTP (POST) vers un requestb.in

Semaine 7

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

Déploiement d'un web serveur maison en c, traitement des requêtes GET: ok

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

Changement de stratégie car le serveur maison ne convient pas au traitement des requêtes post, installation de Apache2 sur la Rpi3, et de PHP, test des premiers script PHP permettant de recevoir les requêtes POST et d'afficher le champ 'data' sur une page web

Point avec le professeur encadrant : - 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 ? - Régler le problème qui empêche les end devices de rejoindre un serveur lorsqu'elles sont rebootées. - Trouver un moyen d'utiliser les capteurs présents sur la shield LoRa.

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

tentative d'installation d'un certificat SSL avec letsencrypt Changement de stratégie : pour un certificat ssl valide, le site doit avoir un nom de domaine, on utilisera trappe.space Il sera donc finalement hébergé sur un des serveurs de l'école dans une VM et administré en se connectant en SSH sur ladite VM

Semaine 8

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

Exploration des différents moyens d'intégration des données reçues depuis le serveur applicatif LoRaWAN - HTTP - MQTT

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

Après discussion avec mon encadrant 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 certbot sur la VM.

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

Suppression des fichiers de configuration d'Apache2 dans la VM (relatifs au chiffrement), toutes les redirection et hôtes virtuels sont gérés sur les serveurs de Polytech directement. 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/P6 (le problème de /P6 sera à régler ultérieurement)

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

Cette séance m'a permis d'installer php sur la VM afin de tester la récuperation des reqêtes POST (d'abord envoyés par le biais de Curl pour les test) J'ai ensuite essayé de faire en sorte à ce que le serveur applicatiçf 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, je ne sais pas encore quoi

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 dmarrage 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 d'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é car apparement 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 ma brancher directement sur un 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.

Semaine 11

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

Exploration de différentes pistes. Résolution en mettant à jour le serveur lorawan, des fichiers de configs avaient été supprimés par mégarde. La nouvelle version a provoqué un conflit avec la BDD, supression et recréation de celle-ci. Le serveur refonctionne correctement, test de redirection du mqtt vers un broker situé sur la machine virtuelle. Echec, ouverture de ports ?

Semaine 12

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

L'ouverture du port 1883 à résolu le problème, à l'aide d'un script php agissant comme un client mqtt se chargeant de réécrire ce qu'il recoit dans un fichier, on reproduit la même fonctionnzalité qu'avec les requetes post envoyés par le serveur lorawan, mais cette fois ci, il y aura possibilité de le sécuriser par une authentification.

Documents Rendus