Wiki de Projets IMA - Contributions de l’utilisateur [fr]

IMA4 2017/2018 P6

2018-05-19T22:02:29Z

Agosse : /* Séance 32 - 07/05/18 - 8H */

[[Fichier:P62017_LoRa.JPG|right|Salle informatique]]
__TOC__
 

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

{| class="wikitable"
!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.

<gallery mode="packed-hover">
File:P62017_IC880ASPI.jpg|Concentrateur LoRa IC880A-SPI
File:P62017_NUCLEOF4.jpg|Microcontrôleur Nucleo-F401RE
File:P62017_LoraShield.jpg|Shield LoRa I-NUCLEO-LRWAN1
File:P62017_RPI3.jpg|RaspBerryPi3
</gallery>

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 :

{|style="margin: 0 auto;
|
[[File:P62017_PINRPI3.jpg|500px]]
|
[[File:P62017_PINIC880ASPI.jpg|500px]]
|
|}

{| class="wikitable" style="margin: 0 auto;"
|+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 <code>boot</code> de la microSD et ajouter ajouter <code>enable_uart=1</code> à la toute fin du fichier <code>config.txt</code>.

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 <code>util_tx_test</code>.
<gallery mode="packed-hover">
File:P62017_utiltxtest.png|Emissions de la passerelle
</gallery>
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.
<gallery mode="packed-hover">
File:P62017_osmbed.png|Compilateur en ligne os.mbed
</gallery>

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
<gallery mode="packed-hover">
File:P62017_loraserver.png|Interface LoRaserver
</gallery>

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 <code>printf</code>.

===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 <code>\n</code>. En me documentant à ce sujet j'ai vu que bien souvent il faut terminer les requêtes par <code>\r\n</code>.

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 <code>wait()</code> 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 <code>trappe.space</code>

==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 <code>.bashrc</code> 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 <code>rc.local</code> 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===
La page web, avec récupération des données sur le broker MQTT à été réalisé comme convenu pendant les vacances.

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)

{|style="margin: 0 auto;
|
[[File:P62017_trappespace.png|500px]]
|
|}

=Documents Rendus=
Rapport de projet : [[:File:Rapport_P6_LoRaWAN_-_Gosse_Antoine.pdf]]

Code : [[:File:Code_P6_LoRaWAN_-_Gosse_Antoine.zip]]

IMA4 2017/2018 P6

2018-05-19T22:01:04Z

Agosse : /* Séance 31 - 18/04/18 - 4H */

[[Fichier:P62017_LoRa.JPG|right|Salle informatique]]
__TOC__
 

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

{| class="wikitable"
!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.

<gallery mode="packed-hover">
File:P62017_IC880ASPI.jpg|Concentrateur LoRa IC880A-SPI
File:P62017_NUCLEOF4.jpg|Microcontrôleur Nucleo-F401RE
File:P62017_LoraShield.jpg|Shield LoRa I-NUCLEO-LRWAN1
File:P62017_RPI3.jpg|RaspBerryPi3
</gallery>

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 :

{|style="margin: 0 auto;
|
[[File:P62017_PINRPI3.jpg|500px]]
|
[[File:P62017_PINIC880ASPI.jpg|500px]]
|
|}

{| class="wikitable" style="margin: 0 auto;"
|+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 <code>boot</code> de la microSD et ajouter ajouter <code>enable_uart=1</code> à la toute fin du fichier <code>config.txt</code>.

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 <code>util_tx_test</code>.
<gallery mode="packed-hover">
File:P62017_utiltxtest.png|Emissions de la passerelle
</gallery>
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.
<gallery mode="packed-hover">
File:P62017_osmbed.png|Compilateur en ligne os.mbed
</gallery>

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
<gallery mode="packed-hover">
File:P62017_loraserver.png|Interface LoRaserver
</gallery>

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 <code>printf</code>.

===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 <code>\n</code>. En me documentant à ce sujet j'ai vu que bien souvent il faut terminer les requêtes par <code>\r\n</code>.

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 <code>wait()</code> 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 <code>trappe.space</code>

==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 <code>.bashrc</code> 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 <code>rc.local</code> 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)

{|style="margin: 0 auto;
|
[[File:P62017_trappespace.png|500px]]
|
|}

=Documents Rendus=
Rapport de projet : [[:File:Rapport_P6_LoRaWAN_-_Gosse_Antoine.pdf]]

Code : [[:File:Code_P6_LoRaWAN_-_Gosse_Antoine.zip]]

IMA4 2017/2018 P6

2018-05-19T21:56:51Z

Agosse : /* Séance 32 - 07/05/18 - 8H */

[[Fichier:P62017_LoRa.JPG|right|Salle informatique]]
__TOC__
 

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

{| class="wikitable"
!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.

<gallery mode="packed-hover">
File:P62017_IC880ASPI.jpg|Concentrateur LoRa IC880A-SPI
File:P62017_NUCLEOF4.jpg|Microcontrôleur Nucleo-F401RE
File:P62017_LoraShield.jpg|Shield LoRa I-NUCLEO-LRWAN1
File:P62017_RPI3.jpg|RaspBerryPi3
</gallery>

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 :

{|style="margin: 0 auto;
|
[[File:P62017_PINRPI3.jpg|500px]]
|
[[File:P62017_PINIC880ASPI.jpg|500px]]
|
|}

{| class="wikitable" style="margin: 0 auto;"
|+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 <code>boot</code> de la microSD et ajouter ajouter <code>enable_uart=1</code> à la toute fin du fichier <code>config.txt</code>.

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 <code>util_tx_test</code>.
<gallery mode="packed-hover">
File:P62017_utiltxtest.png|Emissions de la passerelle
</gallery>
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.
<gallery mode="packed-hover">
File:P62017_osmbed.png|Compilateur en ligne os.mbed
</gallery>

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
<gallery mode="packed-hover">
File:P62017_loraserver.png|Interface LoRaserver
</gallery>

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 <code>printf</code>.

===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 <code>\n</code>. En me documentant à ce sujet j'ai vu que bien souvent il faut terminer les requêtes par <code>\r\n</code>.

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 <code>wait()</code> 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 <code>trappe.space</code>

==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 <code>.bashrc</code> 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 <code>rc.local</code> 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.

==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)

{|style="margin: 0 auto;
|
[[File:P62017_trappespace.png|500px]]
|
|}

=Documents Rendus=
Rapport de projet : [[:File:Rapport_P6_LoRaWAN_-_Gosse_Antoine.pdf]]

Code : [[:File:Code_P6_LoRaWAN_-_Gosse_Antoine.zip]]

IMA4 2017/2018 P6

2018-05-19T21:55:33Z

Agosse : /* Séance 11 - 07/02/18 - 5H */

[[Fichier:P62017_LoRa.JPG|right|Salle informatique]]
__TOC__
 

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

{| class="wikitable"
!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.

<gallery mode="packed-hover">
File:P62017_IC880ASPI.jpg|Concentrateur LoRa IC880A-SPI
File:P62017_NUCLEOF4.jpg|Microcontrôleur Nucleo-F401RE
File:P62017_LoraShield.jpg|Shield LoRa I-NUCLEO-LRWAN1
File:P62017_RPI3.jpg|RaspBerryPi3
</gallery>

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 :

{|style="margin: 0 auto;
|
[[File:P62017_PINRPI3.jpg|500px]]
|
[[File:P62017_PINIC880ASPI.jpg|500px]]
|
|}

{| class="wikitable" style="margin: 0 auto;"
|+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 <code>boot</code> de la microSD et ajouter ajouter <code>enable_uart=1</code> à la toute fin du fichier <code>config.txt</code>.

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 <code>util_tx_test</code>.
<gallery mode="packed-hover">
File:P62017_utiltxtest.png|Emissions de la passerelle
</gallery>
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.
<gallery mode="packed-hover">
File:P62017_osmbed.png|Compilateur en ligne os.mbed
</gallery>

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
<gallery mode="packed-hover">
File:P62017_loraserver.png|Interface LoRaserver
</gallery>

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 <code>printf</code>.

===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 <code>\n</code>. En me documentant à ce sujet j'ai vu que bien souvent il faut terminer les requêtes par <code>\r\n</code>.

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 <code>wait()</code> 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 <code>trappe.space</code>

==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 <code>.bashrc</code> 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 <code>rc.local</code> 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.

==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]]

IMA4 2017/2018 P6

2018-05-19T21:54:02Z

Agosse : /* Séance 4 - 22/01/18 - 2H */

[[Fichier:P62017_LoRa.JPG|right|Salle informatique]]
__TOC__
 

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

{| class="wikitable"
!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.

<gallery mode="packed-hover">
File:P62017_IC880ASPI.jpg|Concentrateur LoRa IC880A-SPI
File:P62017_NUCLEOF4.jpg|Microcontrôleur Nucleo-F401RE
File:P62017_LoraShield.jpg|Shield LoRa I-NUCLEO-LRWAN1
File:P62017_RPI3.jpg|RaspBerryPi3
</gallery>

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 :

{|style="margin: 0 auto;
|
[[File:P62017_PINRPI3.jpg|500px]]
|
[[File:P62017_PINIC880ASPI.jpg|500px]]
|
|}

{| class="wikitable" style="margin: 0 auto;"
|+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 <code>boot</code> de la microSD et ajouter ajouter <code>enable_uart=1</code> à la toute fin du fichier <code>config.txt</code>.

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 <code>util_tx_test</code>.
<gallery mode="packed-hover">
File:P62017_utiltxtest.png|Emissions de la passerelle
</gallery>
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.
<gallery mode="packed-hover">
File:P62017_osmbed.png|Compilateur en ligne os.mbed
</gallery>

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

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 <code>printf</code>.

===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 <code>\n</code>. En me documentant à ce sujet j'ai vu que bien souvent il faut terminer les requêtes par <code>\r\n</code>.

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 <code>wait()</code> 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 <code>trappe.space</code>

==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 <code>.bashrc</code> 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 <code>rc.local</code> 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.

==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]]

IMA4 2017/2018 P6

2018-05-19T21:53:01Z

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

[[Fichier:P62017_LoRa.JPG|right|Salle informatique]]
__TOC__
 

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

{| class="wikitable"
!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.

<gallery mode="packed-hover">
File:P62017_IC880ASPI.jpg|Concentrateur LoRa IC880A-SPI
File:P62017_NUCLEOF4.jpg|Microcontrôleur Nucleo-F401RE
File:P62017_LoraShield.jpg|Shield LoRa I-NUCLEO-LRWAN1
File:P62017_RPI3.jpg|RaspBerryPi3
</gallery>

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 :

{|style="margin: 0 auto;
|
[[File:P62017_PINRPI3.jpg|500px]]
|
[[File:P62017_PINIC880ASPI.jpg|500px]]
|
|}

{| class="wikitable" style="margin: 0 auto;"
|+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 <code>boot</code> de la microSD et ajouter ajouter <code>enable_uart=1</code> à la toute fin du fichier <code>config.txt</code>.

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 <code>util_tx_test</code>.
<gallery mode="packed-hover">
File:P62017_utiltxtest.png|Emissions de la passerelle
</gallery>
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é 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

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 <code>printf</code>.

===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 <code>\n</code>. En me documentant à ce sujet j'ai vu que bien souvent il faut terminer les requêtes par <code>\r\n</code>.

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 <code>wait()</code> 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 <code>trappe.space</code>

==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 <code>.bashrc</code> 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 <code>rc.local</code> 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.

==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]]

IMA4 2017/2018 P6

2018-05-15T22:09:22Z

Agosse : /* Documents Rendus */

[[Fichier:P62017_LoRa.JPG|right|Salle informatique]]
__TOC__
 

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

{| class="wikitable"
!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.

<gallery mode="packed-hover">
File:P62017_IC880ASPI.jpg|Concentrateur LoRa IC880A-SPI
File:P62017_NUCLEOF4.jpg|Microcontrôleur Nucleo-F401RE
File:P62017_LoraShield.jpg|Shield LoRa I-NUCLEO-LRWAN1
File:P62017_RPI3.jpg|RaspBerryPi3
</gallery>

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 :

{|style="margin: 0 auto;
|
[[File:P62017_PINRPI3.jpg|500px]]
|
[[File:P62017_PINIC880ASPI.jpg|500px]]
|
|}

{| class="wikitable" style="margin: 0 auto;"
|+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 <code>boot</code> de la microSD et ajouter ajouter <code>enable_uart=1</code> à la toute fin du fichier <code>config.txt</code>.

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 <code>util_tx_test</code>.
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é 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

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 <code>printf</code>.

===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 <code>\n</code>. En me documentant à ce sujet j'ai vu que bien souvent il faut terminer les requêtes par <code>\r\n</code>.

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 <code>wait()</code> 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 <code>trappe.space</code>

==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 <code>.bashrc</code> 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 <code>rc.local</code> 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.

==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]]

Fichier:Code P6 LoRaWAN - Gosse Antoine.zip

2018-05-15T22:08:16Z

Agosse : Code du projet P6 LoRaWAN utilisé développé lors du projet

Code du projet P6 LoRaWAN utilisé développé lors du projet

Fichier:Code P6 LoRaWAN - Gosse.zip

2018-05-15T22:06:51Z

Agosse : Archive contenant le code développé lors du projet

Archive contenant le code développé lors du projet

IMA4 2017/2018 P6

2018-05-15T21:51:04Z

Agosse : /* Documents Rendus */

[[Fichier:P62017_LoRa.JPG|right|Salle informatique]]
__TOC__
 

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

{| class="wikitable"
!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.

<gallery mode="packed-hover">
File:P62017_IC880ASPI.jpg|Concentrateur LoRa IC880A-SPI
File:P62017_NUCLEOF4.jpg|Microcontrôleur Nucleo-F401RE
File:P62017_LoraShield.jpg|Shield LoRa I-NUCLEO-LRWAN1
File:P62017_RPI3.jpg|RaspBerryPi3
</gallery>

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 :

{|style="margin: 0 auto;
|
[[File:P62017_PINRPI3.jpg|500px]]
|
[[File:P62017_PINIC880ASPI.jpg|500px]]
|
|}

{| class="wikitable" style="margin: 0 auto;"
|+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 <code>boot</code> de la microSD et ajouter ajouter <code>enable_uart=1</code> à la toute fin du fichier <code>config.txt</code>.

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 <code>util_tx_test</code>.
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é 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

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 <code>printf</code>.

===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 <code>\n</code>. En me documentant à ce sujet j'ai vu que bien souvent il faut terminer les requêtes par <code>\r\n</code>.

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 <code>wait()</code> 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 <code>trappe.space</code>

==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 <code>.bashrc</code> 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 <code>rc.local</code> 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.

==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]]

Fichier:Rapport P6 LoRaWAN - Gosse Antoine.pdf

2018-05-15T21:49:29Z

Agosse : Rapport du projet P6 LoRaWAN Réalisé par Antoine Gosse

Rapport du projet P6 LoRaWAN
Réalisé par Antoine Gosse

IMA4 2017/2018 P6

2018-05-15T21:47:28Z

Agosse : /* Prologue */

[[Fichier:P62017_LoRa.JPG|right|Salle informatique]]
__TOC__
 

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

{| class="wikitable"
!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.

<gallery mode="packed-hover">
File:P62017_IC880ASPI.jpg|Concentrateur LoRa IC880A-SPI
File:P62017_NUCLEOF4.jpg|Microcontrôleur Nucleo-F401RE
File:P62017_LoraShield.jpg|Shield LoRa I-NUCLEO-LRWAN1
File:P62017_RPI3.jpg|RaspBerryPi3
</gallery>

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 :

{|style="margin: 0 auto;
|
[[File:P62017_PINRPI3.jpg|500px]]
|
[[File:P62017_PINIC880ASPI.jpg|500px]]
|
|}

{| class="wikitable" style="margin: 0 auto;"
|+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 <code>boot</code> de la microSD et ajouter ajouter <code>enable_uart=1</code> à la toute fin du fichier <code>config.txt</code>.

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 <code>util_tx_test</code>.
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é 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

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 <code>printf</code>.

===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 <code>\n</code>. En me documentant à ce sujet j'ai vu que bien souvent il faut terminer les requêtes par <code>\r\n</code>.

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 <code>wait()</code> 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 <code>trappe.space</code>

==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 <code>.bashrc</code> 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 <code>rc.local</code> 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.

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

IMA4 2017/2018 P6

2018-05-15T21:47:08Z

Agosse : /* Calendrier prévisionnel */

[[Fichier:P62017_LoRa.JPG|right|Salle informatique]]
__TOC__
 

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

{| class="wikitable"
!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
|}

==Prologue==
==Semaine 1==
===Séance 1 - 15/01/18 - 3H===
Cette première séance de projet à permis de découvrir le matériel.

<gallery mode="packed-hover">
File:P62017_IC880ASPI.jpg|Concentrateur LoRa IC880A-SPI
File:P62017_NUCLEOF4.jpg|Microcontrôleur Nucleo-F401RE
File:P62017_LoraShield.jpg|Shield LoRa I-NUCLEO-LRWAN1
File:P62017_RPI3.jpg|RaspBerryPi3
</gallery>

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 :

{|style="margin: 0 auto;
|
[[File:P62017_PINRPI3.jpg|500px]]
|
[[File:P62017_PINIC880ASPI.jpg|500px]]
|
|}

{| class="wikitable" style="margin: 0 auto;"
|+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 <code>boot</code> de la microSD et ajouter ajouter <code>enable_uart=1</code> à la toute fin du fichier <code>config.txt</code>.

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 <code>util_tx_test</code>.
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é 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

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 <code>printf</code>.

===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 <code>\n</code>. En me documentant à ce sujet j'ai vu que bien souvent il faut terminer les requêtes par <code>\r\n</code>.

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 <code>wait()</code> 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 <code>trappe.space</code>

==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 <code>.bashrc</code> 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 <code>rc.local</code> 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.

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

Discussion:Projets IMA4 SC & SA 2017/2018

2018-05-15T09:28:22Z

Agosse :

== Notes sur les projets ==

{| class="wikitable"
| Projet || Analyse du projet || Retour sur l'analyse || Matériel || Mi-parcours || Fin de parcours || Wiki terminé || Rapport || Vidéo
|-
| P1 [[IMA4 2017/2018 P1|Automatisation de la production de bière]]
| Présentation sans supports, bonne analyse de la concurrence. Par contre le scénario d'usage est à revoir en précisant l'usage pour le particulier.
| Le scénario est précisé mais aucune réponse aux questions difficiles "gestion des températures et procédure d'entretien".
| Rien.
| Si le contenu du Wiki reflète la quantité de travail fourni, c'est inquiétant.
| Peu de matière, pas de justification des choix, aucune réalisation concréte présentée. Sauf effort très important de dernière minute, un projet qui n'aboutira pas.
|
|
| Inutile en l'état actuel du projet.
|-
| P3 [[IMA4 2017/2018 P3|Sécurisation de l'Internet des Objets par surveillance globale]]
| Présentation focalisée sur les réseaux de neurones. Exercice mal compris (pas d'introduction du contexte, pas de scénario d'usage).
| Toujours pas d'analyse de la concurrence, ni de scénario d'usage. Pas de réponse aux questions difficiles "quel est le matériel ? quel est le protocole ? quelles sont les entrées du réseau de neurones ?".
| Une liste mais il manque des références vers les fournisseurs agréés (voir page de l'an dernier).
| Illustrez votre Wiki avec des schémas ou des photos de votre montage. Décrivez mieux votre plateforme de test et les résultats obtenus. Essayez de corriger les problèmes de français.
| Wiki trop peu alimenté pour cette phase du projet, aucune illustration, impossible de se faire une idée de l'avancée du projet avec le Wiki. Coquilles non prises en compte.
|
|
| Une démonstration avec le dispositif décrit en fin de Wiki peut être envisagée.
|-
| P4 [[IMA4 2017/2018 P4|Développement d'un module d'énergie pour Internet des Objets]]
| Exercice correctement réalisé.
| Pas de réponse aux questions difficiles "Architecture de la source d'énergie (nombre de chemins d'énergie ?)".
| Rien.
| Vous devriez avoir quelques éléments sur la réalisation. Complétez votre Wiki.
| Un Wiki illustré mais avec du copier/coller des manuels de référence sans grand intérêt. Toujours pas de circuit testé en fin de projet. Un très important effort final est toujours possible.
|
|
| A priori inutile sauf si une version fonctionnelle de la carte était obtenue.
|-
| P5 [[IMA4 2017/2018 P5|Réseau de capteurs de pollution]]
| Présentation focalisée sur la création du site Web. Effort fait pour rédiger un scénario d'usage.
| Réponses aux questions mais l'analyse de la consommation est imprécise. 
| Du matériel listé dans la page Wiki mais à reporter en bas de la page des projets de cette année avec des références valides.
| Un effort de documentation mais illustrez par des schémas, des pages de l'application et des tests.
| Un Wiki correct mais sans plus, des problèmes de format, des illustrations mal incluses, des vidéos youtube. Cela dit le Wiki peut devenir tout à fait correct avec un peu de temps et de soin.
|
|
| Pas de doute sur le travail effectué, une vidéo de démonstration est possible et requise.
|-
| P6 [[IMA4 2017/2018 P6|Réseau LoRaWAN]]
| Exercice correctement réalisé. Scénario d'usage à préciser sur la partie réseau de capteurs.
| Scénario d'usage non précisé. Pas de réponse à la question difficile.
| Du matériel listé mais sans référence, êtes-vous sur que le matériel n'a pas besoin d'être acheté ?
| Très bonne description de l'avancé du projet. N'hésitez pas à solliciter votre encadrant direct en cas de blocage !
| Très bonne description de l'avancé du projet. Prenez un peu de temps pour corriger les coquilles assez fréquentes. Wiki légérement décalé par rapport au travail effectué.
|
|
| Aucun doute sur le travail effectué mais il n'est pas sur que le sujet se prête à une vidéo. A discuter avec les encadrants.
|-
| P7 [[IMA4 2017/2018 P7|Brique pour apprentissage informatique]]
| Pas de support. Exercice très bien réalisé.
| Pas de réponse aux questions difficiles "quelle alimentation ? comment faire pour différencier les briques ? comment les briques vont-elles communiquer ? quelle sécurité vis-à-vis des enfants ?"
| Pas de liste de matériel.
| Très bonne description de l'avancé du projet. Faites un effort de formatage du texte (par exemple en utilisant des sous-titres plutôt que de souligner des lignes).
| Le travail progresse mais le Wiki est décalé.
|
|
| Une démonstration est requise, faites en sorte que les prototypes soient au rendez-vous.
|-
| P10 [[IMA4 2017/2018 P10|Portage de RIOT-OS sur MSP430 pour IOT]]
| Rien à signaler (juste une confusion entre le MSP430 et le CC430).
| Questions difficiles évacuées. 
| Du matériel listé mais sans référence.
| Une bonne description de l'avancé du projet.
| Un Wiki correct permettant de suivre l'avancé du projet. Le rapport devra être plus précis.
|
|
| Aucun doute sur la qualité du travail, le sujet ne se prête pas à une démonstration sauf si des processus visuels peuvent être chargés sur RIOT pour CC430.
|-
| P12 [[IMA4 2017/2018 P12|Système d'ostéophonie pour magicien]]
| Un peu rapide, exercice réalisé. 
| Pas d'analyse de la concurrence. Peu d'effort de rédaction. Des coquilles. Une réponse rapide à la question difficile.
| Du matériel listé mais pas forcément exhaustif et sans référence valide.
| Très bonne description de l'avancé du projet. Wiki agréable à lire.
| Merci de corriger les coquilles trop nombreuses en fin de Wiki. Les derniers travaux sont décrits trop succinctement.
|
|
| Une démonstration est requise. Un grand effort va devoir être fourni pour obtenir un prototype fonctionnel.
|-
| P14 [[IMA4 2017/2018 P14|Ecran géant modulaire]]
| Doublant
| Doublant
| Page Wiki vide, pas de liste de matériel.
| Une bonne description de l'avancé du projet. Essayez de mieux formater votre texte pour une meilleure facilité de lecture.
| Travail correctement décrit mais une tendance à s'arrêter à chaque obstacle, qu'en est-il de l'utilisation de <code>v4l2loopback</code> ?
|
|
| Une démonstration est requise. Faites en sorte d'obtenir un prototype fonctionnel.
|-
| P15 [[IMA4 2017/2018 P15|Balle vibrante connectée pour enfants sourd]]
| Présentation acceptable mais avec des supports non soignés. Pas d'analyse de la concurrence, pas de scénario d'usage.
| L'analyse de la concurrence et le scénario d'usage ont été ajoutés. Par contre pas de réponse aux questions difficiles "quelle sera l'autonomie de la balle et quel sera le système de rechargement ?".
| Pas de liste de matériel.
| Rien sur l'avancé du projet au 18/02/2018. Wiki mis à jour en catastrophe le 19/02/2018. Peu d'informations, seul le routage d'une carte semble avoir été entrepris.
| Aucune mise à jour du Wiki depuis la dernière remarque ci-dessus. L'avancée du travail ne peut pas être évaluée.
|
|
| Une démonstration est requise. Un prototype sera-t-il disponible ?
|-
| P16 [[IMA4 2017/2018 P16|Sous-chaussure chauffante pour docker]]
| Présentation acceptable mais avec des supports non soignés. Trouver des concurrents indirects. Une histoire mais pas de scénario d'usage.
| Page Wiki modifiée après la présentation. Une réponse incomplète à la question difficile. Trop de coquilles pour ce niveau d'études.
| Pas de liste de matériel.
| Bonne description du travail. Cinq séances pour faire chauffer une résistance, n'est-ce pas trop ?
| Rien à dire sur la forme, le Wiki est toujours bien tenu et permet de se faire une bonne idée de l'avancée du projet. Par contre le travail effectué sur les dernières semaine est très léger.
|
|
| De gros doute sur la possibilité d'avoir un dispositif convaincant à montrer en fin de projet. Je ne demande qu'à être démenti.
|-
| P17 [[IMA4 2017/2018 P17|Safe Watch]]
| Doublant
| Doublant
| Aucune modification de la page Wiki depuis début octobre.
| Une bonne description de l'avancé du projet. Projet encore dans la phase de prototypage. Comment vous comptez recevoir une carte SIM ?
| Wiki non mis à jour. Le code (IDE Arduino) est inclus in extenso dans le Wiki. Toujours pas d'intégration des composants.
|
|
| De gros doute sur la possibilité d'avoir un dispositif convaincant à montrer en fin de projet. Je ne demande qu'à être démenti.
|-
| P18 [[IMA4 2017/2018 P18|Mandala électronique]]
| Supports très textuels, pas de scénario d'usage mais une rédaction sur l'intérêt psychologique, pas vraiment de partie "concurrents".
| Un effort pour trouver des "concurrents", pas de réponses aux questions difficiles "combien de LEDs ? quelle alimentation pour quelle autonomie".
| Pas de liste de matériel.
| Le travail est a peu près décrit mais la page Wiki ressemble a un brouillon.
| Beaucoup d'aide pour améliorer le Wiki mais pas d'effort pour le maintenir par la suite : pas de description du mandala décoré. Rien non plus sur la programmation des animations.
|
|
| Une démonstration est requise, il faut finaliser le projet, concernant le matériel c'est correctement engagé mais il faut un gros effort sur la programmation.
|-
| P19 [[IMA4 2017/2018 P19|Bijou électronique]]
| Bonne présentation orale. Utilisation du bluetooth peu convainquant. Pas de scénario d'usage. Un "concurrent" trouvé.
| Concept de scénario d'usage non compris. Une réponse à la question difficile très rapide et non convaincante.
| Une liste de matériel dans la page Wiki mais à insérer dans le tableau en bas de la page principale. Pas de référence (voir sur la page de l'an passé).
| Le travail avec le prototype pilote de LEDs est très bien décrit et de façon agréable à lire. Par contre le schéma du futur circuit est très mal engagé. Il faut commencer par faire un schéma plus précis du collier.
| La discussion sur la conception du circuit est difficile à comprendre, d'où sortent les intensités de 0,6A et de 1,2A ? Mettre une photo d'écran pour le PCB est une hérésie sachant qu'il est possible d'exporter une image directement de Fritzing. Sans un très important travail final, il sera impossible de mener le projet à bien.
|
|
| Une démonstration est requise, il faut finaliser le projet un très gros effort est nécessaire malgré l'aide déjà apporté.
|-
| P20 [[IMA4 2017/2018 P20|Solution de messagerie à base de conteneurs]]
| Support assez corrects, sujet non entièrement compris, scénario d'usage minimal.
| Un problème dans le scénario d'usage : les conteneurs doivent être lancés sur un serveur. Une réponse acceptable à la question difficile.
| Pas de matériel particulier.
| Rien sur l'avancé du projet. Aucun travail ?
| Le Wiki a été utilisé mais montre un manque de travail flagrant. Un élève ne participe pas au projet.
|
|
| Sauf miracle aucune démonstration ne sera possible.
|-
| P22 [[IMA4 2017/2018 P22|Horloge numérique DCF77, serveur de temps et ludique]]
| Analyse très correcte.
| Réponse à la question difficile.
| Aucune liste de matériel.
| Compte-rendu du travail très lapidaire et parfois illisible à cause des coquilles. Le Wiki ne donne pas l'impression que le projet avance.
| Il est clair que le Wiki est alimenté mais un manque de rigueur dans la syntaxe mediawiki et de trop nombreuses coquilles ne permettent pas une lecture facile. Avec un peu de soin vous pourriez avoir un excellent Wiki. Le travail décrit est foisonnant, essayez de synthétiser, en particulier il serait intéressant de savoir dans quel état sont les différents travaux entrepris.
|
|
| Une démonstration est requise.
|-
| P23 [[IMA4 2017/2018 P23|Table de bar connectée]]
| Présentation trop impécise, pas vraiment de scénario d'usage. Par contre des concurrents ont été présentés.
| Un scénario d'usage éloigné de la future utilisation. Trop de coquilles dans ce scénario. Réponse à la question difficile.
| Une liste du matériel mais pas dans la page principale. Pas de référence (voir page de l'an passé).
| Compte-rendu non à jour au 18/02/2018 alors que la feuille d'heures est à jour. Le Wiki manque d'illustration, par exemple donnez le schéma du circuit. Des informations sur la carte en gestation.
| Wiki non mis à jour. Toujours entrain de travailler sur la clef XBee.
|
|
| Une démonstration est requise. Un très grand effort semble nécessaire pour avoir quelque chose à présenter sur la table.
|-
| P25 [[IMA4 2017/2018 P25|Essaim de robots]]
| Analyse très correcte. Un concurrent assez peu en rapport avec les essaims de robots mais dans la ligne des dispositifs de déminage.
| Pas de question difficile.
| Liste du matériel. Préciser pour le chassis.
| Impossible de connaître l'avancé du projet à la lecture du Wiki. N'êtes-vous pas entrain de vous perdre dans vos problèmes avec FreeRTOS ?
| De quelle résistance devant le récepteur IR parlez-vous ? Il n'y en a pas sur le PCB. Votre Wiki se concentre ces dernières semaines sur la modélisation du chassis alors que le travail sur la programmation de l'ATMega328p n'y figure pas. C'est dommage sachant qu'il s'agit du travail le plus valorisant.
|
|
| Une démonstation est requise. Arriverez-vous à souder et programmer une carte à temps ? Votre chassis complexe sera-t-il aussi fonctionnel qu'un chassis très simple à base de 2 plaques et d'entretoises ?
|-
| P30 [[IMA4 2017/2018 P30|Contrôle d'une caméra WiFi.]]
| Objectif mal expliqué. Exercice réalisé.
| Mieux définir l'objectif suite à la visite en entreprise. Pas de réponse à la question difficile.
| Aucune liste de matériel.
| Bonne description du travail. Votre Wiki manque d'illustrations sur un sujet qui le permet.
| Wiki non à jour. Ce qui est disponible donne l'impression d'un papillonnage de tutorial en tutorial. Vous abandonnez la banana PI D1 en début de projet pour vous concentrer sur de la reconnaissance d'image que vous ne semblez pas avoir conduit à bien puisque vous parlez de l'abandonner. Vous passez de C++ à python sans raison convaincante. Vous développez un serveur Web sous <code>flask</code> que vous cachez derrière un proxy inverse <code>ngnix</code>. Vous parlez de stratégie en semaine 9 ce qui bien tardif. Votre projet semble embourbé.
|
|
| Malheureusement il ne semble pas qu'il y aura quoi que ce soit à montrer. Je ne demande qu'à être démenti.
|-
| P32 [[IMA4 2017/2018 P32|Tribute to Peter Vogel]]
| Excellente présentation et excellent travail préparatoire, Scénario d'usage à préciser, trouver des concurrents.
| Réponse à la question difficile.
| Aucune liste de matériel.
| Tout simplement parfait ! Bien illustré, bien rédigé, le travail est très bien décrit. Attention quand vous dites qu'un ATMega328p n'a pas assez de sorties pour commander 8 oscillateurs, il dispose tout de même de plus de 20 E/S.
| Wiki toujours excellent. Votre exploration du monde de l'électronique analogique est passionnant à lire du moins pour un profane en la matière. Juste des notes pour les deux dernières semaines mais c'est mieux que rien et vous avez raison de vous concentrer sur la réalisation.
|
|
| Démonstration requise. En espérant que la sculpture soit totalement opérationnelle.
|-
| P35 [[IMA4 2017/2018 P35|Manette de jeu vidéo pour personne en situation de handicap]]
| Exercice réussi. Cependant précisez les acteurs dans le scénario d'usage.
| Pas de modification du scénario. Pas de réponse à la question difficile.
| Rien à redire sur la liste de matériel.
| Description du travail correct, des illustrations. Essayez de formater avec la syntaxe Wiki.
| Wiki très correct sur la forme. Pas tout à fait à jour.
|
|
| Démonstration requise. Du travail nécessaire pour avoir un prototype pour la démonstration.
|-
| P39 [[IMA4 2017/2018 P39|Musique des plantes]]
| Analyse très correcte.
| Réponses aux questions difficiles.
| Aucune liste de matériel.
| Le travail effectué est décrit. Un nombre de coquilles non acceptable, la lecture en devient difficile. Utilisez la syntaxe de formatage du Wiki.
| Corrigez vos erreurs de grammaire et d'orthographe ! Utilisez correctement la syntaxe mediawiki.
|
|
| Démonstration requise. Même un résultat négatif, du style la plante est muette, est intéressant.
|-
| P40 [[IMA4 2017/2018 P40|Exploration du réseau d'anonymisation Tor]]
| Sujet se prêtant peu à l'exercice mais très bonne présentation. Sujet travaillé.
| Pas vraiment de question, la suggestion est noté dans la page Wiki.
| Pas de matériel à commander.
| Description du travail un peu rapide (DNS leak quesako ?). Rédaction en cours au moment de la lecture du Wiki.Effort de rédaction entre le 18/02/2018 et le 19/02/2018. Il manque des sections mais le travail effectué devient lisible.
| Très bon Wiki. Des améliorations possibles comme la correction des coquilles et compléter la partie état de l'art.
|
|
| Aucun doute sur la qualité et la quantité de travail comme le montre l'"état de l'art" du Wiki. Ce sujet se prête peu à une vidéo. Il est cependant possible d'envisager une courte vidéo avec la confrontation de deux navigations Web, une classique, l'autre en passant par Tor. Le coté délicat est de trouver des démonstrations visuelles de la confidentialité apportée par Tor.
|-
| P42 [[IMA4 2017/2018 P42|Automatisation de l'assemblage de LEGO]]
| Analyse très correcte.
| Pas de réponse aux questions difficiles "Comment démarrer l'imprimante à distance ? Comment sera calibrée la plaque d’impression ?
Comment la plaque va se fixer sur le sol ? 
| Aucune liste de matériel.
| Tout simplement parfait ! Bien illustré, bien rédigé, le travail est très bien décrit. Il est possible de mettre une copie d'écran de l'application de plus. Pas la peine de vous tirer dans les pattes.
| Respectez la syntaxe mediawiki. Voir les corrections. Ajoutez une photo de l'imprimante dans l'état actuel. Très bon Wiki.
|
|
| Démonstration requise. Aucun doute sur le fait que le dispositif fonctionnera parfaitement de bout en bout.
|-
| P44 [[IMA4 2017/2018 P44|Reconnaissance d’objets via Traitement d’image]]
| Le projet ne semble pas encore avoir été sérieusement étudié.
| Net effort de documentation de la page Wiki. Pas de réponse directe à la question difficile sur la Kinect mais une discussion sur le problème posé.
| Aucune liste de matériel.
| Très bonne description du travail. Des illustrations mais il pourrait y avoir des photos du système robotino / kinect.
| Depuis février le projet piétine. Votre feuille d'heure de février en témoigne : les banques d'images des MPS n'ont pas pu être constituées (pas de raison donnée pour cet échec), de plus 13h pour acquérir des images d'une caméra même stéréoscopique est exagéré. Il vous a fallu tout le mois de mars pour résoudre ces problèmes et encore votre discussion sur la reconnaissance des MPS est peu pertinente comme expliqué en séance. Toujours rien sur l'implantation du dispositif de reconnaissance sur le système embarqué.
|
|
| Il semble peu probable qu'une démonstration puisse avoir lieu. Je ne demande qu'à être démenti.
|-
| P49 [[IMA4 2017/2018 P49|Suivi de la qualité de l’air]]
| Contexte mal présenté, sujet flou. Scénario d'usage à préciser. Pas de contact avec les encadrants avant la présentation.
| Page de Wiki vide.
| Aucune liste de matériel.
| Compte-rendu rapide du travail. Ce compte-rendu est inquiétant. Il ne semble y avoir aucun résultat depuis le début du projet. Un module a été abandonné sans que le module en question n'ait été décrit ou que la raison de l'abandon ait été précisé. Attention votre projet est en voie d'échec.
| Wiki court. Le seul travail décrit est l'écriture d'un script shell. Une seule ligne sur la création d'un conteneur.
|
|
| Aucune démonstration envisageable.
|-
| P50 [[IMA4 2017/2018 P50|Etage commande de Centaure]]
| Doublant
| Page de Wiki assez vide.
| Aucune liste de matériel.
| Le robot centaure est en plus mauvais état maintenant qu'au début du projet. Vous semblez avoir une nouvelle fois abandonné votre projet. Des ajouts mineurs au Wiki le 19/02/2018.
| Du travail réalisé avec un certain succès durant le mois de mars. A nouveau abandon du projet en avril.
|
|
| Il ne semble pas raisonnable d'espérer une démonstration.
|-
| P60 [[IMA4 2017/2018 P60|Commande de niveaux d’eau]]
| Présentation très correcte.
| Pas de réponse à la question difficile. Page Wiki un peu vide.
| Pas de matériel à commander.
| Un Wiki incomplet alors que la feuille d'heures est actualisée. Vous semblez toujours bloqués sur les problèmes d'étalonnage !
| Wiki très peu alimenté. Présentation du contrôle avec simulink.
|
|
| Une démonstration requise. Pour l'instant seul le contrôle par simulink est disponible. Ce n'est pas suffisant.
|-
| P64 [[IMA4 2017/2018 P64|Simulation Labview et mise en réseau Modbus d’un ascenseur]]
| Doublant
| Wiki avec quelques informations sur le travail accompli depuis fin novembre : étude sur modbus et labview. Quelques coquilles.
| Aucune liste de matériel.
| Très peu d'illustrations. Texte mal formaté et avec des coquilles intolérable à ce niveau d'étude. Le compte-rendu donne l'impression d'une méthode de travail très brouillonne.
|
| Wiki insuffisant.
|
| Projet terminé, pas de vidéo.
|-
| P65 [[IMA4 2017/2018 P65|Exosquelette pour apprentissage]]
| Présentation sans support. Trouver des concurrents indirects. Pas de scénario d'usage.
| Page Wiki vide.
| Aucune liste de matériel.
| Rien sur l'avancé du projet. Projet en échec ?
| Rien sur l'avancé du projet. Projet en échec.
|
|
| Aucune avancée, il est désormais impossible d'avoir un prototype en fin de projet.
|-
| P66 [[IMA4 2017/2018 P66|Coupe de France de robotique]]
| Analyse très correcte.
| Page Wiki bien tenue. Ajoutez des illustrations.
| Quelques éléments sur le matériel dans la page Wiki mais aucune liste avec références.
| Tout simplement parfait ! Bien illustré, bien rédigé, le travail est très bien décrit. Presque à jour. Vous n'aviez pas des cartes à faire fabriquer à l'extérieur ?
| Rédaction rapide sur les dernières semaine. Une expérimentation est nécessaire à ce stage du projet. Elle est attendue avec impatience.
|
|
| Démonstration requise. Débrouillez-vous pour avoir quelque chose de percutant à montrer !
|-
| P67 [[IMA4 2017/2018 P67|Scanner 3D DIY]]
| Exercice bien réalisé.
| Page Wiki très complète. Ajoutez des illustrations.
| Une liste probablement pas exhaustive.
| Exceptionnel ! Très illustré, bien rédigé, le travail de recherche est très bien décrit. Je ne suis pas un fan de la mise en gras d'un quart du texte et la syntaxe Wiki n'est pas vraiment utilisée mais c'est du détail?
| Il faudra encore relire le Wiki pour corriger les coquilles des nouveaux paragraphes. Les images et les vidéos sont aussi à ajouter. Il n'en reste pas moins que le Wiki et impressionnant et sera exceptionnel une fois totalement rédigé et corrigé.
|
|
| Démonstration absolument requise. Il y aura forcément quelque chose à montrer !
|-
| P68 [[IMA4 2017/2018 P68|Générateur de chronogrammes d'ordonnancement]]
| Doublant
| Page Wiki vide.
| Pas de matériel à commander.
| Rien sur l'avancé du projet. Projet en échec ?
| Toujours rien sur l'avancé du projet. Projet en échec.
|
|
| Vidéo non adaptée au sujet.
|-
| PP1 [[IMA4 2017/2018 Pré-projet 1|Robot hexapode pour escalier]]
| Erasmus
|
|
| Projet en échec constaté.
| A voir avec l'encadrant direct.
|
|
| A voir avec l'encadrant direct.
|-
|}

== Fiche de présence ==

{| class="wikitable"
! Projet !! Elèves !! Séance 1 (17/01) !! Séance 2 (24/01) !! Séance 3 (31/01) !! Séance 4 (7/02) !! Séance 5 (14/02) !! Séance 6 (21/02) !! Séance 7 (7/03) !! Séance 8 (14/03) !! Séance 9 (21/03) !! Séance 10 (28/03) !! Séance 11 (4/04) !! Séance 12 (11/04) !! Séance 13 (18/04)
|-
| P1 [[IMA4 2017/2018 P1|Automatisation de la production de bière]]
|Quentin Boëns / Henri Carlier
|E304
|E304/305
|E304
|E304
|E304
|C201
|C201
|C201/E304
|E304/Fab
|Fab/A313
|C205 Départ 17h (entretien stage)
|C205
|C205
|-
| P3 [[IMA4 2017/2018 P3|Sécurisation de l'Internet des Objets par surveillance globale]]
|Ji Yang
|E306
|E303
| Pas de salle 
|E301
|E306
|E306
|E306
|C201
|E304
|E306
|E306
|
|
|-
| P4 [[IMA4 2017/2018 P4|Développement d'un module d'énergie pour Internet des Objets]]
| Alexis Viscogliosi / Abass Ayoub
|C008
|C008
|E304 Alexis Viscogliosi Absent excusé pour entretien stage
|C008
|C008
|C201
|C201
|C201
|C201
|C201
|C201
|C201
|C201
|-
| P5 [[IMA4 2017/2018 P5|Réseau de capteurs de pollution]]
| Paul Ribeiro / Mehanna Naïf
|E303
|E301
|A204 Absents 
|E301
|E301 puis B309 puis B207
|E301
|E301
|C201 puis E304
|C201 et E304
|C201
|C201/E303
|C201
|E303 puis E304
|-
| P6 [[IMA4 2017/2018 P6|Réseau LoRaWAN]]
| Antoine Gosse
| E306
| E306
| E306
| E306
| E306
| E306
| E306
| E306
| E306
| E306
| E306
| E306
| E306
|-
| P7 [[IMA4 2017/2018 P7|Brique pour apprentissage informatique]]
| Maëva Delaporte / Simon Blas
| E304 
| E304 
| E304 
| E301 
| E301 
| E301 
| E301 
| C201/E304 
| E301 
| E301 
| E301 
|
|
|-
| P10 [[IMA4 2017/2018 P10|Portage de RIOT-OS sur MSP430 pour IOT]]
| Baptiste Cartier
| E306
| E301
| E306
| E301
| E301
| E301
| E306
| E304
| E306
| E301
| E301
|
|
|-
| P12 [[IMA4 2017/2018 P12|Système d'ostéophonie pour magicien]]
| Amine El Messaoudi / Simon Feutrier
| E301
| E301
| C201
| C201
| B207
| C201
| C201
| C201
| C201
| C201
| C201
| E305 - C202
| E306 - C201
|-
| P14 [[IMA4 2017/2018 P14|Ecran géant modulaire]]
| Jade Dupont
|E304
|E304
|E304
|E304
|E304
|Absence Maladie
|E304
|E304
|E304
|E304
|E304
|Absente entretien stage
|E304
|-
| P15 [[IMA4 2017/2018 P15|Balle vibrante connectée pour enfants sourd]]
| Thomas Cunin / Thibault Cattelain
| E304
| B306/E304
| Pas de salle (E304 - A305)
| E301
| E301
| E301
| E301
| E304
| E304/C200
| E304
| E304
|-
| P16 [[IMA4 2017/2018 P16|Sous-chaussure chauffante pour docker]]
| Rémi Mairesse / Gustave Roux
| E304
| E301
| Pas de salle 
| E304
| E304
| E304 / C201
| C201
| C201
| C201
| C201
|-
| P17 [[IMA4 2017/2018 P17|Safe Watch]]
| Oumaima Naanaa
|E302
|E304
|E304
|E304
|E304
|E304
|E304
|E304
|-
| P18 [[IMA4 2017/2018 P18|Mandala électronique]]
| Lirui Zhang / Lihe Zhang
| E304
| E304
| E304
| E304
| E304
| E304
| E304
| E304
| E302
| E304
| E304
| E302
|-
| P19 [[IMA4 2017/2018 P19|Bijou électronique]]
| Lijie Yao / Keren Qiang
| E303
| E304
| E304
| E304
| E304
| E304
| E304
| E304
| E304
| E304
| E304
| E304
| E304
| E304
|-
| P20 [[IMA4 2017/2018 P20|Solution de messagerie à base de conteneurs]]
| Maxime Creteur / Gao Fan
|E303
|E301
|A204 Absents 
|E303
|B309 puis B207
|E301
|E301
|E304
|E301
|E301
|E303 Gao Fan absent 
|E304
|E304
|
|-
| P22 [[IMA4 2017/2018 P22|Horloge numérique DCF77, serveur de temps et ludique]]
| Amaury Knockaert / Fabrice Taingland
| E304
| E304
| E304/E302
| C203/E306
| E306/E304
| Forum stages euratech/E304
| E304
| E306
| E306
| E306
| E304
| E304 / C205
| E304 / C205
|-
| P23 [[IMA4 2017/2018 P23|Table de bar connectée]]
| Matthieu Delobelle
| E306
| E306
| E303 - C201
| E306 - C201
| E304
| E306
| E306
| C201
| C201
| C201
| C201-E302
|-
| P25 [[IMA4 2017/2018 P25|Essaim de robots]]
| Benjamin Canu / Ganix Etcheguibel
| E306
| E306
| E306
| E306
| E306
| Forum Euratech jusqu'à 17h E306
| E306
| E306
| E306
| E306 / Fab
| E306 / Fab
| E306 / C202
| E306 / C202
|-
| P30 [[IMA4 2017/2018 P30|Contrôle d'une caméra WiFi.]]
| Taky Djeraba / Thomas Hubert
| E306
| E306
| Pas de salle 
| E306
| E306
| E306
| E306
|-
| P32 [[IMA4 2017/2018 P32|Tribute to Peter Vogel]]
| Jean-Baptiste Watine / Antoine Untereiner
| E306/C201
| E301
| Pas de salle (C201) 
| C205
| C205/E301
| C205/E301
| E301
| C205
| C205/C201
| C205
|-
| P35 [[IMA4 2017/2018 P35|Manette de jeu vidéo pour personne en situation de handicap]]
| Transley Gracias / Camille Saad
| E306
| E306
| E305
| E306
| E306
| E306
| E306
| E306/C202
| E306
| E306
| E306
| E306/C202
|-
| P39 [[IMA4 2017/2018 P39|Musique des plantes]]
| Xavier Chenot / Rodolphe Toin
| E306
| E306
| E306
| E306
| E306
| E306
| E306 puis C201
| C205
| C205
| C205
| C205
| C205
| C205
|-
| P40 [[IMA4 2017/2018 P40|Exploration du réseau d'anonymisation Tor]]
| Antoine Duquenoy / Anthony Durot
| E306
| E306
| E306
| E306
| E306
| E306
| E306
| E306
| E306
| E305
| E306
| E305
| E305
|-
| P42 [[IMA4 2017/2018 P42|Automatisation de l'assemblage de LEGO]]
| Eloi Zalczer / Justine Senellart
|E302/E306
|E302/E306
|E304/E302
|E304/E302
|E306/E302
|Hors Polytech/E302
|E302/E304
|E302/E304
|E304/E302
|E306/E302
|E306/E302
|Entretien/E302
|
|-
|-
| P44 [[IMA4 2017/2018 P44|Reconnaissance d’objets via Traitement d’image]]
| Damien Narbais / Zoé Briois
| E306
| E301
| Pas de salle (E301)
| E304 + 17h réunion C00X
| C205
| E304 + 17h réunion C00X
| A317
| E304
| E30X
| C205 + Damien -> entretien stage
| C205
| C205
| C205
|-
| P49 [[IMA4 2017/2018 P49|Suivi de la qualité de l’air]]
| Hugo Delbroucq / Nicolas Havard
| E301
| INRIA
| Pas de salle (INRIA)
| E301
| E301 puis E304
| E301
| E301
| E304
| INRIA
| E301
| E301
| E301
|
|-
| P50 [[IMA4 2017/2018 P50|Etage commande de Centaure]]
|-
| P60 [[IMA4 2017/2018 P60|Commande de niveaux d’eau]]
| Claire Vandamme / Alexandra Villa
|C008
|C008
|Hors Polytech/B106
|C008
|C008
|Bureau de Mr Pekpe/E306
|C008
|C008
|C008(Claire : jusque 16h, RDV médical)
|C008
|C008
|C008
|C008
|-
| P64 [[IMA4 2017/2018 P64|Simulation Labview et mise en réseau Modbus d’un ascenseur]]
|-
| P65 [[IMA4 2017/2018 P65|Exosquelette pour apprentissage]]
| Florian Le Foll
| E301
| E301
| (Pas de salle) E303
|E303
|E303
|C201
|C201
|C201
|C201
|C201
|C201
|-
| P66 [[IMA4 2017/2018 P66|Coupe de France de robotique]]
| Carval Amaury/ Prud'Homme Geoffrey
| fabricarium
| fabricarium puis Hors Polytech
| E304
| E301
| Carval E306 - Preud'homme E301
| E301
| Carval C20X - Preud'homme Fabricarium
| Quelque part
| Fabricarium
| E306
| Fabricarium (au fond)
| C201/Fabricarium
| C201/Fabricarium/C205
|-
| P67 [[IMA4 2017/2018 P67|Scanner 3D DIY]]
| Erwan Dufresne
| E302/E306
| E301
| E304
| E301
| E302
| E306
| E302
| E302/Fabricarium
| E302/Fabricarium
| Fabricarium/E304
| E304/Fab
| E306/Fab
| E305/ Fab
|-
| PP1 [[IMA4 2017/2018 PP1|Robot hexapode pour escalier]]
| Eduardo Gomez
| C201
| C201
| C201
| Fabricarium
| Fabricarium
| C201
| C201/Fabricarium
| C201/Fabricarium
| C201/Fabricarium
|
| C201
| C201
| C201
|-
| P68 [[IMA4 2017/2018 P68|Générateur de chronogrammes d'ordonnancement]]
|}

Fichier:P62017 trappespace.png

2018-05-14T10:53:30Z

Agosse :

Fichier:P62017 loraserver.png

2018-05-14T10:53:14Z

Agosse :

Fichier:P62017 osmbed.png

2018-05-14T10:53:02Z

Agosse :

Fichier:P62017 utiltxtest.png

2018-05-14T10:52:35Z

Agosse : .

Fichier:Utiltxtest.png

2018-05-14T10:46:53Z

Agosse :

IMA4 2017/2018 P6

2018-05-14T10:41:51Z

Agosse : /* Séance 20 - 07/03/18 - 5H */

[[Fichier:P62017_LoRa.JPG|right|Salle informatique]]
__TOC__
 

=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

==Calendrier prévisionnel==

=Réalisation du Projet=
==Feuille d'heures==

{| class="wikitable"
!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
|}

==Prologue==
==Semaine 1==
===Séance 1 - 15/01/18 - 3H===
Cette première séance de projet à permis de découvrir le matériel.

<gallery mode="packed-hover">
File:P62017_IC880ASPI.jpg|Concentrateur LoRa IC880A-SPI
File:P62017_NUCLEOF4.jpg|Microcontrôleur Nucleo-F401RE
File:P62017_LoraShield.jpg|Shield LoRa I-NUCLEO-LRWAN1
File:P62017_RPI3.jpg|RaspBerryPi3
</gallery>

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 :

{|style="margin: 0 auto;
|
[[File:P62017_PINRPI3.jpg|500px]]
|
[[File:P62017_PINIC880ASPI.jpg|500px]]
|
|}

{| class="wikitable" style="margin: 0 auto;"
|+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 <code>boot</code> de la microSD et ajouter ajouter <code>enable_uart=1</code> à la toute fin du fichier <code>config.txt</code>.

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 <code>util_tx_test</code>.
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é 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

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 <code>printf</code>.

===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 <code>\n</code>. En me documentant à ce sujet j'ai vu que bien souvent il faut terminer les requêtes par <code>\r\n</code>.

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 <code>wait()</code> 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 <code>trappe.space</code>

==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 <code>.bashrc</code> 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 <code>rc.local</code> 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.

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

IMA4 2017/2018 P6

2018-05-14T09:47:08Z

Agosse : /* Séance 12 - 08/02/18 - 2H */

[[Fichier:P62017_LoRa.JPG|right|Salle informatique]]
__TOC__
 

=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

==Calendrier prévisionnel==

=Réalisation du Projet=
==Feuille d'heures==

{| class="wikitable"
!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
|}

==Prologue==
==Semaine 1==
===Séance 1 - 15/01/18 - 3H===
Cette première séance de projet à permis de découvrir le matériel.

<gallery mode="packed-hover">
File:P62017_IC880ASPI.jpg|Concentrateur LoRa IC880A-SPI
File:P62017_NUCLEOF4.jpg|Microcontrôleur Nucleo-F401RE
File:P62017_LoraShield.jpg|Shield LoRa I-NUCLEO-LRWAN1
File:P62017_RPI3.jpg|RaspBerryPi3
</gallery>

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 :

{|style="margin: 0 auto;
|
[[File:P62017_PINRPI3.jpg|500px]]
|
[[File:P62017_PINIC880ASPI.jpg|500px]]
|
|}

{| class="wikitable" style="margin: 0 auto;"
|+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 <code>boot</code> de la microSD et ajouter ajouter <code>enable_uart=1</code> à la toute fin du fichier <code>config.txt</code>.

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 <code>util_tx_test</code>.
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é 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

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 <code>printf</code>.

===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 <code>\n</code>. En me documentant à ce sujet j'ai vu que bien souvent il faut terminer les requêtes par <code>\r\n</code>.

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 <code>wait()</code> 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 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 <code>trappe.space</code>

==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 <code>.bashrc</code> 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 <code>rc.local</code> 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.

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

IMA4 2017/2018 P6

2018-05-14T09:45:52Z

Agosse : /* Séance 12 - 08/02/18 - 2H */

[[Fichier:P62017_LoRa.JPG|right|Salle informatique]]
__TOC__
 

=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

==Calendrier prévisionnel==

=Réalisation du Projet=
==Feuille d'heures==

{| class="wikitable"
!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
|}

==Prologue==
==Semaine 1==
===Séance 1 - 15/01/18 - 3H===
Cette première séance de projet à permis de découvrir le matériel.

<gallery mode="packed-hover">
File:P62017_IC880ASPI.jpg|Concentrateur LoRa IC880A-SPI
File:P62017_NUCLEOF4.jpg|Microcontrôleur Nucleo-F401RE
File:P62017_LoraShield.jpg|Shield LoRa I-NUCLEO-LRWAN1
File:P62017_RPI3.jpg|RaspBerryPi3
</gallery>

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 :

{|style="margin: 0 auto;
|
[[File:P62017_PINRPI3.jpg|500px]]
|
[[File:P62017_PINIC880ASPI.jpg|500px]]
|
|}

{| class="wikitable" style="margin: 0 auto;"
|+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 <code>boot</code> de la microSD et ajouter ajouter <code>enable_uart=1</code> à la toute fin du fichier <code>config.txt</code>.

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 <code>util_tx_test</code>.
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é 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

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 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==
===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 <code>printf</code>.

===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 <code>\n</code>. En me documentant à ce sujet j'ai vu que bien souvent il faut terminer les requêtes par <code>\r\n</code>.

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 <code>wait()</code> 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 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 <code>trappe.space</code>

==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 <code>.bashrc</code> 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 <code>rc.local</code> 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.

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

IMA4 2017/2018 P6

2018-05-14T09:36:43Z

Agosse : /* Séance 9 - 01/02/18 - 2H */

[[Fichier:P62017_LoRa.JPG|right|Salle informatique]]
__TOC__
 

=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

==Calendrier prévisionnel==

=Réalisation du Projet=
==Feuille d'heures==

{| class="wikitable"
!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
|}

==Prologue==
==Semaine 1==
===Séance 1 - 15/01/18 - 3H===
Cette première séance de projet à permis de découvrir le matériel.

<gallery mode="packed-hover">
File:P62017_IC880ASPI.jpg|Concentrateur LoRa IC880A-SPI
File:P62017_NUCLEOF4.jpg|Microcontrôleur Nucleo-F401RE
File:P62017_LoraShield.jpg|Shield LoRa I-NUCLEO-LRWAN1
File:P62017_RPI3.jpg|RaspBerryPi3
</gallery>

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 :

{|style="margin: 0 auto;
|
[[File:P62017_PINRPI3.jpg|500px]]
|
[[File:P62017_PINIC880ASPI.jpg|500px]]
|
|}

{| class="wikitable" style="margin: 0 auto;"
|+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 <code>boot</code> de la microSD et ajouter ajouter <code>enable_uart=1</code> à la toute fin du fichier <code>config.txt</code>.

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 <code>util_tx_test</code>.
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é 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

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==
===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 <code>printf</code>.

===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 <code>\n</code>. En me documentant à ce sujet j'ai vu que bien souvent il faut terminer les requêtes par <code>\r\n</code>.

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 <code>wait()</code> 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 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 <code>trappe.space</code>

==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 <code>.bashrc</code> 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 <code>rc.local</code> 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.

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

IMA4 2017/2018 P6

2018-05-13T09:38:47Z

Agosse : /* Cahier des charges */

[[Fichier:P62017_LoRa.JPG|right|Salle informatique]]
__TOC__
 

=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

==Calendrier prévisionnel==

=Réalisation du Projet=
==Feuille d'heures==

{| class="wikitable"
!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
|}

==Prologue==
==Semaine 1==
===Séance 1 - 15/01/18 - 3H===
Cette première séance de projet à permis de découvrir le matériel.

<gallery mode="packed-hover">
File:P62017_IC880ASPI.jpg|Concentrateur LoRa IC880A-SPI
File:P62017_NUCLEOF4.jpg|Microcontrôleur Nucleo-F401RE
File:P62017_LoraShield.jpg|Shield LoRa I-NUCLEO-LRWAN1
File:P62017_RPI3.jpg|RaspBerryPi3
</gallery>

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 :

{|style="margin: 0 auto;
|
[[File:P62017_PINRPI3.jpg|500px]]
|
[[File:P62017_PINIC880ASPI.jpg|500px]]
|
|}

{| class="wikitable" style="margin: 0 auto;"
|+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 <code>boot</code> de la microSD et ajouter ajouter <code>enable_uart=1</code> à la toute fin du fichier <code>config.txt</code>.

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 <code>util_tx_test</code>.
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==
===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 <code>printf</code>.

===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 <code>\n</code>. En me documentant à ce sujet j'ai vu que bien souvent il faut terminer les requêtes par <code>\r\n</code>.

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 <code>wait()</code> 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 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 <code>trappe.space</code>

==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 <code>.bashrc</code> 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 <code>rc.local</code> 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.

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

IMA4 2017/2018 P6

2018-05-13T09:35:31Z

Agosse : /* Feuille d'heures */

[[Fichier:P62017_LoRa.JPG|right|Salle informatique]]
__TOC__
 

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

{| class="wikitable"
!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
|}

==Prologue==
==Semaine 1==
===Séance 1 - 15/01/18 - 3H===
Cette première séance de projet à permis de découvrir le matériel.

<gallery mode="packed-hover">
File:P62017_IC880ASPI.jpg|Concentrateur LoRa IC880A-SPI
File:P62017_NUCLEOF4.jpg|Microcontrôleur Nucleo-F401RE
File:P62017_LoraShield.jpg|Shield LoRa I-NUCLEO-LRWAN1
File:P62017_RPI3.jpg|RaspBerryPi3
</gallery>

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 :

{|style="margin: 0 auto;
|
[[File:P62017_PINRPI3.jpg|500px]]
|
[[File:P62017_PINIC880ASPI.jpg|500px]]
|
|}

{| class="wikitable" style="margin: 0 auto;"
|+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 <code>boot</code> de la microSD et ajouter ajouter <code>enable_uart=1</code> à la toute fin du fichier <code>config.txt</code>.

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 <code>util_tx_test</code>.
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==
===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 <code>printf</code>.

===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 <code>\n</code>. En me documentant à ce sujet j'ai vu que bien souvent il faut terminer les requêtes par <code>\r\n</code>.

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 <code>wait()</code> 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 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 <code>trappe.space</code>

==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 <code>.bashrc</code> 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 <code>rc.local</code> 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.

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

IMA4 2017/2018 P6

2018-05-07T16:26:18Z

Agosse : /* Séance 32 - 07/05/18 - 7H */

[[Fichier:P62017_LoRa.JPG|right|Salle informatique]]
__TOC__
 

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

{| class="wikitable"
!Tâche !! Prélude !! Heures S1 !! Heures S2 !! Heures S3 !! Heures S4 !! Heures S5 !! Heures S6 !! Heures S7 !! Heures S8 !! Heures S9 !! Heures S10 !! Total
|-
| Analyse du projet
| 0
|
|
|
|
|
|
|
|
|
|
|
|}

==Prologue==
==Semaine 1==
===Séance 1 - 15/01/18 - 3H===
Cette première séance de projet à permis de découvrir le matériel.

<gallery mode="packed-hover">
File:P62017_IC880ASPI.jpg|Concentrateur LoRa IC880A-SPI
File:P62017_NUCLEOF4.jpg|Microcontrôleur Nucleo-F401RE
File:P62017_LoraShield.jpg|Shield LoRa I-NUCLEO-LRWAN1
File:P62017_RPI3.jpg|RaspBerryPi3
</gallery>

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 :

{|style="margin: 0 auto;
|
[[File:P62017_PINRPI3.jpg|500px]]
|
[[File:P62017_PINIC880ASPI.jpg|500px]]
|
|}

{| class="wikitable" style="margin: 0 auto;"
|+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 <code>boot</code> de la microSD et ajouter ajouter <code>enable_uart=1</code> à la toute fin du fichier <code>config.txt</code>.

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 <code>util_tx_test</code>.
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==
===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 <code>printf</code>.

===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 <code>\n</code>. En me documentant à ce sujet j'ai vu que bien souvent il faut terminer les requêtes par <code>\r\n</code>.

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 <code>wait()</code> 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 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 <code>trappe.space</code>

==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 <code>.bashrc</code> 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 <code>rc.local</code> 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.

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

IMA4 2017/2018 P6

2018-05-07T16:26:04Z

Agosse : /* Semaine 13 */

[[Fichier:P62017_LoRa.JPG|right|Salle informatique]]
__TOC__
 

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

{| class="wikitable"
!Tâche !! Prélude !! Heures S1 !! Heures S2 !! Heures S3 !! Heures S4 !! Heures S5 !! Heures S6 !! Heures S7 !! Heures S8 !! Heures S9 !! Heures S10 !! Total
|-
| Analyse du projet
| 0
|
|
|
|
|
|
|
|
|
|
|
|}

==Prologue==
==Semaine 1==
===Séance 1 - 15/01/18 - 3H===
Cette première séance de projet à permis de découvrir le matériel.

<gallery mode="packed-hover">
File:P62017_IC880ASPI.jpg|Concentrateur LoRa IC880A-SPI
File:P62017_NUCLEOF4.jpg|Microcontrôleur Nucleo-F401RE
File:P62017_LoraShield.jpg|Shield LoRa I-NUCLEO-LRWAN1
File:P62017_RPI3.jpg|RaspBerryPi3
</gallery>

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 :

{|style="margin: 0 auto;
|
[[File:P62017_PINRPI3.jpg|500px]]
|
[[File:P62017_PINIC880ASPI.jpg|500px]]
|
|}

{| class="wikitable" style="margin: 0 auto;"
|+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 <code>boot</code> de la microSD et ajouter ajouter <code>enable_uart=1</code> à la toute fin du fichier <code>config.txt</code>.

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 <code>util_tx_test</code>.
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==
===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 <code>printf</code>.

===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 <code>\n</code>. En me documentant à ce sujet j'ai vu que bien souvent il faut terminer les requêtes par <code>\r\n</code>.

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 <code>wait()</code> 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 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 <code>trappe.space</code>

==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 <code>.bashrc</code> 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 <code>rc.local</code> 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.

==Semaine 14==
===Séance 32 - 07/05/18 - 7H===
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=

IMA4 2017/2018 P6

2018-04-26T10:31:24Z

Agosse : /* Semaine 5 [EN COURS DE RÉDACTION] */

[[Fichier:P62017_LoRa.JPG|right|Salle informatique]]
__TOC__
 

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

{| class="wikitable"
!Tâche !! Prélude !! Heures S1 !! Heures S2 !! Heures S3 !! Heures S4 !! Heures S5 !! Heures S6 !! Heures S7 !! Heures S8 !! Heures S9 !! Heures S10 !! Total
|-
| Analyse du projet
| 0
|
|
|
|
|
|
|
|
|
|
|
|}

==Prologue==
==Semaine 1==
===Séance 1 - 15/01/18 - 3H===
Cette première séance de projet à permis de découvrir le matériel.

<gallery mode="packed-hover">
File:P62017_IC880ASPI.jpg|Concentrateur LoRa IC880A-SPI
File:P62017_NUCLEOF4.jpg|Microcontrôleur Nucleo-F401RE
File:P62017_LoraShield.jpg|Shield LoRa I-NUCLEO-LRWAN1
File:P62017_RPI3.jpg|RaspBerryPi3
</gallery>

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 :

{|style="margin: 0 auto;
|
[[File:P62017_PINRPI3.jpg|500px]]
|
[[File:P62017_PINIC880ASPI.jpg|500px]]
|
|}

{| class="wikitable" style="margin: 0 auto;"
|+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 <code>boot</code> de la microSD et ajouter ajouter <code>enable_uart=1</code> à la toute fin du fichier <code>config.txt</code>.

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 <code>util_tx_test</code>.
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==
===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 <code>printf</code>.

===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 <code>\n</code>. En me documentant à ce sujet j'ai vu que bien souvent il faut terminer les requêtes par <code>\r\n</code>.

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 <code>wait()</code> 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 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 <code>trappe.space</code>

==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 <code>.bashrc</code> 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 <code>rc.local</code> 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.
=Documents Rendus=

IMA4 2017/2018 P6

2018-04-26T10:31:11Z

Agosse :

[[Fichier:P62017_LoRa.JPG|right|Salle informatique]]
__TOC__
 

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

{| class="wikitable"
!Tâche !! Prélude !! Heures S1 !! Heures S2 !! Heures S3 !! Heures S4 !! Heures S5 !! Heures S6 !! Heures S7 !! Heures S8 !! Heures S9 !! Heures S10 !! Total
|-
| Analyse du projet
| 0
|
|
|
|
|
|
|
|
|
|
|
|}

==Prologue==
==Semaine 1==
===Séance 1 - 15/01/18 - 3H===
Cette première séance de projet à permis de découvrir le matériel.

<gallery mode="packed-hover">
File:P62017_IC880ASPI.jpg|Concentrateur LoRa IC880A-SPI
File:P62017_NUCLEOF4.jpg|Microcontrôleur Nucleo-F401RE
File:P62017_LoraShield.jpg|Shield LoRa I-NUCLEO-LRWAN1
File:P62017_RPI3.jpg|RaspBerryPi3
</gallery>

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 :

{|style="margin: 0 auto;
|
[[File:P62017_PINRPI3.jpg|500px]]
|
[[File:P62017_PINIC880ASPI.jpg|500px]]
|
|}

{| class="wikitable" style="margin: 0 auto;"
|+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 <code>boot</code> de la microSD et ajouter ajouter <code>enable_uart=1</code> à la toute fin du fichier <code>config.txt</code>.

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 <code>util_tx_test</code>.
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 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 <code>printf</code>.

===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 <code>\n</code>. En me documentant à ce sujet j'ai vu que bien souvent il faut terminer les requêtes par <code>\r\n</code>.

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 <code>wait()</code> 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 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 <code>trappe.space</code>

==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 <code>.bashrc</code> 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 <code>rc.local</code> 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.
=Documents Rendus=

IMA4 2017/2018 P6

2018-04-26T09:16:58Z

Agosse : /* Semaine 12 */

[[Fichier:P62017_LoRa.JPG|right|Salle informatique]]
__TOC__
 

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

{| class="wikitable"
!Tâche !! Prélude !! Heures S1 !! Heures S2 !! Heures S3 !! Heures S4 !! Heures S5 !! Heures S6 !! Heures S7 !! Heures S8 !! Heures S9 !! Heures S10 !! Total
|-
| Analyse du projet
| 0
|
|
|
|
|
|
|
|
|
|
|
|}

==Prologue==
==Semaine 1==
===Séance 1 - 15/01/18 - 3H===
Cette première séance de projet à permis de découvrir le matériel.

<gallery mode="packed-hover">
File:P62017_IC880ASPI.jpg|Concentrateur LoRa IC880A-SPI
File:P62017_NUCLEOF4.jpg|Microcontrôleur Nucleo-F401RE
File:P62017_LoraShield.jpg|Shield LoRa I-NUCLEO-LRWAN1
File:P62017_RPI3.jpg|RaspBerryPi3
</gallery>

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 :

{|style="margin: 0 auto;
|
[[File:P62017_PINRPI3.jpg|500px]]
|
[[File:P62017_PINIC880ASPI.jpg|500px]]
|
|}

{| class="wikitable" style="margin: 0 auto;"
|+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 <code>boot</code> de la microSD et ajouter ajouter <code>enable_uart=1</code> à la toute fin du fichier <code>config.txt</code>.

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 <code>util_tx_test</code>.
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 <code>printf</code>.

===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 <code>trappe.space</code>
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 <code>.bashrc</code> 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 <code>rc.local</code> 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 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===

==Semaine 13==
===Séance 31 - 18/04/18 - 4H===

=Documents Rendus=

IMA4 2017/2018 P6

2018-04-09T17:26:48Z

Agosse : /* Semaine 11 */

[[Fichier:P62017_LoRa.JPG|right|Salle informatique]]
__TOC__
 

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

{| class="wikitable"
!Tâche !! Prélude !! Heures S1 !! Heures S2 !! Heures S3 !! Heures S4 !! Heures S5 !! Heures S6 !! Heures S7 !! Heures S8 !! Heures S9 !! Heures S10 !! Total
|-
| Analyse du projet
| 0
|
|
|
|
|
|
|
|
|
|
|
|}

==Prologue==
==Semaine 1==
===Séance 1 - 15/01/18 - 3H===
Cette première séance de projet à permis de découvrir le matériel.

<gallery mode="packed-hover">
File:P62017_IC880ASPI.jpg|Concentrateur LoRa IC880A-SPI
File:P62017_NUCLEOF4.jpg|Microcontrôleur Nucleo-F401RE
File:P62017_LoraShield.jpg|Shield LoRa I-NUCLEO-LRWAN1
File:P62017_RPI3.jpg|RaspBerryPi3
</gallery>

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 :

{|style="margin: 0 auto;
|
[[File:P62017_PINRPI3.jpg|500px]]
|
[[File:P62017_PINIC880ASPI.jpg|500px]]
|
|}

{| class="wikitable" style="margin: 0 auto;"
|+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 <code>boot</code> de la microSD et ajouter ajouter <code>enable_uart=1</code> à la toute fin du fichier <code>config.txt</code>.

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 <code>util_tx_test</code>.
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 <code>printf</code>.

===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 <code>trappe.space</code>
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 <code>.bashrc</code> 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 <code>rc.local</code> 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=

IMA4 2017/2018 P6

2018-04-09T17:26:25Z

Agosse : /* Semaine 10 */

[[Fichier:P62017_LoRa.JPG|right|Salle informatique]]
__TOC__
 

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

{| class="wikitable"
!Tâche !! Prélude !! Heures S1 !! Heures S2 !! Heures S3 !! Heures S4 !! Heures S5 !! Heures S6 !! Heures S7 !! Heures S8 !! Heures S9 !! Heures S10 !! Total
|-
| Analyse du projet
| 0
|
|
|
|
|
|
|
|
|
|
|
|}

==Prologue==
==Semaine 1==
===Séance 1 - 15/01/18 - 3H===
Cette première séance de projet à permis de découvrir le matériel.

<gallery mode="packed-hover">
File:P62017_IC880ASPI.jpg|Concentrateur LoRa IC880A-SPI
File:P62017_NUCLEOF4.jpg|Microcontrôleur Nucleo-F401RE
File:P62017_LoraShield.jpg|Shield LoRa I-NUCLEO-LRWAN1
File:P62017_RPI3.jpg|RaspBerryPi3
</gallery>

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 :

{|style="margin: 0 auto;
|
[[File:P62017_PINRPI3.jpg|500px]]
|
[[File:P62017_PINIC880ASPI.jpg|500px]]
|
|}

{| class="wikitable" style="margin: 0 auto;"
|+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 <code>boot</code> de la microSD et ajouter ajouter <code>enable_uart=1</code> à la toute fin du fichier <code>config.txt</code>.

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 <code>util_tx_test</code>.
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 <code>printf</code>.

===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 <code>trappe.space</code>
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 <code>.bashrc</code> 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 <code>rc.local</code> 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 ?

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

IMA4 2017/2018 P6

2018-03-28T16:46:08Z

Agosse : /* Séance 26 - 26/03/18 - 2H */

[[Fichier:P62017_LoRa.JPG|right|Salle informatique]]
__TOC__
 

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

{| class="wikitable"
!Tâche !! Prélude !! Heures S1 !! Heures S2 !! Heures S3 !! Heures S4 !! Heures S5 !! Heures S6 !! Heures S7 !! Heures S8 !! Heures S9 !! Heures S10 !! Total
|-
| Analyse du projet
| 0
|
|
|
|
|
|
|
|
|
|
|
|}

==Prologue==
==Semaine 1==
===Séance 1 - 15/01/18 - 3H===
Cette première séance de projet à permis de découvrir le matériel.

<gallery mode="packed-hover">
File:P62017_IC880ASPI.jpg|Concentrateur LoRa IC880A-SPI
File:P62017_NUCLEOF4.jpg|Microcontrôleur Nucleo-F401RE
File:P62017_LoraShield.jpg|Shield LoRa I-NUCLEO-LRWAN1
File:P62017_RPI3.jpg|RaspBerryPi3
</gallery>

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 :

{|style="margin: 0 auto;
|
[[File:P62017_PINRPI3.jpg|500px]]
|
[[File:P62017_PINIC880ASPI.jpg|500px]]
|
|}

{| class="wikitable" style="margin: 0 auto;"
|+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 <code>boot</code> de la microSD et ajouter ajouter <code>enable_uart=1</code> à la toute fin du fichier <code>config.txt</code>.

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 <code>util_tx_test</code>.
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 <code>printf</code>.

===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 <code>trappe.space</code>
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 <code>.bashrc</code> 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 <code>rc.local</code> 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.

=Documents Rendus=

IMA4 2017/2018 P6

2018-03-28T16:34:04Z

Agosse : /* Séance 27 - 28/03/18 - 4H */

[[Fichier:P62017_LoRa.JPG|right|Salle informatique]]
__TOC__
 

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

{| class="wikitable"
!Tâche !! Prélude !! Heures S1 !! Heures S2 !! Heures S3 !! Heures S4 !! Heures S5 !! Heures S6 !! Heures S7 !! Heures S8 !! Heures S9 !! Heures S10 !! Total
|-
| Analyse du projet
| 0
|
|
|
|
|
|
|
|
|
|
|
|}

==Prologue==
==Semaine 1==
===Séance 1 - 15/01/18 - 3H===
Cette première séance de projet à permis de découvrir le matériel.

<gallery mode="packed-hover">
File:P62017_IC880ASPI.jpg|Concentrateur LoRa IC880A-SPI
File:P62017_NUCLEOF4.jpg|Microcontrôleur Nucleo-F401RE
File:P62017_LoraShield.jpg|Shield LoRa I-NUCLEO-LRWAN1
File:P62017_RPI3.jpg|RaspBerryPi3
</gallery>

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 :

{|style="margin: 0 auto;
|
[[File:P62017_PINRPI3.jpg|500px]]
|
[[File:P62017_PINIC880ASPI.jpg|500px]]
|
|}

{| class="wikitable" style="margin: 0 auto;"
|+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 <code>boot</code> de la microSD et ajouter ajouter <code>enable_uart=1</code> à la toute fin du fichier <code>config.txt</code>.

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 <code>util_tx_test</code>.
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 <code>printf</code>.

===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 <code>trappe.space</code>
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===

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

=Documents Rendus=

IMA4 2017/2018 P6

2018-03-28T16:27:49Z

Agosse : /* Semaine 9 */

[[Fichier:P62017_LoRa.JPG|right|Salle informatique]]
__TOC__
 

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

{| class="wikitable"
!Tâche !! Prélude !! Heures S1 !! Heures S2 !! Heures S3 !! Heures S4 !! Heures S5 !! Heures S6 !! Heures S7 !! Heures S8 !! Heures S9 !! Heures S10 !! Total
|-
| Analyse du projet
| 0
|
|
|
|
|
|
|
|
|
|
|
|}

==Prologue==
==Semaine 1==
===Séance 1 - 15/01/18 - 3H===
Cette première séance de projet à permis de découvrir le matériel.

<gallery mode="packed-hover">
File:P62017_IC880ASPI.jpg|Concentrateur LoRa IC880A-SPI
File:P62017_NUCLEOF4.jpg|Microcontrôleur Nucleo-F401RE
File:P62017_LoraShield.jpg|Shield LoRa I-NUCLEO-LRWAN1
File:P62017_RPI3.jpg|RaspBerryPi3
</gallery>

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 :

{|style="margin: 0 auto;
|
[[File:P62017_PINRPI3.jpg|500px]]
|
[[File:P62017_PINIC880ASPI.jpg|500px]]
|
|}

{| class="wikitable" style="margin: 0 auto;"
|+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 <code>boot</code> de la microSD et ajouter ajouter <code>enable_uart=1</code> à la toute fin du fichier <code>config.txt</code>.

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 <code>util_tx_test</code>.
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 <code>printf</code>.

===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 <code>trappe.space</code>
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===

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

=Documents Rendus=

IMA4 2017/2018 P6

2018-03-21T08:27:55Z

Agosse : /* Semaine 8 */

IMA4 2017/2018 P6

2018-03-14T15:45:46Z

Agosse :

IMA4 2017/2018 P6

2018-03-14T13:31:24Z

Agosse : /* Séance 14 - 14/02/18 - 4H */

IMA4 2017/2018 P6

2018-03-14T13:26:48Z

Agosse : /* Séance 13 - 12/02/18 - 2H */

IMA4 2017/2018 P6

2018-03-09T00:11:13Z

Agosse : /* Semaine 5 */

IMA4 2017/2018 P6

2018-03-09T00:10:23Z

Agosse : /* Séance 13 - 12/02/18 - 2H */

IMA4 2017/2018 P6

2018-03-09T00:08:58Z

Agosse : /* Semaine 4 */

Discussion:Projets IMA4 SC & SA 2017/2018

2018-03-07T19:43:57Z

Agosse :

== Notes sur les projets ==

{| class="wikitable"
| Projet || Analyse du projet || Retour sur l'analyse || Matériel || Mi-parcours || Wiki terminé || Rapport || Vidéo
|-
| P1 [[IMA4 2017/2018 P1|Automatisation de la production de bière]]
| Présentation sans supports, bonne analyse de la concurrence. Par contre le scénario d'usage est à revoir en précisant l'usage pour le particulier.
| Le scénario est précisé mais aucune réponse aux questions difficiles "gestion des températures et procédure d'entretien".
| Rien.
| Si le contenu du Wiki reflète la quantité de travail fourni, c'est inquiétant.
|
|
|
|-
| P3 [[IMA4 2017/2018 P3|Sécurisation de l'Internet des Objets par surveillance globale]]
| Présentation focalisée sur les réseaux de neurones. Exercice mal compris (pas d'introduction du contexte, pas de scénario d'usage).
| Toujours pas d'analyse de la concurrence, ni de scénario d'usage. Pas de réponse aux questions difficiles "quel est le matériel ? quel est le protocole ? quelles sont les entrées du réseau de neurones ?".
| Une liste mais il manque des références vers les fournisseurs agréés (voir page de l'an dernier).
| Illustrez votre Wiki avec des schémas ou des photos de votre montage. Décrivez mieux votre plateforme de test et les résultats obtenus. Essayez de corriger les problèmes de français.
|
|
|
|-
| P4 [[IMA4 2017/2018 P4|Développement d'un module d'énergie pour Internet des Objets]]
| Exercice correctement réalisé.
| Pas de réponse aux questions difficiles "Architecture de la source d'énergie (nombre de chemins d'énergie ?)".
| Rien.
| Vous devriez avoir quelques éléments sur la réalisation. Complétez votre Wiki.
|
|
|
|-
| P5 [[IMA4 2017/2018 P5|Réseau de capteurs de pollution]]
| Présentation focalisée sur la création du site Web. Effort fait pour rédiger un scénario d'usage.
| Réponses aux questions mais l'analyse de la consommation est imprécise. 
| Du matériel listé dans la page Wiki mais à reporter en bas de la page des projets de cette année avec des références valides.
| Un effort de documentation mais illustrez par des schémas, des pages de l'application et des tests.
|
|
|
|-
| P6 [[IMA4 2017/2018 P6|Réseau LoRaWAN]]
| Exercice correctement réalisé. Scénario d'usage à préciser sur la partie réseau de capteurs.
| Scénario d'usage non précisé. Pas de réponse à la question difficile.
| Du matériel listé mais sans référence, êtes-vous sur que le matériel n'a pas besoin d'être acheté ?
| Très bonne description de l'avancé du projet. N'hésitez pas à solliciter votre encadrant direct en cas de blocage !
|
|
|
|-
| P7 [[IMA4 2017/2018 P7|Brique pour apprentissage informatique]]
| Pas de support. Exercice très bien réalisé.
| Pas de réponse aux questions difficiles "quelle alimentation ? comment faire pour différencier les briques ? comment les briques vont-elles communiquer ? quelle sécurité vis-à-vis des enfants ?"
| Pas de liste de matériel.
| Très bonne description de l'avancé du projet. Faites un effort de formatage du texte (par exemple en utilisant des sous-titres plutôt que de souligner des lignes).
|
|
|
|-
| P10 [[IMA4 2017/2018 P10|Portage de RIOT-OS sur MSP430 pour IOT]]
| Rien à signaler (juste une confusion entre le MSP430 et le CC430).
| Questions difficiles évacuées. 
| Du matériel listé mais sans référence.
| Une bonne description de l'avancé du projet.
|
|
|
|-
| P12 [[IMA4 2017/2018 P12|Système d'ostéophonie pour magicien]]
| Un peu rapide, exercice réalisé. 
| Pas d'analyse de la concurrence. Peu d'effort de rédaction. Des coquilles. Une réponse rapide à la question difficile.
| Du matériel listé mais pas forcément exhaustif et sans référence valide.
| Très bonne description de l'avancé du projet. Wiki agréable à lire.
|
|
|
|-
| P14 [[IMA4 2017/2018 P14|Ecran géant modulaire]]
| Doublant
| Doublant
| Page Wiki vide, pas de liste de matériel.
| Une bonne description de l'avancé du projet. Essayez de mieux formater votre texte pour une meilleure facilité de lecture.
|
|
|
|-
| P15 [[IMA4 2017/2018 P15|Balle vibrante connectée pour enfants sourd]]
| Présentation acceptable mais avec des supports non soignés. Pas d'analyse de la concurrence, pas de scénario d'usage.
| L'analyse de la concurrence et le scénario d'usage ont été ajoutés. Par contre pas de réponse aux questions difficiles "quelle sera l'autonomie de la balle et quel sera le système de rechargement ?".
| Pas de liste de matériel.
| Rien sur l'avancé du projet au 18/02/2018. Wiki mis à jour en catastrophe le 19/02/2018. Peu d'informations, seul le routage d'une carte semble avoir été entrepris.
|
|
|
|-
| P16 [[IMA4 2017/2018 P16|Sous-chaussure chauffante pour docker]]
| Présentation acceptable mais avec des supports non soignés. Trouver des concurrents indirects. Une histoire mais pas de scénario d'usage.
| Page Wiki modifiée après la présentation. Une réponse incomplète à la question difficile. Trop de coquilles pour ce niveau d'études.
| Pas de liste de matériel.
| Bonne description du travail. Cinq séances pour faire chauffer une résistance, n'est-ce pas trop ?
|
|
|
|-
| P17 [[IMA4 2017/2018 P17|Safe Watch]]
| Doublant
| Doublant
| Aucune modification de la page Wiki depuis début octobre.
| Une bonne description de l'avancé du projet. Projet encore dans la phase de prototypage. Comment vous comptez recevoir une carte SIM ?
|
|
|
|-
| P18 [[IMA4 2017/2018 P18|Mandala électronique]]
| Supports très textuels, pas de scénario d'usage mais une rédaction sur l'intérêt psychologique, pas vraiment de partie "concurrents".
| Un effort pour trouver des "concurrents", pas de réponses aux questions difficiles "combien de LEDs ? quelle alimentation pour quelle autonomie".
| Pas de liste de matériel.
| Le travail est a peu près décrit mais la page Wiki ressemble a un brouillon.
|
|
|
|-
| P19 [[IMA4 2017/2018 P19|Bijou électronique]]
| Bonne présentation orale. Utilisation du bluetooth peu convainquant. Pas de scénario d'usage. Un "concurrent" trouvé.
| Concept de scénario d'usage non compris. Une réponse à la question difficile très rapide et non convaincante.
| Une liste de matériel dans la page Wiki mais à insérer dans le tableau en bas de la page principale. Pas de référence (voir sur la page de l'an passé).
| Le travail avec le prototype pilote de LEDs est très bien décrit et de façon agréable à lire. Par contre le schéma du futur circuit est très mal engagé. Il faut commencer par faire un schéma plus précis du collier.
|
|
|
|-
| P20 [[IMA4 2017/2018 P20|Solution de messagerie à base de conteneurs]]
| Support assez corrects, sujet non entièrement compris, scénario d'usage minimal.
| Un problème dans le scénario d'usage : les conteneurs doivent être lancés sur un serveur. Une réponse acceptable à la question difficile.
| Pas de matériel particulier.
| Rien sur l'avancé du projet. Aucun travail ?
|
|
|
|-
| P22 [[IMA4 2017/2018 P22|Horloge numérique DCF77, serveur de temps et ludique]]
| Analyse très correcte.
| Réponse à la question difficile.
| Aucune liste de matériel.
| Compte-rendu du travail très lapidaire et parfois illisible à cause des coquilles. Le Wiki ne donne pas l'impression que le projet avance.
|
|
|
|-
| P23 [[IMA4 2017/2018 P23|Table de bar connectée]]
| Présentation trop impécise, pas vraiment de scénario d'usage. Par contre des concurrents ont été présentés.
| Un scénario d'usage éloigné de la future utilisation. Trop de coquilles dans ce scénario. Réponse à la question difficile.
| Une liste du matériel mais pas dans la page principale. Pas de référence (voir page de l'an passé).
| Compte-rendu non à jour au 18/02/2018 alors que la feuille d'heures est à jour. Le Wiki manque d'illustration, par exemple donnez le schéma du circuit. Des informations sur la carte en gestation.
|
|
|
|-
| P25 [[IMA4 2017/2018 P25|Essaim de robots]]
| Analyse très correcte. Un concurrent assez peu en rapport avec les essaims de robots mais dans la ligne des dispositifs de déminage.
| Pas de question difficile.
| Liste du matériel. Préciser pour le chassis.
| Impossible de connaître l'avancé du projet à la lecture du Wiki. N'êtes-vous pas entrain de vous perdre dans vos problèmes avec FreeRTOS ?
|
|
|
|-
| P30 [[IMA4 2017/2018 P30|Contrôle d'une caméra WiFi.]]
| Objectif mal expliqué. Exercice réalisé.
| Mieux définir l'objectif suite à la visite en entreprise. Pas de réponse à la question difficile.
| Aucune liste de matériel.
| Bonne description du travail. Votre Wiki manque d'illustrations sur un sujet qui le permet.
|
|
|
|-
| P32 [[IMA4 2017/2018 P32|Tribute to Peter Vogel]]
| Excellente présentation et excellent travail préparatoire, Scénario d'usage à préciser, trouver des concurrents.
| Réponse à la question difficile.
| Aucune liste de matériel.
| Tout simplement parfait ! Bien illustré, bien rédigé, le travail est très bien décrit. Attention quand vous dites qu'un ATMega328p n'a pas assez de sorties pour commander 8 oscillateurs, il dispose tout de même de plus de 20 E/S.
|
|
|
|-
| P35 [[IMA4 2017/2018 P35|Manette de jeu vidéo pour personne en situation de handicap]]
| Exercice réussi. Cependant précisez les acteurs dans le scénario d'usage.
| Pas de modification du scénario. Pas de réponse à la question difficile.
| Rien à redire sur la liste de matériel.
| Description du travail correct, des illustrations. Essayez de formater avec la syntaxe Wiki.
|
|
|
|-
| P39 [[IMA4 2017/2018 P39|Musique des plantes]]
| Analyse très correcte.
| Réponses aux questions difficiles.
| Aucune liste de matériel.
| Le travail effectué est décrit. Un nombre de coquilles non acceptable, la lecture en devient difficile. Utilisez la syntaxe de formatage du Wiki.
|
|
|
|-
| P40 [[IMA4 2017/2018 P40|Exploration du réseau d'anonymisation Tor]]
| Sujet se prêtant peu à l'exercice mais très bonne présentation. Sujet travaillé.
| Pas vraiment de question, la suggestion est noté dans la page Wiki.
| Pas de matériel à commander.
| Description du travail un peu rapide (DNS leak quesako ?). Rédaction en cours au moment de la lecture du Wiki.Effort de rédaction entre le 18/02/2018 et le 19/02/2018. Il manque des sections mais le travail effectué devient lisible.
|
|
|
|-
| P42 [[IMA4 2017/2018 P42|Automatisation de l'assemblage de LEGO]]
| Analyse très correcte.
| Pas de réponse aux questions difficiles "Comment démarrer l'imprimante à distance ? Comment sera calibrée la plaque d’impression ?
Comment la plaque va se fixer sur le sol ? 
| Aucune liste de matériel.
| Tout simplement parfait ! Bien illustré, bien rédigé, le travail est très bien décrit. Il est possible de mettre une copie d'écran de l'application de plus. Pas la peine de vous tirer dans les pattes.
|
|
|
|-
| P44 [[IMA4 2017/2018 P44|Reconnaissance d’objets via Traitement d’image]]
| Le projet ne semble pas encore avoir été sérieusement étudié.
| Net effort de documentation de la page Wiki. Pas de réponse directe à la question difficile sur la Kinect mais une discussion sur le problème posé.
| Aucune liste de matériel.
| Très bonne description du travail. Des illustrations mais il pourrait y avoir des photos du système robotino / kinect.
|
|
|
|-
| P49 [[IMA4 2017/2018 P49|Suivi de la qualité de l’air]]
| Contexte mal présenté, sujet flou. Scénario d'usage à préciser. Pas de contact avec les encadrants avant la présentation.
| Page de Wiki vide.
| Aucune liste de matériel.
| Compte-rendu rapide du travail. Ce compte-rendu est inquiétant. Il ne semble y avoir aucun résultat depuis le début du projet. Un module a été abandonné sans que le module en question n'ait été décrit ou que la raison de l'abandon ait été précisé. Attention votre projet est en voie d'échec.
|
|
|
|-
| P50 [[IMA4 2017/2018 P50|Etage commande de Centaure]]
| Doublant
| Page de Wiki assez vide.
| Aucune liste de matériel.
| Le robot centaure est en plus mauvais état maintenant qu'au début du projet. Vous semblez avoir une nouvelle fois abandonné votre projet. Des ajouts mineurs au Wiki le 19/02/2018.
|
|
|
|-
| P60 [[IMA4 2017/2018 P60|Commande de niveaux d’eau]]
| Présentation très correcte.
| Pas de réponse à la question difficile. Page Wiki un peu vide.
| Pas de matériel à commander.
| Un Wiki incomplet alors que la feuille d'heures est actualisée. Vous semblez toujours bloqués sur les problèmes d'étalonnage !
|
|
|
|-
| P64 [[IMA4 2017/2018 P64|Simulation Labview et mise en réseau Modbus d’un ascenseur]]
| Doublant
| Wiki avec quelques informations sur le travail accompli depuis fin novembre : étude sur modbus et labview. Quelques coquilles.
| Aucune liste de matériel.
| Très peu d'illustrations. Texte mal formaté et avec des coquilles intolérable à ce niveau d'étude. Le compte-rendu donne l'impression d'une méthode de travail très brouillonne.
|
|
|
|-
| P65 [[IMA4 2017/2018 P65|Exosquelette pour apprentissage]]
| Présentation sans support. Trouver des concurrents indirects. Pas de scénario d'usage.
| Page Wiki vide.
| Aucune liste de matériel.
| Rien sur l'avancé du projet. Projet en échec ?
|
|
|
|-
| P66 [[IMA4 2017/2018 P66|Coupe de France de robotique]]
| Analyse très correcte.
| Page Wiki bien tenue. Ajoutez des illustrations.
| Quelques éléments sur le matériel dans la page Wiki mais aucune liste avec références.
| Tout simplement parfait ! Bien illustré, bien rédigé, le travail est très bien décrit. Presque à jour. Vous n'aviez pas des cartes à faire fabriquer à l'extérieur ?
|
|
|
|-
| P67 [[IMA4 2017/2018 P67|Scanner 3D DIY]]
| Exercice bien réalisé.
| Page Wiki très complète. Ajoutez des illustrations.
| Une liste probablement pas exhaustive.
|Exceptionnel ! Très illustré, bien rédigé, le travail de recherche est très bien décrit. Je ne suis pas un fan de la mise en gras d'un quart du texte et la syntaxe Wiki n'est pas vraiment utilisée mais c'est du détail?
|
|
|
|-
| P68 [[IMA4 2017/2018 P68|Générateur de chronogrammes d'ordonnancement]]
| Doublant
| Page Wiki vide.
| Pas de matériel à commander.
| Rien sur l'avancé du projet. Projet en échec ?
|
|
|
|-
| PP1 [[IMA4 2017/2018 Pré-projet 1|Robot hexapode pour escalier]]
| Erasmus
|
|
| Projet en échec constaté.
|
|
|
|-
|}

== Fiche de présence ==

{| class="wikitable"
! Projet !! Elèves !! Séance 1 (17/01) !! Séance 2 (24/01) !! Séance 3 (31/01) !! Séance 4 (7/02) !! Séance 5 (14/02) !! Séance 6 (21/02) !! Séance 7 (7/03) !! Séance 8 (14/03) !! Séance 9 (21/03) !! Séance 10 (28/03) !! Séance 11 (4/04) !! Séance 12 (11/04) !! Séance 13 (18/04)
|-
| P1 [[IMA4 2017/2018 P1|Automatisation de la production de bière]]
|Quentin Boëns / Henri Carlier
|E304
|E304/305
|E304
|E304
|E304
|C201
|-
| P3 [[IMA4 2017/2018 P3|Sécurisation de l'Internet des Objets par surveillance globale]]
|Ji Yang
|E306
|E303
| Pas de salle 
|E301
|E306
|-
| P4 [[IMA4 2017/2018 P4|Développement d'un module d'énergie pour Internet des Objets]]
| Alexis Viscogliosi / Abass Ayoub
|C008
|C008
|E304 Alexis Viscogliosi Absent excusé pour entretien stage
|C008
|C008
|C201
|C201
|-
| P5 [[IMA4 2017/2018 P5|Réseau de capteurs de pollution]]
| Paul Ribeiro / Mehanna Naïf
|E303
|E301
|A204 Absents 
|E301
|E301 puis B309 puis B207
|E301
|E301
|-
| P6 [[IMA4 2017/2018 P6|Réseau LoRaWAN]]
| Antoine Gosse
| E306
| E306
| E306
| E306
| E306
| E306
| E306
|-
| P7 [[IMA4 2017/2018 P7|Brique pour apprentissage informatique]]
| Maëva Delaporte / Simon Blas
| E304 
| E304 
| E304 
| E301 
| E301 
| E301 
| E301 
|-
| P10 [[IMA4 2017/2018 P10|Portage de RIOT-OS sur MSP430 pour IOT]]
| Baptiste Cartier
| E306
| E301
| E306
| E301
| E301
| E301
| E306
|-
| P12 [[IMA4 2017/2018 P12|Système d'ostéophonie pour magicien]]
| Amine El Messaoudi / Simon Feutrier
| E301
| E301
| C201
| C201
| B207
| C201
| C201
|-
| P14 [[IMA4 2017/2018 P14|Ecran géant modulaire]]
| Jade Dupont
|E304
|E304
|E304
|E304
|E304
|Absence Maladie
|E304
|-
| P15 [[IMA4 2017/2018 P15|Balle vibrante connectée pour enfants sourd]]
| Thomas Cunin / Thibault Cattelain
| E304
| B306/E304
| Pas de salle (E304 - A305)
| E301
| E301
| E301
| E301
|-
| P16 [[IMA4 2017/2018 P16|Sous-chaussure chauffante pour docker]]
| Rémi Mairesse / Gustave Roux
| E304
| E301
| Pas de salle 
| E304
| E304
| E304 / C201
|-
| P17 [[IMA4 2017/2018 P17|Safe Watch]]
| Oumaima Naanaa
|E302
|E304
|E304
|E304
|E304
|E304
|E304
|-
| P18 [[IMA4 2017/2018 P18|Mandala électronique]]
| Lirui Zhang / Lihe Zhang
| E304
| E304
| E304
| E304
| E304

|-
| P19 [[IMA4 2017/2018 P19|Bijou électronique]]
| Lijie Yao / Keren Qiang
| E303
| E304
| E304
| E304
| E304
| E304
| E304
|-
| P20 [[IMA4 2017/2018 P20|Solution de messagerie à base de conteneurs]]
| Maxime Creteur / Gao Fan
|E303
|E301
|A204 Absents 
|E303
|B309 puis B207
|E301
|E301
|-
| P22 [[IMA4 2017/2018 P22|Horloge numérique DCF77, serveur de temps et ludique]]
| Amaury Knockaert / Fabrice Taingland
| E304
| E304
| E304/E302
| C203/E306
| E306/E304
| Forum stages euratech/E304
| E304

|-
| P23 [[IMA4 2017/2018 P23|Table de bar connectée]]
| Matthieu Delobelle
| E306
| E306
| E303 - C201
| E306 - C201
| E304
| E306
| E306
|-
| P25 [[IMA4 2017/2018 P25|Essaim de robots]]
| Benjamin Canu / Ganix Etcheguibel
| E306
| E306
| E306
| E306
| E306
| Forum Euratech jusque 17h E306
| E306
|-
| P30 [[IMA4 2017/2018 P30|Contrôle d'une caméra WiFi.]]
| Taky Djeraba / Thomas Hubert
| E306
| E306
| Pas de salle 
| E306
| E306
| E306
| E306
|-
| P32 [[IMA4 2017/2018 P32|Tribute to Peter Vogel]]
| Jean-Baptiste Watine / Antoine Untereiner
| E306/C201
| E301
| Pas de salle (C201) 
| C205
| C205/E301
| C205/E301
| E301
|-
| P35 [[IMA4 2017/2018 P35|Manette de jeu vidéo pour personne en situation de handicap]]
| Transley Gracias / Camille Saad
| E306
| E306
| E305
| E306
| E306
| E306
| E306
|-
| P39 [[IMA4 2017/2018 P39|Musique des plantes]]
| Xavier Chenot / Rodolphe Toin
| E306
| E306
| E306
| E306
| E306
| E306
| E306 puis C201
|-
| P40 [[IMA4 2017/2018 P40|Exploration du réseau d'anonymisation Tor]]
| Antoine Duquenoy / Anthony Durot
| E306
| E306
| E306
| E306
| E306
| E306
| E306
|-
| P42 [[IMA4 2017/2018 P42|Automatisation de l'assemblage de LEGO]]
| Eloi Zalczer / Justine Senellart
|E302/E306
|E302/E306
|E304/E302
|E304/E302
|E306/E302
|Hors Polytech/E302
|E302/E304
|-
|-
| P44 [[IMA4 2017/2018 P44|Reconnaissance d’objets via Traitement d’image]]
| Damien Narbais / Zoé Briois
| E306
| E301
| Pas de salle (E301)
| E304 + 17h réunion C00X
| C205
| E304 + 17h réunion C00X
| A317
|-
| P49 [[IMA4 2017/2018 P49|Suivi de la qualité de l’air]]
| Hugo Delbroucq / Nicolas Havard
| E301
| INRIA
| Pas de salle (INRIA)
| E301
| E301 puis E304
| E301
| E301
|
|
|-
| P50 [[IMA4 2017/2018 P50|Etage commande de Centaure]]
|-
| P60 [[IMA4 2017/2018 P60|Commande de niveaux d’eau]]
| Claire Vandamme / Alexandra Villa
|C008
|C008
|Hors Polytech/B106 Pas de salle Absentes 
|C008
|C008
|Bureau de Mr Pekpe/E306
|C008
|-
| P64 [[IMA4 2017/2018 P64|Simulation Labview et mise en réseau Modbus d’un ascenseur]]
|-
| P65 [[IMA4 2017/2018 P65|Exosquelette pour apprentissage]]
| Florian Le Foll
| E301
| E301
| (Pas de salle) E303
|E303
|E303
|-
| P66 [[IMA4 2017/2018 P66|Coupe de France de robotique]]
| Carval Amaury/ Prud'Homme Geoffrey
| fabricarium
| fabricarium puis Hors Polytech
| E304
| E301
| Carval E306 - Preud'homme E301
| E301
|-
| P67 [[IMA4 2017/2018 P67|Scanner 3D DIY]]
| Erwan Dufresne
| E302/E306
| E301
| E304
| E301
| E302
| E306
| E302
| Fabricarium
|-
| PP1 [[IMA4 2017/2018 PP1|Robot hexapode pour escalier]]
| Eduardo Gomez
| C201
| C201
| C201
| Fabricarium
| Fabricarium
| C201
| C201/Fabricarium
|-
| P68 [[IMA4 2017/2018 P68|Générateur de chronogrammes d'ordonnancement]]
|}

IMA4 2017/2018 P6

2018-02-21T15:02:54Z

Agosse : /* Séance 17 - 21/02/18 - 4H */

IMA4 2017/2018 P6

2018-02-21T14:56:14Z

Agosse :

Discussion:Projets IMA4 SC & SA 2017/2018

2018-02-15T01:36:15Z

Agosse :

== Notes sur les projets ==

{| class="wikitable"
| Projet || Analyse du projet || Retour sur l'analyse || Matériel || Mi-parcours || Wiki terminé || Rapport || Vidéo
|-
| P1 [[IMA4 2017/2018 P1|Automatisation de la production de bière]]
| Présentation sans supports, bonne analyse de la concurrence. Par contre le scénario d'usage est à revoir en précisant l'usage pour le particulier.
| Le scénario est précisé mais aucune réponse aux questions difficiles "gestion des températures et procédure d'entretien".
| Rien.
|
|
|
|
|-
| P3 [[IMA4 2017/2018 P3|Sécurisation de l'Internet des Objets par surveillance globale]]
| Présentation focalisée sur les réseaux de neurones. Exercice mal compris (pas d'introduction du contexte, pas de scénario d'usage).
| Toujours pas d'analyse de la concurrence, ni de scénario d'usage. Pas de réponse aux questions difficiles "quel est le matériel ? quel est le protocole ? quelles sont les entrées du réseau de neurones ?".
| Une liste mais il manque des références vers les fournisseurs agréés (voir page de l'an dernier).
|
|
|
|
|-
| P4 [[IMA4 2017/2018 P4|Développement d'un module d'énergie pour Internet des Objets]]
| Exercice correctement réalisé.
| Pas de réponse aux questions difficiles "Architecture de la source d'énergie (nombre de chemins d'énergie ?)".
| Rien.
|
|
|
|-
| P5 [[IMA4 2017/2018 P5|Réseau de capteurs de pollution]]
| Présentation focalisée sur la création du site Web. Effort fait pour rédiger un scénario d'usage.
| Réponses aux questions mais l'analyse de la consommation est imprécise. 
| Du matériel listé dans la page Wiki mais à reporter en bas de la page des projets de cette année avec des références valides.
|
|
|
|
|-
| P6 [[IMA4 2017/2018 P6|Réseau LoRaWAN]]
| Exercice correctement réalisé. Scénario d'usage à préciser sur la partie réseau de capteurs.
| Scénario d'usage non précisé. Pas de réponse à la question difficile.
| Du matériel listé mais sans référence, êtes-vous sur que le matériel n'a pas besoin d'être acheté ?
|
|
|
|
|-
| P7 [[IMA4 2017/2018 P7|Brique pour apprentissage informatique]]
| Pas de support. Exercice très bien réalisé.
| Pas de réponse aux questions difficiles "quelle alimentation ? comment faire pour différencier les briques ? comment les briques vont-elles communiquer ? quelle sécurité vis-à-vis des enfants ?"
| Pas de liste de matériel.
|
|
|
|
|-
| P10 [[IMA4 2017/2018 P10|Portage de RIOT-OS sur MSP430 pour IOT]]
| Rien à signaler (juste une confusion entre le MSP430 et le CC430).
| Questions difficiles évacuées. 
| Du matériel listé mais sans référence.
|
|
|
|
|-
| P12 [[IMA4 2017/2018 P12|Système d'ostéophonie pour magicien]]
| Un peu rapide, exercice réalisé. 
| Pas d'analyse de la concurrence. Peu d'effort de rédaction. Des coquilles. Une réponse rapide à la question difficile.
| Du matériel listé mais pas forcément exhaustif et sans référence valide.
|
|
|
|
|-
| P14 [[IMA4 2017/2018 P14|Ecran géant modulaire]]
| Doublant
| Doublant
| Page Wiki vide, pas de liste de matériel.
|
|
|
|
|-
| P15 [[IMA4 2017/2018 P15|Balle vibrante connectée pour enfants sourd]]
| Présentation acceptable mais avec des supports non soignés. Pas d'analyse de la concurrence, pas de scénario d'usage.
| L'analyse de la concurrence et le scénario d'usage ont été ajoutés. Par contre pas de réponse aux questions difficiles "quelle sera l'autonomie de la balle et quel sera le système de rechargement ?".
| Pas de liste de matériel.
|
|
|
|
|-
| P16 [[IMA4 2017/2018 P16|Sous-chaussure chauffante pour docker]]
| Présentation acceptable mais avec des supports non soignés. Trouver des concurrents indirects. Une histoire mais pas de scénario d'usage.
| Page Wiki modifiée après la présentation. Une réponse incomplète à la question difficile. Trop de coquilles pour ce niveau d'études.
| Pas de liste de matériel.
|
|
|
|
|-
| P17 [[IMA4 2017/2018 P17|Safe Watch]]
| Doublant
| Doublant
| Aucune modification de la page Wiki depuis début octobre.
|
|
|-
| P18 [[IMA4 2017/2018 P18|Mandala électronique]]
| Supports très textuels, pas de scénario d'usage mais une rédaction sur l'intérêt psychologique, pas vraiment de partie "concurrents".
| Un effort pour trouver des "concurrents", pas de réponses aux questions difficiles "combien de LEDs ? quelle alimentation pour quelle autonomie".
| Pas de liste de matériel.
|
|
|
|
|-
| P19 [[IMA4 2017/2018 P19|Bijou électronique]]
| Bonne présentation orale. Utilisation du bluetooth peu convainquant. Pas de scénario d'usage. Un "concurrent" trouvé.
| Concept de scénario d'usage non compris. Une réponse à la question difficile très rapide et non convaincante.
| Une liste de matériel dans la page Wiki mais à insérer dans le tableau en bas de la page principale. Pas de référence (voir sur la page de l'an passé).
|
|
|
|
|-
| P20 [[IMA4 2017/2018 P20|Solution de messagerie à base de conteneurs]]
| Support assez corrects, sujet non entièrement compris, scénario d'usage minimal.
| Un problème dans le scénario d'usage : les conteneurs doivent être lancés sur un serveur. Une réponse acceptable à la question difficile.
| Pas de matériel particulier.
|
|
|
|
|-
| P22 [[IMA4 2017/2018 P22|Horloge numérique DCF77, serveur de temps et ludique]]
| Analyse très correcte.
| Réponse à la question difficile.
| Aucune liste de matériel.
|
|
|
|
|-
| P23 [[IMA4 2017/2018 P23|Table de bar connectée]]
| Présentation trop impécise, pas vraiment de scénario d'usage. Par contre des concurrents ont été présentés.
| Un scénario d'usage éloigné de la future utilisation. Trop de coquilles dans ce scénario. Réponse à la question difficile.
| Une liste du matériel mais pas dans la page principale. Pas de référence (voir page de l'an passé).
|
|
|
|
|-
| P25 [[IMA4 2017/2018 P25|Essaim de robots]]
| Analyse très correcte. Un concurrent assez peu en rapport avec les essaims de robots mais dans la ligne des dispositifs de déminage.
| Pas de question difficile.
| Liste du matériel. Préciser pour le chassis.
|
|
|
|
|-
| P30 [[IMA4 2017/2018 P30|Contrôle d'une caméra WiFi.]]
| Objectif mal expliqué. Exercice réalisé.
| Mieux définir l'objectif suite à la visite en entreprise. Pas de réponse à la question difficile.
| Aucune liste de matériel.
|
|
|
|
|-
| P32 [[IMA4 2017/2018 P32|Tribute to Peter Vogel]]
| Excellente présentation et excellent travail préparatoire, Scénario d'usage à préciser, trouver des concurrents.
| Réponse à la question difficile.
| Aucune liste de matériel.
|
|
|
|
|-
| P35 [[IMA4 2017/2018 P35|Manette de jeu vidéo pour personne en situation de handicap]]
| Exercice réussi. Cependant précisez les acteurs dans le scénario d'usage.
| Pas de modification du scénario. Pas de réponse à la question difficile.
| Rien à redire sur la liste de matériel.
|
|
|
|
|-
| P39 [[IMA4 2017/2018 P39|Musique des plantes]]
| Analyse très correcte.
| Réponses aux questions difficiles.
| Aucune liste de matériel.
|
|
|
|
|-
| P40 [[IMA4 2017/2018 P40|Exploration du réseau d'anonymisation Tor]]
| Sujet se prêtant peu à l'exercice mais très bonne présentation. Sujet travaillé.
| Pas vraiment de question, la suggestion est noté dans la page Wiki.
| Pas de matériel à commander.
|
|
|
|
|-
| P42 [[IMA4 2017/2018 P42|Automatisation de l'assemblage de LEGO]]
| Analyse très correcte.
| Pas de réponse aux questions difficiles "Comment démarrer l'imprimante à distance ? Comment sera calibrée la plaque d’impression ?
Comment la plaque va se fixer sur le sol ? 
| Aucune liste de matériel.
|
|
|
|
|-
| P44 [[IMA4 2017/2018 P44|Reconnaissance d’objets via Traitement d’image]]
| Le projet ne semble pas encore avoir été sérieusement étudié.
| Net effort de documentation de la page Wiki. Pas de réponse directe à la question difficile sur la Kinect mais une discussion sur le problème posé.
| Aucune liste de matériel.
|
|
|
|
|-
| P49 [[IMA4 2017/2018 P49|Suivi de la qualité de l’air]]
| Contexte mal présenté, sujet flou. Scénario d'usage à préciser. Pas de contact avec les encadrants avant la présentation.
| Page de Wiki vide.
| Aucune liste de matériel.
|
|
|
|
|-
| P50 [[IMA4 2017/2018 P50|Etage commande de Centaure]]
| Doublant
| Page de Wiki assez vide.
| Aucune liste de matériel.
|
|
|
|
|-
| P60 [[IMA4 2017/2018 P60|Commande de niveaux d’eau]]
| Présentation très correcte.
| Pas de réponse à la question difficile. Page Wiki un peu vide.
| Pas de matériel à commander.
|
|
|
|
|-
| P64 [[IMA4 2017/2018 P64|Simulation Labview et mise en réseau Modbus d’un ascenseur]]
| Doublant
| Wiki avec quelques informations sur le travail accompli depuis fin novembre : étude sur modbus et labview. Quelques coquilles.
| Aucune liste de matériel.
|
|
|
|
|-
| P65 [[IMA4 2017/2018 P65|Exosquelette pour apprentissage]]
| Présentation sans support. Trouver des concurrents indirects. Pas de scénario d'usage.
| Page Wiki vide.
| Aucune liste de matériel.
|
|
|
|
|-
| P66 [[IMA4 2017/2018 P66|Coupe de France de robotique]]
| Analyse très correcte.
| Page Wiki bien tenue. Ajoutez des illustrations.
| Quelques éléments sur le matériel dans la page Wiki mais aucune liste avec références.
|
|
|
|
|-
| P67 [[IMA4 2017/2018 P67|Scanner 3D DIY]]
| Exercice bien réalisé.
| Page Wiki très complète. Ajoutez des illustrations.
| Une liste probablement pas exhaustive.
|
|
|
|
|-
| P68 [[IMA4 2017/2018 P68|Générateur de chronogrammes d'ordonnancement]]
| Doublant
| Page Wiki vide.
| Pas de matériel à commander.
|
|
|
|
|-
| PP1 [[IMA4 2017/2018 Pré-projet 1|Robot hexapode pour escalier]]
| Erasmus
|
|
|
|
|-
|}

== Fiche de présence ==

{| class="wikitable"
! Projet !! Elèves !! Séance 1 (17/01) !! Séance 2 (24/01) !! Séance 3 (31/01) !! Séance 4 (7/02) !! Séance 5 (14/02) !! Séance 6 (21/02) !! Séance 7 (7/03) !! Séance 8 (14/03) !! Séance 9 (21/03) !! Séance 10 (28/03) !! Séance 11 (4/04) !! Séance 12 (11/04) !! Séance 13 (18/04)
|-
| P1 [[IMA4 2017/2018 P1|Automatisation de la production de bière]]
|Quentin Boëns / Henri Carlier
|E304
|E304/305
|E304
|E304
|E304
|-
| P3 [[IMA4 2017/2018 P3|Sécurisation de l'Internet des Objets par surveillance globale]]
|Ji Yang
|E306
|E303
| Pas de salle 
|E301
|E306
|-
| P4 [[IMA4 2017/2018 P4|Développement d'un module d'énergie pour Internet des Objets]]
| Alexis Viscogliosi / Abass Ayoub
|C008
|C008
|E304 Alexis Viscogliosi Absent excusé pour entretien stage
|C008
|C008
|-
| P5 [[IMA4 2017/2018 P5|Réseau de capteurs de pollution]]
| Paul Ribeiro / Mehanna Naïf
|E303
|E301
|A204 Absents 
|E301
|E301 puis B309 puis B207
|-
| P6 [[IMA4 2017/2018 P6|Réseau LoRaWAN]]
| Antoine Gosse
| E306
| E306
| E306
| E306
| E306
|-
| P7 [[IMA4 2017/2018 P7|Brique pour apprentissage informatique]]
| Maëva Delaporte / Simon Blas
| E304 
| E304 
| E304 
| E301 
| E301 
|-
| P10 [[IMA4 2017/2018 P10|Portage de RIOT-OS sur MSP430 pour IOT]]
| Baptiste Cartier
| E306
| E301
| E306
| E301
| E301
|-
| P12 [[IMA4 2017/2018 P12|Système d'ostéophonie pour magicien]]
| Amine El Messaoudi / Simon Feutrier
| E301
| E301
| C201
| C201
|-
| P14 [[IMA4 2017/2018 P14|Ecran géant modulaire]]
| Jade Dupont
|E304
|E304
|E304
|E304
|E304
|-
| P15 [[IMA4 2017/2018 P15|Balle vibrante connectée pour enfants sourd]]
| Thomas Cunin / Thibault Cattelain
| E304
| B306/E304
| Pas de salle (E304 - A305)
| E301
|-
| P16 [[IMA4 2017/2018 P16|Sous-chaussure chauffante pour docker]]
| Rémi Mairesse / Gustave Roux
| E304
| E301
| Pas de salle 
| E304
|-
| P17 [[IMA4 2017/2018 P17|Safe Watch]]
| Oumaima Naanaa
|E302
|E304
|E304
|E304
|E304
|-
| P18 [[IMA4 2017/2018 P18|Mandala électronique]]
| Lirui Zhang / Lihe Zhang
| E304
| E304
| E304
| E304

|-
| P19 [[IMA4 2017/2018 P19|Bijou électronique]]
| Lijie Yao / Keren Qiang
| E303
| E304
| E304
| E304
| E304
|-
| P20 [[IMA4 2017/2018 P20|Solution de messagerie à base de conteneurs]]
| Maxime Creteur / Gao Fan
|E303
|E301
|A204 Absents 
|E303
|B309 puis B207
|-
| P22 [[IMA4 2017/2018 P22|Horloge numérique DCF77, serveur de temps et ludique]]
| Amaury Knockaert / Fabrice Taingland
| E304
| E304
| E304/E302
| C203/E306
|-
| P23 [[IMA4 2017/2018 P23|Table de bar connectée]]
| Matthieu Delobelle
| E306
| E306
| E303 - C201
| E306 - C201
| E304
|-
| P25 [[IMA4 2017/2018 P25|Essaim de robots]]
| Benjamin Canu / Ganix Etcheguibel
| E306
| E306
| E306
| E306
| E306
|-
| P30 [[IMA4 2017/2018 P30|Contrôle d'une caméra WiFi.]]
| Taky Djeraba / Thomas Hubert
| E306
| E306
| Pas de salle 
|-
| P32 [[IMA4 2017/2018 P32|Tribute to Peter Vogel]]
| Jean-Baptiste Watine / Antoine Untereiner
| E306/C201
| E301
| Pas de salle (C201) 
| C205
| C205/E301
|-
| P35 [[IMA4 2017/2018 P35|Manette de jeu vidéo pour personne en situation de handicap]]
| Transley Gracias / Camille Saad
| E306
| E306
| E305
| E306
| E306
|-
| P39 [[IMA4 2017/2018 P39|Musique des plantes]]
| Xavier Chenot / Rodolphe Toin
| E306
| E306
| E306
| E306

|-
| P40 [[IMA4 2017/2018 P40|Exploration du réseau d'anonymisation Tor]]
| Antoine Duquenoy / Anthony Durot
| E306
| E306
| E306
| E306
| E306
|-
| P42 [[IMA4 2017/2018 P42|Automatisation de l'assemblage de LEGO]]
| Eloi Zalczer / Justine Senellart
|E302/E306
|E302/E306
|E304/E302
|E304/E302
|E306/E302
|-
|-
| P44 [[IMA4 2017/2018 P44|Reconnaissance d’objets via Traitement d’image]]
| Damien Narbais / Zoé Briois
| E306
| E301
| Pas de salle (E301)
| E304 + 17h réunion C00X
| C205
|-
| P49 [[IMA4 2017/2018 P49|Suivi de la qualité de l’air]]
| Hugo Delbroucq / Nicolas Havard
| E301
| INRIA
| Pas de salle (INRIA)
| E301
| E301 puis E304
|
|
|
|
|-
| P50 [[IMA4 2017/2018 P50|Etage commande de Centaure]]
|-
| P60 [[IMA4 2017/2018 P60|Commande de niveaux d’eau]]
| Claire Vandamme / Alexandra Villa
|C008
|C008
|Hors Polytech/B106 Pas de salle Absentes 
|C008
|C008
|-
| P64 [[IMA4 2017/2018 P64|Simulation Labview et mise en réseau Modbus d’un ascenseur]]
|-
| P65 [[IMA4 2017/2018 P65|Exosquelette pour apprentissage]]
| Florian Le Foll
| E301
| E301
| (Pas de salle) E303
|E303
|E303
|-
| P66 [[IMA4 2017/2018 P66|Coupe de France de robotique]]
| Carval Amaury/ Prud'Homme Geoffrey
| fabricarium
| fabricarium puis Hors Polytech
| E304
| E301
| Carval E306 - Preud'homme E301
|-
| P67 [[IMA4 2017/2018 P67|Scanner 3D DIY]]
| Erwan Dufresne
| E302/E306
| E301
| E304
| E301
| E302
|-
| P68 [[IMA4 2017/2018 P68|Générateur de chronogrammes d'ordonnancement]]
|}

IMA4 2017/2018 P6

2018-02-08T20:56:44Z

Agosse : /* Scénario d'usage du produit ou du concept envisagé */

IMA4 2017/2018 P6

2018-02-08T20:56:27Z

Agosse : /* Réponse à la question difficile */

IMA4 2017/2018 P6

2018-02-08T20:55:56Z

Agosse : /* Réponse à la question difficile */

IMA4 2017/2018 P6

2018-02-08T20:46:57Z

Agosse : /* Description */