Discussion :

[rocky163]

Bonjour à tous,

J'effectue actuellement un stage, et un de mes premiers projets est de réaliser un serveur web embarqué sur un kit basé sur un F2 de chez ST : seulement voilà, je n'ai jamais vraiment touché à tout ça, malgrès que je sois en train de lire un livre "apprenez le fonctionnement des reseaux tcp/ip" d'eric lalitte

DONC j'aurai aimé que vous me donniez un peu les étapes à suivre, sachant qu'il n'y a encore rien qui est géré au niveau TCP/IP sur la carte, donc faudra que je rajoute la stack IP, etc... et que je rende fonctionnel le serveur web sur mon embarqué, sachant que le serveur web est déjà réalisé mais non débogué.

Merci d'avance pour votre aide !

Bien cordialement,
Sébastien.

[Bktero]

Salut,

Je ne sais pas combien de temps dure ton stage mais ça devrait déjà t'occuper longtemps ce premier projet

Tu as deux choses à faire en parallèle, qui à la fin se recouperont :

1. Faire fonctionner une stack TCP IP sur le micro. Quelle stack comptes-tu / es-tu obliger d'utiliser ? Il faut être capable de gérer des connexions entrantes, de recevoir des données et d'en-renvoyer. netcat (outil Linux) te sera très utile.
2. Comprendre le fonctionnement d'un serveur web. Un serveur web reçoit des commandes et y répond. Il faut que tu saches lesquelles et les réponses associées. Enfin, définir les commandes que ton serveur acceptera et celles qu'il refusera avec un message d'erreur.

Je pense que tu vois le lien entre les deux

[rocky163]

Bonsoir !

Déjà la stack IP est obligatoire : pour le reste j'en fais ce que je veux (j'étais parti sur IP TCP HTTP pour les couches réseau, transport et application, peut être une incompréhension de ma part?) : à ce que tu me dis, il faut faire un choix dans la stack à intégrer dans le micro ? je pensais qu'il fallait intégrer la stack IP pour la partie réseau, la stack TCP pour le transport et le HTTP pour la partie application ? (en rajoutant dans mon cas le driver PHY et la communication MII entre le MAC et le driver PHY).

Aussi, quand tu parles de faire fonctionner la stack TCP IP, tu veux dire pouvoir faire passer des trames toutes simples sur mon cable ethernet, et voir ce qu'il en sort genre avec wireshark ? (je n'arrive peut-être pas bien à visualiser tout ça).

Merci pour tous vos éclaircissements !!

Bien cordialement,
Sébastien.

[Bktero]

Quelle est la stack qui t'est imposée ?

J'ai par exemple bossé récemment avec la stack TCP/IP de Keil pour faire fonctionner des lib Java sur STM32F4 (Cortex M4). La stack gère juste l'envoi de data sous forme de tableaux et la réception sous la même forme. La couche client HTTP codée en Java par dessus se contente juste d'envoyer des tableaux avec un contenu spécial pour créer des requêtes HTTP. Ici, tu dois faire l'inverse : passer les données reçues à ton serveur qui est normalement déjà prêt pour les analyser. Ou alors faire une pré-analyse, faut regarder ce que ton serveur HTTP attend en entrée.

tu parles de faire fonctionner la stack TCP IP, tu veux dire pouvoir faire passer des trames toutes simples sur mon cable ethernet, et voir ce qu'il en sort genre avec wireshark ?

Oui c'est ça. Faire un simple accept(), puis un receive() puis un send(), en TCP "pur". Wireshark peut te servir mais plus pour le debug si ça ne marche pas. Pour les tests, netcat suffit. Ou alors quelques scripts en Python. Perso, j'utilise ces 3 outils.

[rocky163]

C'est la stack IP qui m'est imposée.

Je suis sur Windows 7, mais il doit bien y avoir une version netcat pour windows, non ?
Et je travaille sur une version d'eclipse pour la partie codage, pour plus d'informations.

Cordialement,
Sébastien.

[Bktero]

Tu as une stack juste IP ? Rien pour la partie TCP ?

Oui, ça doit exister, faut chercher. Sinon, une simple VM VirtualBox correctement configurée fait l'affaire, expérience à l'appui. Ou encore de bêtes scripts Python.

Et je travaille sur une version d'eclipse pour la partie codage, pour plus d'informations.

Avec gcc-arm-none-eabi ?

