Communication Ethernet via un switch sans protocole TCP/IP

Communication Ethernet via un switch sans protocole TCP/IP - Nano-ordinateur, microcontrôleurs, FPGA - Electronique, domotique, DIY

Marsh Posté le 17-06-2016 à 16:56:26    

Bonjour,  
 
Je voudrais établir une communication au niveau 2 (Couche MAC) sans protocole TCP/IP ou autre, entre plusieurs cartes embarquées via un switch Cisco SF220 Smart Plus 24 ports et ce pour des raisons particulières.
 
Dans un premier temps, je lie les deux cartes directement par un cable Ethernet et j'envoie un paquet sans utiliser de protocole sous le format suivant : [@Destination | @Source | @Ethertype=Taille des donnèes | DATA], de l'autre coté je reçois bien mes données tout marche parfaitement. Mais le problème arrive quand j'introduis mon switch : je ne reçois aucun paquet et la table d'adresse MAC ne se construit pas dans le switch. Je précise que j'ai établi cette communication via le switch en utilisant le protocole TCP/IP en affectant des adresses IP à mes cartes et ça a marché.
 
J'ai beau chercher la source du problème mais en vain.  
Est-ce que quelqu'un sait si on peut faire une communication au niveau de la couche 2 sans utiliser de protocole à travers un switch.
 
Merci d'avance.


---------------
MM
Reply

Marsh Posté le 17-06-2016 à 16:56:26   

Reply

Marsh Posté le 21-06-2016 à 23:17:52    

Oui, normalement rien ne t'en empêche.
Mais dans une trame ethernet (et non pas un paquet), il y a un champ FCS qui doit contenir une somme de contrôle. Si ce FCS n'est pas bon, alors le switch ignore la trame. D'après une rapide recherche sur le net, il s'agit d'un CRC-32 complémenté à 1.
D'autre part, la taille minimum de ta payload est de 46 octets. Je suppose que le switch en tient compte aussi pour détecter des trames incomplètes.


---------------
Un proverbe chinois dit que lorsqu'on a rien à dire d'intéressant, on cite généralement un proverbe chinois.
Reply

Marsh Posté le 22-06-2016 à 09:32:08    

Je pense que tu es obligé d'implémenté l'ARP:
https://supportforums.cisco.com/doc [...] munication


---------------
sheep++
Reply

Marsh Posté le 22-06-2016 à 11:18:42    

De l'ARP sans adresse IP ? Il ferait comment ?


---------------
Un proverbe chinois dit que lorsqu'on a rien à dire d'intéressant, on cite généralement un proverbe chinois.
Reply

Marsh Posté le 22-06-2016 à 11:21:46    

Tu mets un IP bidon, c'est juste pour que le switch remplisse sa table MAC.

 
Citation :

To obtain MAC address, ARP performs following process: (ARP request by host machine)

 

   Source machine generate ARP REQUEST packet with source MAC address (of this machine), source IP address (of this machine) and destination IP address and forwards this packet to switch.
    Switch receives the incoming packet and reads the source MAC address and checks its MAC address table, if entry for packet at incoming port is found then it checks its MAC address with the source MAC address and updates it, if entry not found then switch add and entry for incoming port with MAC address.
    All ARP REQUEST packets are broadcasted in network, so switch broadcast ARP REQUEST packet in network.
    (Broadcast are those packets which are sent to everyone in network except the sender, only in network to which it belongs, it cannot span multiple networks)
    All devices in network receives ARP packet and compare their own IP address with the destination IP address in that packet.
    Only the machine which matches the both will reply with ARP reply packet. This packet will have source IP of this machine (which was destination machine in previous packet, as now its replying this machine will be the source machine) , source MAC address, destination MAC address (same as source MAC address in REQUEST packet) and destination IP address (same as source IP address in REQUEST packet).
    Then switch reads the ARP reply message and add entry in its MAC Address Table for port number on which it has received packet by reading its source MAC address field and forwards that packet to destination machine (source machine in REQUEST packet) as its MAC is in destination MAC address.

 

Et aussi: https://wiki.wireshark.org/Gratuitous_ARP

