Dans whireshark, tout de suite les @MAC. Les bits IG/UL comme c'est
represente, cela signifie qu'ils se trouvent dans le 2=B0 octet
respectivement en bit poids 0 et 1 ?
Mais alors pourquoi je lis dans les documents que les deux premiers
bits transmis sont justement ces bits IG/UL et qu'apres arrivent les
@MAC ? C'est whireshark qui melange tout, ou c'est moi ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Pascal Hambourg
Salut,
Dans whireshark, tout de suite les @MAC. Les bits IG/UL comme c'est represente, cela signifie qu'ils se trouvent dans le 2° octet respectivement en bit poids 0 et 1 ?
Ces bits sont dans le premier octet de chaque adresse MAC.
Mais alors pourquoi je lis dans les documents que les deux premiers bits transmis sont justement ces bits IG/UL et qu'apres arrivent les @MAC ?
Après ces deux bits arrive le reste de l'adresse MAC.
C'est whireshark qui melange tout, ou c'est moi ?
Sur une ligne ethernet, chaque octet est transmis avec le bit de poids faible en premier. Wireshark affiche les octets avec le bit de poids faible à droite comme c'est l'usage. Par conséquent il n'affiche pas les bits dans l'ordre de transmission.
Salut,
Dans whireshark, tout de suite les @MAC. Les bits IG/UL comme c'est
represente, cela signifie qu'ils se trouvent dans le 2° octet
respectivement en bit poids 0 et 1 ?
Ces bits sont dans le premier octet de chaque adresse MAC.
Mais alors pourquoi je lis dans les documents que les deux premiers
bits transmis sont justement ces bits IG/UL et qu'apres arrivent les
@MAC ?
Après ces deux bits arrive le reste de l'adresse MAC.
C'est whireshark qui melange tout, ou c'est moi ?
Sur une ligne ethernet, chaque octet est transmis avec le bit de poids
faible en premier. Wireshark affiche les octets avec le bit de poids
faible à droite comme c'est l'usage. Par conséquent il n'affiche pas les
bits dans l'ordre de transmission.
Dans whireshark, tout de suite les @MAC. Les bits IG/UL comme c'est represente, cela signifie qu'ils se trouvent dans le 2° octet respectivement en bit poids 0 et 1 ?
Ces bits sont dans le premier octet de chaque adresse MAC.
Mais alors pourquoi je lis dans les documents que les deux premiers bits transmis sont justement ces bits IG/UL et qu'apres arrivent les @MAC ?
Après ces deux bits arrive le reste de l'adresse MAC.
C'est whireshark qui melange tout, ou c'est moi ?
Sur une ligne ethernet, chaque octet est transmis avec le bit de poids faible en premier. Wireshark affiche les octets avec le bit de poids faible à droite comme c'est l'usage. Par conséquent il n'affiche pas les bits dans l'ordre de transmission.
Chof Marcel
Merci ;o)
Salut,
Dans whireshark, tout de suite les @MAC. Les bits IG/UL comme c'est represente, cela signifie qu'ils se trouvent dans le 2° octet respectivement en bit poids 0 et 1 ?
Ces bits sont dans le premier octet de chaque adresse MAC.
Mais alors pourquoi je lis dans les documents que les deux premiers bits transmis sont justement ces bits IG/UL et qu'apres arrivent les @MAC ?
Après ces deux bits arrive le reste de l'adresse MAC.
C'est whireshark qui melange tout, ou c'est moi ?
Sur une ligne ethernet, chaque octet est transmis avec le bit de poids faible en premier. Wireshark affiche les octets avec le bit de poids faible à droite comme c'est l'usage. Par conséquent il n'affiche pas les bits dans l'ordre de transmission.
Merci ;o)
Salut,
Dans whireshark, tout de suite les @MAC. Les bits IG/UL comme c'est
represente, cela signifie qu'ils se trouvent dans le 2° octet
respectivement en bit poids 0 et 1 ?
Ces bits sont dans le premier octet de chaque adresse MAC.
Mais alors pourquoi je lis dans les documents que les deux premiers
bits transmis sont justement ces bits IG/UL et qu'apres arrivent les
@MAC ?
Après ces deux bits arrive le reste de l'adresse MAC.
C'est whireshark qui melange tout, ou c'est moi ?
Sur une ligne ethernet, chaque octet est transmis avec le bit de poids
faible en premier. Wireshark affiche les octets avec le bit de poids
faible à droite comme c'est l'usage. Par conséquent il n'affiche pas les
bits dans l'ordre de transmission.
Dans whireshark, tout de suite les @MAC. Les bits IG/UL comme c'est represente, cela signifie qu'ils se trouvent dans le 2° octet respectivement en bit poids 0 et 1 ?
Ces bits sont dans le premier octet de chaque adresse MAC.
Mais alors pourquoi je lis dans les documents que les deux premiers bits transmis sont justement ces bits IG/UL et qu'apres arrivent les @MAC ?
Après ces deux bits arrive le reste de l'adresse MAC.
C'est whireshark qui melange tout, ou c'est moi ?
Sur une ligne ethernet, chaque octet est transmis avec le bit de poids faible en premier. Wireshark affiche les octets avec le bit de poids faible à droite comme c'est l'usage. Par conséquent il n'affiche pas les bits dans l'ordre de transmission.
artintel
On 28 fév, 22:37, Pascal Hambourg wrote:
Salut,
Dans whireshark, tout de suite les @MAC. Les bits IG/UL comme c'est represente, cela signifie qu'ils se trouvent dans le 2° octet respectivement en bit poids 0 et 1 ?
Ces bits sont dans le premier octet de chaque adresse MAC.
Mais alors pourquoi je lis dans les documents que les deux premiers bits transmis sont justement ces bits IG/UL et qu'apres arrivent les @MAC ?
Après ces deux bits arrive le reste de l'adresse MAC.
C'est whireshark qui melange tout, ou c'est moi ?
Sur une ligne ethernet, chaque octet est transmis avec le bit de poids faible en premier. Wireshark affiche les octets avec le bit de poids faible à droite comme c'est l'usage. Par conséquent il n'affiche pas l es bits dans l'ordre de transmission.
Oui, merci beaucoups, on me l'avait dit, mais je n'arrivais pas a faire le lien.
Bonne journee
On 28 fév, 22:37, Pascal Hambourg <boite-a-s...@plouf.fr.eu.org>
wrote:
Salut,
Dans whireshark, tout de suite les @MAC. Les bits IG/UL comme c'est
represente, cela signifie qu'ils se trouvent dans le 2° octet
respectivement en bit poids 0 et 1 ?
Ces bits sont dans le premier octet de chaque adresse MAC.
Mais alors pourquoi je lis dans les documents que les deux premiers
bits transmis sont justement ces bits IG/UL et qu'apres arrivent les
@MAC ?
Après ces deux bits arrive le reste de l'adresse MAC.
C'est whireshark qui melange tout, ou c'est moi ?
Sur une ligne ethernet, chaque octet est transmis avec le bit de poids
faible en premier. Wireshark affiche les octets avec le bit de poids
faible à droite comme c'est l'usage. Par conséquent il n'affiche pas l es
bits dans l'ordre de transmission.
Oui, merci beaucoups, on me l'avait dit, mais je n'arrivais pas a
faire le lien.
Dans whireshark, tout de suite les @MAC. Les bits IG/UL comme c'est represente, cela signifie qu'ils se trouvent dans le 2° octet respectivement en bit poids 0 et 1 ?
Ces bits sont dans le premier octet de chaque adresse MAC.
Mais alors pourquoi je lis dans les documents que les deux premiers bits transmis sont justement ces bits IG/UL et qu'apres arrivent les @MAC ?
Après ces deux bits arrive le reste de l'adresse MAC.
C'est whireshark qui melange tout, ou c'est moi ?
Sur une ligne ethernet, chaque octet est transmis avec le bit de poids faible en premier. Wireshark affiche les octets avec le bit de poids faible à droite comme c'est l'usage. Par conséquent il n'affiche pas l es bits dans l'ordre de transmission.
Oui, merci beaucoups, on me l'avait dit, mais je n'arrivais pas a faire le lien.