[rocky163]

Avec ceux-ci,qu'en est-il des stack UDP et ICMP ? parce que j'ai vu par exemple qu'en situation de réception de données, une couche IP pouvait envoyer une trame ICMP si un problème apparaissait.

Alors, pour éclaircir un peu aussi dans ma petite tête, j'aimerai juste expliciter quelques actions :
Mon F2 possède une couche MAC mais pas de couche PHY ; Il lui faudra alors un driver ethernet (le fameux driver PHY), de même que ce driver servira à porter la stack IP sur le micro. Donc faut que je crée ces fameux fichiers qui permettront de faire le lien entre la stack IP et le contrôleur ethernet sur mon F2 c'est ça ?

J'ai aussi entendu parlé du protocole MDIO qui s'occupe des registres de la PHY : il faudrait aussi le prendre en compte, non ?

Pour répondre à ta question concernant le compilateur, oui j'utilise bien gcc-arm-none-eabi !

Et pas grand chose pour la partie TCP, à part biensûr des fichiers avec quelques fonctions pour gérer cette stack ! mais je veux dire qu'il n'a pas été explicité de la part de mon référent autres choses que la stack IP à intégrer et à associer au driver PHY !
Après il est sûr que cela reste logique quant à l'intégration de la stack TCP...

Merci !!

Cordialement,
Sébastien.

[boboss123]

Hello,

Tu n'as pas répondu à la question la plus importante de Bktero à savoir

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Quelle est la stack qui t'est imposée ?

=> c'est une stack fabriquée "maison" ou autre ? le nom ?
=> pourquoi on t'impose la stack IP ? ça serait quand même beaucoup plus simple de partir sur une stack gratuite comprenant toutes les couches dont tu as besoin... à toi d'analyser si le choix d'imposer la stack IP est pertinent : si le choix n'est pas pertinent, tu pourrais très bien en parler à ton tuteur et proposer une autre stack (justifier que tu gagneras en temps de développement/couts, ...)


Normalement les protocoles ICMP et IP sont fournis ensembles car ils sont indissociables l'un de l'autre : IP à besoin d'avoir une table de correspondance "adresse MAC/adresse IP" pour se connecter à une machine distante et c'est le protocole ICMP qui te permet de l'avoir.

MDIO n'est pas un protocole : c'est le nom d'une des 2 lignes du bus SMI qui permet de faire communiquer PHY/MAC/CPU.

Le PHY gère la couche PHYSIQUE du transport. Parmi ses fonctions, il y a la gestion de l'auto-negociation (le débit et le mode duplex) et du MDI. En général, il n'y a même pas besoin d'aller configurer les registres du PHY car par défaut l'auto-négociation est activée. L'un des seuls intérêts d'aller configurer le PHY est d'avoir la possibilité de pouvoir forcer son fonctionnement dans un mode donné (ex : 10Mb/Half-duplex, MDI-X).
Le MAC à besoin de savoir dans quel mode se mettre (débit/duplex) et pour cela, il faut qu'il récupère ces informations sur le PHY : soit le MAC est intelligent et il a son bus SMI qui est relié a celui du PHY (le MAC va rechercher les informations tout seul), soit il faut aller lire manuellement la configuration du PHY pour pouvoir aller configurer le MAC.

Pour debugger la partie driver, je te conseille de commencer par développer un truc simple : un serveur Telnet basique => c'est juste un socket TCP ouvert sur le port 23. Tu pourras ainsi facilement te copnnecter à ton système en utilisant un simple client Telnet.

Par contre ce qui m’étonne, c'est qu'on te demande dans un premier stage sur l'Ethernet de travailler sur la partie bas niveau (driver/protocoles couches 1-3) et la partie haut niveau (HTTP). Si vraiment tu parts de pas grand chose, s’arrêter à la couche UDP/TCP aurait déjà été pas mal.
=> tu as beaucoup de temps ?

[rocky163]

Salut salut !

Désolé, alors oui la stack IP est fabriquée maison !
En faites les fonctions d'intégration des autres stacks sont plus ou moins déjà présentes ! il faut que je vérifie s'il n'y a pas d'erreurs et s'il manque des choses.

En faites je suis en alternance, j'ai utilisé le mot "stage" pour faire court on va dire ! Et je suis là jusqu'à septembre prochain ! mais normalement il faudrait que je finisse cette partie avant échéance pour que je puisse bosser sur un autre projet qui me plait aussi !

Et oui, ce projet est très complet, mais je suis prêt à bosser chez moi pour avancer rapidement et justement !

Aussi, penses-tu qu'il faudrait que j'installe la machine virtuelle debian pour pouvoir faciliter mes tests et mon projet ? ou je peux rester sur windows ?


Merci beaucoup !


Cordialement,
Sébastien.

[boboss123]

Aussi, penses-tu qu'il faudrait que j'installe la machine virtuelle debian pour pouvoir faciliter mes tests et mon projet ? ou je peux rester sur windows ?

A toi de voir : mesure les pour et les contres
=> attention, si tu utilises une MV, il y aura forcement une passerelle réseau à configurer entre windows 7 et ta MV pour faire communiquer ta MV vers l’extérieur : ça pourrait poser problème.

PS : j'ai l'impression que la définition de ton projet n'est pas bien définie, je te conseille de faire un état des lieux (connaissances acquises, outils disponibles, ...), de lister ce qu'il reste à faire (sur quelles solutions tu vas partir et avec quels outils => un petit planning peut aider sur ton organisation) et de procéder par étape.
Essaies de tout rationaliser : problème, état des lieux, hypothèses, choix, justification, test, résultats, synthèse

[rocky163]

Okey, merci du conseil !

Je fais ça, et dans la foulée je teste pour un serveur telnet comme tu me l'as conseillé, et je reviendrai ce soir pour rapporter ce qu'il en est, cela vous va-t-il ?

Merci beaucoup et bonne journée !


Cordialement,
Sébastien.

[rocky163]

Bonsoir à tous !

Alors aujourd'hui j'ai eu un problème de compilation qui m'a pris une bonne partie de la journée, mais j'ai quand même pu avancer dans mon projet !
Donc j'ai fouillé un peu dans les docs de chez ST et j'ai trouvé des routines qui permettent d'initialiser la couche PHY et le MAC/PHY pour ethernet, et donc la communication ethernet est OK. (je suis passé pour cela par la création d'un socket simple lié au buffer RxTx).
=> J'ai vérifié tout cela avec wireshark.

Aussi, ce que j'ai commencé à faire c'est la création de sockets pour TCP, ICP, ICMP et UDP !

A mon avis je devrais commencer par la stack ICMP, qui est la plus simple car il suffit de pinguer ma carte.
Ensuite la stack IP, puis la TCP !

Peut être vais-je encore trop vite ?

Par contre à ce jour je ne vois pas vraiment comment vais-je relier les stacks plus tard (etant donné qu'ils se valident individuellement) afin que, par exemple si je veux envoyer un message, celui-ci s'agrémente de "chaque entête de chaque protocole" pour ensuite etre envoyé puis recu.

De plus, je ne comprends pas ce que boboss123 veut dire quand il dit "aller lire manuellement la configuration du PHY pour pouvoir aller configurer le MAC." stp ?

Merci pour toute votre attention et toute votre aide !


Cordialement,
Sébastien.

[mith06]

Par contre à ce jour je ne vois pas vraiment comment vais-je relier les stacks plus tard (etant donné qu'ils se valident individuellement) afin que, par exemple si je veux envoyer un message, celui-ci s'agrémente de "chaque entête de chaque protocole" pour ensuite etre envoyé puis recu.

Le plus simple sera de passer les paquets d'une couche vers une autre par copie. Ça permet de bien compartimenter les couches. Mais c'est aussi le moins performant car tu crames des cycle CPU à recopier des octets d'un endroit de la mémoire vers un autre.

Le plus élégant mais aussi le plus compliqué est de faire passer les paquets par référence. C'est très efficaces mais plus difficile à mettre en place car les couches sont beaucoup moins indépendantes.

[boboss123]

De plus, je ne comprends pas ce que boboss123 veut dire quand il dit "aller lire manuellement la configuration du PHY pour pouvoir aller configurer le MAC." stp ?

Ce que je veux dire, c'est que le PHY via l'auto-neogiaciation, va négocié avec le produit distant un mode de fonctionnement (ex: 100Mb/full-duplex), il faut alors que ta stack/driver aille lire dans le PHY pour voir dans quel mode il s'est configuré puis aller configurer le MAC dans le même mode.
=> certains composants MAC reliés à un PHY via un bus SMI vont lire tout seul ces informations et se mettent à jour automatiquement.

Le plus simple sera de passer les paquets d'une couche vers une autre par copie. Ça permet de bien compartimenter les couches. Mais c'est aussi le moins performant car tu crames des cycle CPU à recopier des octets d'un endroit de la mémoire vers un autre.

Perso j'éviterais cette méthode, le baisse de performance doit être énorme (ex: pour le traitement d'un paquet HTTP, on a comme couches MAC => IP => TCP => HTTP, ce qui fait 3 recopie de buffer )

Par contre à ce jour je ne vois pas vraiment comment vais-je relier les stacks plus tard (etant donné qu'ils se valident individuellement) afin que, par exemple si je veux envoyer un message, celui-ci s'agrémente de "chaque entête de chaque protocole" pour ensuite etre envoyé puis recu.

Il faut voir ce que chaque couches à besoin comme informations de la couche inférieure pour fonctionner et voir si les fonctions de la couche inférieure peuvent fournir ces informations => il est possible que tes différentes stack soient incompatibles.
Dans chaque couche, il doit y avoir une fonction à définir pour communiquer avec la couche inférieure : tu les as identifiées ?
=> Pour la partie réception, en général ce genre de fonctions à besoin en entrée d'une structure contenant des informations de la couches inférieure et un pointeur sur les données qu'il reste à traiter

[rocky163]

Bonsoir à tous !

D'abord merci pour toutes vos réponses !

Alors aujourd'hui rebelote, j'ai été bloqué sur un problème de linker, mais maintenant tout va bien.

Déjà à propos des config du MAC, dans ma doc technique il est écrit :
"The Ethernet peripheral also includes an SMI to communicate with external PHY. A set of configuration registers permit the user to select the desired mode and features for the MAC and the DMA controller."
=> Donc le MAC récupère bien automatiquement les config de la PHY vu qu'il y est relié, non ? (au moyen des signaux MDC et MIO de ce fameux bus SMI qui correspondent resp. à la clock et l'I/O data).

Concernant la communication entre les couches, j'ai fouillé et trouvé des routines qui apparemment permettent de preparer l'en-tête , par exemple pour preparer l'en tete ethernet pour la réponse, donc je pense que ce sont là les fonctions dont tu me parlait boboss123 ! je vérifierais bien tout ça demain. Quand tu me dis de communiquer avec la couche inférieure, c'est respectivement la couche supérieure ? (histoire d'être bien clair meme si ce que je dis là est un peu bete).

Ensuite, concernant l'adressage IP, il faudra bien donner au socket TCP, à la stack IP et aux en-têtes respectives une adresse IP qui sera celle du micro, non ? parce que dans ce cas je ne vois que l'allocation par serveur DHCP, mais il faudra une fixe. (j'ai peut etre pas bien regardé/réfléchi vous allez me dire ...)

Par contre, question sûrement très bête : il faut bien 2 sockets par couche : un SCK client ET un SCK serveur ?
J'ai pensé pour valider un peu les couches après, d'utiliser un protocole des STM32 qui est le protocole echo utile pour les tests de connexion client/serveur, qu'en pensez-vous ?

Merci de votre patience, et de vos réponses !!

Dans l'attente de vous lire,


Cordialement,
Sébastien.

[boboss123]

Déjà à propos des config du MAC, dans ma doc technique il est écrit :
"The Ethernet peripheral also includes an SMI to communicate with external PHY. A set of configuration registers permit the user to select the desired mode and features for the MAC and the DMA controller."
=> Donc le MAC récupère bien automatiquement les config de la PHY vu qu'il y est relié, non ? (au moyen des signaux MDC et MIO de ce fameux bus SMI qui correspondent resp. à la clock et l'I/O data).

A priori la réponse est oui (il faut bien sure que sur ta car le bus SMI soit relié entre le PHY et le MAC. Et normalement tu devrais avoir un autre bus SMI en le MAC et le CPU).

Quand tu me dis de communiquer avec la couche inférieure, c'est respectivement la couche supérieure ? (histoire d'être bien clair meme si ce que je dis là est un peu bete).

Quand un paquet est reçu, la couche MAC recupère les adresses MAC source/destination et les met dans une structure qui normalement devrait être passé à la couche supérieure (IP ou autre en fonction de l'EtherType) avec un pointeur sur le buffer des données restant a traiter, ensuite la couche IP récupérè les adresse IP qu'elle passe à la couche suivante en paramètre et ainsi de suite....

Ensuite, concernant l'adressage IP, il faudra bien donner au socket TCP, à la stack IP et aux en-têtes respectives une adresse IP qui sera celle du micro, non ? parce que dans ce cas je ne vois que l'allocation par serveur DHCP, mais il faudra une fixe. (j'ai peut etre pas bien regardé/réfléchi vous allez me dire ...)

A l'allumage tu dois definir à quelque par une adresse IP fixe par défaut en attendant que le DHCP récupère une adresse (en général, on utilise l'adresse IP 192.168.1.1).

Par contre, question sûrement très bête : il faut bien 2 sockets par couche : un SCK client ET un SCK serveur ?

ça depend du protocole utilisé : certains protocoles sont unidirectionnels et tu peux etre client ou serveur (des clients peuvent communiquer entre eux et des serveurs aussi => flux multicasts)
=> un socket client peut être un socket de réception ou d’émission selon si ton module est en fonctionnement serveur ou client.

J'ai pensé pour valider un peu les couches après, d'utiliser un protocole des STM32 qui est le protocole echo utile pour les tests de connexion client/serveur, qu'en pensez-vous ?

Un socket Telnet comme je l'avais dit précédemment me semble une bonne solution (ça permet de tester les couches MAC/IP/TCP) => tu renvoies les données reçu comme ça dans ton client Telent (qui est executé sur ton PC), quand tu taperas une touche, elle devrait apparaitre en double.
Avant de valider la partie émission, tu peux valider la partie réception uniquement en redirigeant les données reçues vers le port série de ta carte (le logiciel Hyperterminal permet de lire/écrire sur le port série de ton PC)

[rocky163]

Bonjour à tous !! et bonjour boboss123 !!

D'abord désolé du retard de ma réponse ici présente.

Pour répondre à tes propos, je suis toujours en train d'implémenter les stacks ; mais pour etre sûr d'avoir bien compris quelques trucs, j'aimerai savoir :

- tu me dis que lorsqu'une trame ethernet est reçue, elle est mise dans une structure aux normes de la couche supérieure avec un pointeur sur le buffer des données restantes à traiter ; mais si on est en mode client, donc en mode émission, comme on "encapsule" à chaque fois, comment cela va-t-il fonctionner s'il te plait ? (j'ai mon idée qui je pense est bonne mais je préfère avoir un avis de quelqu'un qui a de l'expérience dans le domaine ! )

- ensuite, tu me parles de l'adresse IP 192.168.1.1 à donner au démarrage : donc je pose cet IP en tant qu'IP source dans un ARP gratuit pour vérifier que personne ne l'a déjà, puis je fais une requete ARP simple avec cet IP 192.168.1.1 pour avoir l'adresse MAC de mon micro ?
(je pense que c'est la vision d'un micro sans couche IP et MAC qui fait que je mélange un peu tout ça...).

- J'aurai besoin d'un petit éclaircissement aussi sur la facon d'encapsuler la trame UDP dans un datagramme IP, puis le datagramme IP dans une trame ethernet ; je comprends très bien comment ça marche mais j'arrive pas à visualiser tout ça d'un point de vue du code à proprement dit en faites... j'ai pourtant cherché sur le net histoire de me débloquer là-dessus mais en vain... ça doit être tout con, mais je n'arrive pas encore à le visualiser d'un point de vue des lignes de code... (ce qui je pense se réfère aux systèmes de structures et de pointeurs sur buffers dans le cas d'une réception serveur).

- j'ajouterai juste : il n'y a pas d'autres façons à ce que mon micro ait une adresse IP ? mis a part la facon dynamique du DHCP et la facon manuelle je veux dire... (si non, alors je travaillerai avec le 192.168.1.1 jusqu'à ce que j'appréhende les services et les applicatifs, que je pense aborder après avoir validé toutes les couches...)

- (ah et étant donné que j'ai déjà fait mon programme d'ARP gratuit, en créant un buffer ARP type que j'ai envoyé sur la couche PHY, il me semble bien avoir vu qu'un serveur DHCP m'a répondu et donné un IP : donc cela voudrait dire que la carte réseau de mon ordi est configurée pour aller chercher automatiquement un IP ? est-ce possible ? ( je retesterai tout ça demain...) )


En tout cas encore merci pour toutes vos aides !!!! Et désolé pour toutes les bêtises que j'ai pu dire jusque là qui enrageraient plus d'un je pense !!!


Bien à vous,

Sébastien.

[boboss123]

Salut,

- tu me dis que lorsqu'une trame ethernet est reçue, elle est mise dans une structure aux normes de la couche supérieure avec un pointeur sur le buffer des données restantes à traiter ; mais si on est en mode client, donc en mode émission, comme on "encapsule" à chaque fois, comment cela va-t-il fonctionner s'il te plait ? (j'ai mon idée qui je pense est bonne mais je préfère avoir un avis de quelqu'un qui a de l'expérience dans le domaine ! )

Pour l’émission c'est plus compliqué car il faut gérer les CRC de certaines couches. Le CRC TCP doit être calculé avant le CRC IP car vu que le champ CRC TCP est à l’intérieur de la couche IP, celui-ci à une influence sur le calcul du CRC de la couche IP. Tu peux générer ton paquet dans l'ordre des couches de la plus basse vers la plus haute mais il faut alors à la fin du processus, reparcourir le contenu du paquet pour calculer les CRC (en commençant par la couche la plus haute). Autrement, il faut remplir de la couche la plus haute vers la plus basse mais il faut identifier au départ du processus l'adresse de début de chaque couches.
=> la première méthode me semble meilleure car plus modulaire (on peut plus facilement rajouter une nouvelle couche entre deux couches => ex: gestion de VLANs).

- ensuite, tu me parles de l'adresse IP 192.168.1.1 à donner au démarrage : donc je pose cet IP en tant qu'IP source dans un ARP gratuit pour vérifier que personne ne l'a déjà, puis je fais une requete ARP simple avec cet IP 192.168.1.1 pour avoir l'adresse MAC de mon micro ?
(je pense que c'est la vision d'un micro sans couche IP et MAC qui fait que je mélange un peu tout ça...).

Oui tu peux vérifier que l'adresse n'est pas déjà prise: il existe des protocoles comme autoIP pour gérer l'adresse IP lorsqu'il n'y a pas de serveur DHCP mais le problème est qu'après, tu ne connaitras pas l'adresse IP par défaut du produit vu qu'elle n'est pas fixe.
=> à toi de voir quel est pour toi le meilleur comportement (perso, je préfère avoir une adresse IP par défaut fixe).

- J'aurai besoin d'un petit éclaircissement aussi sur la facon d'encapsuler la trame UDP dans un datagramme IP, puis le datagramme IP dans une trame ethernet ; je comprends très bien comment ça marche mais j'arrive pas à visualiser tout ça d'un point de vue du code à proprement dit en faites... j'ai pourtant cherché sur le net histoire de me débloquer là-dessus mais en vain... ça doit être tout con, mais je n'arrive pas encore à le visualiser d'un point de vue des lignes de code... (ce qui je pense se réfère aux systèmes de structures et de pointeurs sur buffers dans le cas d'une réception serveur).

ça depend de la structure de tes Stack, c'est elles qui vont t'imposer comment remplir les champs. Attention, pour la lecture/ecriture des paquets, je t'ai décrit ce qui semble pour moi la meilleure méthode, mais peut être que tes stacks ne font pas de la même façon (ex: copie de buffers au lieu de gestion de pointeurs).
Pour voir comment est constitué un paquet, tu peux utiliser le sniffer wireshark.

[rocky163]

Bonjour à tous !

Merci pour tes réponses boboss123 !

En faites j'ai fouillé un peu dans les docs et apparemment j'ai des adresses MAC/PHY fixe par défaut........... rahlala tete en l'air que je suis !!!
Sur wireshark apparemment il il n'y a pas de réponses quand j'envois mon code ARP gratuit, mais la requete a bien été envoyée : donc je pense que c'est parce qu'il faut mettre à jour la table CAM de l'ARP, non ?

Dit moi juste, l'ordre de validation des couches en partant de la couche basse vers la couche haute serait laquelle pour toi ? pour moi c'est couche ethernet en envoyant une trame ethernet simple sur la PHY, ensuite couche IP, puis couche ICMP, puis couche UDP, puis TCP en se calant sur Telnet et enfin les autres types de services.

cordialement,
Sébastien.

[boboss123]

regardes la définition de ARP et ICMP sous wikipedia, ça devrait répondre à ta question