Message cité 1 fois
Message édité par h3bus le 22-06-2016 à 11:50:52

---------------
sheep++
Reply

Marsh Posté le 22-06-2016 à 13:14:20    

Ruliane a écrit :

Oui, normalement rien ne t'en empêche.
Mais dans une trame ethernet (et non pas un paquet), il y a un champ FCS qui doit contenir une somme de contrôle. Si ce FCS n'est pas bon, alors le switch ignore la trame. D'après une rapide recherche sur le net, il s'agit d'un CRC-32 complémenté à 1.
D'autre part, la taille minimum de ta payload est de 46 octets. Je suppose que le switch en tient compte aussi pour détecter des trames incomplètes.


 
Oui mais le FCS est calculé automatiquement ! Il se peut tout de même que le problème viennent du FCS. Par ailleurs le switch n'arrive même pas à écrire l'adresse MAC de l'émetteur de la trame dans la table d'adresse MAC, sachant que c'est la première étape qu'il faut faire, puisqu'il a l'adresse MAC et le port associé. Auriez-vous des explications ?  
En ce qui concerne la payload elle est de 100 octets !
Merci

Reply

Marsh Posté le 22-06-2016 à 13:18:55    

h3bus a écrit :

Tu mets un IP bidon, c'est juste pour que le switch remplisse sa table MAC.
 

Citation :

To obtain MAC address, ARP performs following process: (ARP request by host machine)
 
    Source machine generate ARP REQUEST packet with source MAC address (of this machine), source IP address (of this machine) and destination IP address and forwards this packet to switch.
    Switch receives the incoming packet and reads the source MAC address and checks its MAC address table, if entry for packet at incoming port is found then it checks its MAC address with the source MAC address and updates it, if entry not found then switch add and entry for incoming port with MAC address.
    All ARP REQUEST packets are broadcasted in network, so switch broadcast ARP REQUEST packet in network.
    (Broadcast are those packets which are sent to everyone in network except the sender, only in network to which it belongs, it cannot span multiple networks)
    All devices in network receives ARP packet and compare their own IP address with the destination IP address in that packet.
    Only the machine which matches the both will reply with ARP reply packet. This packet will have source IP of this machine (which was destination machine in previous packet, as now its replying this machine will be the source machine) , source MAC address, destination MAC address (same as source MAC address in REQUEST packet) and destination IP address (same as source IP address in REQUEST packet).
    Then switch reads the ARP reply message and add entry in its MAC Address Table for port number on which it has received packet by reading its source MAC address field and forwards that packet to destination machine (source machine in REQUEST packet) as its MAC is in destination MAC address.


 
