c'est le driver ethernet qui fait le tri des trames reçues
Je croyais que c'était le contrôleur ethernet de la carte elle-même qui filtrait les trames sur l'adresse MAC destination (n'accepte que la sienne et l'adresse de broadcast ethernet). Sauf dans le cas où la carte est configurée en mode promiscuous, alors la carte accepte tout et le tri est à la charge du driver.
Maintenant, le problème, ça va être d'injecter cette trame sur le réseau dans la mesure où elle n'a pas un format ethernet standard. Comme la carte cible attend cette séquence sous forme de signal, on peut encapsuler ces données dans n'importe qu'elle type de paquets.
Si cette séquence est transmise dans le champ de données d'une trame ethernet, pourquoi écrire que le format n'est pas de l'ethernet standard ? On peut mettre n'importe quoi dans le champ de données d'une trame ethernet, elle reste une trame ethernet standard, non ?
c'est le driver ethernet qui fait le tri des trames reçues
Je croyais que c'était le contrôleur ethernet de la carte elle-même qui
filtrait les trames sur l'adresse MAC destination (n'accepte que la
sienne et l'adresse de broadcast ethernet). Sauf dans le cas où la carte
est configurée en mode promiscuous, alors la carte accepte tout et le
tri est à la charge du driver.
Maintenant, le problème, ça va être d'injecter
cette trame sur le réseau dans la mesure où elle n'a pas un format
ethernet standard. Comme la carte cible attend cette séquence sous forme
de signal, on peut encapsuler ces données dans n'importe qu'elle type de
paquets.
Si cette séquence est transmise dans le champ de données d'une trame
ethernet, pourquoi écrire que le format n'est pas de l'ethernet standard
? On peut mettre n'importe quoi dans le champ de données d'une trame
ethernet, elle reste une trame ethernet standard, non ?
c'est le driver ethernet qui fait le tri des trames reçues
Je croyais que c'était le contrôleur ethernet de la carte elle-même qui filtrait les trames sur l'adresse MAC destination (n'accepte que la sienne et l'adresse de broadcast ethernet). Sauf dans le cas où la carte est configurée en mode promiscuous, alors la carte accepte tout et le tri est à la charge du driver.
Maintenant, le problème, ça va être d'injecter cette trame sur le réseau dans la mesure où elle n'a pas un format ethernet standard. Comme la carte cible attend cette séquence sous forme de signal, on peut encapsuler ces données dans n'importe qu'elle type de paquets.
Si cette séquence est transmise dans le champ de données d'une trame ethernet, pourquoi écrire que le format n'est pas de l'ethernet standard ? On peut mettre n'importe quoi dans le champ de données d'une trame ethernet, elle reste une trame ethernet standard, non ?
Cedric Blancher
Dans sa prose, Annie D. nous ecrivait :
Je croyais que c'était le contrôleur ethernet de la carte elle-même qui filtrait les trames sur l'adresse MAC destination (n'accepte que la sienne et l'adresse de broadcast ethernet). Sauf dans le cas où la carte est configurée en mode promiscuous, alors la carte accepte tout et le tri est à la charge du driver.
Ça dépend des capacités des cartes réseau. Cela va de la carte qui vous remonte un train binaire à la carte qui est capable de gérer à peu près tout, y compris les calculs/vérification de checksum.
Si cette séquence est transmise dans le champ de données d'une trame ethernet, pourquoi écrire que le format n'est pas de l'ethernet standard ? On peut mettre n'importe quoi dans le champ de données d'une trame ethernet, elle reste une trame ethernet standard, non ?
Parce que si tu sais faire de l'injection directe au niveau 2 (genre avec lc), tu peux lancer la magic sequence directement sur le câble. Seulement ça te limite à ton domaine de collision, ce qui en pratique est quand même très limité, et ça demande une configuration particulière ainsi qu'un niveau de privilèges élevé, contrairement à l'encapsulation dans UDP.
--
Utilise eshell ! :) Et accroche-toi au pinceau, j'enlève la RAM ...
-+- EL in GFA : "C'est l'histoire d'un emacsien fou..." -+-
Dans sa prose, Annie D. nous ecrivait :
Je croyais que c'était le contrôleur ethernet de la carte elle-même
qui filtrait les trames sur l'adresse MAC destination (n'accepte que la
sienne et l'adresse de broadcast ethernet). Sauf dans le cas où la
carte est configurée en mode promiscuous, alors la carte accepte tout
et le tri est à la charge du driver.
Ça dépend des capacités des cartes réseau. Cela va de la carte qui
vous remonte un train binaire à la carte qui est capable de gérer à peu
près tout, y compris les calculs/vérification de checksum.
Si cette séquence est transmise dans le champ de données d'une trame
ethernet, pourquoi écrire que le format n'est pas de l'ethernet
standard ? On peut mettre n'importe quoi dans le champ de données d'une
trame ethernet, elle reste une trame ethernet standard, non ?
Parce que si tu sais faire de l'injection directe au niveau 2 (genre avec
lc), tu peux lancer la magic sequence directement sur le câble. Seulement
ça te limite à ton domaine de collision, ce qui en pratique est quand
même très limité, et ça demande une configuration particulière ainsi
qu'un niveau de privilèges élevé, contrairement à l'encapsulation dans
UDP.
--
Utilise eshell ! :)
Et accroche-toi au pinceau, j'enlève la RAM ...
-+- EL in GFA : "C'est l'histoire d'un emacsien fou..." -+-
Je croyais que c'était le contrôleur ethernet de la carte elle-même qui filtrait les trames sur l'adresse MAC destination (n'accepte que la sienne et l'adresse de broadcast ethernet). Sauf dans le cas où la carte est configurée en mode promiscuous, alors la carte accepte tout et le tri est à la charge du driver.
Ça dépend des capacités des cartes réseau. Cela va de la carte qui vous remonte un train binaire à la carte qui est capable de gérer à peu près tout, y compris les calculs/vérification de checksum.
Si cette séquence est transmise dans le champ de données d'une trame ethernet, pourquoi écrire que le format n'est pas de l'ethernet standard ? On peut mettre n'importe quoi dans le champ de données d'une trame ethernet, elle reste une trame ethernet standard, non ?
Parce que si tu sais faire de l'injection directe au niveau 2 (genre avec lc), tu peux lancer la magic sequence directement sur le câble. Seulement ça te limite à ton domaine de collision, ce qui en pratique est quand même très limité, et ça demande une configuration particulière ainsi qu'un niveau de privilèges élevé, contrairement à l'encapsulation dans UDP.
--
Utilise eshell ! :) Et accroche-toi au pinceau, j'enlève la RAM ...
-+- EL in GFA : "C'est l'histoire d'un emacsien fou..." -+-
Annie D.
Cedric Blancher wrote:
Ça dépend des capacités des cartes réseau. Cela va de la carte qui vous remonte un train binaire
J'imagine que ces cartes sont réservées à des utilisations particulières.
à la carte qui est capable de gérer à peu près tout, y compris les calculs/vérification de checksum.
N'est-ce pas le cas de toutes les cartes courantes ?
Parce que si tu sais faire de l'injection directe au niveau 2 (genre avec lc), tu peux lancer la magic sequence directement sur le câble [...]
Autrement dit, pourquoi faire simple quand on peut faire compliqué ?
Cedric Blancher wrote:
Ça dépend des capacités des cartes réseau. Cela va de la carte qui
vous remonte un train binaire
J'imagine que ces cartes sont réservées à des utilisations
particulières.
à la carte qui est capable de gérer à peu
près tout, y compris les calculs/vérification de checksum.
N'est-ce pas le cas de toutes les cartes courantes ?
Parce que si tu sais faire de l'injection directe au niveau 2 (genre avec
lc), tu peux lancer la magic sequence directement sur le câble
[...]
Autrement dit, pourquoi faire simple quand on peut faire compliqué ?
Ça dépend des capacités des cartes réseau. Cela va de la carte qui vous remonte un train binaire
J'imagine que ces cartes sont réservées à des utilisations particulières.
à la carte qui est capable de gérer à peu près tout, y compris les calculs/vérification de checksum.
N'est-ce pas le cas de toutes les cartes courantes ?
Parce que si tu sais faire de l'injection directe au niveau 2 (genre avec lc), tu peux lancer la magic sequence directement sur le câble [...]
Autrement dit, pourquoi faire simple quand on peut faire compliqué ?
Eric Belhomme
"Annie D." wrote in news::
Ça dépend des capacités des cartes réseau. Cela va de la carte qui vous remonte un train binaire
J'imagine que ces cartes sont réservées à des utilisations particulières.
à la carte qui est capable de gérer à peu près tout, y compris les calculs/vérification de checksum.
N'est-ce pas le cas de toutes les cartes courantes ?
au contraire !!!
Les cartes les moins cheres (genre Realtek) ne sont capable que de remonter le flux ethernet brut, qui devra etre interprété par le processeur central, alors qu'une bonne carte (une 3c905 ou une eepro100 par exemple) sera capable de désencapsuler le flux ethernet...
Toujours le bon vieil addage : qui peut le plus, peut le moins...
-- Rico (RicoSpirit) - http://www.ricospirit.net Pour en savoir autant que moi sur INN (c.a.d. pas grand chose !) : http://www.ricospirit.net/inn/
"Annie D." <annie.demur@free.fr> wrote in
news:3F0C7425.11661E61@free.fr:
Ça dépend des capacités des cartes réseau. Cela va de la carte qui
vous remonte un train binaire
J'imagine que ces cartes sont réservées à des utilisations
particulières.
à la carte qui est capable de gérer à peu
près tout, y compris les calculs/vérification de checksum.
N'est-ce pas le cas de toutes les cartes courantes ?
au contraire !!!
Les cartes les moins cheres (genre Realtek) ne sont capable que de remonter
le flux ethernet brut, qui devra etre interprété par le processeur central,
alors qu'une bonne carte (une 3c905 ou une eepro100 par exemple) sera
capable de désencapsuler le flux ethernet...
Toujours le bon vieil addage : qui peut le plus, peut le moins...
--
Rico (RicoSpirit) - http://www.ricospirit.net
Pour en savoir autant que moi sur INN (c.a.d. pas grand chose !) :
http://www.ricospirit.net/inn/
Ça dépend des capacités des cartes réseau. Cela va de la carte qui vous remonte un train binaire
J'imagine que ces cartes sont réservées à des utilisations particulières.
à la carte qui est capable de gérer à peu près tout, y compris les calculs/vérification de checksum.
N'est-ce pas le cas de toutes les cartes courantes ?
au contraire !!!
Les cartes les moins cheres (genre Realtek) ne sont capable que de remonter le flux ethernet brut, qui devra etre interprété par le processeur central, alors qu'une bonne carte (une 3c905 ou une eepro100 par exemple) sera capable de désencapsuler le flux ethernet...
Toujours le bon vieil addage : qui peut le plus, peut le moins...
-- Rico (RicoSpirit) - http://www.ricospirit.net Pour en savoir autant que moi sur INN (c.a.d. pas grand chose !) : http://www.ricospirit.net/inn/
Cedric Blancher
Dans sa prose, Annie D. nous ecrivait :
à la carte qui est capable de gérer à peu près tout, y compris les calculs/vérification de checksum. N'est-ce pas le cas de toutes les cartes courantes ?
Vu ce que nous sort RealTek en termes de chipsets, je n'en jurerai pas.
Parce que si tu sais faire de l'injection directe au niveau 2 (genre avec lc), tu peux lancer la magic sequence directement sur le câble [...]
Autrement dit, pourquoi faire simple quand on peut faire compliqué ?
C'est exactement là que je voulais en venir :)
-- C'est pas avec la censure que tu vas censurer les censeurs. -+- JL in GNU : Las, censeurs pour l'échafaud -+-
Dans sa prose, Annie D. nous ecrivait :
à la carte qui est capable de gérer à peu près tout, y compris les
calculs/vérification de checksum.
N'est-ce pas le cas de toutes les cartes courantes ?
Vu ce que nous sort RealTek en termes de chipsets, je n'en jurerai pas.
Parce que si tu sais faire de l'injection directe au niveau 2 (genre
avec lc), tu peux lancer la magic sequence directement sur le câble
[...]
Autrement dit, pourquoi faire simple quand on peut faire compliqué ?
C'est exactement là que je voulais en venir :)
--
C'est pas avec la censure que tu vas censurer les censeurs.
-+- JL in GNU : Las, censeurs pour l'échafaud -+-
à la carte qui est capable de gérer à peu près tout, y compris les calculs/vérification de checksum. N'est-ce pas le cas de toutes les cartes courantes ?
Vu ce que nous sort RealTek en termes de chipsets, je n'en jurerai pas.
Parce que si tu sais faire de l'injection directe au niveau 2 (genre avec lc), tu peux lancer la magic sequence directement sur le câble [...]
Autrement dit, pourquoi faire simple quand on peut faire compliqué ?
C'est exactement là que je voulais en venir :)
-- C'est pas avec la censure que tu vas censurer les censeurs. -+- JL in GNU : Las, censeurs pour l'échafaud -+-
Eric Masson
"Cedric" == Cedric Blancher writes:
Cedric> Vu ce que nous sort RealTek en termes de chipsets, je n'en Cedric> jurerai pas.
Il semblerait que le 8139C+ (la dernière mouture en date d'une longue liste d'infamies) soit enfin au niveau de la concurrence sans pour autant exploser les tarifs. (Cette nouvelle mouture aurait bénéficié des travaux de realtek sur un chipset giga dont la sortie serait imminente)
Wait'n'see, mais peut-être que bientôt, il faudra trouver un autre fondeur que Realtek sur qui taper (si les intégrateurs réussissent à livrer des cartes qui ne tombent pas en panne dès le déballage, cela pourrait même devenir intéressant, les derniers tests effectués par le mainteneur de rl(4) semblent plus que prometteurs, à sa grande surprise)
Eric Masson
-- C> Merci de renommer vos fils et sous-fils, sinon c'est le bordel. BdB> Tu parles, c'est si je renomme mon fils que ça va être le bordel. Tu seras une pomme, mon fils -+- pH in <http://www.le-gnu.net>: de pire en père et de pomme en fils.
Cedric> Vu ce que nous sort RealTek en termes de chipsets, je n'en
Cedric> jurerai pas.
Il semblerait que le 8139C+ (la dernière mouture en date d'une longue
liste d'infamies) soit enfin au niveau de la concurrence sans pour
autant exploser les tarifs. (Cette nouvelle mouture aurait bénéficié des
travaux de realtek sur un chipset giga dont la sortie serait imminente)
Wait'n'see, mais peut-être que bientôt, il faudra trouver un autre
fondeur que Realtek sur qui taper (si les intégrateurs réussissent à
livrer des cartes qui ne tombent pas en panne dès le déballage, cela
pourrait même devenir intéressant, les derniers tests effectués par le
mainteneur de rl(4) semblent plus que prometteurs, à sa grande surprise)
Eric Masson
--
C> Merci de renommer vos fils et sous-fils, sinon c'est le bordel.
BdB> Tu parles, c'est si je renomme mon fils que ça va être le bordel.
Tu seras une pomme, mon fils
-+- pH in <http://www.le-gnu.net>: de pire en père et de pomme en fils.
Cedric> Vu ce que nous sort RealTek en termes de chipsets, je n'en Cedric> jurerai pas.
Il semblerait que le 8139C+ (la dernière mouture en date d'une longue liste d'infamies) soit enfin au niveau de la concurrence sans pour autant exploser les tarifs. (Cette nouvelle mouture aurait bénéficié des travaux de realtek sur un chipset giga dont la sortie serait imminente)
Wait'n'see, mais peut-être que bientôt, il faudra trouver un autre fondeur que Realtek sur qui taper (si les intégrateurs réussissent à livrer des cartes qui ne tombent pas en panne dès le déballage, cela pourrait même devenir intéressant, les derniers tests effectués par le mainteneur de rl(4) semblent plus que prometteurs, à sa grande surprise)
Eric Masson
-- C> Merci de renommer vos fils et sous-fils, sinon c'est le bordel. BdB> Tu parles, c'est si je renomme mon fils que ça va être le bordel. Tu seras une pomme, mon fils -+- pH in <http://www.le-gnu.net>: de pire en père et de pomme en fils.
Annie D.
Eric Belhomme wrote:
à la carte qui est capable de gérer à peu près tout, y compris les calculs/vérification de checksum.
N'est-ce pas le cas de toutes les cartes courantes ?
au contraire !!!
Les cartes les moins cheres (genre Realtek) ne sont capable que de remonter le flux ethernet brut, qui devra etre interprété par le processeur central, alors qu'une bonne carte (une 3c905 ou une eepro100 par exemple) sera capable de désencapsuler le flux ethernet...
Votre réponse catégorique m'a presque mis le doute malgré son apparente énormité. A vous lire, autant dire que ces contrôleurs ne seraient que des registres à décalage. Alors je suis allée chercher les datasheets de quelques contrôleurs ethernet bas de gamme, compatibles NE2000 (on ne doit pas pouvoir faire pire, hein) : le fameux RTL8029 de Realtek et un composant de la famille 8390 de National Semiconductor, celle qui est précisément à l'origine du standard NE2000. Et j'ai lu.
Il en ressort que, bien sûr, comme je le pensais, tous ces composants sont capables d'encapsuler et désencapsuler les trames ethernet, gèrent automatiquement la détection des erreurs et collisions, les retransmissions, le filtrage en réception sur adresse physique, multicast et broadcast. Bien entendu, ils génèrent et vérifient le CRC. Toutes ces fonctions, qui sont quand même le minimum qu'on est en droit d'attendre d'un contrôleur ethernet, font partie du standard NE2000.
Les différences avec les cartes plus haut de gammes sont donc ailleurs. Probablement dans la qualité de conception et de fabrication, l'optimisation, les capacités et performances de l'interface avec le système hôte (efficacité du mode busmaster/DMA par exemple), la taille des buffers d'émission et réception, la gestion de la file d'émission...
Eric Belhomme wrote:
à la carte qui est capable de gérer à peu
près tout, y compris les calculs/vérification de checksum.
N'est-ce pas le cas de toutes les cartes courantes ?
au contraire !!!
Les cartes les moins cheres (genre Realtek) ne sont capable que de remonter
le flux ethernet brut, qui devra etre interprété par le processeur central,
alors qu'une bonne carte (une 3c905 ou une eepro100 par exemple) sera
capable de désencapsuler le flux ethernet...
Votre réponse catégorique m'a presque mis le doute malgré son apparente
énormité. A vous lire, autant dire que ces contrôleurs ne seraient que
des registres à décalage. Alors je suis allée chercher les datasheets de
quelques contrôleurs ethernet bas de gamme, compatibles NE2000 (on ne
doit pas pouvoir faire pire, hein) : le fameux RTL8029 de Realtek et un
composant de la famille 8390 de National Semiconductor, celle qui est
précisément à l'origine du standard NE2000. Et j'ai lu.
Il en ressort que, bien sûr, comme je le pensais, tous ces composants
sont capables d'encapsuler et désencapsuler les trames ethernet, gèrent
automatiquement la détection des erreurs et collisions, les
retransmissions, le filtrage en réception sur adresse physique,
multicast et broadcast. Bien entendu, ils génèrent et vérifient le CRC.
Toutes ces fonctions, qui sont quand même le minimum qu'on est en droit
d'attendre d'un contrôleur ethernet, font partie du standard NE2000.
Les différences avec les cartes plus haut de gammes sont donc ailleurs.
Probablement dans la qualité de conception et de fabrication,
l'optimisation, les capacités et performances de l'interface avec le
système hôte (efficacité du mode busmaster/DMA par exemple), la taille
des buffers d'émission et réception, la gestion de la file d'émission...
à la carte qui est capable de gérer à peu près tout, y compris les calculs/vérification de checksum.
N'est-ce pas le cas de toutes les cartes courantes ?
au contraire !!!
Les cartes les moins cheres (genre Realtek) ne sont capable que de remonter le flux ethernet brut, qui devra etre interprété par le processeur central, alors qu'une bonne carte (une 3c905 ou une eepro100 par exemple) sera capable de désencapsuler le flux ethernet...
Votre réponse catégorique m'a presque mis le doute malgré son apparente énormité. A vous lire, autant dire que ces contrôleurs ne seraient que des registres à décalage. Alors je suis allée chercher les datasheets de quelques contrôleurs ethernet bas de gamme, compatibles NE2000 (on ne doit pas pouvoir faire pire, hein) : le fameux RTL8029 de Realtek et un composant de la famille 8390 de National Semiconductor, celle qui est précisément à l'origine du standard NE2000. Et j'ai lu.
Il en ressort que, bien sûr, comme je le pensais, tous ces composants sont capables d'encapsuler et désencapsuler les trames ethernet, gèrent automatiquement la détection des erreurs et collisions, les retransmissions, le filtrage en réception sur adresse physique, multicast et broadcast. Bien entendu, ils génèrent et vérifient le CRC. Toutes ces fonctions, qui sont quand même le minimum qu'on est en droit d'attendre d'un contrôleur ethernet, font partie du standard NE2000.
Les différences avec les cartes plus haut de gammes sont donc ailleurs. Probablement dans la qualité de conception et de fabrication, l'optimisation, les capacités et performances de l'interface avec le système hôte (efficacité du mode busmaster/DMA par exemple), la taille des buffers d'émission et réception, la gestion de la file d'émission...
Eric Belhomme
"Annie D." wrote in news::
Votre réponse catégorique m'a presque mis le doute malgré son apparente énormité. A vous lire, autant dire que ces contrôleurs ne seraient que des registres à décalage.
bon ben j'ai perdu une bonne occasion de me taire... sans rancune ;)
-- Rico (RicoSpirit) - http://www.ricospirit.net Pour en savoir autant que moi sur INN (c.a.d. pas grand chose !) : http://www.ricospirit.net/inn/
"Annie D." <annie.demur@free.fr> wrote in
news:3F0D4D07.CCC2B60D@free.fr:
Votre réponse catégorique m'a presque mis le doute malgré son
apparente énormité. A vous lire, autant dire que ces contrôleurs ne
seraient que des registres à décalage.
bon ben j'ai perdu une bonne occasion de me taire...
sans rancune ;)
--
Rico (RicoSpirit) - http://www.ricospirit.net
Pour en savoir autant que moi sur INN (c.a.d. pas grand chose !) :
http://www.ricospirit.net/inn/
Votre réponse catégorique m'a presque mis le doute malgré son apparente énormité. A vous lire, autant dire que ces contrôleurs ne seraient que des registres à décalage.
bon ben j'ai perdu une bonne occasion de me taire... sans rancune ;)
-- Rico (RicoSpirit) - http://www.ricospirit.net Pour en savoir autant que moi sur INN (c.a.d. pas grand chose !) : http://www.ricospirit.net/inn/
Annie D.
Eric Belhomme wrote:
bon ben j'ai perdu une bonne occasion de me taire...
Mais non. Votre intervention m'a poussée à remuer ma flemme et à vérifier, et nous avons tous deux appris quelque chose. Soyez-en remercié.
Eric Belhomme wrote:
bon ben j'ai perdu une bonne occasion de me taire...
Mais non. Votre intervention m'a poussée à remuer ma flemme et à
vérifier, et nous avons tous deux appris quelque chose. Soyez-en
remercié.
