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

Fichier:P20 2022 2023 rapport final.pdf

2025-01-30T12:12:28Z

Rex :

IMA5 2020/2021 P2

2024-12-11T17:25:55Z

Rex : /* Network Server */

__TOC__
<br style="clear: both;"/>

=Présentation générale=

==Description==
Aujourd’hui la qualité de l’air et plus globalement la pollution atmosphérique est un enjeu environnemental majeur, notamment dans le cadre du travail. Ce danger fait l’objet de préoccupations depuis plusieurs années et apparaît aujourd’hui comme un problème majeur de santé publique. Notre projet a pour objectif de répondre à cette problématique en proposant une analyse en temps réel de la qualité de l’air des locaux de Polytech. En effet, l’amélioration de la qualité de l’air passe en premier lieu par l’étude de celle-ci, il est primordial de connaître notre environnement avec précision.

==Objectifs==
Nos objectifs se séparent en 3 parties :
*Le développement de stations émettrices.
Nous devons développer le firmware des stations émettrices pour que ces dernières puissent intégrer les capteurs que nous avons à dispositions (température, humidité, pression, CO2, H2S, …) et envoyer ces données par ondes radio via nos modules Lora, ce code devra être le plus générique possible en vue de l’intégration de futurs capteurs. Nous devons également mettre en place un shield pour que la modularité de ces stations soit accrue et que l’ajout de capteur soit facilement faisable. Notre microcontrôleur, notre module antenne Lora ainsi que nos capteurs seront placés dans une boîte ce qui constituera notre station. Cette boîte permettra de rendre notre station plus compacte et plus esthétique tout en garantissant un accès facile aux composants internes de cette dernière.
*La mise en place d’un réseau LoRaWaN.
La mise en place de notre réseau LoRaWAN passe par plusieurs éléments. Tout d’abord ce qu’on appelle des end-points ou nœuds terminaux (nos stations émettrices). Ces stations envoient leurs informations par ondes radios, qui sont reçues par nos passerelles Kerlink. Le but de ces passerelles est de faire le lien entre nos stations et notre network serveur. Notre tâche est donc de configurer ces passerelles mais également notre network serveur qui réceptionne toutes les informations de nos stations. Finalement notre dernière tâche est de mettre en place un serveur applicatif qui stockera l’ensemble des données pour pouvoir par la suite les présenter à l’utilisateur. Bien entendu notre chaîne de transmission devra être sécurisée avec un système de chiffrement (clé publique/privée).
*La récupération et l'affichage des données.
Notre dernier objectif représente notre partie applicative. Une fois les données enregistrées et stockées dans notre base de données, nous devons mettre en place un application qui sera mise à disposition des utilisateurs pour consulter les données sur la qualité de l’air. Certaines de ces données ne seront pas totalement traitées, il faudra donc pouvoir les repérer et leur appliquer un dernier traitement avant de les présenter. Pour ce qui est de la présentation, un système de graphique sur une donnée spécifique et des indices sur la qualité sur la qualité de l’air représente la manière la plus simple (pour l’utilisateur) de visualiser les informations importantes.

=Travail effectué=

==Prise en main du matériel==

===Transmission entre 2 cartes===

Choix de l'IDE : Nous avons testé différentes IDE (Semtec, uVision, Mbed Studio, STM32).
De par sa simplicité d'utilisation ainsi que de par la possibilité d'utiliser une version online nous avons privilégier l'utilisation de l'IDE Mbed pour effectuer nos tests.
Cette IDE a d'ailleurs été utilisée dans d'anciens projets Polytech utilisant des émetteurs Lora et des cartes Nucléo.

Afin d'avoir une première manipulation de ces cartes et de l'IDE nous avons utilisé des programmes de démonstration du type "Ping/Pong".
L'émission et la réception des données sont fonctionnelles entre 2 cartes Nucléo possédant des Antennes Lora.

Par la suite et sur demande de nos enseignants référents nous avons arrêté d'utiliser l'IDE Mbed pour partir sur l'IDE STM32.
Cette IDE à l'avantage d'être plus bas niveau dans la configuration des pins mais elle dispose également de fonctions HAL (Hardware Abstraction Layer).
Ce sont des fonctions qui ont été préalablement programmées par STMicroelectronics et qui nous permettent, par exemple, d'effectuer diverses opérations de lectures et d'écriture dans notre mémoire.

===Test des différents capteurs===

Nous disposons de plusieurs capteurs afin d'affiner nos données sur la qualité de l'air :

SEN0248 de chez DFROBOT, capteur de température, humidité, pression et gaz. L'envoie et la réception de données s'effectue via un bus I2C, il est donc nécessaire de fournir une clock à ce capteur.
https://wiki.dfrobot.com/Gravity__I2C_BME680_Environmental_Sensor__VOC,_Temperature,_Humidity,_Barometer__SKU__SEN0248

DFR0066 de chez DFROBOT, capteur de température et d'humidité. L'envoie et la réception de données se fait via une pin Data et SCK, nous devons également fournir une clock à ce capteur.
Datasheet : https://wiki.dfrobot.com/SHT1x_Humidity_and_Temperature_Sensor__SKU__DFR0066_

ULPSM-H2S de chez SPEC SENSOR, capteur de sulfure d'hydrogène
https://www.spec-sensors.com/wp-content/uploads/2016/10/ULPSM-H2S-968-003.pdf

T6713 de chez TELAIRE, capteur de C02
https://14core.com/wp-content/uploads/2017/11/T6700_Series_CO2_sensor_Module_Datasheet.pdf

EC4-2000-SO2 de chez SGX SensorTech, capteur de dioxyde de souffre
https://www.sgxsensortech.com/content/uploads/2014/07/DS-0243-EC4-2000-SO2-Datasheet-V2.pdf

==Réseau LoRaWan==

===Network Server===

Une machine virtuelle est déployée afin d'héberger le Network Server :
* Nom : lorawan.plil.info
* Mdp : *******

Cette machine est connectée à internet via l'interface eth0 et est relié au Vlan 501 (Lorawan) via l'interface eth1. Le Vlan501 comprend donc notre VM, la passerelle Kerlink Outdoor (sur le toit de l'école) et la passerelle Kerlink Indor.

====Serveur DHCP====
Les passerelles Kerlink doivent être connues sur notre réseau, elles doivent donc posséder leur propre adresse IP. Cette adresse IP leur est fournie par un serveur DHCP présent sur la carte réseau "eth1" de la VM lorawan.
Pour ce faire nous créons un sous-réseau IPV4 192.168.42.0/24. Nous attribuons l'adresse 192.168.42.10 à la carte "eth1" et nous configurons le serveur DHCP de manière à attribuer dynamiquement des adresses IPV4 aux nouveaux appareils repérés sur le réseau.

'''''Dans le fichier dhcpd.conf :'''''
subnet 192.168.42.0 netmask 255.255.255.0 {
range 192.168.42.1 192.168.42.9
}

Ce sous réseau permet d'attribuer des adresses IPV4 allant de 192.168.42.1 à 192.168.42.9.

Nous pouvons ainsi accéder à l'interface de configuration des passerelles Kerlink en ssh via l'adresse IP attribuée (Sur lorawan.plil.info) :
* '''Passerelle Outdoor :''' ssh 192.168.42.1, mdp: pdmk-062E7A)
* '''Passerelle Indoor :''' ssh 192.168.42.2, mdp: pdmk-030970)
Cette interface de configuration nous sera très utile lors de la configuration de notre Network Server.

====Installation et configuration du ChirpStack Network Server====
ChirpStack Network Server est une implémentation open-source de LoRaWAN® Network Server. La responsabilité du composant Network Server est la déduplication des trames LoRaWAN reçues par les passerelles LoRa® et de gérer :

- L'authentification

- La couche mac LoRaWAN (et commandes mac)

- La communication avec le serveur d'applications ChirpStack

- La planification des trames de liaison descendante

* '''Installation :'''
La mise en place de ce serveur sur la VM lorawan nécessite d'installer trois entités : un '''gateway-bridge''', un '''network-server''' et un '''application-server

Pour se faire nous avons suivi les instructions du site officiel :
https://www.chirpstack.io/network-server/

* '''Configuration :'''
Différents fichiers de configuration sont alors disponibles :

- /etc/chirpstack-gateway-bridge/chirpstack-gateway-bridge.toml

- /etc/chirpstack-network-server/chirpstack-network-server.toml

- /etc/chirpstack-application-server/chirpstack-application-server.toml

Paramétrages notables :
- Les trois serveurs démarrent automatiquement lors de l'allumage de la VM
- NetworkID : 000000

Nous avons alors un accès a une interface graphique de configuration sur le port 8080 pour notre LoRaWan_Network (accès 172.26.189.22:8080 '''(désactiver le proxy pour cette adresse)'''). Nous instancions alors notre network serveur sous le nom de localhost (localhost:8000).

* '''Configuration des passerelles Kerlink :'''

En connection ssh sur les gateways, nous mettons à jour le firmware des deux passerelles (Indoor : Wirnet iFemToCell et Outdoor Wirnet iBTS). Une fois l'environnement correctement installé, nous nous sommes appuyés sur le https://wikikerlink.fr/ pour activer les '''gateways''' ainsi que leurs '''packet_fowarder''' (https://wikikerlink.fr/wirnet-productline/doku.php?id=wiki:lora:keros_4.3.3:cpf_configuration). Nous instancions notamment notre LoraNetworkServer au sein de nos gateways via la ligne ''gwmp.node = "192.168.42.10"'' dans le fichier ''/etc/lorafwd.toml''

* '''Instanciation des passerelles sur le LNS (LoraNetworkServer) :'''

Sur la VM lorawan, les logs nous montre bien l'émission de message en provenance de nos deux passerelles. Sur l'interface graphique de paramétrage, nous créons alors deux nouvelles instances de gateways en fournissant leur ID respective. Les gateways sont alors visible pour notre LNS et nous remarquons une émission de trame LoRaWan de façon régulière.

A ce point, nous avons un LNS installé, configuré, capable de détecter et communiquer en LoRaWan avec les passerelles au sein de son réseau. La dernière étape consiste donc à tester la transmission complète d'une trame, d'un terminal LoRa à l'application_server.

* '''Test du LNS :'''

Une nouvelle application GPS_Test est créée sur l'interface graphique du LNS, des "application" et "network" keys sont alors générées et transmises manuellement à notre terminal LoRa en le connectant à un ordinateur (la configuration de ce module est possible grâce à l’application : ). Une fois les clefs correctement transmises, nous sommes capables de recevoir les trames et données issues du GPS. Ces données ont donc correctement transité au sein de nos passerelles Kerlink pour être finalement reçues par notre network serveur.
Ceci conclut donc la mise en place du LoraNetworkServer, la prochaine étape consiste donc à connecter nos propres terminaux LoRa.

==Stations==

===Implémentation du firmware===

Suite à plusieurs tests et expérimentations et comme expliqué dans notre partie sur le choix de l'IDE, il a été décidé d'utiliser l'IDE STM32 Cube pour implémenter le firmware. Cette IDE permet en effet l'utilisation de bibliothèques de plus bas niveau que mbed et ainsi d'obtenir un meilleur contrôle de notre carte. Ce meilleur contrôle nous sera par ailleurs utile lors de l'implémentation des bus I2C pour la lecture de certains capteurs mais également lors de la mise en commun de nos différents bibliothèques relatives à nos capteurs.

====Architecture du firmware====

Dans un souci de modularité et de simplicité d'implémentation, notre firmware se découpera en deux parties. La première partie permettra la lecture de chaque capteur connecté à la station tandis que la seconde se chargera de transmettre toute ces données en LoRaWan. Afin de faciliter l'ajout ou le retrait de capteur sur une station établie l'architecture ci-dessous :

[[Fichier:Firmware_archi.png|center|500px]]

Il convient ainsi de créer, pour chaque capteur sur la station :
*Une fonction d'initialisation du capteur (startup séquence etc...), appelée au démarrage de la station.
*Une fonction de lecture spécifique à chaque capteur, appelée dans la boucle principale. Cette fonction de lecture se déroule en deux temps :
**1 - Lecture du capteur (réception et prétraitement des données si besoin)
**2 - Remplissage de la trame avec les données récupérées (en accord avec le format ci-contre)

[[Fichier:FormatTrame.png|center|700px]]

Une fois la trame remplie, celle-ci est transmise à la fonction d'envoi, chargée de transmettre ces données par ondes radio.

Il est capital pour notre projet, avant toute lecture de capteur, d'être capable de transmettre des données vers notre LNS. Nous devons donc disposer d'une bibliothèque permettant de communiquer en respectant les normes d'un réseau LoRa. Cette bibliothèque existe et est disponible à l'adresse suivante : https://www.st.com/content/st_com/en/products/embedded-software/mcu-mpu-embedded-software/stm32-embedded-software/stm32cube-expansion-packages/i-cube-lrwan.html

'''Problèmes rencontrés :'''

La bibliothèque propose des programmes de communications LoRaWan uniquement pour des carte STM32L, non compatible avec notre STM32F411. Après avoir tenté durant plusieurs jours d'adapter le code de la bibliothèque et face à la complexité de la tâche, décision est prise d'utiliser des cartes compatibles avec notre librairie. Nos stations seront donc bâties sur des cartes STM32L152_RE.

'''Communication en LoRa'''

Sur l'interface du LNS :
*Nous créons donc une application "PFE_TheoLolo_2020"
*Nous y instancions un nouveau Device
*L'EUI Device doit correspondre à celui de notre carte, que l'on récupère via les logs de notre serveur.
*Generation d'une Application_key (MAIS PAS de Gen_Application_key qui doit être laissé vide)

Sur notre firmware :
*Ouverture du projet EndNode présent dans la librairie
*Modification du commisionning.h : MAJ de la LORAWAN_APP_KEY et de la LORAWAN_NTW_KEY (Ces deux clefs doivent être IDENTIQUES)

Une fois ces quelques paramètres ajustés, nous sommes capables de visualiser les données issues de notre carte sur notre LNS. La chaîne de communication est maintenant entièrement fonctionnelle. On peut donc pleinement se concentrés sur la lecture des capteurs et la mise en forme des données en amont ainsi que sur la récupération et l'affichage de ces données en aval.

'''Lecture des capteurs'''
Nous disposons, pour notre projet, de nombreux capteurs différents, avec chacun un protocole de lecture définit (en principe) dans leur datasheet. Dans un souci

==Application==

Les données arrivant sur notre LNS doivent être transmises et traitées afin d'être présentées aux utilisateurs de l'application. La partie applicative de notre projet s'effectuera sur une VM nommée Lorap, afin de bien cloisonner la gestion du réseau LoRaWan (sur la VM lorawan) de la gestion applicative (traitement et affichage des données).

===Réception et Gestion des données===

Afin de recevoir les données en provenance de notre LNS (Lora Network Serveur), nous utilisons un bus MQTT.
Mais avant tout qu'est que MQTT ? MQTT (Message Queuing Telemetry Transport) est un protocole de messagerie qui fonctionne sur le principe de souscription/publication qui a été développé à la base pour simplifier la communication entre les machines, pour fonctionner ce protocole de transport nécessite l'utilisation d'un Broker (un serveur) dans notre cas nous avons utilisé le broker Mosquitto.

Ce broker est notamment proposé dans les fichiers de configuration du LNS pour récupérer les données émises par nos stations. La configuration de cette file de message s'effectue dans le fichier '''/etc/chirpstack-application-server/chirpstack-application-server.toml''' de la VM lorawan. Par défaut, le MQTT serveur est disponible sur '''tcp://localhost(VMlorawan):1883.'''.
Nous installons le broker Mosquitto sur la VM lorap puis nous implémentons un script python chargé de récupérer et stocker les données à chaque nouveau message dans des bases de données.

Explication de mosquitto.py :

*Tout d'abord nous souscrivons à un topic de la file de message MQTT 172.26.189.22:1883 (utilisée par notre LNS en tant que publisher)
*Une fonction d'écoute attend l'arrivée de message UP (arrivée de données sous format Json)
*Nous extrayons l'EUI de la station émettrice ainsi que la trame de données des capteurs (en base64)
*Une fonction de traitement se charge d'extraire les informations utiles de cette trame (température, pression, etc...)
*Ces données sont par la suite stockées au sein d'une base de données PostgreSQL et ce grâce à l'utilisation d'un second script en python : postgres.py

Pour toucher quelques mots par rapport à ce dernier script, ce dernier se veut très modulaire et propose des opérations génériques de création de table, d'insertion et de mise à jour de données et bien entendu de suppression.

Ces différents scripts sont exécutés dans un containeur Docker afin d'être totalement indépendant et lancés au démarrage de la machine lorap.

Pour lancer ce containeur nous avons tout d'abord installer Docker sur notre machine, puis créé une image Docker. Cette dernière est très simple, elle se charge de vérifier que python est installé et mis à jour et que les paquets utilisés par le script sont installés.

===Serveur HTTP===

Afin de fournir une interface utilisateur web, nous avons installé le serveur HTTP Apache2. Un serveur HTTP permet à un site web de communiquer avec un navigateur en utilisant le protocole HTTP(S) et ses extensions (WebDAV, etc.).

Installation :
apt install apache2

Une configuration précise n’a pas été nécessaire pour qu’apache fonctionne, la seule configuration a été faite au niveau de notre machine tricholome sur le serveur capbreton, l’explication est faite dans une des parties suivantes.

Le but de notre interface Web est de permettre aux utilisateurs de consulter les informations et les données envoyées par nos stations. Pour ce faire, cette dernière devra disposer d’une page de monitoring (ou utilisation d’une API telle que Grafana, voir partie suivante) permettant de connaître en temps réel la qualité de l’air d’une pièce. Une section devra aussi être développée pour configurer nos balises et changer leur mode (active, inactive ou supprimée), comme nos scripts au niveau de la réception de données sont modulaires, il n’est pas nécessaire de renseigner quelles données sont attendues à la réception. Elle devra également lister l’ensemble des stations connues de la base de données ainsi que leur état. Enfin, une section sera également mise à disposition pour l’affichage de notre monitoring de test.

L’ensemble de nos fichiers html et php se situent dans le dossier /var/www/html. Pour pouvoir utiliser du php sur notre serveur web nous devons installer une extension via la commande suivante :
apt install libapache2-mod-php

Pour pouvoir utiliser et manipuler notre base de données dans nos pages php (à travers des PDO, PHP Data Object) nous avons également installer le package php-pgssql, via la commande :
apt install php-pgsql
Puis il faut décommenter la ligne extension=php_pdo_pgsql dans le fichier php.ini qui se situe dans /etc/php/7.3/apache2/. Dans ce fichier, il peut d'ailleurs être intéressant de modifier les lignes error_reporting et ajouter l'option E_ALL ainsi que la ligne display_errors et ajouter l'option On. Cette modification permet à php de renvoyer des erreurs lors des chargements de nos pages lorsque celles-ci comportent des erreurs.

De plus, pour mettre en place cette interface Web, nous avons utilisé Bootstrap, qui est un Framework, une collection d’outils, utiles à la création du design (graphisme, animation et interactions avec la page dans le navigateur, etc.) pour des sites et des applications Web (code HTML et CSS pour faire des formulaires, boutons, barre de navigation, de recherche, …).

===Base de données===

Pour stocker nos données nous nous sommes dans un premier temps orientés vers InfluxDB, qui est un système de gestion de base de données orienté séries temporelles hautes performances. Ce choix vient du fait que ce système de gestion de données est très largement utilisé dans les applications IoT notamment grâce à ces hautes exigences en termes de disponibilité et de performances en temps réel. Après avoir discuté avec nos tuteurs nous nous sommes réorientés vers PostgreSQL, système de gestion de données que nous avions déjà utilisé en 3e année. Comme nous venons de l'expliquer, la réelle force d'InfluxDB est son aspect temps réels, qui offre beaucoup de précision au niveau des relevés, dans notre cas une telle précision n’était pas réellement justifiée et il valait mieux se concentrer sur une technologie que nous connaissions afin d’aboutir le plus rapidement possible sur un projet fonctionnel.

Installation :
apt install postgresql

Après avoir installé ce serveur, nous avons commencé par créer un nouvel utilisateur (Par défaut seul l’utilisateur postgres peut se connecter aux bases de données, c’est utilisateur créé automatiquement à la suite de l’installation de PostgreSQL) cette opération s’effectue avec la commande suivante :
createuser -d -P user_pfe (mot de passe glopglop)
A la suite de la création de cet utilisateur, nous créons notre base de données :
createdb -O user_pfe db_pfe
Pour se connecter à notre base de données tout juste créée nous utilisons la commande suivante :
psql db_pfe

Notre base de données contient 3 tables :

*La première table, list_stations contient l’ID unique d’une station (ce qui constitue la clé primaire de la table), la trame type que cette dernière envoie (cette trame est présente dans le fichier tram.yaml), le mode de fonctionne de la station ainsi que son statut.

*Notre deuxième table, history_stations contient et stocke l’ensemble des valeurs transmises par notre station. Cette table se compose d’un indice unique d’entrée (qui constitue la clé primaire de la table), de l’ID de la station qui a transmis cette entrée (ce qui est notre clé étrangère, liée à l’ID de la table list_stations), d’une colonne temps qui nous permet d’indexer chaque entrée (ce qui nous sera également utile pour tracer nos graphiques par la suite), d’un type de données (température, taux d’humidité, pression, …) et bien évidemment de la valeur en elle-même.

*Notre dernière table, qui se nomme history_stations_test est comme son nom l’indique une table similaire à history_stations mais utilisée pour nos tests. En effet, comme nous avions pris du retard sur notre projet au niveau développement des firmwares nous avons tout de même avancé sur cette partie en nous basant sur des données fictives, générées grâce à un script en python.

Ces 3 tables sont créées grâce aux commandes suivantes :
CREATE TABLE IF NOT EXISTS list_stations(DevEUI_station VARCHAR (50) NOT NULL, Trame VARCHAR(200) NOT NULL, Mode INT NOT NULL, Status INT NOT NULL, PRIMARY KEY(DevEUI_station))

CREATE TABLE IF NOT EXISTS history_stations(Indice SERIAL, DevEUI_station VARCHAR (100) NOT NULL, Time TIMESTAMP WITH TIME ZONE NOT NULL, Type VARCHAR (50) NOT NULL, Value DOUBLE PRECISION NOT NULL, PRIMARY KEY(Indice), CONSTRAINT fk_list_stations FOREIGN KEY(DevEUI_station) REFERENCES list_stations(DevEUI_station))

Nous avons également, dans un second temps, lors de l’utilisation de containers Docker, modifié le fichier de configuration de PostgreSQL. En effet, avant cette modification, la base de données autorise seulement des connexions en provenance de localhost. Pour pallier à ce problème, dans le fichier pg_hba.conf (qui se situe dans /etc/postgresql/11/main/), nous avons changé l’adresse IPv4 de provenance des connexions par 0.0.0.0/0 (ce qui autorise des connexions de n’importe quel hôte)

===Interface utilisateur===

Afin de prodiguer une interface de monitoring à nos utilisateurs, nous nous servons de l'API Grafana.
Grafana est un logiciel libre sous licence Apache 2.0 qui permet la visualisation de données sous formes de graphique, de tableaux de bord ou simplement d’indicateur depuis plusieurs sources de données tel que PostgreSQL.

La prise en main et l’utilisation de cette API est simple et intuitive. Elle se base sur un système de Dashboard dans lequel il est possible de créer différents panels pour y afficher différentes informations de diverses manières. Dans notre cas nous avons créé 2 Dashboards (un pour notre table history_stations et history_stations_test). Pour créer un graphique qui affiche sur une échelle temporelle les relevés de températures issus de nos stations la requête est la suivante :
SELECT time AS "time", value AS "Température" FROM history_station WHERE type = 'TMP_1 ORDER BY 1

Grafana propose également de partager ces panels, malheureusement de manière statique car ces panels sont transmis sous forme d’image. Une solution est de partager le Dashboard en entier, c’est d’ailleurs la solution qui a été retenue.
Pour que ces Dashboard soient visibles depuis n’importe quelle source et pour tous les utilisateurs (même ceux non connectés) il faut modifier le fichier grafana.ini qui se situe dans /etc/grafana/.

Plusieurs lignes sont décommentés :
*Dans la section Anonymous :
enabled = true

*Dans la section Embedded :
allow_embedding = true
org_name = Main Org.
org_role = Viewer

===Accessibilité de notre application===

Pour rendre notre application web accessible depuis n’importe quel navigateur et sans être connecté au réseau de l’école nous avons réutiliser notre machine virtuelle de PRA qui dispose d’une adresse IP routée ainsi que d’un serveur DNS (qui est d’ailleurs sécurisé par DNSSEC). Dans cette partie nous ne parlerons pas du DNS car la configuration de ce dernier a été fait en PRA. Cette machine virtuelle dispose, comme dit précédemment, d’une adresse ip public : 193.48.57.185. Nous avons rajouté la ligne suivante à la configuration de notre service DNS Bind9 (fichier db.tricholome.site qui se situe dans /etc/bind/) :
pfe IN CNAME www

Grâce à cette ligne, lorsque nous tapons « pfe.tricholome.site » dans notre barre de recherche, le DNS nous retransmet correctement l’adresse de notre site.
De plus, il faut maintenant rediriger l’utilisateur vers le bon site lorsque ce dernier saisi pfe.tricholome.site. Pour cela nous mettons en place un reverse proxy (mandataire inversé). Un reverse proxy permet à un utilisateur d’Internet d’accéder à des serveurs internes. De cette manière, lorsqu'un utilisateur demande la page pfe.tricholome.site, ce dernier arrive sur notre machine tricholome de PRA qui redirige la requête sur notre machine lorap.

La configuration à fournir au fichier pfe.conf (à créer au niveau de /etc/apache2/sites-available) est la suivante :
<VirtualHost * :80>
ServerName pfe.tricholome.site
ServerAdmin Theoic
ProxyPass / http://172.26.189.24:80/
ProxyPassReverse / http://172.26.189.24:80/
</VirtualHost>

Pour autant pour que cela soit totalement fonctionnel il faut que notre machine tricholome de PRA et notre machine lorap puissent communiquer entre elles, en effet le routeur de l’école bloque les échanges entre le vlan 50 et le vlan48. Une solution est de fournir à notre machine tricholome une adresse IP dans le vlan 48 et de fournir une route statique afin de contacter la machine lorap :
up ip address add dev eth1 172.26.145.239/24
up ip route add 172.26.188.0/22 via 172.26.145.254
down ip address del dev eth1 172.26.145.239/24
down ip route del 172.26.188.0/22 via 172.26.145.254

===Sécurisation de notre site - HTTPS===

La sécurisation de notre interface web a également été vivement conseillée par nos tuteurs.
Pour passer un site de HTTP vers HTTPS plusieurs étapes sont nécessaires : la génération des clés publiques et privées, la modification de notre hôte virtuel Apache (qui avait été précédemment modifié pour y inclure notre reverse proxy) mais aussi la signature numérique de notre certificat TLS/SSL par une autorité de certification, ici Let’s encrypt (une autorité de certification qui a pour but de proposer à tous, des certificats SSL gratuitement).

Pour cela nous avons tout d’abord télécharger snapd, qui est un système de déploiement de logiciel pour les systèmes d’exploitation linux. Grâce à snapd nous avons installé Certbot. Certbot est un logiciel client qui automatise la plupart des étapes énoncés précédemment de plus il est facile et intuitif à prendre en main.

La première commande après l’installation et la préparation de Certbot permet d’obtenir nos certificats (il est possible de laisser Certbot les installer mais nous avons préféré le faire nous-même)
certbot certonly –apache

Pour notre PFE nous n’avons pas décidé de mettre en place un système de renouvellement automatique pour nos certificats mais il est tout à fait possible de mettre en place un système de ce genre pour une application amenée à durer dans le temps.
A la suite de cette commande 4 certificats sont obtenus (dans le dossier /etc/letsencrypt/live/pfe.tricholome.site.tld)
*Une clé privée : privkey.pem à impérativement garder confidentielle
*Un certificat serveur : cert.pem
*Des certificats intermédiaires : chain.pem
*L’ensemble des certificats : fullchain.prem

Une fois ces certificats obtenus, il faut intégrer nos certificats à Apache dans notre hôte virtuel :
Une fois de plus nous modifions le fichier pfe.conf (/etc/apache2/sites-available) de la manière suivante :
<VirtualHost *:80>
ServerName pfe.tricholome.site
ServerAdmin Theioc
Redirect permanent / https://pfe.tricholome.site/
</VirtualHost>

<VirtualHost *:443>
ServerName pfe.tricholome.site
ServerAlias pfe.tricholome.site
ServerAdmin Theioc
ProxyPass / http://172.26.189.24:80/
ProxyPassReverse / http://172.26.189.24:80/
SSLEngine on
SSLCertificateFile /etc/letsencrypt/live/pfe.tricholome.site/cert.pem
SSLCertificateKeyFile /etc/letsencrypt/live/pfe.tricholome.site/privkey.pem
SSLCertificateChainFile /etc/letsencrypt/live/pfe.tricholome.site/chain.pem
SSLProtocol all -SSLv2 -SSLv3
SSLHonorCipherOrder on
SSLCompression off
SSLOptions +StrictRequire
SSLCipherSuite ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256
</VirtualHost>

Finalement nous pouvons tester notre nouvelle configuration d’Apache avec la commande :
apachectl configtest
Puis relancer notre serveur Apache pour que les modifications apportées soient prises en compte :
service apache2 restart

====Vérification de la sécurité====

Grâce au site : https://www.ssllabs.com/ssltest/ nous pouvons vérifier la sécurité de notre serveur web

[[Fichier:Securite_tricholome.PNG|center|700px]]

Nous obtenons les mêmes résultats pour notre site graf.tricholome.site, les tests sont concluants, nos sites sont sécurisés.

==Documents rendus==

Rapport (compressé) : [[:File:Rapport_Final_PFE_Thoic.pdf|Rapport_Final_PFE_Thoic.pdf]]

Diapo soutenance : [[:File:Diapo_soutenance_finale_Thoic.pdf|Diapo_soutenance_finale_Thoic.pdf]]

Git du projet : https://archives.plil.fr/tevrard/PFE_Thoic

IMA2a4 2022/2023 P1

2022-12-08T08:55:09Z

Rex :

= <div class="mcwiki-header" style="border-radius: 10px; padding: 20px; font-weight: bold; text-align: center; font-size: 80%; background: #9FE7FF; vertical-align: top ; width: 100%;">Présentation générale</div> =

==Objectifs==

Conception, réalisation et programmation d’une clef USB réaliste.

==Contexte==

En bureau d’études PeiP systèmes embarqués [[https://peip-ima.plil.fr]] nous faisons réaliser des clefs USB aux élèves depuis 3 ans. Mais ces clefs sont très limitées en capacité, les mémoires utilisées, faciles à adresser, ne dépassant pas les quelques Mo. Le but de ce projet est de concevoir une clef USB de l’ordre de quelques Go avec une gestion de mémoire réaliste pour une durée de vie de la clef
raisonnable.

Les mémoires flash de grande taille sont :
# généralement à accès parallèle et non série (comme les mémoires SPI utilisées en BE PeiP) ;
# sans aucun mécanisme de gestion de l’usure (comme les mémoires utilisées en BE PeiP) ;
# de type NAND, à savoir que l’on ne peut que transformer des 1 en 0, si l’on souhaite revenir sur des 1, il faut réinitialiser toute une page avec que des 1.

Mais surtout ces mémoires sont imparfaites :
*des erreurs peuvent se produire dans certains blocs (quelques bits mais pas si rarement que cela) ;
*des pages complètes peuvent ne plus pouvoir être réinitialisées (selon les mémoires les pages peuvent être réinitialisées 3000 à 10000 fois suivant les modéles).

==Cahier des charges==

En plus de la programmation USB de type « mémoire de masse » vous devrez implanter les dispositifs suivants :
* une table pour repérer les pages hors services ;
* un dispositif de correction d’erreur dans les blocs (vous utiliserez l’algorithme de hamming avec un nombre de bits adapté à la fois au taux d’erreurs de la mémoire et à la fois au nombres d’octets disponibles pour stocker ces bits de correction d’erreur) ;
* un dispositif de réduction d’usure comptant le nombre de réinitialisation des pages et permettant de déplacer des blocs souvent modifiés vers d’autres adresses.

Il est fortement recommandé de simuler tous ces dispositifs sur un PC pour tester tous les éléments avant implantation dans le microcontrôleur.

Du coté matériel vous pourrez vous aider des schémas de clefs sur le Wiki des PeiP. Il est cependant conseillé de passer d’un ATMega16u2 à un ATMega32u4 pour disposer de plus d’E/S et de bus. En effet pour implanter les tables nécessaires au fonctionnement des dispositifs décrits ci-dessus, il est conseillé d’ajouter une mémoire SPI plutôt que d’essayer d’implanter les tables sur la mémoire flash principale.

Implantez aussi des points d’accès USB sur votre clef pour pouvoir obtenir des informations sur la gestion des blocs sur la clef :
* lister les pages hors service ;
* récupérer le nombre d’écritures pour des blocs donnés ;
* récupérer le nombre d’erreurs pour des blocs donnés.

Ecrivez aussi le programme PC permettant de récupérer ces informations pour afficher des statistiques sur la clef.

==Cahier des spécifications==

==Diagramme de Gantt prévisionnel==

= <div class="mcwiki-header" style="border-radius: 10px; padding: 20px; font-weight: bold; text-align: center; font-size: 80%; background: #9FE7FF; vertical-align: top ; width: 100%;">Liens externes</div> =

Lien GitLab :

Présentation projet final :

Rapport final :

IMA2a4 2022/2023 P1

2022-12-08T08:36:16Z

Rex :

= <div class="mcwiki-header" style="border-radius: 10px; padding: 20px; font-weight: bold; text-align: center; font-size: 80%; background: #9FE7FF; vertical-align: top ; width: 100%;">Présentation générale</div> =

==Objectifs==

Conception, réalisation et programmation d’une clef USB réaliste.

==Contexte==

En bureau d’études PeiP systèmes embarqués [[https://peip-ima.plil.fr]] nous faisons réaliser des clefs USB aux élèves depuis 3 ans. Mais ces clefs sont très limitées en capacité, les mémoires utilisées, faciles à adresser, ne dépassant pas les quelques Mo. Le but de ce projet est de concevoir une clef USB de l’ordre de quelques Go avec une gestion de mémoire réaliste pour une durée de vie de la clef
raisonnable.

Les mémoires flash de grande taille sont :
# généralement à accès parallèle et non série (comme les mémoires SPI utilisées en BE PeiP) ;
# sans aucun mécanisme de gestion de l’usure (comme les mémoires utilisées en BE PeiP) ;
# de type NAND, à savoir que l’on ne peut que transformer des 1 en 0, si l’on souhaite revenir sur des 1, il faut réinitialiser toute une page avec que des 1.

Mais surtout ces mémoires sont imparfaites :
*des erreurs peuvent se produire dans certains blocs (quelques bits mais pas si rarement que cela) ;
*des pages complètes peuvent ne plus pouvoir être réinitialisées (selon les mémoires les pages peuvent être réinitialisées 3000 à 10000 fois suivant les modéles).

==Cahier des charges==

Donc, en plus de la programmation USB de type « mémoire de masse » vous devrez implanter les dispositifs suivants :
    • une table pour repérer les pages hors services ;
    • un dispositif de correction d’erreur dans les blocs (vous utiliserez l’algorithme de hamming avec un nombre de bits adapté à la fois au taux
d’erreurs de la mémoire et à la fois au nombres d’octets disponibles pour stocker ces bits de correction d’erreur) ;
    • Un dispositif de réduction d’usure comptant le nombre de réinitialisation des pages et permettant de déplacer des blocs souvent modifiés vers
d’autres adresses.
Il est fortement recommandé de simuler tous ces dispositifs sur un PC pour tester tous les éléments avant implantation dans le microcontrôleur.

Du coté matériel vous pourrez vous aider des schémas de clefs sur le Wiki des PeiP. Il est cependant conseillé de passer d’un ATMega16u2 à un ATMega32u4
pour disposer de plus d’E/S et de bus. En effet pour implanter les tables nécessaires au fonctionnement des dispositifs décrits ci-dessus, il est
conseillé d’ajouter une mémoire SPI plutôt que d’essayer d’implanter les tables sur la mémoire flash principale.

Si vous avez le temps, évitez d’utiliser la bibliothèque LUFA pour la partie USB et passez sur une bibliothèque plus bas niveau comme V-USB voire en
programmant directement les registres.

Implantez aussi des points d’accès USB sur votre clef pour pouvoir obtenir des informations sur la gestion des blocs sur la clef :
    • lister les pages hors service ;
    • récupérer le nombre d’écritures pour des blocs donnés ;
    • récupérer le nombre d’erreurs pour des blocs donnés.
Ecrivez aussi le programme PC permettant de récupérer ces informations pour afficher des statistiques sur la clef.

Pendant que vous y êtes implantez des points d’accès pour pouvoir écrire des données dans les octets non utilisés de votre clef et pour pouvoir récupérer
ces octets.

==Cahier des spécifications==

==Diagramme de Gantt prévisionnel==

= <div class="mcwiki-header" style="border-radius: 10px; padding: 20px; font-weight: bold; text-align: center; font-size: 80%; background: #9FE7FF; vertical-align: top ; width: 100%;">Liens externes</div> =

Lien GitLab :

Présentation projet final :

Rapport final :

IMA2a4 2022/2023 P1

2022-12-08T08:29:57Z

Rex : Page créée avec « = <div class="mcwiki-header" style="border-radius: 10px; padding: 20px; font-weight: bold; text-align: center; font-size: 80%; background: #9FE7FF; vertical-align: top ; w... »

= <div class="mcwiki-header" style="border-radius: 10px; padding: 20px; font-weight: bold; text-align: center; font-size: 80%; background: #9FE7FF; vertical-align: top ; width: 100%;">Présentation générale</div> =

==Contexte==

==Objectifs==

==Historique==

==Cahier des charges==

==Cahier des spécifications==

==Diagramme de Gantt prévisionnel==

= <div class="mcwiki-header" style="border-radius: 10px; padding: 20px; font-weight: bold; text-align: center; font-size: 80%; background: #9FE7FF; vertical-align: top ; width: 100%;">Liens externes</div> =

Lien GitLab :

Présentation projet final :

Rapport final :

Projets IMA5 2022/2023

2022-12-08T08:27:48Z

Rex : /* Répartition des binômes */

== Répartition des binômes ==

{| class="wikitable"
! Projet !! Encadrants école !! Elèves
|-
| P1 [[IMA2a4 2022/2023 P1|2022/2023 Clef USB avec répartition d'usure]]
| Xavier Redon
| Bastien Germond
|-
| P11 [[IMA5 2022/2023 P11|2022/2023 Mallette cybersécurité]]
| Alexandre Boé, Xavier Redon & Thomas Vantroys
| Maxence Laurent
|-
| P15 [[IMA5 2022/2023 P15|2022/2023 Réalisation d’un système d’écoutes sonores à base de MEMS]]
| Alexandre Boé, Thomas Vantroys
| Logan Paquin & Ali Khalaf
|-
| P20 [[IMA5 2022/2023 P20|2022/2023 Jeu de billard virtuel augmenté]]
| Alexandre Boé, Xavier Redon & Thomas Vantroys
| Florian Derlique, Thibault Meynier
|-
|}

IMA3/IMA4 2019/2021 P2

2022-10-03T09:40:01Z

Rex : /* Diagnostics */

= Introduction =

Le réseau RENATER n'est pas adapté à l'enseignement : trop de restrictions par les différents administrateurs réseau. Il est par exemple très compliqué de faire installer des serveurs (DNS, SMTP, Web, etc) aux élèves.

La plateforme mathématiques et informatique s'est donc dotée de lignes spécifiques à l'enseignement. Ces lignes commencent à dater et utilisent la technologie cuivre / ADSL. La migration vers la fibre est en cours.

En attendant, il faut maintenir les lignes ADSL. Les opérateurs, bien que continuant à présenter des factures, ne sont plus en mesure de remplacer les modems / routeurs initialement fournis. Le sujet de ce projet consiste à basculer sur du matériel réseau de la plateforme pour gérer les liaisons ADSL. Le coût doit rester minimal vu qu'il s'agit d'une solution temporaire.

Les deux lignes ADSL sont des lignes France Télécom conservées lors de la privatisation de l'institution sous le nom commercial "orange". La première ligne a même été négociée avec Oléane au début des années 2000 pour permettre aux élèves logés dans la résidence crous Eiffel d'avoir un accès Internet. Une dizaine d'année plus tard la direction de l'école a accédé aux sollicitations du crous pour confier l'accès Internet à un opérateur privé. Nostalgie à part la dénomination officielle des deux lignes est :
* ADSL business internet office (vendue pour un débit 18Mb/s descendant et 80Kb/s montant) ;
* ADSL internet pro solo (accès classique comme pour les particuliers).

Les deux modems / routeurs de ces lignes ont cessé de fonctionner (en 2018 pour la première ligne et en 2020 pour la seconde ligne).

= Première approche Cisco C1700 =

[[File:Cisco1721.jpeg|thumbs|200px|right|Cisco 1721]]

Un premier test a été effectué avec un routeur Cisco 1721. Avec une mémoire flash de 32Mo et une mémoire vive de 64Mo, il est possible de le faire tourner sous un IOS 12.4.

[[File:Wic1adsl.jpeg|thumbs|200px|left|Carte ADSL]]

Le 1721 peut prendre deux cartes WIC classiques, dont en particulier la carte <tt>WIC-1ADSL=</tt>. Ces cartes peuvent se trouver d'occasion autour de 4 euros.

La configuration de l'interface ATM de la carte ADSL est simple :

interface ATM0
no ip address
no atm ilmi-keepalive
dsl operating-mode auto
pvc 8/35
pppoe-client dial-pool-number 1
!
!

A noter que les caractéristiques (ici <tt>8/35</tt>) du circuit vers le fournisseur d'accès dépendent totalement du dit fournisseur. Les identifiants pour l'accès au fournisseur sont déclarés dans une interface virtuelle <tt>Dialer</tt> qui se charge du protocole PPPoE (Point-to-Point Protocol over Ethernet). Le numéro du <tt>dial pool</tt> doit être le même dans la référence de l'interface ATM et dans la configuration de l'interface <tt>Dialer</tt> (ici le numéro est 1).

interface Dialer1
mtu 1492
ip address negotiated
ip virtual-reassembly
encapsulation ppp
dialer pool 1
dialer idle-timeout 0
dialer persistent
ppp chap hostname IDENTIFIANT
ppp chap password 0 MOTDEPASSE
!

Bien entendu il faut remplacer les mot <tt>IDENTIFIANT</TT> et <tt>MOTDEPASSE</tt> avec l'identification fournie par votre fournisseur d'accès. A noter que la récupération de ces identifiants n'est pas toujours évidente. Pour l'ADSL Pro d'orange une demande a été suivie par un courriel contenant l'identifiant le lendemain mais pour l'accès ADSL BIO il a été nécessaire de fournir un document d'autorisation de divulgation par un responsable de l'établissement.

La configuration <tt>mtu 1492</tt> n'est pas optionnelle sans elle le passage par l'interface ATM casse la découverte du MTU maximal d'une façon ou d'une autre. Pour les liaisons peu stables, comme les notres, la directive <tt>dialer persistent</tt> est très utile pour relancer l'identification sur la connexion.

Enfin une liaison ADSL sans mascarade n'est pas très utile vu que l'opérateur ne donne qu'une adresse IPv4 routée. Pour mettre en place la mascarade il faut ajouter la directive <tt>ip nat outside</tt> dans l'interface de sortie vers Internet (ici <tt>Dialer1</tt>) et il faut ajouter <tt>ip nat inside</tt> dans l'interface du réseau local (généralement une interface Ethernet). Enfin il faut définir la mascarade par elle-même :

access-list 1 permit 192.168.0.0 0.0.0.255
ip nat inside source list 1 interface Dialer1 overload

Il ne reste plus qu'à ajouter la route par défaut : <tt>ip route 0.0.0.0 0.0.0.0 Dialer1</tt>.

Dans cette configuration il est supposé que le réseau IPv4 local est <tt>192.168.0.0/24</tt>.

La solution à base de 1721 est fonctionnelle mais avec les limitations ou défauts suivant :
* la carte <tt>WICADSL1=</tt> n'implante que ADSL version 1, dans le cas de notre liaison avec 40db d'atténuation on se retrouve avec des débit de quelques Mb/s même sur la ligne certifiée à 18Mb/s ;
* il n'est pas possible de configurer deux WIC ADSL dans un 1721, ce bogue est répertorié sous le numéro CSCsa90021 ;
* le 2721 est un routeur de bureau non facilement intégrable dans une baie (non fixable sur les rails, alimentation massive séparée), d'autant plus s'il en faut deux, un par liaison ADSL.

= Seconde approche Cisco C2600 =

[[File:2621.jpg|thumbs|500px|left|2621 en baie]]

Il est possible de récupérer les cartes ADSL <tt>WIC-1ADSL</tt> de ces routeurs pour les installer sur un Cisco 2621 un peu plus puissant. De plus ce routeur n'est pas affecté par le bogue CSCsa90021, les 2 cartes ADSL peuvent être configurées simultanément. Le 2621 dont nous disposions possédait lui aussi une mémoire flash de 32Mo et une mémoire vive de 64Mo. Du coup le 2621 peut tourner sous un IOS sensiblement identique à celui du 1721 soit un IOS 12.4.

Pas de modification notable dans la configuration des interfaces ATM, hors numérotation des interfaces et nouvelles options ATM par défaut :
interface ATM0/0
no ip address
atm restart timer 300 ! nouvelle option par défaut
no atm ilmi-keepalive
dsl operating-mode auto
dsl enable-training-log ! nouvelle option par défaut
pvc 8/35
pppoe-client dial-pool-number 1
!
!

La configuration de l'interface <tt>ATM0/1</tt> est identique mis à part le numéro du <tt>dial-pool-number</tt>. Les interfaces virtuelles <tt>Dialer</tt> se configurent de façon strictement semblable sur le 2921 par rapport au 1721.

Par contre cette fois nous avons deux interfaces de sortie par les deux lignes ADSL. Le routage et la mascarade deviennent plus compliqué à configurer.

track 1 ip route IPV4_ISP_ADSL1 255.255.255.255 reachability
track 2 ip route IPV4_ISP_ADSL2 255.255.255.255 reachability
ip route 0.0.0.0 0.0.0.0 Dialer1 track 1
ip route 0.0.0.0 0.0.0.0 Dialer2 track 2

Ce bloc ajoute les routes par défaut via les lignes disponibles à un moment donné. La disponibilité se fait par test ICMP sur les adresses IPv4 coté fournisseur d'adresse. Si deux routes par défaut sont ajoutées, l'algorithme de routage doit équilibrer le trafic sur les différentes lignes ADSL. Dans notre cas le trafic se fait principalement via un mandataire Web. L'algorithme Cisco classique <tt>original</tt> peut suffire. Cet algorithme route toutes les communications d'une adresse IPv4 donnée vers une autre adresse IPv4 donnée vers la même sortie. Si les sites web visités sont peu variés il vaut mieux passer sur l'algorithme <tt>universal</tt> qui ajoute les ports sources et destination dans les éléments de choix de la route de sortie. Cela peut se faire avec la commande

(config)# ip cef load-sharing algorithm universal

Pour la mascarade la configuration est de la forme :

access-list 1 permit 192.168.0.0 0.0.0.255
route-map ADSL1 permit 10
match ip address 1
match interface Dialer1
!
route-map ADSL2 permit 10
match ip address 1
match interface Dialer2
!
ip nat inside source route-map ADSL1 interface Dialer1 overload
ip nat inside source route-map ADSL2 interface Dialer2 overload

Vous constatez que l'astuce consiste à passer par des <tt>route-map</tt> pour que la mascarade puisse se faire en bonne intelligence avec l'équilibrage de charge. Ne pas oublier d'ajouter les <tt>ip nat inside</tt> sur l'interface du réseau local et les <tt>ip nat outside</tt> dans les deux interfaces <tt>Dialer</tt>.

A noter : l'équilibrage n'a pas été testé avec cette configuration, les deux lignes ADSL n'ayant pas pu être opérationnelles simultanément avant l'acquisition de nouvelles cartes ADSL et le passage à un Cisco 2901.

Cette solution à base de 2621 est fonctionnelle mais toujours avec le défaut que les <tt>WIC-1ADSL=</tt> ne sont pas suffisantes pour obtenir un débit satisfaisant avec les limitations ou défauts suivant :

<br style="clear: both;"/>

= Troisième approche Cisco C2900 =

[[File:2901.jpg|thumbs|500px|left|2901 en baie]]

A l'origine l'idée était d'installer les cartes <tt>WIC-1ADSL=</tt> dans 2 des 4 slots WIC d'un Cisco 2901. Mais les slots WIC du 2901 sont des EHWIC (Enhanced High-Speed WAN Interface Cards). Et étrangement les cartes WIC classiques (du moins les <tt>WIC-1ADSL=</tt>) ne fonctionnent pas dans ces slots ou ne sont pas prises en compte par l'IOS.

Un mal pour un bien, il faut utiliser des cartes ADSL plus récentes comme les <tt>HWIC-1ADSL-M</tt>. Ces cartes peuvent être achetées d'occassion autour de 14 euros. C'est plus cher que les <tt>WIC-1ADSL=</tt> mais cela reste tout à fait acceptable. De plus ces cartes sont compatible ADSL version 2 voire même version 2+ ce qui va nettement améliorer le débit des connexions.

Du coté de l'IOS pas de changement par rapport aux 1721 et 2621, nous sommes toujours sur un IOS classique version 12.4 (pour être précis l'image utilisée est <tt>c2900-universalk9-mz.SPA.154-1.T1.bin</tt>). Par contre la complexité de la configuration augmente du au fait que le routeur est déjà utilisé à d'autres fins. Il n'est donc pas possible de modifier la table de routage principale. Il va donc falloir utiliser le dispositif PBR (Policy-Based Routing) de Cisco. Hélas ce dispositif est bien moins abouti que la politique de routage de Linux qui permet d'utiliser de vraies tables de routages annexes et pas seulement de modifier un peu la table principale. Nous allons aussi utiliser le dispositif SLA (Service Level Agreements) dont le principe est de de suivre l'état de services Internet et qui va au delà du simple suivi d'interfaces (tracking) dont nous nous sommes servis jusque là.

<br style="clear: both;"/>

== Configuration ADSL ==

La configuration ADSL est strictement semblable à celle déjà utilisée avec les routeurs précédents.

interface ATM0/0/0
no ip address
no atm ilmi-keepalive
dsl enable-training-log
pvc 8/35
pppoe-client dial-pool-number 1
!
!

interface Dialer1
mtu 1492
ip address negotiated
ip nat outside
ip virtual-reassembly in
encapsulation ppp
dialer pool 1
dialer idle-timeout 0
dialer persistent
ppp chap hostname IDENTIFIANT
ppp chap password 0 MOTDEPASSE
!

Une tentative de récupérer une adresse IPv6 au niveau des interfaces <tt>Dialer</tt> n'a pas réussi. Il faut dire que je ne suis pas convaincu que le fournisseur en propose une.

== Configuration SLA ==

La configuration de vérification de l'état des connexions :

ip sla 20
icmp-echo IPV4_ISP_ADSL1
ip sla schedule 20 life forever start-time now
ip sla 21
icmp-echo IPV4_ISP_ADSL2
ip sla schedule 21 life forever start-time now
track 20 ip sla 20 reachability
track 21 ip sla 21 reachability

Dans notre configuration le dispositif SLA est clairement sous-exploité.

== Configuration PBR ==

Sur l'interface du réseau local il est fait référence à la <tt>route-map</tt> qui implante notre politique de routage (PBR) :

interface INTERFACE
...
ip nat inside
ip virtual-reassembly in max-reassemblies 128
ip tcp adjust-mss 1452
ip policy route-map to_adsl
!

La <tt>route-map</tt> en question :

route-map to_adsl permit 10
match ip address 20
set ip next-hop verify-availability IPV4_ISP_ADSL1 1 track 20
set ip next-hop verify-availability IPV4_ISP_ADSL1 2 track 21
!

Et vous constatez le problème : l'obligation d'un numéro de séquence pour le <tt>next-hop</tt> (juste après l'adresse IPv4 du saut). Du coup les deux routeurs ne sont pas au même niveau (il est interdit d'utiliser deux numéros identique) et donc pas d'équilibrage de charge juste un lien de secours.

== La mascarade ==

Aucun changement dans la définition de la mascarade :

access-list 20 permit 192.168.0.0 0.0.0.255
route-map ADSL2 permit 10
match ip address 20
match interface Dialer2
!
route-map ADSL1 permit 10
match ip address 20
match interface Dialer1
!
ip nat inside source route-map ADSL1 interface Dialer1 overload
ip nat inside source route-map ADSL2 interface Dialer2 overload

== Diagnostics ==

Cette sous-section présente quelques commandes permettant un rapide diagnostic des liaisons ADSL.

Tout d'abord il faut vérifier si le circuit ATM de la connexion ADSL a pu être établi. Ici ce n'est pas le cas :
#show interface ATM0/0/0 | include VCs
23 maximum active VCs, 256 VCs per VP, 0 current VCCs
alors que là tout va bien :
#show interface ATM0/0/0 | include VCs
23 maximum active VCs, 256 VCs per VP, 1 current VCCs
Si vous avez un problème à ce niveau c'est que la connexion physique vers votre ISP est hors-service. Voyez avec eux.

Il est ensuite possible d'apprécier la qualité de la ligne :
#show dsl interface atm 0/0/0 | include Attenuation:
Attenuation: 38.5 dB 22.0 dB
L'atténuation est de 40db sur l'autre ligne. Ces valeurs sont cohérentes avec celles mesurées par les techniciens de l'opérateur. Ils expliquent aussi les débits obtenus dans la sous-section suivante.

Vous pouvez regarder si l'identification PPPoE se passe bien :
#show pppoe session
Uniq ID PPPoE RemMAC Port VT VA State
SID LocMAC VA-st Type
N/A 18215 xxxx.yyyy.zzzz ATM0/0/0 Di1 Vi1 UP
xxxx.yyyy.zzzz VC: 8/35 UP
N/A 2968 xxxx.yyyy.zzzz ATM0/1/0 Di2 Vi2 UP
xxxx.yyyy.zzzz VC: 8/35 UP
Ici un miracle : les deux lignes sont actives.

Pour aller plus loin le suivi des accès est-il correct ?
#sh ip sla summary
IPSLAs Latest Operation Summary
Codes: * active, ^ inactive, ~ pending
ID Type Destination Stats Return Last
(ms) Code Run
-----------------------------------------------------------------------
*20 icmp-echo IPV4_ISP_ADSL1 TT=16 OK 0 seconds ago
*21 icmp-echo IPV4_ISP_ADSL2 TT=20 OK 55 seconds ago
Là encore tout se passe bien les deux lignes ADSL sont opérationnelles, du moins les adresses IPv4 des ISP répondent bien au ping.

Enfin vous pouvez vérifier si la mascarade est opérationnelle :
#sh ip nat statistics
Total active translations: 420 (1 static, 419 dynamic; 411 extended)
Peak translations: 11285, occurred 4w5d ago
...
Dynamic mappings:
-- Inside Source
[Id: 2] route-map ADSL1 interface Dialer1 refcount 1
[Id: 3] route-map ADSL2 interface Dialer2 refcount 0
Le <tt>refcount 1</tt> indique que la première ligne ADSL est utilisée même si elle n'est pas surchargée. Par contre le <tt>refcount 0</tt> montre le défaut d'équilibrage de charge.

== Conclusion ==

Les cartes ADSL2+ permettent d'obtenir de meilleurs débits. Avec quelques rapides mesures en utilisant <tt>ssh</tt> et <tt>dd</tt> les résultats suivants sont obtenus :
* ADSL "pro" : 1,1Mo/s descendant et 100Ko/s montant
* ADSL B.I.O. : 1,3Mo/s descendant et 130Ko/s montant

A noter que les débits "certifiés" pour la liaison B.I.O. ne sont absolument pas tenus. La société orange dirait probablement que les routeurs Cisco ne sont pas assez performants.

Le point négatif est tout de même l'impossibilité, à notre connaissance, d'arriver à effectuer de l'équilibrage de charge avec le dispositif PBR.

= Améliorations =

Plusieurs améliorations de notre configuration sont possibles :
* Mettre en place un routeur dédié : l'utilisation de PBR avec la limitation rencontrée sur l'équilibrage de charge peut être contourner en dédiant un routeur aux seules lignes ADSL. Dans ce cas PBR n'est plus nécessaire et le routage peut se faire comme pour le 2621 avec deux routes par défaut dans la table de routage principale.
* Passer sur une routeur plus récent : nous avons acheté un routeur Cisco 9300 avec un IOS plus récent permettant SLA, PBR et mascarade (cette dernière étant impossible sur un C9200), la limitation sur l'équlibrage de charge PBR de l'IOS 12.4 est peut-être levée ? Au pire le C9300 va remplacer le 2901 qui sera dédié aux lignes ADSL.
* Passer à une technologie de connexion plus récente : un travail de fourmies a été mené par la plateforme maths/info pour recenser les lignes de communication utilisées par Polytech'Lille, une bonne partie étant obsolètes il a été possible de négocier une mutation des lignes ADSL, Numéris, dédiées et SDSL pour se concentrer sur un accès fibre 200Mb/s symétrique.

MediaWiki:Sidebar

2022-09-01T21:29:00Z

Rex :

* navigation
** mainpage|mainpage-description
*** Projets_troisième_quatrième_années|Projets IMA3/IMA4
**** Projets_IMA3_IMA4_2020/2022 |- IMA3/4 2020/22
**** Projets_IMA3_IMA4_2019/2021 |- IMA3/4 2019/21
**** Projets_IMA3_IMA4_2018/2020 |- IMA3/4 2018/20
*** Projets_de_cinquième_année|Projets IMA5
**** Projets_IMA5_SC_2011/2012|- IMA5SC 2011/12
**** Projets_IMA5_2012/2013|- IMA5 2012/13
**** Projets_IMA5_2013/2014|- IMA5 2013/14
**** Projets_IMA5_2014/2015|- IMA5 2014/15
**** Projets_IMA5_2015/2016|- IMA5 2015/16
**** Projets_IMA5_2016/2017|- IMA5 2016/17
**** Projets_IMA5_2017/2018|- IMA5 2017/18
**** Projets_IMA5_2018/2019|- IMA5 2018/19
**** Projets_IMA5_2019/2020|- IMA5 2019/20
**** Projets_IMA5_2020/2021|- IMA5 2020/21
**** Projets_IMA5_2021/2022|- IMA5 2021/22
**** Projets_IMA5_2022/2023|- IMA5 2022/23
*** Projets_de_troisième_année|Archives IMA3 SC
*** Projets_de_quatrième_année|Archives IMA4
**** Projets_IMA4_SC_2010/2011|- IMA4SC 2010/11
**** Projets_IMA4_SC_&_SA_2011/2012|- IMA4 2011/12
**** Projets_IMA4_SC_&_SA_2012/2013|- IMA4 2012/13
**** Projets_IMA4_SC_&_SA_2013/2014|- IMA4 2013/14
**** Projets_IMA4_SC_&_SA_2014/2015|- IMA4 2014/15
**** Projets_IMA4_SC_&_SA_2015/2016|- IMA4 2015/16
**** Projets_IMA4_SC_&_SA_2016/2017|- IMA4 2016/17
**** Projets_IMA4_SC_&_SA_2017/2018|- IMA4 2017/18
**** Projets_IMA4_SC_&_SA_2018/2019|- IMA4 2018/19
**** Projets_IMA4_SC_&_SA_2019/2020|- IMA4 2019/20
** currentevents-url|currentevents
** recentchanges-url|recentchanges
** randompage-url|randompage
** helppage|help
* SEARCH
* TOOLBOX
* LANGUAGES

Projets IMA3 IMA4 2020/2022

2021-10-11T09:27:13Z

Rex :

== Répartition des binômes 2021/2022 ==

{| class="wikitable"
! Projet !! Encadrants ecole !! Eleves
|-
| P1 [[IMA3/IMA4 2020/2022 P1|Titre]]
| Thomas Vantroys
| Prénom Nom
|-
|}

== Répartition des binômes 2020/2021 ==

{| class="wikitable"
! Projet !! Encadrants ecole !! Eleves
|-
| P3 [[IMA3/IMA4 2020/2022 P3|Conception et commande d'un Drone]]
| Midzodzi Pekpe / Othman Lakhal
| Louise Maës / Léo Poumaer / Niels Godbert / Rémi Brachot / Lucas Postollec / Chaimae Yasmine
|-
|}

Projets IMA3 IMA4 2020/2022

2021-10-11T09:24:49Z

Rex :

== Répartition des binômes 2021/2022 ==

{| class="wikitable"
! Projet !! Encadrants ecole !! Eleves
|-
| P3 [[IMA3/IMA4 2020/2022 P3|Conception et commande d'un Drone]]
| K. Midzodzi PEKPE / Othman Lakhal
| Louise MAËS / Léo POUMAER / Niels GODBERT / Rémi BRACHOT / Lucas POSTOLLEC / Chaimae YASMINE
|-
|}

== Répartition des binômes 2020/2021 ==

{| class="wikitable"
! Projet !! Encadrants ecole !! Eleves
|-
| P3 [[IMA3/IMA4 2020/2022 P3|Conception et commande d'un Drone]]
| K. Midzodzi PEKPE / Othman Lakhal
| Louise MAËS / Léo POUMAER / Niels GODBERT / Rémi BRACHOT / Lucas POSTOLLEC / Chaimae YASMINE
|-
|}

Projets IMA3 IMA4 2020/2022

2021-10-11T09:24:06Z

Rex :

== Répartition des binômes 2020/2022 ==

{| class="wikitable"
! Projet !! Encadrants ecole !! Eleves
|-
| P3 [[IMA3/IMA4 2020/2022 P3|Conception et commande d'un Drone]]
| K. Midzodzi PEKPE / Othman Lakhal
| Louise MAËS / Léo POUMAER / Niels GODBERT / Rémi BRACHOT / Lucas POSTOLLEC / Chaimae YASMINE
|-
|}

Projets IMA3 IMA4 2020/2022

2021-10-11T09:19:48Z

Rex :

Projets IMA3 IMA4 2020/2022

2021-10-11T09:19:18Z

Rex :

== Répartition des binômes 2020/2022 ==

{| class="wikitable"
! Projet !! Encadrants ecole !! Eleves
| P3 [[IMA3/IMA4 2020/2022 P3|Conception et commande d'un Drone]]
| K. Midzodzi PEKPE / Othman Lakhal
| Louise MAËS / Léo POUMAER / Niels GODBERT / Rémi BRACHOT / Lucas POSTOLLEC / Chaimae YASMINE
|-
|
|}

MediaWiki:Sidebar

2021-10-11T09:16:53Z

Rex :

* navigation
** mainpage|mainpage-description
*** Projets_troisième_quatrième_années|Projets IMA3/IMA4
**** Projets_IMA3_IMA4_2020/2022 |- IMA3/4 2020/22
**** Projets_IMA3_IMA4_2019/2021 |- IMA3/4 2019/21
**** Projets_IMA3_IMA4_2018/2020 |- IMA3/4 2018/20
*** Projets_de_cinquième_année|Projets IMA5
**** Projets_IMA5_SC_2011/2012|- IMA5SC 2011/12
**** Projets_IMA5_2012/2013|- IMA5 2012/13
**** Projets_IMA5_2013/2014|- IMA5 2013/14
**** Projets_IMA5_2014/2015|- IMA5 2014/15
**** Projets_IMA5_2015/2016|- IMA5 2015/16
**** Projets_IMA5_2016/2017|- IMA5 2016/17
**** Projets_IMA5_2017/2018|- IMA5 2017/18
**** Projets_IMA5_2018/2019|- IMA5 2018/19
**** Projets_IMA5_2019/2020|- IMA5 2019/20
**** Projets_IMA5_2020/2021|- IMA5 2020/21
**** Projets_IMA5_2021/2022|- IMA5 2021/22
*** Projets_de_troisième_année|Archives IMA3 SC
*** Projets_de_quatrième_année|Archives IMA4
**** Projets_IMA4_SC_2010/2011|- IMA4SC 2010/11
**** Projets_IMA4_SC_&_SA_2011/2012|- IMA4 2011/12
**** Projets_IMA4_SC_&_SA_2012/2013|- IMA4 2012/13
**** Projets_IMA4_SC_&_SA_2013/2014|- IMA4 2013/14
**** Projets_IMA4_SC_&_SA_2014/2015|- IMA4 2014/15
**** Projets_IMA4_SC_&_SA_2015/2016|- IMA4 2015/16
**** Projets_IMA4_SC_&_SA_2016/2017|- IMA4 2016/17
**** Projets_IMA4_SC_&_SA_2017/2018|- IMA4 2017/18
**** Projets_IMA4_SC_&_SA_2018/2019|- IMA4 2018/19
**** Projets_IMA4_SC_&_SA_2019/2020|- IMA4 2019/20
** currentevents-url|currentevents
** recentchanges-url|recentchanges
** randompage-url|randompage
** helppage|help
* SEARCH
* TOOLBOX
* LANGUAGES

Projets IMA5 2021/2022

2021-09-06T07:33:34Z

Rex : Page créée avec « == Répartition des binômes == {| class="wikitable" ! Projet !! Encadrants école !! Elèves |- | P20 IMA5 2021/2022 P20|2021/2022 Système de messagerie global mais i... »

== Répartition des binômes ==

{| class="wikitable"
! Projet !! Encadrants école !! Elèves
|-
| P20 [[IMA5 2021/2022 P20|2021/2022 Système de messagerie global mais individualisé]]
| Xavier Redon
| Souleymane Sow
|-
| P22 [[IMA5 2021/2022 P22|2021/2022 Infobénisterie II : coucou]]
| Alexandre Boé, Xavier Redon & Thomas Vantroys
| Enoch Hodonou
|-
| P7 [[IMA5 2021/2022 P7|2021/2022 Robot Rampant]]
| Xavier Redon
| Jean Baumann
|-
|}

MediaWiki:Sidebar

2021-09-06T07:26:38Z

Rex :

* navigation
** mainpage|mainpage-description
*** Projets_troisième_quatrième_années|Projets IMA3/IMA4
**** Projets_IMA3_IMA4_2019/2021 |- IMA3/4 2019/21
**** Projets_IMA3_IMA4_2018/2020 |- IMA3/4 2018/20
*** Projets_de_cinquième_année|Projets IMA5
**** Projets_IMA5_SC_2011/2012|- IMA5SC 2011/12
**** Projets_IMA5_2012/2013|- IMA5 2012/13
**** Projets_IMA5_2013/2014|- IMA5 2013/14
**** Projets_IMA5_2014/2015|- IMA5 2014/15
**** Projets_IMA5_2015/2016|- IMA5 2015/16
**** Projets_IMA5_2016/2017|- IMA5 2016/17
**** Projets_IMA5_2017/2018|- IMA5 2017/18
**** Projets_IMA5_2018/2019|- IMA5 2018/19
**** Projets_IMA5_2019/2020|- IMA5 2019/20
**** Projets_IMA5_2020/2021|- IMA5 2020/21
**** Projets_IMA5_2021/2022|- IMA5 2021/22
*** Projets_de_troisième_année|Archives IMA3 SC
*** Projets_de_quatrième_année|Archives IMA4
**** Projets_IMA4_SC_2010/2011|- IMA4SC 2010/11
**** Projets_IMA4_SC_&_SA_2011/2012|- IMA4 2011/12
**** Projets_IMA4_SC_&_SA_2012/2013|- IMA4 2012/13
**** Projets_IMA4_SC_&_SA_2013/2014|- IMA4 2013/14
**** Projets_IMA4_SC_&_SA_2014/2015|- IMA4 2014/15
**** Projets_IMA4_SC_&_SA_2015/2016|- IMA4 2015/16
**** Projets_IMA4_SC_&_SA_2016/2017|- IMA4 2016/17
**** Projets_IMA4_SC_&_SA_2017/2018|- IMA4 2017/18
**** Projets_IMA4_SC_&_SA_2018/2019|- IMA4 2018/19
**** Projets_IMA4_SC_&_SA_2019/2020|- IMA4 2019/20
** currentevents-url|currentevents
** recentchanges-url|recentchanges
** randompage-url|randompage
** helppage|help
* SEARCH
* TOOLBOX
* LANGUAGES

IMA3/IMA4 2019/2021 P19+

2021-06-18T13:29:36Z

Rex : /* Semaine 1 */

__TOC__
<br style="clear: both;"/>

=Présentation générale=

==Description==
La puissance de calcul disponible à bas coût permet d'envisager de réaliser des appareils de mesures complexes en mode DIY (Do It Yourself). Dans ce projet, nous proposons la conception et la réalisation d'un oscilloscope pour des signaux analogiques et numériques (analyseur logique). L'oscilloscope sera constitué d'un microcontrôleur et/ou d'un FPGA, d'une partie d'acquisition de données, de stockage de données (RAM) et éventuellement d'une interface de visualisation.

==Objectifs==
Concevoir et réaliser un oscilloscope "maison" open source.

=Préparation du projet=

==Cahier des charges==
==Choix techniques : matériel et logiciel==

* Matériel :
** Microcontrôleur STM32.
** Ecran LCD
** Générateur basses fréquences

* Logiciel/Language:
**Langage C

==Liste des tâches à effectuer==
* Analyser et définir des différents composants nécessaires

* Programmer le CAN pour récupérer et stocker la valeur de l'amplitude à un temps donné

* Programmer l'écran LCD pour visualiser un signal

* Mettre en place une interface pour modifier l'échelle du signal.

==Calendrier prévisionnel==

=Réalisation du Projet=

==Prologue==
==Semaine 1==
Pour commencer le projet, nous allons voir les différentes manières de réaliser un oscilloscope. Il existe plusieurs façons de le réaliser comme par exemple à l'aide d'un FPGA ou d'un microcontrôleur STM32. En amont de la partie intelligente de l'oscilloscope, nous avons au moins un convertisseur Analogique/numérique afin d'envoyer la tension mesurée sur le FPGA ou microcontrôleur. Nous avons ensuite un écran LCD qui va permettre d'afficher le signal.
[[Fichier:Schema_ard.png|350px|right|thumb|Schéma de fonctionnement avec Arduino]]

Notre choix de microcontrôleur et de carte de développement s'arrête sur un des deux choix, la NUCLEO F401RE et la NUCLEO F412ZG. Ceux-ci seront tous les deux ouverts à la programmation, disposent déjà d'un ADC et peuvent être équipé d'un écran LCD. Le problème du F401RE est qu'il ne peut gérer qu'une seule channel de l'oscilloscope. Cela veut dire que notre microcontrôleur STM32F401 ne peut réaliser qu'une seule conversion analogique/numérique à la fois.
<br style="clear: both;" />

==Semaine 2==
Avant de commencer la réalisation de l'oscilloscope, nous allons nous intéresser aux projets déjà existants et nous documenter pour voir quelle solution serait la plus viable.
En effet, des projets de ce genre existent déjà sur internet comme par exemple sur le site instructables.com où un utilisateur a réaliser un mini oscilloscope à base de microcontrôleur STM32F030F4 et d'un écran LCD avec une résolution de 160x128px. Le microcontrôleur possède un convertisseur Analogique/Numérique avec un temps de conversion minimal de 1 us.

=Documents Rendus=

=Liens Utiles=

*http://www.jiee.eu/wp-content/uploads/papers/vol2i2/v2i2_Murcko_Molnar.pdf
*[https://pdf.sciencedirectassets.com/277811/1-s2.0-S1877042815X00127/1-s2.0-S187704281500717X/main.pdf?X-Amz-Security-Token=IQoJb3JpZ2luX2VjEKz%2F%2F%2F%2F%2F%2F%2F%2F%2F%2FwEaCXVzLWVhc3QtMSJGMEQCIGhjMDzhipfAfaWURi%2BFzP94OSJ%2FdhMmSvRgOJLuZzwvAiBb7NkDxSSZW%2FhFfFPyQ1dGept5nuq3LI0PQ9z7gRxk0Cq0AwhFEAMaDDA1OTAwMzU0Njg2NSIMH5qv%2BIbDn3qGH1eRKpEDfvvFSJnBDYA7vNKTmhWIfy7zX1HO%2Bv4XVYYnjbG388vOsGnvF5qo9NbYxWG2ZvBLl4UptM0mmCuPHnz5ZRL%2BMgGr0cZA8v3ZAc6zHuosolMvrIzisDuSb6CEkAWQ0lHgt5AEB97cqM185GZRJu50Osn0wPQy5GpPEkSz0MM5DFoeUGfExYEmsFXm%2B3244IJ0ejXgVIvo6gyjT65z2HvAfcBN1HayQkDdIWtbm1Z4mnoPF0pG26%2BCGDvO1uCJekFO4XsGWybocWxwOTKi6yqmIJlTsPewoo9o6O7bWvxQq9XJLlwcMwwlwyDqSFpQwSZIpWLwEiqtFd27Ow5TbLWJhRWIjDhaPIRnw9lNojgZhKHmqK2u%2FsOffF6lPJ2mXv6RZZpnZzJ%2FEbaeSrRw002Sc6AXtBFGt9ZHJ6%2BYFWXBfcPDZsWXVzemzIaM9EDC4sCW3ZQwcQNzwTlU%2Fe7zWrkctSGZeyuKYQ4F6F%2BOFX7g%2BhHzB9dqdSgA5RTk7l%2B7Y9jllTw9uyOd9i4SXZ7JPTmFbzIwuK%2BJhQY67AHoIboyG2h%2BAhc0bbi%2FjfJDq4facC8YEFg7md%2BhftjE2nfpKNIC2zDrILy2%2F9AgZKfyTW8TmFpiTL16l%2FwY%2Bj4%2BkwED5sGRTmMSntlXwgBEoW5HKaKN4NAqF5msMjJa%2FOQijh0A%2BDrKNOTd4EupLPZM8ZzR6n57%2FKS6lArvqhvL6zH8%2BGH%2Bwe5qNZGXtGTCztdHfkcI3PTqv2c2vVNFRH97MXqF2lWYRJcyUaZVZtpPOfFwzzoPJ31VyQMqnIEsp5hAW%2F0H9arhtHkttve2Vs1EbsCfxNADs5ozZaIDd4sSzwMo2Yu0JaNwDBII7g%3D%3D&X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Date=20210517T123008Z&X-Amz-SignedHeaders=host&X-Amz-Expires=300&X-Amz-Credential=ASIAQ3PHCVTYR3FRAZNN%2F20210517%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Signature=a8a561185aeef42d25319c18fcb061ead66607e2707a83f3b4df299a4856a19c&hash=b41061f66104ece83eeff5ef3e7091f869e85c8455ad06944cdad582c62baf54&host=68042c943591013ac2b2430a89b270f6af2c76d8dfd086a07176afe7c76c2c61&pii=S187704281500717X&tid=spdf-66f8cd23-0e48-402b-8af4-34f2abee30a7&sid=4ca04885778dd74d321a6505f35e7d4ec82egxrqb&type=client/ Avec FPGA]

*[https://www.electronique-mixte.fr/projet-electronique-oscilloscope-numerique-a-base-du-microcontroleur-pic18f4680-a-liaison-serie-rs232/ Oscillo sur liaison série]

*[https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=&cad=rja&uact=8&ved=2ahUKEwj9-fXC5tXwAhXJ8eAKHbRwD4YQFjAAegQIBhAD&url=https%3A%2F%2Fwww.st.com%2Fresource%2Fen%2Freference_manual%2Fdm00180369-stm32f412-advanced-armbased-32bit-mcus-stmicroelectronics.pdf&usg=AOvVaw1jBYKXOIhft-b6t_Gni65g Lien Ref manual du STM32F412]
*[https://www.st.com/resource/en/reference_manual/dm00096844-stm32f401xbc-and-stm32f401xde-advanced-armbased-32bit-mcus-stmicroelectronics.pdf Lien ref Manual du STM32F401]

*Projets déjà réalisés :
**https://github.com/cskarai/csabiscope
**https://github.com/pingumacpenguin/STM32-O-Scope
**https://www.instructables.com/Mini-Oscilloscope/

*https://programmer.group/simple-oscilloscope-library-function-based-on-stm32.html
*https://www.gameinstance.com/post/79/STM32-Oscilloscope
*https://projets-ima.plil.fr/mediawiki/index.php/IMA4_2018/2019_P5

*Programmation du STM32 :
**http://jmfriedt.free.fr/tp3stm32_2014.pdf
**https://review.coreboot.org/plugins/gitiles/chrome-ec/+/b7308fdff1300bb4bf0362e71ed022b2dbf92c25/board/nucleo-f412zg/
**https://www.youtube.com/watch?v=xsYIh1sunso
**https://github.com/davisjp1822/stm32_nucleo_linux

IMA3/IMA4 2019/2021 P11+

2021-06-18T13:13:04Z

Rex : /* Semaine 1 */

__TOC__
<br style="clear: both;"/>

=Présentation générale=

==Description==

Concevoir et réaliser une interface de visualisation pour des appareils de mesure

==Objectifs==

L'objectif du projet global (découpé en trois sous-projets) est de réaliser une plateforme complète permettant de faire des travaux pratiques d'électronique à distance.

Ce sous projet consiste en la réalisation d'une interface de commande d'un appareil de mesure (oscilloscope, multimètre, ...) ou d'un générateur à distance au travers d'une interface LXI ([https://en.wikipedia.org/wiki/LAN_eXtensions_for_Instrumentation LAN eXtensions for Instrumentation]).

L'interface sera constituée de deux modules :
<ul>
<li> une interface paramétrable de commande à distance des appareils (panneau de commande) ; </li>

<li> une interface d'affichage des données. </li>
</ul>
Si possible, les développements se feront en HMTL5 au travers d'un framework à choisir.

=Préparation du projet=

==Cahier des charges==
==Choix techniques : matériel et logiciel==

* Utilisation de l'HTML5 et du PHP pour le développement de l'interface ;

* Framework : Bootstrap ;

* Pas de matériel particulier à commander, j'utiliserai les appareils de mesure déjà disponibles à Polytech.

==Liste des tâches à effectuer==

* Prendre en main l'interface LXI avec des appareils de mesure électronique (oscilloscope, multimètre, ...) ;

* Réaliser une interface web permettant de contrôler les appareils et afficher les résultats.

==Calendrier prévisionnel==

=Réalisation du Projet=

==Prologue==
==Semaine 1==

Prise d'information sur l'interface LXI : en entrant l'IP de l'appareil dans la barre de recherche d'un navigateur, il semblerait que l'on puisse accéder à l'interface et commander l'appareil.

Utilisation d'un oscilloscope SDS 1102CML+ pour tester l'interface LXI :

* on le branche sur une carte réseau du PC puis on lui assigne une adresse ip dans le réseau local (dans le menu Utility de l'oscilloscope) et on ping cette adresse pour s'assurer de la connexion : cela fonctionne ;

* j'essaie d'entrer l'adresse IP sur un navigateur pour vérifier s'il existe une interface LXI mais la connexion ne fonctionne pas ;

* installation du programme [https://lxi-tools.github.io/ lxi-tools] (et même installation plus simple avec la commande : apt-get install lxi-tools) qui permet d'utiliser LXI en ligne de commande et l'oscilloscope est bien retrouvé avec la bonne adresse IP.

Avec ce programme on peut obtenir des screenshots de l'oscilloscope, cela pourra être utile pour l'affichage.

[[Fichier:premier_screen.jpg|200px|thumb|right|Premier screenshot de l'oscilloscope]]

Liens qui peuvent être utiles pour la suite :

[https://teledynelecroy.com/doc/introducing-the-lxi-interface]

[https://lxistandard.org/About/LXI-Core-Features.aspx]

[https://www.lxistandard.org/About/LXI-Discovery-Tools.aspx]

[https://siglentna.com/application-note/lxi-tools/]

[https://www.siglenteu.com/application-note/quick-remote-computer-control-using-lxi-tools/ Résumé de l'utilisation de la commande lxi].

Voici une [https://siglentna.com/wp-content/uploads/dlm_uploads/2017/10/ProgrammingGuide_forSDS-1-1.pdf liste des commandes SCPI] pour contrôler l'oscilloscope. Peut-être faudra-t-il trouver d'autres commandes pour d'autres appareils de mesures.

En testant quelques commandes en mode SCPI, on s'aperçoit qu'elles ont le comportement souhaité sur l'oscilloscope.

Pour réaliser l'interface web, j'utilise un serveur Apache2 et le langage PHP (sous Linux utilisation des commandes : "apt-get install apache2" et "apt-get install libapache2-mod-php"). Pour le moment, on peut lancer la recherche des appareils connectés au réseau (réalisé avec la commande 'lxi discover'); puis choisir l'appareil que l'on souhaite utiliser.

[[Fichier:Appareils_decouverts.png]]

J'ai à ma disposition un seul oscilloscope donc pour le moment cela ne lance que la page de contrôle et de visualisation de l'oscilloscope. A l'avenir, il faudra ajouter une base de donnée pour pouvoir sélectionner la bonne page à lancer selon l'appareil selectionné. Sur la page de contrôle et de visualisation, on affiche une capture d'écran de l'oscilloscope et quelques boutons pour tester la communication entre le serveur et l'oscilloscope.

[[Fichier:Visu_et_cmd_oscillo.png|thumb|600px|center]]
<br style="clear: both;" />

Afin d'afficher cette capture d'écran, il faut modifier le groupe des fichiers du serveur apache2 (sachant que les fichiers se trouvent dans le dossier /var/www/testdomain.info, on utilise la commande 'chgrp -R www-data /var/www/testdomain.info'), et on donne la permission au groupe d'écrire dans ce dossier pour y sauvegarder la photo (avec la commande 'chmod -R g+w /var/www/testdomain.info/').

J'utiliserai ensuite le framework Bootstrap pour l'interface web.

L'affichage du screenshot devrait être raffraichit le plus souvent possible pour obtenir une visualisation réactive. Pour ce faire, il faut regarder du côté du JavaScript.

Pour débuger le code HTML/PHP, on utilise la commande : tail -f /var/log/apache2/error.log .

==Semaine 2==

Afin d'utiliser Bootstrap pour l'interface Web, j'utilise les lignes de code que l'on peut retrouver [https://getbootstrap.com/docs/5.0/getting-started/download/#cdn-via-jsdelivr ici]. Ceci correspond à utiliser un CDN (Content Delivery Network) qui permet de faire le lien entre le framework sans avoir à télécharger les fichiers sources sur le serveur Apache2. Il faudra alors utiliser ces deux lignes dans les entêtes de chaque fichier html et php. On peut trouver un petit comparatif entre la version locale de Bootstrap et la version CDN : [https://www.studiogalaxie.fr/librairies-cdn-ou-local-que-choisir/]. Etant donné que l'ordinateur sur lequel j'implémente le serveur est connecté à Internet, l'utilisation du CDN ne devrait pas poser du soucis. Dans le pire des cas, il devrait être possible de passer de cette version à la version locale facilement.

Avec ce framework, je peux maintenant commencer à réaliser des affichages plus esthétiques en utilisant la [https://getbootstrap.com/docs/5.0/components/ documentation de Bootstrap].

Je me penche maintenant vers la redirection sur la bonne page lors du choix de l'appareil. En effet, étant donné le type de l'appareil, la page de visualisation et commande doit être différente, et donc selon l'appareil choisi, il faut pouvoir visualiser la bonne page. J'utilise pour l'instant un fichier .JSON qui me permet d'associer un type d'appareil avec un nom. De ce fait pour la redirection, selon le nom que l'on trouve dans ce fichier, on peut savoir sur quelle page il faut rediriger selon le type trouvé (si c'est un oscilloscope, un multimètre...). Par la suite, peut-être qu'une base de donnée SQL correspondra mieux au travail à réaliser.

Maintenant que cette redirection est effective, il faut pouvoir transmettre les données (nom et adresse ip de l'appareil) vers la page web. Etant donné que ces données transitent par 2 pages différentes, j'utilise la méthode GET (qui écrit les données dans l'URL de la page). Cela peut poser un problème de confidentialité des données mais ici cela ne devrait pas être un problème, la seule information importante est l'adresse IP de l'appareil.

Il semblerait qu'un léger problème se pose avec une interférence entre les données. L'affichage de la capture d'écran en fonction de la commande envoyée depuis le site est correct, mais par exemple en réalité l'oscilloscope affiche un menu alors qu'on lui envoie une commande pour fermer le menu. Cette réaction semble donc sans conséquence sur l'utilisation depuis l'interface web, mais cela reste à surveiller pour la suite du projet.

Pour le moment, j'ai ajouté quelques fonctionnalités à l'interface de l'oscilloscope :

[[Fichier:Interface_web_ajout_boutons.png]]

L'utilisation du framework Bootstrap reste à parfaire pour une interface claire et esthétique, mais on peut voir un début de prise en main.

Je précisais auparavant que j'utilisais la méthode GET pour faire transiter les données. Je suis finalement revenu sur cette partie du code parce qu'on pouvait y trouver de la duplication de code. J'utilise maintenant des variables de session pour l'adresse IP et le nom de l'appareil. Cela fourni un code un peu plus propre qu'avec la méthode GET.

==Semaine 3==

Lors de cette semaine, je commence par réaliser le raffraichissement de l'image de l'oscilloscope sur l'interface Web.

Afin de pouvoir obtenir une capture d'écran de l'oscilloscope toutes les secondes, je crée un nouveau fichier (screenshot.php) qui sera appelé toutes les secondes par un script sur la page de l'oscilloscope. Le fichier de screenshot réalise juste la commande de capture d'écran avec la commande 'lxi screenshot' et l'adresse IP de l'appareil. En plus d'appeler ce fichier, le script recharge l'image sur la page.

Ensuite, je mets en place d'autres boutons permettant d'utiliser l'oscilloscope. De plus, en utilisant bootstrap je regroupe les boutons dans des onglets pour rendre l'interface web plus facilement compréhensible, avec moins d'information sur la même page.

Voici trois captures d'écrans permettant de résumer les paramètres utilisables sur l'oscilloscope à partir de l'interface :

[[Fichier:interface_global.png]]

[[Fichier:interface_ch1.png]]

[[Fichier:interface_curseurs.png]]

Les onglets 'CH1' et 'CH2' réalisent chacuns les mêmes actions respectivement sur le signal de la voie 1 et de la voie 2.

De plus, j'organise l'interface pour faire en sorte que tous les paramètres soient accordés avec les paramètres sur l'oscilloscope. Cela permet de voir directement si le changement que l'on souhaite faire sur l'oscilloscope a été effectué, parce que l'on ne peut pas choisir le menu que l'on peut voir sur l'oscilloscope. Par exemple, si on modifie l'unité de la voie 1, l'interface se met à jour avec l'unité choisie sur l'onglet de la voie 1 (si l'on choisit des ampères, 1V/Division devient 1A/Division et ce jusqu'au prochain changement d'unité).

==Semaine 4==

Pour rendre l'interface plus agréable à utiliser, je retire les boutons pour soumettre les changements. Les changements sont maintenant réalisés directement une fois l'option sélectionnée. Ceci est réalisé en ajoutant simplement la commande 'onchange="this.form.submit();"' au bon endroit dans le code.

Par exemple, pour l'onglet CH1, on a maintenant :

[[Fichier:Nouveau_ch1.png]]

A faire maintenant : Rendre modulaire le fichier de l'interface de l'oscilloscope pour rendre les potentielles modificationsi sur ce fichier plus simple :

* Un dossier par type d'appareil :
** Dans ce dossier, on trouve 1 dossier par commande
*** Dans ces dossiers : un fichier pour l'affichage et un fichier pour la réalisation de la commande.

Pour cela, la fonction PHP 'scandir' sera à utiliser.

Avant d'attaquer cette partie, j'ajoute deux dernières commandes sur l'interface de l'oscilloscope : la modification du Trigger Level ainsi que la modification des limites de fréquences des filtres.

Maintenant, le fichier principal reprend les fichiers d'affichage et de réalisation des commandes pour l'oscilloscope comme c'était prévu. Je pense que dans le futur j'essaierai d'avoir une page principale et selon le type de l'appareil que l'on choisit d'utiliser, cette page va chercher dans le dossier du type tout ce dont elle a besoin pour le bon fonctionnement de l'interface.

Avant de commencer à commander un nouvel appareil (qui sera le générateur de signaux SDG1032X dont la documentation pour les commandes avec LXI se trouve [https://siglentna.com/USA_website_2014/Documents/Program_Material/SDG_ProgrammingGuide_PG_E03B.pdf ici]), on essaie l'interface en regardant l'oscillation d'un Quartz sur [https://projets-ima.plil.fr/mediawiki/index.php/IMA3/IMA4_2019/2021_P1%2B le projet d'Andrei Florea]. On obtient le résultat suivant :

[[Fichier:Utilisation_oscilloscope.png]]

L'interface est alors bien utilisable.

Au final je m'attaque tout de suite à réaliser une page unique peu importe l'appareil selectionné, mais qui affiche de façon différente selon le type de l'appareil sélectionné.

Cette page fonctionne de la manière suivante :

* Il y a un grand dossier par type d'appareil (Oscilloscope, Generateur...). A l'interieur de ce dossier, on retrouve des dossiers avec le nom des menus que l'on affiche (pour l'Oscilloscope par exemple : CH1,CH2,Curseurs et Global). A l'intérieur de ces dossiers, se trouvent des dossiers selon les commandes que l'on peut réaliser sur l'appareil. Dans ces derniers dossiers, on retrouve un fichier avec le code l'affichage de la commande sur la page et un autre fichier avec la réalisation de la commande si celle-ci a été choisie par l'utilisateur. Ainsi, on peut parcourir l'arborescence pour afficher de manière procédurale l'ensemble des menus, boutons...

Afin que ceci soit efficace, il faut reprendre cette arborescence pour les différents types d'appareils que l'on utilise.

Cette fois-ci je m'attaque pour de bon à la réalisation de l'interface du générateur de signaux SDG1032X. Pour commencer, j'assigne une adresse IP valide à l'appareil, puis je m'assure tout d'abord qu'il est possible de réaliser une capture d'écran avec la commande 'lxi screenshot'. Cette commande fonctionne, donc on pourra l'utiliser pour l'affichage sur l'interface Web. En parcourant les commandes LXI disponibles dans la documentation, je m'aperçois qu'il existe une commande permettant de simuler l'appuie d'une touche sur le générateur. Cette commande permet de faciliter grandement la tâche par rapport à l'oscilloscope. L'interface ne sera donc composée que de boutons comme pour le générateur physique. Avec la commande SCPI 'VKEY VALUE,<valeur>,STATE,1', on peut réaliser la pression de la touche 'valeur'. Les valeurs des touches sont indiquées sur la documentation.

[[Fichier:Tableau_valeurs_touches.png]]

[[Fichier:Association_touches_valeurs.png]]

Pour la réalisation sur l'interface, je crée le dossier 'Generateur' correspondant au type de l'appareil. A l'intérieur de ce dossier, je crée trois dossiers différents pour réaliser trois menus sur l'interface (Fonction,Global et Menus). A l'interieur de ces dossiers je ne place pour l'instant qu'un seul sous dossier qui contient le code d'affichage et de réalisation des différents boutons.

[[Fichier:Apercu_interface_generateur.png]]

L'affichage est alors très basique mais l'utilisation est n'est pas intuitif du tout. Pour ajouter une note positive, tous les boutons fonctionnent correctement. L'un des prochains objectifs est d'améliorer l'affichage pour rendre l'utilisation plus simple.

De plus, lors de l'affichage des appareils disponibles, il est maintenant indiqué le type des appareils.

[[Fichier:Choix_app_avec_type.png]]

Pour conclure cette semaine, j'ai essayé de brancher l'oscilloscope et le générateur en même temps. La page de recherche affiche bien les deux appareils avec leurs bons types respectifs, et la sélection fonctionne correctement. L'affichage des interfaces et les réalisations des commandes se comportent convenablement.

==Semaine 5==

==Semaine 6==

=Documents Rendus=

IMA3/IMA4 2019/2021 P11+

2021-06-18T13:12:28Z

Rex :

__TOC__
<br style="clear: both;"/>

=Présentation générale=

==Description==

Concevoir et réaliser une interface de visualisation pour des appareils de mesure

==Objectifs==

L'objectif du projet global (découpé en trois sous-projets) est de réaliser une plateforme complète permettant de faire des travaux pratiques d'électronique à distance.

Ce sous projet consiste en la réalisation d'une interface de commande d'un appareil de mesure (oscilloscope, multimètre, ...) ou d'un générateur à distance au travers d'une interface LXI ([https://en.wikipedia.org/wiki/LAN_eXtensions_for_Instrumentation LAN eXtensions for Instrumentation]).

L'interface sera constituée de deux modules :
<ul>
<li> une interface paramétrable de commande à distance des appareils (panneau de commande) ; </li>

<li> une interface d'affichage des données. </li>
</ul>
Si possible, les développements se feront en HMTL5 au travers d'un framework à choisir.

=Préparation du projet=

==Cahier des charges==
==Choix techniques : matériel et logiciel==

* Utilisation de l'HTML5 et du PHP pour le développement de l'interface ;

* Framework : Bootstrap ;

* Pas de matériel particulier à commander, j'utiliserai les appareils de mesure déjà disponibles à Polytech.

==Liste des tâches à effectuer==

* Prendre en main l'interface LXI avec des appareils de mesure électronique (oscilloscope, multimètre, ...) ;

* Réaliser une interface web permettant de contrôler les appareils et afficher les résultats.

==Calendrier prévisionnel==

=Réalisation du Projet=

==Prologue==
==Semaine 1==

Prise d'information sur l'interface LXI : en entrant l'IP de l'appareil dans la barre de recherche d'un navigateur, il semblerait que l'on puisse accéder à l'interface et commander l'appareil.

Utilisation d'un oscilloscope SDS 1102CML+ pour tester l'interface LXI :

* on le branche sur une carte réseau du PC puis on lui assigne une adresse ip dans le réseau local (dans le menu Utility de l'oscilloscope) et on ping cette adresse pour s'assurer de la connexion : cela fonctionne ;

* j'essaie d'entrer l'adresse IP sur un navigateur pour vérifier s'il existe une interface LXI mais la connexion ne fonctionne pas ;

* installation du programme [https://lxi-tools.github.io/ lxi-tools] (et même installation plus simple avec la commande : apt-get install lxi-tools) qui permet d'utiliser LXI en ligne de commande et l'oscilloscope est bien retrouvé avec la bonne adresse IP.

Avec ce programme on peut obtenir des screenshots de l'oscilloscope, cela pourra être utile pour l'affichage.

[[Fichier:premier_screen.jpg|200px|thumb|right|Premier screenshot de l'oscilloscope]]

Liens qui peuvent être utiles pour la suite :

[https://teledynelecroy.com/doc/introducing-the-lxi-interface]

[https://lxistandard.org/About/LXI-Core-Features.aspx]

[https://www.lxistandard.org/About/LXI-Discovery-Tools.aspx]

[https://siglentna.com/application-note/lxi-tools/]

[https://www.siglenteu.com/application-note/quick-remote-computer-control-using-lxi-tools/ Résumé de l'utilisation de la commande lxi].

Voici une [https://siglentna.com/wp-content/uploads/dlm_uploads/2017/10/ProgrammingGuide_forSDS-1-1.pdf liste des commandes SCPI] pour contrôler l'oscilloscope. Peut-être faudra-t-il trouver d'autres commandes pour d'autres appareils de mesures.

En testant quelques commandes en mode SCPI, on s'aperçoit qu'elles ont le comportement souhaité sur l'oscilloscope.

Pour réaliser l'interface web, j'utilise un serveur Apache2 et le langage PHP (sous Linux utilisation des commandes : "apt-get install apache2" et "apt-get install libapache2-mod-php"). Pour le moment, on peut lancer la recherche des appareils connectés au réseau (réalisé avec la commande 'lxi discover'); puis choisir l'appareil que l'on souhaite utiliser.

[[Fichier:Appareils_decouverts.png]]

J'ai à ma disposition un seul oscilloscope donc pour le moment cela ne lance que la page de contrôle et de visualisation de l'oscilloscope. A l'avenir, il faudra ajouter une base de donnée pour pouvoir sélectionner la bonne page à lancer selon l'appareil selectionné. Sur la page de contrôle et de visualisation, on affiche une capture d'écran de l'oscilloscope et quelques boutons pour tester la communication entre le serveur et l'oscilloscope.

[[Fichier:Visu_et_cmd_oscillo.png|thumb|400px|center]]
<br style="clear: both;" />

Afin d'afficher cette capture d'écran, il faut modifier le groupe des fichiers du serveur apache2 (sachant que les fichiers se trouvent dans le dossier /var/www/testdomain.info, on utilise la commande 'chgrp -R www-data /var/www/testdomain.info'), et on donne la permission au groupe d'écrire dans ce dossier pour y sauvegarder la photo (avec la commande 'chmod -R g+w /var/www/testdomain.info/').

J'utiliserai ensuite le framework Bootstrap pour l'interface web.

L'affichage du screenshot devrait être raffraichit le plus souvent possible pour obtenir une visualisation réactive. Pour ce faire, il faut regarder du côté du JavaScript.

Pour débuger le code HTML/PHP, on utilise la commande : tail -f /var/log/apache2/error.log .

==Semaine 2==

Afin d'utiliser Bootstrap pour l'interface Web, j'utilise les lignes de code que l'on peut retrouver [https://getbootstrap.com/docs/5.0/getting-started/download/#cdn-via-jsdelivr ici]. Ceci correspond à utiliser un CDN (Content Delivery Network) qui permet de faire le lien entre le framework sans avoir à télécharger les fichiers sources sur le serveur Apache2. Il faudra alors utiliser ces deux lignes dans les entêtes de chaque fichier html et php. On peut trouver un petit comparatif entre la version locale de Bootstrap et la version CDN : [https://www.studiogalaxie.fr/librairies-cdn-ou-local-que-choisir/]. Etant donné que l'ordinateur sur lequel j'implémente le serveur est connecté à Internet, l'utilisation du CDN ne devrait pas poser du soucis. Dans le pire des cas, il devrait être possible de passer de cette version à la version locale facilement.

Avec ce framework, je peux maintenant commencer à réaliser des affichages plus esthétiques en utilisant la [https://getbootstrap.com/docs/5.0/components/ documentation de Bootstrap].

Je me penche maintenant vers la redirection sur la bonne page lors du choix de l'appareil. En effet, étant donné le type de l'appareil, la page de visualisation et commande doit être différente, et donc selon l'appareil choisi, il faut pouvoir visualiser la bonne page. J'utilise pour l'instant un fichier .JSON qui me permet d'associer un type d'appareil avec un nom. De ce fait pour la redirection, selon le nom que l'on trouve dans ce fichier, on peut savoir sur quelle page il faut rediriger selon le type trouvé (si c'est un oscilloscope, un multimètre...). Par la suite, peut-être qu'une base de donnée SQL correspondra mieux au travail à réaliser.

Maintenant que cette redirection est effective, il faut pouvoir transmettre les données (nom et adresse ip de l'appareil) vers la page web. Etant donné que ces données transitent par 2 pages différentes, j'utilise la méthode GET (qui écrit les données dans l'URL de la page). Cela peut poser un problème de confidentialité des données mais ici cela ne devrait pas être un problème, la seule information importante est l'adresse IP de l'appareil.

Il semblerait qu'un léger problème se pose avec une interférence entre les données. L'affichage de la capture d'écran en fonction de la commande envoyée depuis le site est correct, mais par exemple en réalité l'oscilloscope affiche un menu alors qu'on lui envoie une commande pour fermer le menu. Cette réaction semble donc sans conséquence sur l'utilisation depuis l'interface web, mais cela reste à surveiller pour la suite du projet.

Pour le moment, j'ai ajouté quelques fonctionnalités à l'interface de l'oscilloscope :

[[Fichier:Interface_web_ajout_boutons.png]]

L'utilisation du framework Bootstrap reste à parfaire pour une interface claire et esthétique, mais on peut voir un début de prise en main.

Je précisais auparavant que j'utilisais la méthode GET pour faire transiter les données. Je suis finalement revenu sur cette partie du code parce qu'on pouvait y trouver de la duplication de code. J'utilise maintenant des variables de session pour l'adresse IP et le nom de l'appareil. Cela fourni un code un peu plus propre qu'avec la méthode GET.

==Semaine 3==

Lors de cette semaine, je commence par réaliser le raffraichissement de l'image de l'oscilloscope sur l'interface Web.

Afin de pouvoir obtenir une capture d'écran de l'oscilloscope toutes les secondes, je crée un nouveau fichier (screenshot.php) qui sera appelé toutes les secondes par un script sur la page de l'oscilloscope. Le fichier de screenshot réalise juste la commande de capture d'écran avec la commande 'lxi screenshot' et l'adresse IP de l'appareil. En plus d'appeler ce fichier, le script recharge l'image sur la page.

Ensuite, je mets en place d'autres boutons permettant d'utiliser l'oscilloscope. De plus, en utilisant bootstrap je regroupe les boutons dans des onglets pour rendre l'interface web plus facilement compréhensible, avec moins d'information sur la même page.

Voici trois captures d'écrans permettant de résumer les paramètres utilisables sur l'oscilloscope à partir de l'interface :

[[Fichier:interface_global.png]]

[[Fichier:interface_ch1.png]]

[[Fichier:interface_curseurs.png]]

Les onglets 'CH1' et 'CH2' réalisent chacuns les mêmes actions respectivement sur le signal de la voie 1 et de la voie 2.

De plus, j'organise l'interface pour faire en sorte que tous les paramètres soient accordés avec les paramètres sur l'oscilloscope. Cela permet de voir directement si le changement que l'on souhaite faire sur l'oscilloscope a été effectué, parce que l'on ne peut pas choisir le menu que l'on peut voir sur l'oscilloscope. Par exemple, si on modifie l'unité de la voie 1, l'interface se met à jour avec l'unité choisie sur l'onglet de la voie 1 (si l'on choisit des ampères, 1V/Division devient 1A/Division et ce jusqu'au prochain changement d'unité).

==Semaine 4==

Pour rendre l'interface plus agréable à utiliser, je retire les boutons pour soumettre les changements. Les changements sont maintenant réalisés directement une fois l'option sélectionnée. Ceci est réalisé en ajoutant simplement la commande 'onchange="this.form.submit();"' au bon endroit dans le code.

Par exemple, pour l'onglet CH1, on a maintenant :

[[Fichier:Nouveau_ch1.png]]

A faire maintenant : Rendre modulaire le fichier de l'interface de l'oscilloscope pour rendre les potentielles modificationsi sur ce fichier plus simple :

* Un dossier par type d'appareil :
** Dans ce dossier, on trouve 1 dossier par commande
*** Dans ces dossiers : un fichier pour l'affichage et un fichier pour la réalisation de la commande.

Pour cela, la fonction PHP 'scandir' sera à utiliser.

Avant d'attaquer cette partie, j'ajoute deux dernières commandes sur l'interface de l'oscilloscope : la modification du Trigger Level ainsi que la modification des limites de fréquences des filtres.

Maintenant, le fichier principal reprend les fichiers d'affichage et de réalisation des commandes pour l'oscilloscope comme c'était prévu. Je pense que dans le futur j'essaierai d'avoir une page principale et selon le type de l'appareil que l'on choisit d'utiliser, cette page va chercher dans le dossier du type tout ce dont elle a besoin pour le bon fonctionnement de l'interface.

Avant de commencer à commander un nouvel appareil (qui sera le générateur de signaux SDG1032X dont la documentation pour les commandes avec LXI se trouve [https://siglentna.com/USA_website_2014/Documents/Program_Material/SDG_ProgrammingGuide_PG_E03B.pdf ici]), on essaie l'interface en regardant l'oscillation d'un Quartz sur [https://projets-ima.plil.fr/mediawiki/index.php/IMA3/IMA4_2019/2021_P1%2B le projet d'Andrei Florea]. On obtient le résultat suivant :

[[Fichier:Utilisation_oscilloscope.png]]

L'interface est alors bien utilisable.

Au final je m'attaque tout de suite à réaliser une page unique peu importe l'appareil selectionné, mais qui affiche de façon différente selon le type de l'appareil sélectionné.

Cette page fonctionne de la manière suivante :

* Il y a un grand dossier par type d'appareil (Oscilloscope, Generateur...). A l'interieur de ce dossier, on retrouve des dossiers avec le nom des menus que l'on affiche (pour l'Oscilloscope par exemple : CH1,CH2,Curseurs et Global). A l'intérieur de ces dossiers, se trouvent des dossiers selon les commandes que l'on peut réaliser sur l'appareil. Dans ces derniers dossiers, on retrouve un fichier avec le code l'affichage de la commande sur la page et un autre fichier avec la réalisation de la commande si celle-ci a été choisie par l'utilisateur. Ainsi, on peut parcourir l'arborescence pour afficher de manière procédurale l'ensemble des menus, boutons...

Afin que ceci soit efficace, il faut reprendre cette arborescence pour les différents types d'appareils que l'on utilise.

Cette fois-ci je m'attaque pour de bon à la réalisation de l'interface du générateur de signaux SDG1032X. Pour commencer, j'assigne une adresse IP valide à l'appareil, puis je m'assure tout d'abord qu'il est possible de réaliser une capture d'écran avec la commande 'lxi screenshot'. Cette commande fonctionne, donc on pourra l'utiliser pour l'affichage sur l'interface Web. En parcourant les commandes LXI disponibles dans la documentation, je m'aperçois qu'il existe une commande permettant de simuler l'appuie d'une touche sur le générateur. Cette commande permet de faciliter grandement la tâche par rapport à l'oscilloscope. L'interface ne sera donc composée que de boutons comme pour le générateur physique. Avec la commande SCPI 'VKEY VALUE,<valeur>,STATE,1', on peut réaliser la pression de la touche 'valeur'. Les valeurs des touches sont indiquées sur la documentation.

[[Fichier:Tableau_valeurs_touches.png]]

[[Fichier:Association_touches_valeurs.png]]

Pour la réalisation sur l'interface, je crée le dossier 'Generateur' correspondant au type de l'appareil. A l'intérieur de ce dossier, je crée trois dossiers différents pour réaliser trois menus sur l'interface (Fonction,Global et Menus). A l'interieur de ces dossiers je ne place pour l'instant qu'un seul sous dossier qui contient le code d'affichage et de réalisation des différents boutons.

[[Fichier:Apercu_interface_generateur.png]]

L'affichage est alors très basique mais l'utilisation est n'est pas intuitif du tout. Pour ajouter une note positive, tous les boutons fonctionnent correctement. L'un des prochains objectifs est d'améliorer l'affichage pour rendre l'utilisation plus simple.

De plus, lors de l'affichage des appareils disponibles, il est maintenant indiqué le type des appareils.

[[Fichier:Choix_app_avec_type.png]]

Pour conclure cette semaine, j'ai essayé de brancher l'oscilloscope et le générateur en même temps. La page de recherche affiche bien les deux appareils avec leurs bons types respectifs, et la sélection fonctionne correctement. L'affichage des interfaces et les réalisations des commandes se comportent convenablement.

==Semaine 5==

==Semaine 6==

=Documents Rendus=

Fichier:Urobot10 Pcb.zip

2021-06-17T21:24:51Z

Rex : Rex a téléversé une nouvelle version de Fichier:Urobot10 Pcb.zip

Fichier:Urobot10Pcb.zip

2021-06-17T17:33:50Z

Rex : Rex a téléversé une nouvelle version de Fichier:Urobot10Pcb.zip

Fichier:Arduino pcb mar.zip

2021-06-10T22:48:32Z

Rex : Rex a téléversé une nouvelle version de Fichier:Arduino pcb mar.zip

Fichier:Arduino pcb mar.zip

2021-06-10T09:27:04Z

Rex : Rex a téléversé une nouvelle version de Fichier:Arduino pcb mar.zip

Fichier:Arduino pcb mar.zip

2021-06-08T21:59:50Z

Rex : Rex a téléversé une nouvelle version de Fichier:Arduino pcb mar.zip

Fichier:2020 P1 HostUSB.zip

2021-05-28T17:13:07Z

Rex :

IMA3/IMA4 2019/2021 P1+

2021-05-28T17:09:08Z

Rex : /* Documents Rendus */

<br style="clear: both;"/>

=Présentation générale=

* '''Nom du projet :''' Micro-ordinateur pour la pédagogie
* '''Stagiaire :''' Andrei FLOREA
* '''Encadrant :''' Xavier REDON
* '''Durée :''' 6 semaines (17 Mai - 25 Juin 2021)

==Description==

Concevoir et réaliser un ordinateur du même type que les ordinateurs familiaux des années 1980. L'ordinateur sera à base de micro-contrôleur mais avec clavier, écran et périphérique de sauvegarde.

==Objectifs==

Le but de ce projet est de réaliser un ordinateur peu puissant mais en le concevant de A à Z. Concernant le matériel :

# Le coeur doit être un micro-contrôleur, un processeur étant trop complexe à maîtriser, même si un AVR est envisageable, il serait préférable de partir vers un Cortex-M pour bénéficier d'une mémoire plus importante ;
# Pour les périphériques d'entrée, il faut utiliser un clavier USB et éventuellement une souris USB, ce qui implique de choisir un micro-contrôleur avec gestion USB ;
# Plusieurs choix sont possibles pour l'écran, un choix est de partir sur la génération de signaux VGA, il semble même envisageable d'utiliser une puce HDMI et enfin il existe le choix de l'écran LCD avec contrôleur intégré, choix fait par les concepteurs de la calculatrice NumWorks ;
# Pour le stockage, une carte micro-SD semble adaptée ;
# Une interface réseau est probablement indispensable qu'elle soit Ethernet ou WiFi.

Le système d'exploitation de l'ordinateur peut être basé sur micro-python avec ajout d'options spécifiques

=Préparation du projet=

Une première tentative de porter micro-python sur une carte ATXMEGAC3-XPLD [https://wiki-ima.plil.fr/mediawiki//index.php/Micro-ordinateur_pour_la_p%C3%A9dagogie a déjà été faite par Xuelu YAN en 2020]. Je base donc mes efforts sur les siens.

De plus, il existe un [https://github.com/slavaza/micropython-avr8 port de micropython sur AVR].

==Cahier des charges==
==Choix techniques : matériel et logiciel==

[[File:ATXMEGAC3-XPLD.jpg|thumb|alt=La carte ATXMEGAC3-XPLD|La carte ATXMEGAC3-XPLD]]

* Matériel :
** Carte ATXMEGAC3-XPLD pour le prototypage
* Logiciel :
** [http://www.micropython.org/ Micro-python] ([https://github.com/micropython/micropython source sur github])

==Liste des tâches à effectuer==

* Première partie : Prototypage
** Prise en main de la carte ATXMEGAC3-XPLD
** Porter micro-python sur la carte ATXMEGAC3-XPLD
** OU créer un OS "maison"
*** Gestion entrée/sortie
*** Gestion capteurs
*** Gestion périphérique de sauvegarde
* Créer un module USB (pour brancher un clavier)
** Choisir les composants
** Concevoir le circuit
** L'imprimer et y souder les composants
** Porter la bibliothèque LUFA de commande USB
** Coder l'interaction avec l'ATXMEGAC3

==Calendrier prévisionnel==

=Réalisation du Projet=

==Prologue==
==Semaine 1 : Aventures avec micropython==

===Exploration du code source de micropython===

J'ai d'abord commencé par explorer le code de micropython; je me suis dans un premier temps penché sur le port "avr8-dummy", qui est un exemple très basique (et générique) d'une implémentation de micro-python sur AVR.

On y voit un ''main.c'', avec une fonction main qui ressemble à ça :

int main()
{
...
pyexec_event_repl_init();
for(;;) {
usb_vcp_handling(); // = LUFA_USB_Handling()
int c = mp_hal_stdin_rx_chr();
if (pyexec_event_repl_process_char(c)) {
break;
}
}
pyexec_friendly_reply();
...
}

Il semble que <code>mp_hal_stdin_rx_chr</code> serve à lire un caractère sur l'entrée standard,, et <code>mp_hal_stdout_tx_strn</code>. Une question se pose alors : qu'est-ce que l'entrée/sortie standard sur une Arduino ?

En cherchant un peu, j'ai trouvé le fichier ''mphalports.h'', qui définit ces deux fonctions, ainsi que la fonction <code>usb_vcp_handling</code>. Il me faut maintenant modifier la définition pour utiliser le port série. C'est ici que rentre en jeu la [http://www.fourwalledcubicle.com/LUFA.php bibliothèque LUFA].

===Exploration du code source de LUFA===

LUFA est une librairie USB pour les microcontrolleurs AVR. Elle permet notamment de créer une connexion série entre un ordi et la carte.

Pour faciliter la tâche, on peut utiliser l'exemple VirtualSerial.

En modifiant légèrement le code du port micropython, on peut modifier les fonctions de façon à ce que les ''read'' et les ''print'' se fassent sur le port série.

En regardant un peu la documentation, on voit que la fonction <code>LUFA_USB_Handling</code> doit être appelée au minimum toutes les 30ms afin (entre autres) de relancer périodiquement la connexion USB à l'hôte. Or, avec la boucle que nous avons dans le main, nous risquons de rater cette échéance. Dans certaines boards Arduino, la connexion USB est réalisée via un deuxième microcontrolleur. Ainsi, il y a de grandes chances qu'il faille, à un moment ou un autre, réaliser un bouclier pour notre Arduino permettant de gérer cettte connexion USB.

===Fusion de micropython et de LUFA===

En ajoutant la bibliothèque LUFA dans le projet micropython, on peut maintenant interagir avec l’Arduino via le port série avec <code>minicom</code>. On peut interagir avec l'invite de commandes, mais..

[[File:Ordinateur_minicom_erreurs_mp.png|400px]]

On peut voir que micropython n'a pas l'air de très bien savoir ce qu'on veut de lui. Par conséquent, c'est le moment de plonger plus loin dans le code de micropython.

===Replonger dans micropython===

La fonction la plus intéressante dans <code>main</code> est <code>pyexec_event_repl_process_char</code>. Cette fonction appelle les fonctions suivantes (seules les fonctions les plus intéressantes (selon moi) sont renseignées) :

FONCTIONS DEFINITIONS
pyexec_event_repl_process_char (lib/utils/pyexec.c:345)
└ pyexec_friendly_repl_process_char (lib/utils/pyexec.c:232)
└ parse_compile_execute (lib/utils/pyexec.c:62)
├ mp_lexer_new_from_str_len (py/lexer.c:706)
│ └ mp_lexer_new (py/lexer.c:670)
├ mp_parse (py/parse.c:832)
├ mp_compile (py/compile.c:3527)
│ ├ mp_compile_to_raw_code (py/compile.c:3364)
│ └ mp_make_function_from_raw_code (py/emitglue.c:122)
└ mp_call_function_0 (py/runtime.c:601)
└ mp_call_function_n_kw (py/runtime.c:617)
└ mp_obj_get_type (py/obj.c:40)
└ type->call (py/obj.h:481)
On apprend déjà que micropython ''compile'' les instructions qu'on lui donne ; ce qui est assez surprenant car Python est un language typiquement interprété.

En résumé, l'erreur peut venir de l'une des 4 étapes suivantes :
* lexing
* parsing
* compilation
* exécution

Pour l'instant, je n'ai pas envie de toucher aux parties lexing-parsing-compilation ; je vois d'abord la partie exécution. Je m’intéresse donc à la fonction <code>mp_call_function_n_kw</code>. La première fonction appelée par cette dernière est <code>DEBUG_OP_printf</code>, qui imprime des informations sur la fonction exécutée ; il suffit de definir MICROPY_DEBUG_VERBOSE = 1 pour activer l'affichage des printf de déverminage. J'ai également rajouté l'affichage de la mémoire utilisée, afin de déverminer de ce côté aussi. Malheureusement, je n'ai rien trouvé.

==Semaine 2 : Un OS maison==

Après l'échec avec micropython, je passe alors à l'option "créer mon propre OS". Puisque j'aime bien les fleurs, je décide de le nommer "fleurOS".

===fleurOS===

Dans un premier temps, je crée une invite de commandes :

[[Fichier:FleurOS_shell_1.png]]

=Documents Rendus=

[https://archives.plil.fr/aflorea/micro-ordinateur-pour-la-pedagogie source] (archives.plil.fr)

Fichier Fritzing PCB : [[file:2020_P1_HostUSB.zip]].

Fichier:Manette mar2.zip

2021-05-26T11:54:05Z

Rex : Rex a téléversé une nouvelle version de Fichier:Manette mar2.zip

Fichier:2021ManetteCentaure.zip

2021-05-21T22:59:48Z

Rex :

IMA3/IMA4 2019/2021 P2+

2021-05-21T22:59:14Z

Rex : /* Semaine 1 */

__TOC__
<br style="clear: both;"/>

=Présentation Générale=
*'''Projet''' : ROBOT AUTONOME CENTAURE
** '''Encadrant''' : Xavier Redon
*'''Lieu de la formation''' : [[École polytechnique universitaire de Lille|Polytech Lille]], [[Lille]] , [[France]]
*'''Réalisé par''' : Marlène Kameni
*'''Calendrier'''
**'''Debut du projet''' : 17 Mai 2021
**'''Fin du projet''' : xx Juin 2021

==Description==
ce projet s'intègre dans le cadre de la formation des élèves ingénieurs de<br>
Polytech Lille, étudiante dans la filiaire Systèmes Embarqués.Il consiste à<br>
à terminer l'avancement et la mise sur pieds du robot.

==Objectifs==
Rendre opérationnel le robot Centaure au niveau de l'étage commande.

=Préparation du projet=

==Cahier des charges==
*''terminer l'agencement interne du robot, e.g. terminer les supports des différents composants et réaliser un câblage organisé et maintenable ''
*''inaliser les modules permettant de diriger le robot en filaire (manette) et sans fil (télécommande infrarouge)''
*''finaliser l'implantation des capteurs à courte distance (optique et de contact)''
*''finaliser la programmation de l'étage micro-contrôleur pour permettre la conduite du robot avec les moyens cités plus haut et en intégrant un arrêt d'urgence en cas de détection d'obstacle''

==Choix techniques : matériel et logiciel==
==Liste des tâches à effectuer==
; Terminer l'agencement matériel
: faire le design sur onshape dela vitre de couverture supérieure
: intaller et s'assurer de démontage facile du deuxième boutton d'arrêt d'urgence sur cette vitre
: moyen de recharge des batteries.

; Fonctionnement des battéries
: faire fonctionner les battéries
: reprogrammer l'arduino et lancer chaque roue 1s

; Module de direction du robot
: realiser une carte avec connecteur RJ11 pour une manette
: realisation de la manette avec le joystick pour commander le robot
: programme de l'arduino pour que les roues soient commandées par la manette

; Montage des capteurs
: Terminer l'installation de tous les capteurs
: connecter tous les capteurs à l'arduino de façon esthétique avec les cables adaptés
: refaire la carte de l'arduino pour inserer les trous des 4 cables rajoutés
: Reecrire le code de l'arduino pour arreter le robot en cas d'obstacle

==Calendrier prévisionnel==

=Réalisation du Projet=

==Prologue==
==Semaine 1==
1.'''Prise en main du travail fait '''<br>
En parcourant de long en large les rapports des groupes qui ont précedement travaillé sur le robot Centaure , on constate qu'une large partie du travail avait déja été entamé , notamment concernant la construction mécanique.les connecteurs Molex permettant de contrôler les variateurs ont bien été branchés.Le chargeur/testeur de battérie a lui aussi été déjà reçu.<br>

2.'''Installation et realisation du capot de dessus'''<br>
[[Fichier:capot.png|right|thumb|"Capot supérieur Robot"]]
Grâce au logiciel Onshape, on realise une représentation 3D de cette partie et Grace à l'imprimante laser du Fabricarum de [[Polytech Lille]], on la conçoit.<br>
L'installation du bouton d'arrêt d'urgence est réalisé avec succès mais une seule des vis prévues pour ce bouton sur le capot entre, ceci est due à la conception d'un rayon plus grand que pévu.<br>
Mais on peut constater que ce petit écart de dimensionnement permet d'avoir un désassemblage facile par la suite.Néanmoins si on constate une erreur du à cela on pourra toujours refaire une découpe avec un diamètre du trou plus petit. <br>

3.'''Alimentation des moteurs'''<br>
On dispose de moteurs SRG0131 24V / 15.5 A / 0.35 kW / 10 km/h.Ces moteurs ont un courant de pic d’approximativement 30-35A. En régime normal, leur consommation est d’environ 8A.<br>
'''Attention: il est impératif de desserrer les freins en injectant du 24V sur les deux petits fils (jaune et violet) allant vers les moteurs'''<br>
Afin de recharger les batteries , on dispose d'un :<br>
**chargeur/testeur de battérie
[[Fichier:Batterie-en-recharge.jpg|500px|center|thumb|"chargeur"]] [[Fichier:Voltmetre.jpg|100px|right|thumb|"voltmètre"]]

Concernant le test de batterie , grâce à un voltmètre on arrivera à voir si notre batterie est déchargée ou pleinement chargée.
sachant qu'avec ce chargeur ,la pleine charge peut indiquer une valeur supérieure à 12,79 V. Cela peu aller à un poil au dessus de 13V. Sachant qu’après l’avoir débrancher elle redescend à 12,8 12,9V.<br>

le travail sur la conception de la carte PCB relié à l'arduino n'a pas été bien explicité sur le wiki. du fait de ce manque d'informations j'ai pris contact avec les élèves qui travaillaient dessus avant moi. J'attends donc leur réponse. En parallèle j'ai retravaillé sur le bouton d’arrêt d'urgence qui était pas bien fixé et sur l'écriture du code arduino.<br>

Aujourd'hui le code Arduino écrit pour faire avancer les deux moteurs a fonctionné parfaitement comme sur la vidéo ci-dessous.<br>
https://drive.google.com/file/d/16iUzUwIlVSCd7hW3ifejBdymHrCmGnTZ/view?usp=sharing|titre= les roues tournent

4.'''Creation de la manette'''<br>
le premier essai de conception de la manette du robot cette fois ci avec deux joysticks.le soucis étant une intersection de certains liens entre eux qui créons un court_circuit plutard à l'utilisation.
[[Fichier:Essai_pcb_manette.png|500px|center|thumb|"PCB MANETTE"]] <br>

https://drive.google.com/file/d/1YFVXnUZzZk38-oYSxc2sWJVdBAq8i-jY/view?usp=sharing|titre= lien vers le fichier .fzz

Fichier Fritzing corrigé : [[File:2021ManetteCentaure.zip]]

==Semaine 2==

=Documents Rendus=

IMA3/IMA4 2019/2021 P2+

2021-05-21T22:58:16Z

Rex : /* Semaine 1 */

Projets IMA3 IMA4 2019/2021

2021-05-14T14:29:34Z

Rex : /* Projets réalisés en 2019/21 sous forme de stages */

Le fait qu'il n'existe plus de projets IMA3/IMA4 publics n'empêche pas que des projets soient encore réalisés. Voici quelques exemples.

== Projets réalisés en 2019/21 par les enseignants ==

{| class="wikitable"
! Projet !! Encadrants ecole
|-
| P1 [[IMA3/IMA4 2019/2021 P1|Outil de configuration d'un serveur NTP embarqué]]
| Xavier Redon
|-
| P2 [[IMA3/IMA4 2019/2021 P2|Accès à Internet "Vintage"]]
| Xavier Redon
|-
| P3 [[IMA3/IMA4 2019/2021 P3|Banc de piratage WiFi à l'aide de grappes de Raspberry PI]]
| Xavier Redon
|-
|}

== Projets réalisés en 2019/21 sous forme de stages ==

Vu la difficulté de trouver des stages de seconde année du cycle ingénieur (covid), l'école a proposé des stages académiques.

{| class="wikitable"
! Projet !! Elèves !! Encadrants ecole
|-
| P1 [[IMA3/IMA4 2019/2021 P1+|Micro-ordinateur pour la pédagogie]]
| Andrei Florea
| Xavier Redon / Alexandre Boé
|-
| P2 [[IMA3/IMA4 2019/2021 P2+|Robot autonome Centaure]]
| Marlene Kameni
| Xavier Redon / Alexandre Boé
|-
| P3 [[IMA3/IMA4 2019/2021 P3+|Installation d'un orchestrateur de machines virtuelles]]
| Souleymane Sow
| Xavier Redon
|-
| P5 [[IMA3/IMA4 2019/2021 P5+|Robot rampant]]
| Agossou-alexandre Edoh
| Xavier Redon / Alexandre Boé
|-
| P6 [[IMA3/IMA4 2019/2021 P6+|Visualisation et positionnement de fibre optique]]
| Enzo Derisbourg
| Thomas Vantroys
|-
| P11 [[IMA3/IMA4 2019/2021 P11+|TP à distance - Interface de visualisation]]
| Louis Wadbled
| Alexandre Boé / Xavier Redon
|-
| P17 [[IMA3/IMA4 2019/2021 P17+|Capteur de mesure de pollution]]
| Enoch Hodonou
| Alexandre Boé / Thomas Vantroys
|-
| P24 [[IMA3/IMA4 2019/2021 P24+|Interface graphique pour surveillance des communications d'un système embarqué]]
| Julien Delabre / Theo Van-Rompaey
| Thomas Vantroys
|-
|}

IMA3/IMA4 2019/2021 P24+

2021-05-14T14:24:10Z

Rex : Page créée avec « __TOC__ <br style="clear: both;"/> =Présentation générale= ==Description== ==Objectifs== =Préparation du projet= ==Cahier des charges== ==Choix techniques : matér... »

__TOC__
<br style="clear: both;"/>

=Présentation générale=

==Description==
==Objectifs==

=Préparation du projet=

==Cahier des charges==
==Choix techniques : matériel et logiciel==
==Liste des tâches à effectuer==
==Calendrier prévisionnel==

=Réalisation du Projet=

==Prologue==
==Semaine 1==
==Semaine 2==

=Documents Rendus=

IMA3/IMA4 2019/2021 P17+

2021-05-14T14:24:06Z

IMA3/IMA4 2019/2021 P11+

2021-05-14T14:24:03Z

IMA3/IMA4 2019/2021 P6+

2021-05-14T14:24:01Z

IMA3/IMA4 2019/2021 P5+

2021-05-14T14:23:58Z

IMA3/IMA4 2019/2021 P3+

2021-05-14T14:23:54Z

IMA3/IMA4 2019/2021 P2+

2021-05-14T14:23:51Z

IMA3/IMA4 2019/2021 P1+

2021-05-14T14:23:20Z

Projets IMA3 IMA4 2019/2021

2021-05-14T14:21:48Z

Rex :

Le fait qu'il n'existe plus de projets IMA3/IMA4 publics n'empêche pas que des projets soient encore réalisés. Voici quelques exemples.

== Projets réalisés en 2019/21 par les enseignants ==

{| class="wikitable"
! Projet !! Encadrants ecole
|-
| P1 [[IMA3/IMA4 2019/2021 P1|Outil de configuration d'un serveur NTP embarqué]]
| Xavier Redon
|-
| P2 [[IMA3/IMA4 2019/2021 P2|Accès à Internet "Vintage"]]
| Xavier Redon
|-
| P3 [[IMA3/IMA4 2019/2021 P3|Banc de piratage WiFi à l'aide de grappes de Raspberry PI]]
| Xavier Redon
|-
|}

== Projets réalisés en 2019/21 sous forme de stages ==

Vu la difficulté de trouver des stages de seconde année du cycle ingénieur (covid), l'école a proposé des stages académiques.

{| class="wikitable"
! Projet !! Encadrants ecole
|-
| P1 [[IMA3/IMA4 2019/2021 P1+|Micro-ordinateur pour la pédagogie]]
| Xavier Redon / Alexandre Boé
|-
| P2 [[IMA3/IMA4 2019/2021 P2+|Robot autonome Centaure]]
| Xavier Redon / Alexandre Boé
|-
| P3 [[IMA3/IMA4 2019/2021 P3+|Installation d'un orchestrateur de machines virtuelles]]
| Xavier Redon
|-
| P5 [[IMA3/IMA4 2019/2021 P5+|Robot rampant]]
| Xavier Redon / Alexandre Boé
|-
| P6 [[IMA3/IMA4 2019/2021 P6+|Visualisation et positionnement de fibre optique]]
| Thomas Vantroys
|-
| P11 [[IMA3/IMA4 2019/2021 P11+|TP à distance - Interface de visualisation]]
| Alexandre Boé / Xavier Redon
|-
| P17 [[IMA3/IMA4 2019/2021 P17+|Capteur de mesure de pollution]]
| Alexandre Boé / Thomas Vantroys
|-
| P24 [[IMA3/IMA4 2019/2021 P24+|Interface graphique pour surveillance des communications d'un système embarqué]]
| Thomas Vantroys
|-
|}

IMA3/IMA4 2019/2021 P3

2021-01-08T10:58:20Z

Rex : /* Le banc complet */

= Introduction =

Dans le cadre de travaux pratiques d'administration système et réseau, un atelier de cassage de clefs WiFi WEP et WPA est organisé. Le but est de donner la possibilité d'avoir un SSID par binôme. De plus cet atelier ne devant pas prendre plusieurs heures à se dérouler, une aide au cassage doit être apporté sous la forme de la génération d'un trafic significatif sur les réseaux WiFi concernés.

Autant créer plusieurs SSID est facile avec des points d'accès WiFi Cisco, autant connecter un client sur chaque SSID est assez compliqué. Il est difficile d'avoir une machine avec plusieurs interfaces WiFi et il est délicat d'utiliser un PC par SSID.

Cette page décrit l'utilisation de grappes de Raspberry Pi pour réaliser les clients WiFi.

= Autres solutions =

Une solution sans matériel institutionnel consiste à demander aux élèves de créer un SSID sur leur téléphone. Plusieurs défauts à cette solution :
* pas de possibilité d'utiliser une clef WEP, même si WEP est maintenant largement obsolète, l'étude de cas est intéressante pour initier les élèves au chiffrement ;
* pas de contrôle sur les SSID créés, donc pas de possibilité de vérification du résultat possible, non utilisable pour un examen ;
* dans le cadre d'utilisation d'un point d'accès WiFi configuré avec 12 SSID, deux solutions avaient déjà été utilisée pour générer le trafic :
** utiliser 12 PC avec une clef USB WiFi, de nombreux soucis se sont présentés : certains PC étaient trop éloignés, les clefs disparaisaient, les scripts de connexion et de génération de trafic étaient arrêtés ;
** utiliser une machine dédiée avec 12 clefs USB WiFi, en pratique cela ne fonctionne pas, même Linux se rélève incapable de gérer autant d'interface WiFi de façon stable.

= Matériel =

La solution consiste donc à remplacer les 12 PC par autant de Raspberry Pi. La tentative d'utiliser des Raspberry Pi indépendantes dans leurs propres boitiers s'est révélée très pénible à gérer (en particulier pour l'alimentation avec 12 adaptateurs séparés).

L'idée est donc d'empiler les Raspberry Pi et des les alimenter de façon centralisée. Nous utilisons deux grappes de 7 Raspberry chacune.

La liste du matériel utilisé est :
* 14 Raspberry Pi 2 utilisées dans d'anciens travaux pratiques réseau et remplacées depuis par des modèles plus récents, les cartes ont été retirées de leurs boitiers ;
* l'alimentation se fait via un hub USB de marque Anker offrant 10 ports USB et une puissance totale utilisable de 60 Watt, soit 6 Watt par port soit encore un courant de plus d'un Ampère par port, c'est suffisant pour notre application ;
* pour ajouter à la facilité d'utilisation et pour stabiliser physiquement les grappes, un commutateur 8 ports gigabit de marque D-Link est ajouté, la référence de ce commutateur est DGS-108 ;
* quelques petits accessoires sont aussi nécessaires : 14 câbles Ethernet de 25cm, 14 câbles USB de 30cm, quelques ventilateurs, des entretoises, des vis.

A environ 40 euros pièce, ce sont clairement les Raspberry les composants les plus onéreux. Il faut équiper ces dernières de 14 clefs WiPi à 8 euros pièce. Les hubs USB se trouvent à 30 euros, les commutateurs un peu en dessous de 35 euros, les câbles réseau autour de 20 euros, les câbles USB autour de 30 euros, rajoutons 30 euros pour la visserie. Nous arrivons donc à un total, non négligeable, qui approche des 900 euros TTC.

= Réalisation Physique =

== Les grappes ==

[[File:WiFi-Grappe-vue1.jpg|thumbs|200px|left]]
[[File:WiFi-Grappe-vue2.jpg|thumbs|200px|right]]

Sur internet, vous pouvez trouver des boitiers ou des kits pour grappes de Raspberry Pi. Ces dispositifs ne sont pas souvent prévus pour autant de cartes que nous souhaitons utiliser. Ils sont aussi assez onéreux. En fait nous avons constaté que simplement relier les Raspberry Pi par des entretoises était acceptable. Il faut juste trouver des entretoises de la bonne hauteur et avec un filetage mâle d'un coté et femelle de l'autre. Avouons avoir du un peu élargir les trous de fixation des Raspberry Pi pour que les filetage mâles M3 puissent passer.

Les boitiers des commutateurs ont été dévissés pour pouvoir percer 4 trous dans la face supérieure et ainsi pouvoir visser les entretoises du bas de la pile sur le boitier du commutateur. Des vis nylon ont été utilisées.

L'ensemble ainsi obtenu est plutôt robuste. Cela dit les câbles réseau étant un peu courts et assez rigide leur utilisation a fait vriller la pile de Raspberry. L'utilisation d'un kit d"empilement de Raspberry aurait certainement évité cela. Il est aussi envisageable de trouver des câbles de 30cm ou plus flexible pour éviter la torsion.

Le hub USB est fixé sur une équerre métallique visée sur le boitier du commutateur en détournant une vis de terre de sa fonction première. La fixation du hub sur l'équerre se fait avec un simple lien plastique. Il suffit ensuite d'alimenter les Raspberry par des câbles USB de type A vers des micro-USB.

Il est prévu de rajouter un ventilateur sur le coté des piles mais plus pour le coté esthétique (ventilateurs avec LED RGB) que pour un réel besoin de refroidissement, les Raspberry n'étant pas trop surchauffée par l'envoi de quelques paquets réseau. Pour la fixation du ventilateur, un système doit être conçu aucune solution directe n'ayant été trouvée.

<br style="clear: both;" />

== Le banc complet ==

Le banc complet comprend les deux grappes de Raspberry mais aussi :
* deux points d'accès WiFi Cisco (un avec 12 SSID WEP et un avec 12 SSID WPA) ;
* un commutateur pour relier les deux grappes, les deux points d'accès et le réseau de la salle ;
* un PC comme cible aux paquets de trafic sur 24 VLANS mais aussi pour l'accès série sur les points d'accès.

A noter que le commutateur alimente les deux points d'accès par PoE.

Concernant le coût : des Aironet 1600 se trouvent d'occasion autour de 30 euros et les autres matériels ne sont pas forcément utiles comme indiqué ci-dessous.

Des optimisations sont possibles :
* n'avoir que des commutateurs 8 ports complique la configuration en n'autorisant pas la connexion entre les grappes ET avec la salle, aucun commutateur de la même catégorie de prix ne semble être disponible avec plus de ports, utiliser un commutateur professionnel pour faire le lien est un peu exagéré, quelques autres pistes :
** ajouter un troisième commutateur DGS-108 et alimenter les points d'accès de façon plus traditionnelle ;
** ajouter un adaptateur USB Ethernet sur une Raspberry comme point d'interconnexion avec la salle.
* Le PC n'est pas strictement obligatoire, une Rasperry Pi peut être utilisée via son interface Ethernet comme puit pour les paquets du trafic, les points d'accès peuvent être configurée par Ethernet.

= Configuration logicielle =

IMA3/IMA4 2019/2021 P3

2021-01-08T10:43:35Z

Rex : /* Réalisation Physique */

= Introduction =

Dans le cadre de travaux pratiques d'administration système et réseau, un atelier de cassage de clefs WiFi WEP et WPA est organisé. Le but est de donner la possibilité d'avoir un SSID par binôme. De plus cet atelier ne devant pas prendre plusieurs heures à se dérouler, une aide au cassage doit être apporté sous la forme de la génération d'un trafic significatif sur les réseaux WiFi concernés.

Autant créer plusieurs SSID est facile avec des points d'accès WiFi Cisco, autant connecter un client sur chaque SSID est assez compliqué. Il est difficile d'avoir une machine avec plusieurs interfaces WiFi et il est délicat d'utiliser un PC par SSID.

Cette page décrit l'utilisation de grappes de Raspberry Pi pour réaliser les clients WiFi.

= Autres solutions =

Une solution sans matériel institutionnel consiste à demander aux élèves de créer un SSID sur leur téléphone. Plusieurs défauts à cette solution :
* pas de possibilité d'utiliser une clef WEP, même si WEP est maintenant largement obsolète, l'étude de cas est intéressante pour initier les élèves au chiffrement ;
* pas de contrôle sur les SSID créés, donc pas de possibilité de vérification du résultat possible, non utilisable pour un examen ;
* dans le cadre d'utilisation d'un point d'accès WiFi configuré avec 12 SSID, deux solutions avaient déjà été utilisée pour générer le trafic :
** utiliser 12 PC avec une clef USB WiFi, de nombreux soucis se sont présentés : certains PC étaient trop éloignés, les clefs disparaisaient, les scripts de connexion et de génération de trafic étaient arrêtés ;
** utiliser une machine dédiée avec 12 clefs USB WiFi, en pratique cela ne fonctionne pas, même Linux se rélève incapable de gérer autant d'interface WiFi de façon stable.

= Matériel =

La solution consiste donc à remplacer les 12 PC par autant de Raspberry Pi. La tentative d'utiliser des Raspberry Pi indépendantes dans leurs propres boitiers s'est révélée très pénible à gérer (en particulier pour l'alimentation avec 12 adaptateurs séparés).

L'idée est donc d'empiler les Raspberry Pi et des les alimenter de façon centralisée. Nous utilisons deux grappes de 7 Raspberry chacune.

La liste du matériel utilisé est :
* 14 Raspberry Pi 2 utilisées dans d'anciens travaux pratiques réseau et remplacées depuis par des modèles plus récents, les cartes ont été retirées de leurs boitiers ;
* l'alimentation se fait via un hub USB de marque Anker offrant 10 ports USB et une puissance totale utilisable de 60 Watt, soit 6 Watt par port soit encore un courant de plus d'un Ampère par port, c'est suffisant pour notre application ;
* pour ajouter à la facilité d'utilisation et pour stabiliser physiquement les grappes, un commutateur 8 ports gigabit de marque D-Link est ajouté, la référence de ce commutateur est DGS-108 ;
* quelques petits accessoires sont aussi nécessaires : 14 câbles Ethernet de 25cm, 14 câbles USB de 30cm, quelques ventilateurs, des entretoises, des vis.

A environ 40 euros pièce, ce sont clairement les Raspberry les composants les plus onéreux. Il faut équiper ces dernières de 14 clefs WiPi à 8 euros pièce. Les hubs USB se trouvent à 30 euros, les commutateurs un peu en dessous de 35 euros, les câbles réseau autour de 20 euros, les câbles USB autour de 30 euros, rajoutons 30 euros pour la visserie. Nous arrivons donc à un total, non négligeable, qui approche des 900 euros TTC.

= Réalisation Physique =

== Les grappes ==

[[File:WiFi-Grappe-vue1.jpg|thumbs|200px|left]]
[[File:WiFi-Grappe-vue2.jpg|thumbs|200px|right]]

Sur internet, vous pouvez trouver des boitiers ou des kits pour grappes de Raspberry Pi. Ces dispositifs ne sont pas souvent prévus pour autant de cartes que nous souhaitons utiliser. Ils sont aussi assez onéreux. En fait nous avons constaté que simplement relier les Raspberry Pi par des entretoises était acceptable. Il faut juste trouver des entretoises de la bonne hauteur et avec un filetage mâle d'un coté et femelle de l'autre. Avouons avoir du un peu élargir les trous de fixation des Raspberry Pi pour que les filetage mâles M3 puissent passer.

Les boitiers des commutateurs ont été dévissés pour pouvoir percer 4 trous dans la face supérieure et ainsi pouvoir visser les entretoises du bas de la pile sur le boitier du commutateur. Des vis nylon ont été utilisées.

L'ensemble ainsi obtenu est plutôt robuste. Cela dit les câbles réseau étant un peu courts et assez rigide leur utilisation a fait vriller la pile de Raspberry. L'utilisation d'un kit d"empilement de Raspberry aurait certainement évité cela. Il est aussi envisageable de trouver des câbles de 30cm ou plus flexible pour éviter la torsion.

Le hub USB est fixé sur une équerre métallique visée sur le boitier du commutateur en détournant une vis de terre de sa fonction première. La fixation du hub sur l'équerre se fait avec un simple lien plastique. Il suffit ensuite d'alimenter les Raspberry par des câbles USB de type A vers des micro-USB.

Il est prévu de rajouter un ventilateur sur le coté des piles mais plus pour le coté esthétique (ventilateurs avec LED RGB) que pour un réel besoin de refroidissement, les Raspberry n'étant pas trop surchauffée par l'envoi de quelques paquets réseau. Pour la fixation du ventilateur, un système doit être conçu aucune solution directe n'ayant été trouvée.

<br style="clear: both;" />

== Le banc complet ==

Le banc complet comprend les deux grappes de Raspberry mais aussi :
* deux points d'accès WiFi Cisco (un avec 12 SSID WEP et un avec 12 SSID WPA) ;
* un commutateur pour relier les deux grappes, les deux points d'accès et le réseau de la salle ;
* un PC pour l'accès série sur les points d'accès.

= Configuration logicielle =

IMA3/IMA4 2019/2021 P3

2021-01-08T10:41:36Z

Rex : /* Réalisation Physique */

IMA3/IMA4 2019/2021 P3

2021-01-08T10:38:06Z

Rex : /* Réalisation Physique */

= Introduction =

Dans le cadre de travaux pratiques d'administration système et réseau, un atelier de cassage de clefs WiFi WEP et WPA est organisé. Le but est de donner la possibilité d'avoir un SSID par binôme. De plus cet atelier ne devant pas prendre plusieurs heures à se dérouler, une aide au cassage doit être apporté sous la forme de la génération d'un trafic significatif sur les réseaux WiFi concernés.

Autant créer plusieurs SSID est facile avec des points d'accès WiFi Cisco, autant connecter un client sur chaque SSID est assez compliqué. Il est difficile d'avoir une machine avec plusieurs interfaces WiFi et il est délicat d'utiliser un PC par SSID.

Cette page décrit l'utilisation de grappes de Raspberry Pi pour réaliser les clients WiFi.

= Autres solutions =

Une solution sans matériel institutionnel consiste à demander aux élèves de créer un SSID sur leur téléphone. Plusieurs défauts à cette solution :
* pas de possibilité d'utiliser une clef WEP, même si WEP est maintenant largement obsolète, l'étude de cas est intéressante pour initier les élèves au chiffrement ;
* pas de contrôle sur les SSID créés, donc pas de possibilité de vérification du résultat possible, non utilisable pour un examen ;
* dans le cadre d'utilisation d'un point d'accès WiFi configuré avec 12 SSID, deux solutions avaient déjà été utilisée pour générer le trafic :
** utiliser 12 PC avec une clef USB WiFi, de nombreux soucis se sont présentés : certains PC étaient trop éloignés, les clefs disparaisaient, les scripts de connexion et de génération de trafic étaient arrêtés ;
** utiliser une machine dédiée avec 12 clefs USB WiFi, en pratique cela ne fonctionne pas, même Linux se rélève incapable de gérer autant d'interface WiFi de façon stable.

= Matériel =

La solution consiste donc à remplacer les 12 PC par autant de Raspberry Pi. La tentative d'utiliser des Raspberry Pi indépendantes dans leurs propres boitiers s'est révélée très pénible à gérer (en particulier pour l'alimentation avec 12 adaptateurs séparés).

L'idée est donc d'empiler les Raspberry Pi et des les alimenter de façon centralisée. Nous utilisons deux grappes de 7 Raspberry chacune.

La liste du matériel utilisé est :
* 14 Raspberry Pi 2 utilisées dans d'anciens travaux pratiques réseau et remplacées depuis par des modèles plus récents, les cartes ont été retirées de leurs boitiers ;
* l'alimentation se fait via un hub USB de marque Anker offrant 10 ports USB et une puissance totale utilisable de 60 Watt, soit 6 Watt par port soit encore un courant de plus d'un Ampère par port, c'est suffisant pour notre application ;
* pour ajouter à la facilité d'utilisation et pour stabiliser physiquement les grappes, un commutateur 8 ports gigabit de marque D-Link est ajouté, la référence de ce commutateur est DGS-108 ;
* quelques petits accessoires sont aussi nécessaires : 14 câbles Ethernet de 25cm, 14 câbles USB de 30cm, quelques ventilateurs, des entretoises, des vis.

A environ 40 euros pièce, ce sont clairement les Raspberry les composants les plus onéreux. Il faut équiper ces dernières de 14 clefs WiPi à 8 euros pièce. Les hubs USB se trouvent à 30 euros, les commutateurs un peu en dessous de 35 euros, les câbles réseau autour de 20 euros, les câbles USB autour de 30 euros, rajoutons 30 euros pour la visserie. Nous arrivons donc à un total, non négligeable, qui approche des 900 euros TTC.

= Réalisation Physique =

== Les grappes ==

[[File:WiFi-Grappe-vue1.jpg|thumbs|200px|left]]
[[File:WiFi-Grappe-vue2.jpg|thumbs|200px|right]]

Sur internet, vous pouvez trouver des boitiers ou des kits pour grappes de Raspberry Pi. Ces dispositifs ne sont pas souvent prévus pour autant de cartes que nous souhaitons utiliser. Ils sont aussi assez onéreux. En fait nous avons constaté que simplement relier les Raspberry Pi par des entretoises était acceptable. Il faut juste trouver des entretoises de la bonne hauteur et avec un filetage mâle d'un coté et femelle de l'autre. Avouons avoir du un peu élargir les trous de fixation des Raspberry Pi pour que les filetage mâles M3 puissent passer.

Les boitiers des commutateurs ont été dévissés pour pouvoir percer 4 trous dans la face supérieure et ainsi pouvoir visser les entretoises du bas de la pile sur le boitier du commutateur. Des vis nylon ont été utilisées.

L'ensemble ainsi obtenu est plutôt robuste. Cela dit les câbles réseau étant un peu courts et assez rigide leur utilisation a fait vriller la pile de Raspberry. L'utilisation d'un kit d"empilement de Raspberry aurait certainement évité cela. Il est aussi envisageable de trouver des câbles de 30cm ou plus flexible pour éviter la torsion.

Le hub USB est fixé sur une équerre métallique visée sur le boitier du commutateur en détournant une vis de terre de sa fonction première. La fixation du hub sur l'équerre se fait avec un simple lien plastique. Il suffit ensuite d'alimenter les Raspberry par des câbles USB de type A vers des micro-USB.

<br style="clear: both;" />

== Le banc complet ==

= Configuration logicielle =

IMA3/IMA4 2019/2021 P3

2021-01-08T10:24:59Z

Rex :

IMA3/IMA4 2019/2021 P2

2021-01-08T09:26:02Z

Rex : /* Améliorations */

= Introduction =

Le réseau RENATER n'est pas adapté à l'enseignement : trop de restrictions par les différents administrateurs réseau. Il est par exemple très compliqué de faire installer des serveurs (DNS, SMTP, Web, etc) aux élèves.

La plateforme mathématiques et informatique s'est donc dotée de lignes spécifiques à l'enseignement. Ces lignes commencent à dater et utilisent la technologie cuivre / ADSL. La migration vers la fibre est en cours.

En attendant, il faut maintenir les lignes ADSL. Les opérateurs, bien que continuant à présenter des factures, ne sont plus en mesure de remplacer les modems / routeurs initialement fournis. Le sujet de ce projet consiste à basculer sur du matériel réseau de la plateforme pour gérer les liaisons ADSL. Le coût doit rester minimal vu qu'il s'agit d'une solution temporaire.

Les deux lignes ADSL sont des lignes France Télécom conservées lors de la privatisation de l'institution sous le nom commercial "orange". La première ligne a même été négociée avec Oléane au début des années 2000 pour permettre aux élèves logés dans la résidence crous Eiffel d'avoir un accès Internet. Une dizaine d'année plus tard la direction de l'école a accédé aux sollicitations du crous pour confier l'accès Internet à un opérateur privé. Nostalgie à part la dénomination officielle des deux lignes est :
* ADSL business internet office (vendue pour un débit 18Mb/s descendant et 80Kb/s montant) ;
* ADSL internet pro solo (accès classique comme pour les particuliers).

Les deux modems / routeurs de ces lignes ont cessé de fonctionner (en 2018 pour la première ligne et en 2020 pour la seconde ligne).

= Première approche Cisco C1700 =

[[File:Cisco1721.jpeg|thumbs|200px|right|Cisco 1721]]

Un premier test a été effectué avec un routeur Cisco 1721. Avec une mémoire flash de 32Mo et une mémoire vive de 64Mo, il est possible de le faire tourner sous un IOS 12.4.

[[File:Wic1adsl.jpeg|thumbs|200px|left|Carte ADSL]]

Le 1721 peut prendre deux cartes WIC classiques, dont en particulier la carte <tt>WIC-1ADSL=</tt>. Ces cartes peuvent se trouver d'occasion autour de 4 euros.

La configuration de l'interface ATM de la carte ADSL est simple :

interface ATM0
no ip address
no atm ilmi-keepalive
dsl operating-mode auto
pvc 8/35
pppoe-client dial-pool-number 1
!
!

A noter que les caractéristiques (ici <tt>8/35</tt>) du circuit vers le fournisseur d'accès dépendent totalement du dit fournisseur. Les identifiants pour l'accès au fournisseur sont déclarés dans une interface virtuelle <tt>Dialer</tt> qui se charge du protocole PPPoE (Point-to-Point Protocol over Ethernet). Le numéro du <tt>dial pool</tt> doit être le même dans la référence de l'interface ATM et dans la configuration de l'interface <tt>Dialer</tt> (ici le numéro est 1).

interface Dialer1
mtu 1492
ip address negotiated
ip virtual-reassembly
encapsulation ppp
dialer pool 1
dialer idle-timeout 0
dialer persistent
ppp chap hostname IDENTIFIANT
ppp chap password 0 MOTDEPASSE
!

Bien entendu il faut remplacer les mot <tt>IDENTIFIANT</TT> et <tt>MOTDEPASSE</tt> avec l'identification fournie par votre fournisseur d'accès. A noter que la récupération de ces identifiants n'est pas toujours évidente. Pour l'ADSL Pro d'orange une demande a été suivie par un courriel contenant l'identifiant le lendemain mais pour l'accès ADSL BIO il a été nécessaire de fournir un document d'autorisation de divulgation par un responsable de l'établissement.

La configuration <tt>mtu 1492</tt> n'est pas optionnelle sans elle le passage par l'interface ATM casse la découverte du MTU maximal d'une façon ou d'une autre. Pour les liaisons peu stables, comme les notres, la directive <tt>dialer persistent</tt> est très utile pour relancer l'identification sur la connexion.

Enfin une liaison ADSL sans mascarade n'est pas très utile vu que l'opérateur ne donne qu'une adresse IPv4 routée. Pour mettre en place la mascarade il faut ajouter la directive <tt>ip nat outside</tt> dans l'interface de sortie vers Internet (ici <tt>Dialer1</tt>) et il faut ajouter <tt>ip nat inside</tt> dans l'interface du réseau local (généralement une interface Ethernet). Enfin il faut définir la mascarade par elle-même :

access-list 1 permit 192.168.0.0 0.0.0.255
ip nat inside source list 1 interface Dialer1 overload

Il ne reste plus qu'à ajouter la route par défaut : <tt>ip route 0.0.0.0 0.0.0.0 Dialer1</tt>.

Dans cette configuration il est supposé que le réseau IPv4 local est <tt>192.168.0.0/24</tt>.

La solution à base de 1721 est fonctionnelle mais avec les limitations ou défauts suivant :
* la carte <tt>WICADSL1=</tt> n'implante que ADSL version 1, dans le cas de notre liaison avec 40db d'atténuation on se retrouve avec des débit de quelques Mb/s même sur la ligne certifiée à 18Mb/s ;
* il n'est pas possible de configurer deux WIC ADSL dans un 1721, ce bogue est répertorié sous le numéro CSCsa90021 ;
* le 2721 est un routeur de bureau non facilement intégrable dans une baie (non fixable sur les rails, alimentation massive séparée), d'autant plus s'il en faut deux, un par liaison ADSL.

= Seconde approche Cisco C2600 =

[[File:2621.jpg|thumbs|500px|left|2621 en baie]]

Il est possible de récupérer les cartes ADSL <tt>WIC-1ADSL</tt> de ces routeurs pour les installer sur un Cisco 2621 un peu plus puissant. De plus ce routeur n'est pas affecté par le bogue CSCsa90021, les 2 cartes ADSL peuvent être configurées simultanément. Le 2621 dont nous disposions possédait lui aussi une mémoire flash de 32Mo et une mémoire vive de 64Mo. Du coup le 2621 peut tourner sous un IOS sensiblement identique à celui du 1721 soit un IOS 12.4.

Pas de modification notable dans la configuration des interfaces ATM, hors numérotation des interfaces et nouvelles options ATM par défaut :
interface ATM0/0
no ip address
atm restart timer 300 ! nouvelle option par défaut
no atm ilmi-keepalive
dsl operating-mode auto
dsl enable-training-log ! nouvelle option par défaut
pvc 8/35
pppoe-client dial-pool-number 1
!
!

La configuration de l'interface <tt>ATM0/1</tt> est identique mis à part le numéro du <tt>dial-pool-number</tt>. Les interfaces virtuelles <tt>Dialer</tt> se configurent de façon strictement semblable sur le 2921 par rapport au 1721.

Par contre cette fois nous avons deux interfaces de sortie par les deux lignes ADSL. Le routage et la mascarade deviennent plus compliqué à configurer.

track 1 ip route IPV4_ISP_ADSL1 255.255.255.255 reachability
track 2 ip route IPV4_ISP_ADSL2 255.255.255.255 reachability
ip route 0.0.0.0 0.0.0.0 Dialer1 track 1
ip route 0.0.0.0 0.0.0.0 Dialer2 track 2

Ce bloc ajoute les routes par défaut via les lignes disponibles à un moment donné. La disponibilité se fait par test ICMP sur les adresses IPv4 coté fournisseur d'adresse. Si deux routes par défaut sont ajoutées, l'algorithme de routage doit équilibrer le trafic sur les différentes lignes ADSL. Dans notre cas le trafic se fait principalement via un mandataire Web. L'algorithme Cisco classique <tt>original</tt> peut suffire. Cet algorithme route toutes les communications d'une adresse IPv4 donnée vers une autre adresse IPv4 donnée vers la même sortie. Si les sites web visités sont peu variés il vaut mieux passer sur l'algorithme <tt>universal</tt> qui ajoute les ports sources et destination dans les éléments de choix de la route de sortie. Cela peut se faire avec la commande

(config)# ip cef load-sharing algorithm universal

Pour la mascarade la configuration est de la forme :

access-list 1 permit 192.168.0.0 0.0.0.255
route-map ADSL1 permit 10
match ip address 1
match interface Dialer1
!
route-map ADSL2 permit 10
match ip address 1
match interface Dialer2
!
ip nat inside source route-map ADSL1 interface Dialer1 overload
ip nat inside source route-map ADSL2 interface Dialer2 overload

Vous constatez que l'astuce consiste à passer par des <tt>route-map</tt> pour que la mascarade puisse se faire en bonne intelligence avec l'équilibrage de charge. Ne pas oublier d'ajouter les <tt>ip nat inside</tt> sur l'interface du réseau local et les <tt>ip nat outside</tt> dans les deux interfaces <tt>Dialer</tt>.

A noter : l'équilibrage n'a pas été testé avec cette configuration, les deux lignes ADSL n'ayant pas pu être opérationnelles simultanément avant l'acquisition de nouvelles cartes ADSL et le passage à un Cisco 2901.

Cette solution à base de 2621 est fonctionnelle mais toujours avec le défaut que les <tt>WIC-1ADSL=</tt> ne sont pas suffisantes pour obtenir un débit satisfaisant avec les limitations ou défauts suivant :

<br style="clear: both;"/>

= Troisième approche Cisco C2900 =

[[File:2901.jpg|thumbs|500px|left|2901 en baie]]

A l'origine l'idée était d'installer les cartes <tt>WIC-1ADSL=</tt> dans 2 des 4 slots WIC d'un Cisco 2901. Mais les slots WIC du 2901 sont des EHWIC (Enhanced High-Speed WAN Interface Cards). Et étrangement les cartes WIC classiques (du moins les <tt>WIC-1ADSL=</tt>) ne fonctionnent pas dans ces slots ou ne sont pas prises en compte par l'IOS.

Un mal pour un bien, il faut utiliser des cartes ADSL plus récentes comme les <tt>HWIC-1ADSL-M</tt>. Ces cartes peuvent être achetées d'occassion autour de 14 euros. C'est plus cher que les <tt>WIC-1ADSL=</tt> mais cela reste tout à fait acceptable. De plus ces cartes sont compatible ADSL version 2 voire même version 2+ ce qui va nettement améliorer le débit des connexions.

Du coté de l'IOS pas de changement par rapport aux 1721 et 2621, nous sommes toujours sur un IOS classique version 12.4 (pour être précis l'image utilisée est <tt>c2900-universalk9-mz.SPA.154-1.T1.bin</tt>). Par contre la complexité de la configuration augmente du au fait que le routeur est déjà utilisé à d'autres fins. Il n'est donc pas possible de modifier la table de routage principale. Il va donc falloir utiliser le dispositif PBR (Policy-Based Routing) de Cisco. Hélas ce dispositif est bien moins abouti que la politique de routage de Linux qui permet d'utiliser de vraies tables de routages annexes et pas seulement de modifier un peu la table principale. Nous allons aussi utiliser le dispositif SLA (Service Level Agreements) dont le principe est de de suivre l'état de services Internet et qui va au delà du simple suivi d'interfaces (tracking) dont nous nous sommes servis jusque là.

<br style="clear: both;"/>

== Configuration ADSL ==

La configuration ADSL est strictement semblable à celle déjà utilisée avec les routeurs précédents.

interface ATM0/0/0
no ip address
no atm ilmi-keepalive
dsl enable-training-log
pvc 8/35
pppoe-client dial-pool-number 1
!
!

interface Dialer1
mtu 1492
ip address negotiated
ip nat outside
ip virtual-reassembly in
encapsulation ppp
dialer pool 1
dialer idle-timeout 0
dialer persistent
ppp chap hostname IDENTIFIANT
ppp chap password 0 MOTDEPASSE
!

Une tentative de récupérer une adresse IPv6 au niveau des interfaces <tt>Dialer</tt> n'a pas réussi. Il faut dire que je ne suis pas convaincu que le fournisseur en propose une.

== Configuration SLA ==

La configuration de vérification de l'état des connexions :

ip sla 20
icmp-echo IPV4_ISP_ADSL1
ip sla schedule 20 life forever start-time now
ip sla 21
icmp-echo IPV4_ISP_ADSL2
ip sla schedule 21 life forever start-time now
track 20 ip sla 20 reachability
track 21 ip sla 21 reachability

Dans notre configuration le dispositif SLA est clairement sous-exploité.

== Configuration PBR ==

Sur l'interface du réseau local il est fait référence à la <tt>route-map</tt> qui implante notre politique de routage (PBR) :

interface INTERFACE
...
ip nat inside
ip virtual-reassembly in max-reassemblies 128
ip tcp adjust-mss 1452
ip policy route-map to_adsl
!

La <tt>route-map</tt> en question :

route-map to_adsl permit 10
match ip address 20
set ip next-hop verify-availability IPV4_ISP_ADSL1 1 track 20
set ip next-hop verify-availability IPV4_ISP_ADSL1 2 track 21
!

Et vous constatez le problème : l'obligation d'un numéro de séquence pour le <tt>next-hop</tt> (juste après l'adresse IPv4 du saut). Du coup les deux routeurs ne sont pas au même niveau (il est interdit d'utiliser deux numéros identique) et donc pas d'équilibrage de charge juste un lien de secours.

== La mascarade ==

Aucun changement dans la définition de la mascarade :

access-list 20 permit 192.168.0.0 0.0.0.255
route-map ADSL2 permit 10
match ip address 20
match interface Dialer2
!
route-map ADSL1 permit 10
match ip address 20
match interface Dialer1
!
ip nat inside source route-map ADSL1 interface Dialer1 overload
ip nat inside source route-map ADSL2 interface Dialer2 overload

== Diagnostics ==

Cette sous-section présente quelques commandes permettant un rapide diagnostic des liaisons ADSL.

Tout d'abord il faut vérifier si le circuit ATM de la connexion ADSL a pu être établi. Ici ce n'est pas le cas :
#show interface ATM0/0 | include VCs
23 maximum active VCs, 256 VCs per VP, 0 current VCCs
alors que là tout va bien :
#show interface ATM0/0/0 | include VCs
23 maximum active VCs, 256 VCs per VP, 1 current VCCs
Si vous avez un problème à ce niveau c'est que la connexion physique vers votre ISP est hors-service. Voyez avec eux.

Il est ensuite possible d'apprécier la qualité de la ligne :
#show dsl interface atm 0/0/0 | include Attenuation:
Attenuation: 38.5 dB 22.0 dB
L'atténuation est de 40db sur l'autre ligne. Ces valeurs sont cohérentes avec celles mesurées par les techniciens de l'opérateur. Ils expliquent aussi les débits obtenus dans la sous-section suivante.

Vous pouvez regarder si l'identification PPPoE se passe bien :
#show pppoe session
Uniq ID PPPoE RemMAC Port VT VA State
SID LocMAC VA-st Type
N/A 18215 xxxx.yyyy.zzzz ATM0/0/0 Di1 Vi1 UP
xxxx.yyyy.zzzz VC: 8/35 UP
N/A 2968 xxxx.yyyy.zzzz ATM0/1/0 Di2 Vi2 UP
xxxx.yyyy.zzzz VC: 8/35 UP
Ici un miracle : les deux lignes sont actives.

Pour aller plus loin le suivi des accès est-il correct ?
#sh ip sla summary
IPSLAs Latest Operation Summary
Codes: * active, ^ inactive, ~ pending
ID Type Destination Stats Return Last
(ms) Code Run
-----------------------------------------------------------------------
*20 icmp-echo IPV4_ISP_ADSL1 TT=16 OK 0 seconds ago
*21 icmp-echo IPV4_ISP_ADSL2 TT=20 OK 55 seconds ago
Là encore tout se passe bien les deux lignes ADSL sont opérationnelles, du moins les adresses IPv4 des ISP répondent bien au ping.

Enfin vous pouvez vérifier si la mascarade est opérationnelle :
#sh ip nat statistics
Total active translations: 420 (1 static, 419 dynamic; 411 extended)
Peak translations: 11285, occurred 4w5d ago
...
Dynamic mappings:
-- Inside Source
[Id: 2] route-map ADSL1 interface Dialer1 refcount 1
[Id: 3] route-map ADSL2 interface Dialer2 refcount 0
Le <tt>refcount 1</tt> indique que la première ligne ADSL est utilisée même si elle n'est pas surchargée. Par contre le <tt>refcount 0</tt> montre le défaut d'équilibrage de charge.

== Conclusion ==

Les cartes ADSL2+ permettent d'obtenir de meilleurs débits. Avec quelques rapides mesures en utilisant <tt>ssh</tt> et <tt>dd</tt> les résultats suivants sont obtenus :
* ADSL "pro" : 1,1Mo/s descendant et 100Ko/s montant
* ADSL B.I.O. : 1,3Mo/s descendant et 130Ko/s montant

A noter que les débits "certifiés" pour la liaison B.I.O. ne sont absolument pas tenus. La société orange dirait probablement que les routeurs Cisco ne sont pas assez performants.

Le point négatif est tout de même l'impossibilité, à notre connaissance, d'arriver à effectuer de l'équilibrage de charge avec le dispositif PBR.

= Améliorations =

Plusieurs améliorations de notre configuration sont possibles :
* Mettre en place un routeur dédié : l'utilisation de PBR avec la limitation rencontrée sur l'équilibrage de charge peut être contourner en dédiant un routeur aux seules lignes ADSL. Dans ce cas PBR n'est plus nécessaire et le routage peut se faire comme pour le 2621 avec deux routes par défaut dans la table de routage principale.
* Passer sur une routeur plus récent : nous avons acheté un routeur Cisco 9300 avec un IOS plus récent permettant SLA, PBR et mascarade (cette dernière étant impossible sur un C9200), la limitation sur l'équlibrage de charge PBR de l'IOS 12.4 est peut-être levée ? Au pire le C9300 va remplacer le 2901 qui sera dédié aux lignes ADSL.
* Passer à une technologie de connexion plus récente : un travail de fourmies a été mené par la plateforme maths/info pour recenser les lignes de communication utilisées par Polytech'Lille, une bonne partie étant obsolètes il a été possible de négocier une mutation des lignes ADSL, Numéris, dédiées et SDSL pour se concentrer sur un accès fibre 200Mb/s symétrique.

IMA3/IMA4 2019/2021 P1

2021-01-08T00:31:02Z

Rex : /* Fichiers */

= Introduction =

L'idée était d'avoir un serveur de temps pour synchroniser l'heure sur les stations de travail sans avoir à se reposer sur un serveur NTP d'Internet.

Actuellement des systèmes embarqués sont vendus sur divers sites à bas prix. Ce matériel est désigné sous une appellation à rallonge : "Network Time Server NTP Time Server for GPS Beidou GLONASS Galileo QZSS Desktop Version". Son manuel le désigne sous la référence [[Media:FC-NTP-100.pdf|FC-NTP-100]].

A priori ce matériel arrive prêt à l'emploi mais sa configuration IP nécessite l'utilisation d'un logiciel windows donc graphique. C'est assez peu pratique quand vous le connectez sur un VLAN de serveurs sur lequel vous n'avez aucune station de travail et aucun serveur sous windows. La configuration du système embarqué s'est donc transformé en un exercice d'ingénierie inverse et de codage réseau.

= Matériel =

Le système embarqué est livré avec un adapteur secteur non française, de plus il est assez compliqué d'accumuler les adaptateurs dans une baie. Un boitier d'alimentation 12V a été acquis pour l'alimentation. Ce type de boitier est plutôt destiné à alimenter des caméras mais convient très bien pour le système embarqué NTP. Le boitier d'alimentation se compose d'un transformateur utilisable au travers de fusibles et de borniers. Pour le modèle acheté 4 borniers sont disponibles et se partagent les 5A de l'alimentation.

= Installation =

[[File:PLIL-FC-NTP-100.jpg|thumbs|200px|left]]

L'installation physique est assez triviale. Pour éviter de poser des éléments sur des tablettes dans la baie, l'alimentation et le système embarqué sont vissés sur le mur. Le cordon de l'alimentation a été récupéré et connecté aux borniers. Le système embarqué est relié à un commutateur via une jarretière RJ45. La LED du port du commutateur s'allume prouvant la présence d'une porteuse Ethernet. Par contre la commande ci-dessous montre qu'aucun paquet Ethernet n'est envoyé par le périphérique.
#show mac address-table interface gigabitEthernet 0/44
Mac Address Table
-------------------------------------------
Vlan Mac Address Type Ports
---- ----------- -------- -----
L'antenne est positionnée près d'une fenêtre. La longueur du câble est largement suffisante pour ce faire.
<br style="clear: both;"/>

= Configuration =

[[Fichier:Fc-ntp-100-p1.png|thumb|300px|right]]

C'est au niveau de la configuration que cela se corse.

Le système embarqué sort d'usine avec comme adresse IPv4 <tt>192.168.0.100</tt>. Pour changer cette adresse, une [[:File:NTPConfig_EN.zip|application]] windows est fournie.

Pas de port série sur la version bon marché du système embarqué NTP (FC-NTP-100). Une documentation fait état d'une autre version du système embarqué avec une connexion série bizarrement accessible sur une broche DB15.

Comme décrit dans l'introduction le but est d'écrire une application Linux texte avec les mêmes fonctionnalités que l'application graphique. Pour cela le principal est d'arriver à trouver le protocole utilisé par le périphérique.

= Ingénierie inverse =

C'est aussi simple que de lancer l'application windows sous <tt>wine</tt>, de lancer un <tt>tcpdump</tt> dans une console et de cliquer sur tous les boutons de l'application graphique.

Il est possible de compliquer un peu et de tenter une partie de l'ingénierie inverse sans le système embarqué en ligne. Dans ce cas ajouter une entrée dans la table ARP :
# arp -s 192.168.0.100 00:11:22:33:44:55
Après ça si vous appuyez sur le bouton <tt>NET Connect</tt> puis sur le bouton <tt>Query</tt>, la console vous indiquera :
# tcpdump -vvv -n -Xe host 192.168.0.100
19:46:37.410925 24:77:03:24:8e:30 > 00:11:22:33:44:55, ethertype IPv4 (0x0800), length 49: (tos 0x0, ttl 64, id 26566, offset 0, flags [none], proto UDP (17), length 35)
192.168.0.101.58025 > 192.168.0.100.23: [udp sum ok] UDP, length 7
0x0000: 4500 0023 67c6 0000 4011 90ea c0a8 0065 E..#g...@......e
0x0010: c0a8 0064 e2a9 0017 000f 12a7 2410 2a31 ...d........$.*1
0x0020: 300d 0a

Nous savons donc que la communication avec le périphérique se fait en UDP sur le port 23. Vérifions en changeant le filtre de <tt>tcpdump</tt> et en appuyant sur le bouton <tt>Search</tt> :
# tcpdump -vvv -n -Xe port 23
20:55:37.788646 24:77:03:24:8e:30 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 49: (tos 0x0, ttl 64, id 26376, offset 0, flags [none], proto UDP (17), length 35)
192.168.0.101.35413 > 255.255.255.255.23: [udp sum ok] UDP, length 7
0x0000: 4500 0023 6708 0000 4011 52b5 c0a8 0065 E..#g...@.R....e
0x0010: ffff ffff 8a55 0017 000f 19fd 241b 2a31 .....U......$.*1
0x0020: 420d 0a
Bien vu, la recherche du périphérique, si jamais son adresse IPv4 est inconnue, se fait avec une simple diffusion UDP encore sur le port 23.

Quelques essais supplémentaires en renseignant divers champs dans l'application graphique puis en appuyant sur les boutons <tt>Set</tt> correspondants (pour le type d'adresse IP, pour l'adresse IP et pour le masque réseau) :
# tcpdump -vvv -n -Xe port 23
21:44:26.529704 24:77:03:24:8e:30 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 50: (tos 0x0, ttl 64, id 6680, offset 0, flags [none], proto UDP (17), length 36)
192.168.0.101.35413 > 255.255.255.255.23: [udp sum ok] UDP, length 8
0x0000: 4500 0024 1a18 0000 4011 9fa4 c0a8 0065 E..$....@......e
0x0010: ffff ffff 8a55 0017 0010 52f0 2400 002a .....U....R.$..*
0x0020: 3030 0d0a 00..
21:44:40.843945 24:77:03:24:8e:30 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 53: (tos 0x0, ttl 64, id 7396, offset 0, flags [none], proto UDP (17), length 39)
192.168.0.101.35413 > 255.255.255.255.23: [udp sum ok] UDP, length 11
0x0000: 4500 0027 1ce4 0000 4011 9cd5 c0a8 0065 E..'....@......e
0x0010: ffff ffff 8a55 0017 0013 5703 2401 c0a8 .....U....W.$...
0x0020: 0064 2a30 440d 0a .d*0D..
21:44:49.432484 24:77:03:24:8e:30 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 53: (tos 0x0, ttl 64, id 8621, offset 0, flags [none], proto UDP (17), length 39)
192.168.0.101.35413 > 255.255.255.255.23: [udp sum ok] UDP, length 11
0x0000: 4500 0027 21ad 0000 4011 980c c0a8 0065 E..'!...@......e
0x0010: ffff ffff 8a55 0017 0013 181e 2402 ffff .....U......$...
0x0020: fff0 2a30 440d 0a

Pour pouvoir cerner le protocole il faut obtenir une réponse du périphérique. Là pas d'autre solution que de connecter le système embarqué NTP sur le même réseau que la station de travail.
Essayons de modifier le type de l'adresse IP, voila ce qui arrive sur la sortie standard de <tt>tcpdump</tt> :
# tcpdump -vvv -n -Xe port 23
22:21:39.072053 00:16:3e:aa:10:56 > d8:b0:4c:ff:01:76, ethertype IPv4 (0x0800), length 50: (tos 0x0, ttl 64, id 20379, offset 0, flags [DF], proto UDP (17), length 36)
172.26.189.7.42350 > 172.26.191.100.23: [bad udp cksum 0xd4c2 -> 0x2443!] UDP, length 8
0x0000: 4500 0024 4f9b 4000 4011 168d ac1a bd07 E..$O.@.@.......
0x0010: ac1a bf64 a56e 0017 0010 d4c2 2400 002a ...d.n......$..*
0x0020: 3030 0d0a 00..
22:21:39.097510 d8:b0:4c:ff:01:76 > 00:16:3e:aa:10:56, ethertype IPv4 (0x0800), length 47: (tos 0x0, ttl 255, id 42738, offset 0, flags [none], proto UDP (17), length 33)
172.26.191.100.23 > 172.26.189.7.42350: [udp sum ok] UDP, length 5
0x0000: 4500 0021 a6f2 0000 ff11 4038 ac1a bf64 E..!......@8...d
0x0010: ac1a bd07 0017 a56e 000d 57a0 2400 000d .......n..W.$...
0x0020: 0a

= Le protocole applicatif =

Regardons d'un peu plus près les données UDP envoyées par l'application. Déjà toutes ces données commencent par la valeur 0x25 soit le caractère <tt>$</tt>. L'octet suivant semble correspondre au type de données envoyées (0x00 pour le type d'adresse, 0x01 pour l'adresse IPv4, 0x02 pour le masque réseau, etc). Suivent les octets de données (1 octet pour le type, 4 octets pour l'adresse IPv4 et le masque réseau, etc). Suit un octet de séparation 0x2a soit le caractère <tt>*</tt>. Les deux derniers octets semble bien être un saut de ligne à la mode windows soit 0x0d et 0x0a (CR et LF). Restent les deux octets entre le caractère de séparation <tt>*</tt>. Sur les différents exemples ces deux octets semblent devoir être lus en ASCII et semblent être la représentation en hexadécimal d'un octet.

Après quelques essais et erreurs cet octet se révèle être une somme de contrôle basique sur les octets entre les caractères <tt>$</tt> et <tt>*</tt> non inclus. La somme est calculée par le simple opérateur ou exclusif bit à bit. Les différents essais ont été réalisés sur l'envoi de l'adresse IPv4 en commençant par mettre tous les bits à zéro (résultat <tt>00</tt>) puis en modifiant bit à bit le <tt>0.0.0.0</tt> initial.

Pour les demandes d'information le format semble être le même (voir le premier paquet des tests) mais sans octets de données et avec un code correspondant au type de l'information auquel on applique un ou bit à bit avec 0x10.

Donc pour les requêtes au périphérique le format est synthétisé dans les tableaux ci-dessous :

{| class="wikitable"
!colspan="10"|Modification de configuration
|-
| 1 octet
| 1 octet
| colspan="3" | n octet(s)
| 1 octet
| 2 octets
| 2 octets
|-
| '$'
| Type de configuration
| colspan="3"| Données
| '*'
| Somme de contrôle
| Saut de ligne
|-
| 0x24
| T
| colspan="3"| D1 ... Dn
| 0x2a
| T ^ D1 ^ ... ^ Dn
| 0x0d 0x0a
|-
|}

{| class="wikitable"
!colspan="7"|Lecture de configuration
|-
| 1 octet
| 1 octet
| 1 octet
| 2 octets
| 2 octets
|-
| '$'
| Type de configuration
| '*'
| Somme de contrôle
| Saut de ligne
|-
| 0x24
| T | 0x10
| 0x2a
| T | 0x10
| 0x0d 0x0a
|-
|}

Notons que ce protocole est loin d'être optimal :
* les caractères de séparation <tt>$</tt> et <tt>*</tt> sont loin d'être indispensables ;
* le saut de ligne final à la microsoft est totalement inutile ;
* l'envoi de la somme de contrôle en ASCII est une aberration ;
* la somme de contrôle pour la récupération d'information ne porte que sur un octet ...

Regardons les réponses du périphérique aux requêtes de l'application. En réponse à une modification le type de la configuration à modifier est retournée puis un octet à zéro. Il est possible que si un nombre non correct d'octets de données est envoyé le zéro se transforme en autre chose mais nous ne comptons pas faire d'erreur. En réponse à une lecture le type est retourné suivi des données mais cette fois pas de somme de contrôle. Probablement parce que s'il est indispensable de vérifier la configuration à appliquer, afficher une configuration erronée n'est pas trop grave.

La synthèse :

{| class="wikitable"
!colspan="5"|Réponse à une modification
|-
| 1 octet
| 1 octet
| 1 octet
| 2 octets
|-
| '$'
| Type de configuration
| Code réponse
| Saut de ligne
|-
| 0x24
| T
| R
| 0x0d 0x0a
|-
|}

{| class="wikitable"
!colspan="8"|Réponse à une lecture
|-
| 1 octet
| 1 octet
| colspan="3" | n octet(s)
| 2 octets
|-
| '$'
| Type de configuration
| colspan="3"| Données
| Saut de ligne
|-
| 0x24
| T
| colspan="3"| D1 ... Dn
| 0x0d 0x0a
|-
|}

Les types de configuration identifiées sont les suivantes :

{| class="wikitable"
! Code !! Type de configuration
|-
| 0x00 || Type d'IPv4 (statique ou dynamique)
|-
| 0x01 || Adresse IPv4
|-
| 0x02 || Masque réseau
|-
| 0x03 || Passerelle
|-
| 0x04 || Adresse Ethernet
|-
| 0x07 || Mode NTP (serveur ou diffusion)
|-
| 0x0a || Délai entre diffusion NTP
|-
| 0x0b || Recherche de périphérique
|-
|}

Le dernier code ne correspond pas à une configuration mais sert pour la recherche de périphérique. Il est inclus dans le tableau pour avoir une liste complète des codes.

A noter que certains codes non listés permettent d'obtenir une réponse du périphérique mais cette réponse contient des données à 0xff que nous n'avons pas réussi à identifier :
* le code 0x05 retourne 330 octets à la valeur 0xff ;
* le code 0x06 retourne 1 octet à la valeur 0xff ;
* les codes 0x08 et 0x09 retournent 4 octets à la valeur 0xff ;
* les codes 0x0c, 0x0d, 0x0e et 0x0f ne provoquent aucune réaction et ne doivent pas être implantés.

= Programmation =

Une fois le protocole applicatif trouvé, l'écriture du programme est une simple formalité. Le code est donné en fin de page.

Quatre fonctions implantent très classiquement l'aspect programmation réseau UDP :
* <tt>initialisationSocketUDP</tt> initialise la socket UDP ;
* <tt>libereSocketUDP</tt> libère la réservation mémoire effectuée par la fonction précédente ;
* <tt>boucleServeurUDP</tt> gère les paquets UDP envoyé par le périphérique ;
* <tt>messageUDP</tt> permet d'envoyer des paquets UDP.

Les deux fonctions suivantes permettent la manipulation des données UDP suivant le protocole découvert dans la section précédente :
* <tt>fabricationMessage</tt> assemble un message UDP ;
* <tt>lectureMessage</tt> scanne un message UDP.

Le programme principal tente de rendre le programme le plus ergonomique possible :
* l'utilisation d'une option inconnue permet d'afficher une rapide explication des options possibles ;
* si l'adresse IPv4 du périphérique n'est pas donnée en premier argument une recherche des périphériques est effectué par diffusion UDP, si une réponse est reçue l'adresse IPv4 inclue est utilisée comme adresse du périphérique ;
* si aucune option n'est spécifiée pour modifier une configuration, toutes les configurations connues sont demandées au périphérique et affichées.

Ainsi si le programme est lancé sans aucun paramètre, une découverte de périphérique est lancée et ses configurations sont affichées.

= Bonus =

[[File:plil-gps.png|thumbs|300px|right|xgps]]

Pour tester le bon fonctionnement du serveur NTP, il est possible d'installer le paquetage <tt>gpsd</tt>.

Il faut faire pointer vers votre serveur NTP dans le fichier <tt>/etc/default/gpsd</tt> :

# grep DEVICES /etc/default/gpsd
...
DEVICES="tcp://192.168.0.1000:4001"
...

Une fois le service relancé, utiliser le programme <tt>xgps</tt> du paquetage <tt>gpsd-clients</tt> pour afficher la constellation satellite.

A la droite de cette page vous voyez le résultat dans notre cas. Du coup vous avez la position précise de Polytech'Lille mais bon c'est moyennent secret.

<br style="clear: both;"/>

= Ressources =
* Page consacrée au FC-NTP-100 : [https://fc-ntp-100.toimii.fi/]
* Programme : [[Media:fcntp100.zip]]

IMA3/IMA4 2019/2021 P1

2021-01-08T00:28:25Z

Rex :

IMA3/IMA4 2019/2021 P1

2021-01-08T00:27:42Z

Rex : /* Bonus */

Fichier:Plil-gps.png

2021-01-08T00:27:20Z

Rex :