Et aussi: https://wiki.wireshark.org/Gratuitous_ARP


 
J'ai attribué une adresse IP à ma carte et je ping d'un pc vers la carte via le switch, ça marche et la table d'adresse MAC est construite.  
J'utilise aussi Wireshark pour voir les trames transmises. En effet le protocole ARP est utilisé pour connaitre l'adresse MAC associée à l'adresse IP destination, mais la trame avec laquelle la carte répond à l'ARP est incorrecte au niveau du FCS (d'après Wireshark) sachant que le FCS est calculé automatiquement !  

Reply

Marsh Posté le 22-06-2016 à 14:52:59    

Deux cas sont possibles concernant le FCS :
- soit celui-ci est calculé en software, et tu dois l'implémenter dans ton logiciel
- soit ce calcul est déporté à la carte réseau (c'est le cas le plus fréquent) et il est normal que Wireshark détecte une erreur, car lorsque la trame est analysée par Wireshark le FCS n'est pas encore calculé : il le sera par la carte réseau juste avant d'être envoyé sur le media.
 
 
EDIT : Mais pour moi, le switch devrait enregistrer l'adresse MAC dans sa table ARP à partir du moment où la trame est bonne.
Peut-être que certains (tous ?) switchs mettent en place un protection pour éviter qu'un petit malin ne blinde la table ARP en envoyant des trames bidon.

Message cité 1 fois
Message édité par Ruliane le 22-06-2016 à 14:55:13

---------------
Un proverbe chinois dit que lorsqu'on a rien à dire d'intéressant, on cite généralement un proverbe chinois.
Reply

Marsh Posté le 22-06-2016 à 16:48:19    

Ruliane a écrit :

Deux cas sont possibles concernant le FCS :
- soit celui-ci est calculé en software, et tu dois l'implémenter dans ton logiciel
- soit ce calcul est déporté à la carte réseau (c'est le cas le plus fréquent) et il est normal que Wireshark détecte une erreur, car lorsque la trame est analysée par Wireshark le FCS n'est pas encore calculé : il le sera par la carte réseau juste avant d'être envoyé sur le media.
 
 
EDIT : Mais pour moi, le switch devrait enregistrer l'adresse MAC dans sa table ARP à partir du moment où la trame est bonne.
Peut-être que certains (tous ?) switchs mettent en place un protection pour éviter qu'un petit malin ne blinde la table ARP en envoyant des trames bidon.


 
En fait je parle de la réponse de la carte à un "ARP request", quand le switch demande à qui appartient l'adresse MAC et la carte correspondante répond par un message pour dire que c'est son adresse MAC, car je fais un ping d'un pc vers une carte mbed.
Donc si j'ai bien compris, il ne construit la table que si toute la trame est bonne et non pas au fur et à mesure comme certains l'expliquent ?
Merci pour ces éclaircicements.

Reply

Marsh Posté le 22-06-2016 à 20:21:06    

Un "ARP request" c'est "Je recherche l'adresse MAC correspondant à l'adresse IP x.x.x.x ?" La réponse habituelle est "Je suis x.x.x.x, et mon adresse MAC est yy:yy:yy:yy:yy:yy:yy".
À mon sens, tu n'as pas à te soucier d'ARP puisque 1/ tu n'as pas d'adresse IP et 2/ le switch n'a pas besoin de cette correspondance pour commuter les trames ethernet.
 
Par contre, il est possible que le switch mette en place une protection qui consiste, avant de commuter une trame, à vérifier que l'adresse MAC correspond bien à un device existant sur le réseau... par exemple en faisant un reverse ARP ("Quelle adresse IP se cache derrière la MAC yy:yy:yy:yy:yy:yy:yy ?" )
Là je suppute, car j'ignore si un tel mécanisme existe. Si quelqu'un a la réponse, ça m'intéresse. :wahoo:

Message cité 1 fois
Message édité par Ruliane le 22-06-2016 à 20:21:52

---------------
Un proverbe chinois dit que lorsqu'on a rien à dire d'intéressant, on cite généralement un proverbe chinois.
Reply

Marsh Posté le 22-06-2016 à 20:21:06   

Reply

Marsh Posté le 23-06-2016 à 09:49:37    

Ruliane a écrit :

Un "ARP request" c'est "Je recherche l'adresse MAC correspondant à l'adresse IP x.x.x.x ?" La réponse habituelle est "Je suis x.x.x.x, et mon adresse MAC est yy:yy:yy:yy:yy:yy:yy".
À mon sens, tu n'as pas à te soucier d'ARP puisque 1/ tu n'as pas d'adresse IP et 2/ le switch n'a pas besoin de cette correspondance pour commuter les trames ethernet.
 
Par contre, il est possible que le switch mette en place une protection qui consiste, avant de commuter une trame, à vérifier que l'adresse MAC correspond bien à un device existant sur le réseau... par exemple en faisant un reverse ARP ("Quelle adresse IP se cache derrière la MAC yy:yy:yy:yy:yy:yy:yy ?" )
Là je suppute, car j'ignore si un tel mécanisme existe. Si quelqu'un a la réponse, ça m'intéresse. :wahoo:


 
En fait j'ai attribué une adresse IP à la carte juste pour voir le contenu de la trame, pour cela j'ai utilisé wireshark pour visualiser ce qui se passait quand j'envoyais un ping du PC vers ma carte et il y avait ce mécanisme d'ARP. Je voulais faire ce test pour pouvoir le reproduire en écrivant à la main le contenu de ma trame et l'envoyer cette fois ci à une autre carte du même type. Mais je pense que le problème vient du fait que la trame Ethernet que j'envoie est mal écrite ou que mon switch n'est pas configuré pour faire de l'Ethernet brut.

Reply

Marsh Posté le 27-06-2016 à 18:30:11    

mehdy1 a écrit :


 
En fait j'ai attribué une adresse IP à la carte juste pour voir le contenu de la trame, pour cela j'ai utilisé wireshark pour visualiser ce qui se passait quand j'envoyais un ping du PC vers ma carte et il y avait ce mécanisme d'ARP. Je voulais faire ce test pour pouvoir le reproduire en écrivant à la main le contenu de ma trame et l'envoyer cette fois ci à une autre carte du même type. Mais je pense que le problème vient du fait que la trame Ethernet que j'envoie est mal écrite ou que mon switch n'est pas configuré pour faire de l'Ethernet brut.


Possible, et Wireshark devrait pouvoir te l'indiquer aisément.
 
Ton switch, c'est quel modèle ?
 
 
Ça me titille ton histoire, faudra que j'essaye. ^^ Tu aurais un petit programme pour tester ce genre de chose ? (pour m'éviter d'avoir à réinventer la roue)


---------------
Un proverbe chinois dit que lorsqu'on a rien à dire d'intéressant, on cite généralement un proverbe chinois.
Reply

Marsh Posté le 28-06-2016 à 09:28:12    

Ruliane a écrit :


Possible, et Wireshark devrait pouvoir te l'indiquer aisément.
 
Ton switch, c'est quel modèle ?
 
 
Ça me titille ton histoire, faudra que j'essaye. ^^ Tu aurais un petit programme pour tester ce genre de chose ? (pour m'éviter d'avoir à réinventer la roue)


 
Mon swicth est un cisco SF220 SMart Plus ! En fait j'ai presque identifié la source du problème ! ça vient du fait que la carte n'est pas reconnu par mon switch ! Donc ce que j'ai fait c'est d'attribuer une adresse MAC à ma carte identique à celle d'un PC et brancher le PC et la carte sur un hub qui est branché sur l'un des ports du switch. Une fois le switch identifie le PC et son adresse MAC, la carte peut donc envoyer des trames Ethernet II sans aucun problème, j'ai utilisé wireshark pour visualiser les trames à la réception ( de l'autre côté du switch).

Reply

Marsh Posté le 28-06-2016 à 09:32:47    

mehdy1 a écrit :

 

Mon swicth est un cisco SF220 SMart Plus ! En fait j'ai presque identifié la source du problème ! ça vient du fait que la carte n'est pas reconnu par mon switch ! Donc ce que j'ai fait c'est d'attribuer une adresse MAC à ma carte identique à celle d'un PC et brancher le PC et la carte sur un hub qui est branché sur l'un des ports du switch. Une fois le switch identifie le PC et son adresse MAC, la carte peut donc envoyer des trames Ethernet II sans aucun problème, j'ai utilisé wireshark pour visualiser les trames à la réception ( de l'autre côté du switch).

 

voici un exemple de programme qui permet d'attribuer une adresse IP à une carte, ceci étant dit que tu peux faire un ping du PC sur ta carte :
 
#include "mbed.h"
#include "EthernetInterface.h"
 
 
EthernetInterface ethI;
DigitalOut myled(LED1);
Serial pc(USBTX,USBRX);
 
char ipA[]="192.168.1.22"; // adresse ip de la carte A
char masque[]="255.255.255.0";
char pass[]="0.0.0.0";
char type[1]={0x0800};
 
int main() {
    pc.printf("Hello world\n\r" );
    if(ethI.init(ipA,masque,pass)!=0) {
        pc.printf("ERREUR INIT ETHERNET\r\n" );
        return -1;
        }
    if(ethI.connect()!=0) {
        pc.printf("ERREUR CONNECT\r\n" );
        return -1;
        }
    pc.printf("L'adresse IP est %s\r\n",ethI.getIPAddress());
     
    while(1) {
        myled = 1;
        wait(0.2);
        myled = 0;
        wait(0.2);
    }
}


Message édité par mehdy1 le 28-06-2016 à 09:35:41
Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed