Les forums sont fermés. Ils restent présent pour consultation et archivage.
Vous pouvez désormais poser vos questions directement dans les commentaires en bas de chaque page du site.
Alors n'hésitez pas à participer

ethernet et fcs

me revoila 🙄 hum petite question pratique l'header ethernet ne contient pas de champs indiquant la longueur de la trame, et la fin de la trame est marquée par un séquence de 4 octet, le fcs Or dans le lot d'octet constituant la données (plus d'un millier) prkoi une séquence assimilable au fcs ne peut être présente, genre si une séquence du header ip, comment distingue t on une trame ether mal formée (genre un header, quelques bits et un fcs) ? est ce impossible ?

Salut, Je sais pas si j'ai bien saisi ta question, Mais pour moi le champ FCS est déjà le champ qui réalise le contrôle d'intégrité de la trame, puisque si le CRC n'est pas bon la trame est censé être considéré comme étant de mauvaise. Si tu parle des données proprement dis, étant donnée que c'est la couche applicative qui est en général en charge de l'interprétation de ce bloque, il convient que c'est l'appli qui va déterminer si les données sont valides ou non. Dans le cadre du processus de désencapsulation de paquet à partir d'Ethernet il ne faut pas perdre de vu que les entêtes de couches supérieurs (IP/TCP/UDP....) sont comprises dans le lot d'octets. En général les problèmes viennent souvent d'une mauvaise interprétation physique du signal. Concernant IP un contrôle d'intégrité est également effectué puisque le champ checksum (2 octets)est défini dans ce but. En espérant que cela correspond à ce que tu attendais. @+

merci, oui je n'ai pas été trés clair, en fait ce qui me perturbais, c'est que comme il n'y a pas de champ longueur dans le header mac,donc que ce passe t'il si on reçoit par exemple une séquence de bit identique au SFD, on suppose que la superposition de deux trames est impossible, donc la question ne se pose pas 🙂