SE4 2022/2023 EC3

Objectifs

Il vous est demandé de :

• concevoir et réaliser un projet LUFA sur la base de la démonstration bas-niveau RNDIS ;
• la cible est l'ATMega8u2ATMega16u2 d'un Arduino Uno R3 ;
• d'intégrer dans le projet LUFA une micro-pile TCP/IPv4 comportant de réduire la pile TCP/IP du projet LUFA à une micro-pile permettant  :
  • la gestion des requêtes et des questions ARP,
  • la gestion des paquets IPv4, en particulier avec les calculs de sommes de contrôle,
  • la gestion des paquets ICMP de type requête et réponse d'écho,
• vous testerez votre projets LUFA à partir d'une machine Linux en lançant un ping sur l'adresse IPv4 de l'Arduino UNO ;
• pour rendre le test plus visuel vous utilisez les deux LED TX et RX commandées par l'ATMega8u2ATMega16u2 :
  • une LED pour indiquer la réception de paquets IPv4 destinés à l'ATMega8u2ATMega16u2 ;
  • une LED pour toute requête d'écho destinée à l'ATMega8u2ATMega16u2.

Matériel nécessaire

Le seul matériel nécessaire est un Arduino Uno Rev3.

Travail réalisé

Semaine 1

• Recherche d'un Arduino Uno Rev3.
• Activation de RNDIS sur Ubuntu 20.04.
• Tentative de compréhension de la démo RNDISEthernet dans LUFA.
• Modification du Makefile du programme de démonstration pour l'adapter au matériel.
• Passage de l'Arduino en mode DFU (en connectant la broche RESET de l'ATmega16u2 à la masse).
• Premier téléversement du programme de démonstration RNDISEthernet (problème de compatibilité avec l'ATmega16u2, qui ne semble pas faire partie des microcontrôleurs compatible) avec dfu-programmer, puis rétablissement du firmware d'origine.
• Recherches sur uIP, pour savoir s'il possible de l'implémenter dans mon cas.

ReX : L'exemple RNDIS de la LUFA est bien plus complet que prévu, en particulier une pile TCP/IP est déjà implantée dans le sous-répertoire Lib.

ReX : Effectivement l'exemple complet ne peut pas tourner sur un ATMega16u2, rien que la variable globale utilisée pour un paquet Ethernet fait 1500 octets (un ATMega16u2 n'a que 2K de mémoire).

ReX : Votre sujet est modifié en conséquence.

• D'après la documentation Arduino et la documentation de chez Microchip, l'ATmega16u2 ne possède même que 512B de mémoire SRAM, cela ajoute-t-il de nouvelles contraintes ?
• Un projet surprenant qui pourrait peut-être m'aider.

ReX : Oui, cela ajoute environ 4 fois plus de contraintes ... mais cela reste faisable sous certaines conditions que je vous laisse expliciter.

ReX : Le projet pointé est amusant mais vous n'avez pas à implanter UDP ou TCP, donc je ne suis pas sûr que ce soit une bonne piste.

• Analyse des différents programmes pour trouver ce qui peut être supprimé dans RNDISEthernet, pour ne conserver que l'essentiel.

Fonctionnement à implémenter

1	Linux (ping) → ARP - IPv4 - Ethernet par USB (RNDIS) → ATmega16u2 → RX
2	ATmega16u2 → ARP (avec adresse MAC) - IPv4 - Ethernet par USB → Linux
3	Linux → ICMP (requête) - IPv4 - Ethernet par USB → ATmega16u2
4	ATmega16u2 → RX & TX
5	ATmega16u2 → ICMP (réponse d'écho) - IPv4 - Ethernet par USB → Linux

Semaine 2

• Première tentative de réduction de la pile TCP/IP vers une micro-pile (peu fructueuse pour le moment).
• L'ensemble compile (après avoir supprimé la gestion de TCP, UDP, DHCP et Webserver), cependant l'exécutable généré requiert 626.8% de la SRAM disponible.
• Ethernet devrait pouvoir être optimisable (principalement au vu de la variable globale pesant 1500 octets de base).
• En passant de 1500 à 100 octets la constante globale ETHERNET_FRAME_SIZE_MAX, cela réduit la consommation de RAM à 409B, ce qui permet de pouvoir téléverser le programme, pour faire les premiers tests tout en laissant une certaine marge.
• L'Arduino apparait maintenant sous le nom : Atmel Corp. LUFA RNDIS Demo Application lors d'un lsusb.
• En tapant la commande ip a, une nouvelle interface réseau apparait sous le nom usb0.
• Il suffit maintenant d'attribuer une adresse IP avec la commande sudo ip addr add 192.168.42.42/24 dev usb0.
• La commande ping 192.168.42.42 fonctionne, la réponse d'écho est bien reçue.

ReX : Oui c'est le PC qui répond pas le microcontrôleur.

• Effectivement, cela se voit rien qu'au temps de réponse au ping, l'adresse IP est attribuée à l'interface réseau usb0 de l'ordinateur.

ReX : Voila, maintenant trouvez, dans le code du projet LUFA, quelle adresse IPv4 est assignée au microcontrôleur et lancez un ping sur cette adresse.

ReX : Indice : et si vous lisiez la documentation RNDISEthernet.txt ?

• Merci pour l'indication, étant donné que je me servais de la version la plus récente disponible sut Github, cela n'était pas indiqué dans la documentation.

ReX : Je veux bien que tu partes de cette version mais elle ne comporte pas de pile TCP/IP, ça va être plus difficile (sujet originel).

• Il semblerait que la connexion en réseau entre l'ATmega16u2 et l'ordinateur sous Linux n'est pas encore parfaitement fonctionnelle (un message d'erreur indique en permanence : Connection failed Activation of network connection failed), il faut que je trouve d'où vient l'erreur.

ReX : Tu peux utiliser des outils graphiques pour configurer ton réseau mais ce sera sans moi.

• J'avais oublié de désactiver le DHCP sur mon ordinateur, je me suis attribué l'adresse IP 10.0.0.1.
• En prenant soin de me déconnecter des autres réseaux, j'ai tenté un ping 10.0.0.2 avec succès, et cette fois avec un temps de réponse qui semble cohérent (de l'ordre de 1ms).

ReX : Bien ! Fait une capture des paquets réseau avec wireshark sur usb0 pour être sûr.

• Il me faut maintenant implémenter le clignotement des LEDs, permettant de confirmer la réception du signal.
• Vérification en me servant de Wireshark montrant l'enchaînement requête puis réponse d'écho avec le protocole ICMP lors d'un ping, avec régulièrement des requêtes ARP (et MDNS, uniquement émises depuis mon ordinateur).

ReX : :) une copie écran de wireshark SVP ?

• L'adresse MAC obtenue en réponse à la requête ARP (00:01:00:01:00:01) correspond à celle décrite dans le fichier AppConfig.h.

Capture d'écran vidéo d'un test avec Wireshark

Capture d'écran de trames sur Wireshark du test effectué

ReX : La vidéo de gauche n'est pas visible.

• PS: j'ai oublié de préciser que je suis passé sur la version de LUFA dont on s'était servi au S7 (210130) lorsque je me suis rendu compte du problème.
• Ajout du clignotement de la LED TX lors de la réception d'une requête d'écho.
• Ajout du clignotement de la LED RX lors de la réception d'une requête ARP (je me suis permis d'adapter le sujet pour rendre l'identification visuelle plus claire).

Test du clignotement des LEDs RX et TX

• Dans cette vidéo, RX est la LED de droite et TX celle de gauche.
• La LED RX clignote avant de lancer la commande ping, car deux requêtes ARP sont diffusées par l'ordinateur lors de la connexion en USB. C'est un phénomène qui n'était pas présent lors de mes précédents tests, tout comme l'envoi de requêtes IPv4 et IGMPv3 par mon ordinateur.
• La LED TX clignote correctement lors de la réception de requêtes d'écho.

ReX : Je n'arrive pas à voir le clignotement sur la vidéo, il semble qu'il y ait 5s figées sur la vidéo.

• Étrange, les deux vidéos fonctionnent correctement de mon côté.
• J'ai tout de même supprimé la vidéo de gauche droite, étant redondante avec celle de droite gauche, je l'avais mise pour montrer l'apparition de l'interface usb0 sur Wireshark, lors de la connexion de l'Arduino à l'ordinateur.
• Je vais compresser et raccourcir la seconde vidéo non fonctionnelle, en espérant que cela corrige le souci.
• Je viens d'effectuer la modification, j'espère que la vidéo fonctionne correctement maintenant. Sinon je peux toujours vous l'envoyer par mail.

ReX : La vidéo de test des LEDs fonctionne mieux en mode compressé, pas besoin de haute définition pour voir une LED clignoter. Par contre la vidéo sur wireshark .mkv n'est toujours pas visualisable, à convertir en .mp4.

• Passage de la vidéo .mkv en .mp4.

Documents Rendus

• Voici le projet LUFA fonctionnel : Fichier:EC3 RNDIS.zip.

ReX : Je testerais le code quand j'en aurais l'occasion.

ReX : Code testé sur la carte keylogger (partie ATMega16u2), fonctionne à 8Mhz, pas de LED, il faudrait redéfinir une "BOARD".

• Pour ne plus avoir le WARNING lors de la compilation, il faut passer la valeur de la ETHERNET_FRAME_SIZE_MAX à 100 à la place de 1500, à la ligne 176 du fichier LUFA/Drivers/USB/Class/Common/RNDISClassCommon.h.
• Le code permettant de faire clignoter la LED TX se situe lignes 76 à 78 du fichier IP.c, situé dans le dossier Lib.

ReX : Oui mais ça prend tous les ICMP, plutôt à mettre dans ICMP.c dans l'alternative sur la requête d'écho.

ReX : De plus mettre un délai pour éteindre la LED est assez peu efficace. Eteindre dans Ethernet.c lors de la réception d'un paquet.

• Le code permettant de faire clignoter la LED RX se situe lignes 87 à 89 du fichier Ethernet.c, situé dans le dossier Lib lui aussi.

ReX : OK pour allumer la LED à cet endroit mais supprimer le délai et éteindre comme pour l'autre LED.

• L'état initial des LEDs est configuré ligne 283 du fichier EC3_RNDIS.c, situé à la racine du projet.

ReX : Très bien.

• Ayant testé le programme en éteignant les LEDs lors de la réception d'un paquet, sans rajouter de délai, cela ne laissait pas assez de temps pour apercevoir le clignotement.
• Je me suis donc permis d'adapter le fonctionnement en changeant l'état de la LED RX lors de la réception d'une requête ARP, idem pour la LED TX lors de la réception d'un message d'écho. Cela évite d'avoir à rajouter un délai.

ReX : Bonne idée mais utilise plutôt LEDs_ToggleLEDs plutôt que ton code qui fait la même chose mais en plus de lignes.

• J'ai donc supprimé le fait d'éteindre les LEDs lors de la réception d'un nouveau paquet dans le fichier EC3_RNDIS.c.
• J'ai aussi corrigé l'emplacement du code pour faire clignoter la LED TX, je l'ai posé lignes 76 à 79 du fichier ICMP.c, dans le dossier Lib.

ReX : Oui c'est bien.

• Téléversement du projet contenant les fichiers modifiés.
• Utilisation de la fonction LEDs_ToggleLEDs à la place de mon code.