Je place mon sniffer sur un brin où circulent des trames 802.1Q.
Tout va bien quand les data sont inférieures à 1496 (1514-14-4). Je les
captures correctement. Cependant, je ne capture pas les trames dont les data
sont supérieurs à 1496.
Y a t il un mode à activer dans le driver de ma carte 3Com 3C920 Integrated
Fast Ethernet Controller (3C905C-TX Compatible)?
Oui mais pour sniffer, il faut un driver NDIS qui aille farfouiller là-dedans, et si par hasard le dit driver est compilé en dur avec une limite à 1500 octets, il risque d'ignorer les trames plus longues...
C'est une possibilité aussi. J'ai essayé avec Etheral, mais c'est pareil il ne voit rien.
Je ne sais pas ce qui provoque le "clignotement", mais je pense que c'est
plutôt au niveau du driver IP que ça se passe, non? No sé...
Je ne penses pas que cela soit IP, mais plutôt au niveau 2, car cela clignote bien au passage des trames Ipx.
Je pencherais plutôt pour un problème au niveau Ethernet vu que c'est à ce niveau qu'est fixée la MTU. D'ailleurs, après décapsulation Ethernet, le datagramme résultant doit bien faire 1500 octets.
Je pense aussi que cela vient du niveau 2. Est ce le driver ou la carte ?
Sachant que IP peut aller jusqu'à 65535, IP ne devrait pas avoir de problèmes.
Il n'y pas de rapport avec IP, car le switch va taggé toutes les trames de type Ethernet qui rentrera sur son port. Peux importe la couche 3.
D'autre part, le sniffer devrait bosser en couche 2 où il intercepte la totalité de la trame pour l'interprêter. Si Sebastien ne voit pas ses trames au niveau du sniffer, ca semble vouloir dire que celles-ci ont été rejetées par l'interface.
J'en ai peur, mais comme le disait Jacques, il se peux aussi que se soit le Driver qui ne remonte pas la trame.
D'où ma question d'origine qui est comment faire pour visualiser une trame Ethernet suppérieur à1518 ?
Sur la compatibilité des carte, je ne sais pas, mais j'ai vu que l'on pouvait gérer les Vlan sur un Linux. Donc cela signifie que la carte Ethernet du Linux sait gérer des trames suppérieurs à 1518 !
Une autre solution peut être de diminuer la MTU de 4 octets sur les machines participant au dialogue, ou routeurs intermédiaires, pour avoir une trame qui fait bien 1518 octets au niveau du port monitoré. Ca ressemble à une ruse de Sioux pas très propre, mais bon...
Oui, mais ce n'est pas possible, par exemple, je voudrais sniffer un lien backbone Internet "Vlélanéisé" (avec des Vlan). De plus, c'est aussi pour comprendre l'interaction générale du matériel du marché avec les Vlan.
Sebastien Fontaine
"T0t0" <bibi@antionline.org> a écrit dans le message de news:
60a904f33b83171c79e20f6dc67501be.28089@mygate.mailgate.org...
"Jacques Caron" <jc@imfeurope.com> wrote in message
news:oprxh5uvitq1hokb@news.free.fr
Oui mais pour sniffer, il faut un driver NDIS qui aille farfouiller
là-dedans, et si par hasard le dit driver est compilé en dur avec une
limite à 1500 octets, il risque d'ignorer les trames plus longues...
C'est une possibilité aussi. J'ai essayé avec Etheral, mais c'est pareil il
ne voit rien.
Je ne sais pas ce qui provoque le "clignotement", mais je pense que
c'est
plutôt au niveau du driver IP que ça se passe, non? No sé...
Je ne penses pas que cela soit IP, mais plutôt au niveau 2, car cela
clignote bien au passage des trames Ipx.
Je pencherais plutôt pour un problème au niveau Ethernet vu que c'est
à ce niveau qu'est fixée la MTU. D'ailleurs, après décapsulation
Ethernet, le datagramme résultant doit bien faire 1500 octets.
Je pense aussi que cela vient du niveau 2. Est ce le driver ou la carte ?
Sachant que IP peut aller jusqu'à 65535, IP ne devrait pas avoir de
problèmes.
Il n'y pas de rapport avec IP, car le switch va taggé toutes les trames de
type Ethernet qui rentrera sur son port. Peux importe la couche 3.
D'autre part, le sniffer devrait bosser en couche 2 où il intercepte
la totalité de la trame pour l'interprêter.
Si Sebastien ne voit pas ses trames au niveau du sniffer, ca semble
vouloir dire que celles-ci ont été rejetées par l'interface.
J'en ai peur, mais comme le disait Jacques, il se peux aussi que se soit le
Driver qui ne remonte pas la trame.
D'où ma question d'origine qui est comment faire pour visualiser une trame
Ethernet suppérieur à1518 ?
Sur la compatibilité des carte, je ne sais pas, mais j'ai vu que l'on
pouvait gérer les Vlan sur un Linux. Donc cela signifie que la carte
Ethernet du Linux sait gérer des trames suppérieurs à 1518 !
Une autre solution peut être de diminuer la MTU de 4 octets sur les
machines participant au dialogue, ou routeurs intermédiaires, pour
avoir une trame qui fait bien 1518 octets au niveau du port monitoré.
Ca ressemble à une ruse de Sioux pas très propre, mais bon...
Oui, mais ce n'est pas possible, par exemple, je voudrais sniffer un lien
backbone Internet "Vlélanéisé" (avec des Vlan).
De plus, c'est aussi pour comprendre l'interaction générale du matériel du
marché avec les Vlan.
Oui mais pour sniffer, il faut un driver NDIS qui aille farfouiller là-dedans, et si par hasard le dit driver est compilé en dur avec une limite à 1500 octets, il risque d'ignorer les trames plus longues...
C'est une possibilité aussi. J'ai essayé avec Etheral, mais c'est pareil il ne voit rien.
Je ne sais pas ce qui provoque le "clignotement", mais je pense que c'est
plutôt au niveau du driver IP que ça se passe, non? No sé...
Je ne penses pas que cela soit IP, mais plutôt au niveau 2, car cela clignote bien au passage des trames Ipx.
Je pencherais plutôt pour un problème au niveau Ethernet vu que c'est à ce niveau qu'est fixée la MTU. D'ailleurs, après décapsulation Ethernet, le datagramme résultant doit bien faire 1500 octets.
Je pense aussi que cela vient du niveau 2. Est ce le driver ou la carte ?
Sachant que IP peut aller jusqu'à 65535, IP ne devrait pas avoir de problèmes.
Il n'y pas de rapport avec IP, car le switch va taggé toutes les trames de type Ethernet qui rentrera sur son port. Peux importe la couche 3.
D'autre part, le sniffer devrait bosser en couche 2 où il intercepte la totalité de la trame pour l'interprêter. Si Sebastien ne voit pas ses trames au niveau du sniffer, ca semble vouloir dire que celles-ci ont été rejetées par l'interface.
J'en ai peur, mais comme le disait Jacques, il se peux aussi que se soit le Driver qui ne remonte pas la trame.
D'où ma question d'origine qui est comment faire pour visualiser une trame Ethernet suppérieur à1518 ?
Sur la compatibilité des carte, je ne sais pas, mais j'ai vu que l'on pouvait gérer les Vlan sur un Linux. Donc cela signifie que la carte Ethernet du Linux sait gérer des trames suppérieurs à 1518 !
Une autre solution peut être de diminuer la MTU de 4 octets sur les machines participant au dialogue, ou routeurs intermédiaires, pour avoir une trame qui fait bien 1518 octets au niveau du port monitoré. Ca ressemble à une ruse de Sioux pas très propre, mais bon...
Oui, mais ce n'est pas possible, par exemple, je voudrais sniffer un lien backbone Internet "Vlélanéisé" (avec des Vlan). De plus, c'est aussi pour comprendre l'interaction générale du matériel du marché avec les Vlan.
Sebastien Fontaine
Jacques Caron
On Thu, 23 Oct 2003 18:40:16 +0200, Fontaine Sebastien wrote:
C'est une possibilité aussi. J'ai essayé avec Etheral, mais c'est pareil il ne voit rien.
Mais il voit bien les trames plus petites?
J'ai jeté un oeil dans le code de winpcap et je ne vois pas de limitation, et théoriquement il ne devrait pas y en avoir non plus au niveau de Windows. Tu peux essayer d'activer 802.1p par contre, en théorie ça devrait forcer le driver à virer l'en-tête 802.1Q et à le mettre ailleurs, mais bon, c'est la théorie :-)
Sinon tu télécharges les sources de winpcap, tu compiles en mode debug, tu lances windump, et tu regardes les logs pour voir ce qu'il raconte. Tiens, d'ailleurs, le journal d'événements de Windows ne dit rien d'intéressant je suppose?
Je ne penses pas que cela soit IP, mais plutôt au niveau 2, car cela clignote bien au passage des trames Ipx.
Question idiote, tu n'as rien entre l'équipement qui envoie les trames tagguées 802.1Q et ton PC qui risquerait de ne pas laisser passer les trames trop longues, par hasard? La LED d'activité de ta carte clignote bien quand tu reçois de telles trames?
Sur la compatibilité des carte, je ne sais pas, mais j'ai vu que l'on pouvait gérer les Vlan sur un Linux. Donc cela signifie que la carte Ethernet du Linux sait gérer des trames suppérieurs à 1518 !
Oui, a priori la carte supporte les trames longues, et on peut faire des VLANs avec, même si le driver Windows ne semble pas les gérer. Mais il devrait au moins recevoir les trames et les balancer aux protocoles supérieurs... Sinon il ne te reste plus qu'à installer un bon *BSD ou Linux :-)
Jacques. -- Interactive Media Factory Création, développement et hébergement de services interactifs: SMS, SMS+, Audiotel... http://www.imfeurope.com/
On Thu, 23 Oct 2003 18:40:16 +0200, Fontaine Sebastien
<Fontaine.Sebastien@nonononoLaposte.net> wrote:
C'est une possibilité aussi. J'ai essayé avec Etheral, mais c'est pareil
il ne voit rien.
Mais il voit bien les trames plus petites?
J'ai jeté un oeil dans le code de winpcap et je ne vois pas de limitation,
et théoriquement il ne devrait pas y en avoir non plus au niveau de
Windows. Tu peux essayer d'activer 802.1p par contre, en théorie ça
devrait forcer le driver à virer l'en-tête 802.1Q et à le mettre ailleurs,
mais bon, c'est la théorie :-)
Sinon tu télécharges les sources de winpcap, tu compiles en mode debug, tu
lances windump, et tu regardes les logs pour voir ce qu'il raconte. Tiens,
d'ailleurs, le journal d'événements de Windows ne dit rien d'intéressant
je suppose?
Je ne penses pas que cela soit IP, mais plutôt au niveau 2, car cela
clignote bien au passage des trames Ipx.
Question idiote, tu n'as rien entre l'équipement qui envoie les trames
tagguées 802.1Q et ton PC qui risquerait de ne pas laisser passer les
trames trop longues, par hasard? La LED d'activité de ta carte clignote
bien quand tu reçois de telles trames?
Sur la compatibilité des carte, je ne sais pas, mais j'ai vu que l'on
pouvait gérer les Vlan sur un Linux. Donc cela signifie que la carte
Ethernet du Linux sait gérer des trames suppérieurs à 1518 !
Oui, a priori la carte supporte les trames longues, et on peut faire des
VLANs avec, même si le driver Windows ne semble pas les gérer. Mais il
devrait au moins recevoir les trames et les balancer aux protocoles
supérieurs... Sinon il ne te reste plus qu'à installer un bon *BSD ou
Linux :-)
Jacques.
--
Interactive Media Factory
Création, développement et hébergement
de services interactifs: SMS, SMS+, Audiotel...
http://www.imfeurope.com/
On Thu, 23 Oct 2003 18:40:16 +0200, Fontaine Sebastien wrote:
C'est une possibilité aussi. J'ai essayé avec Etheral, mais c'est pareil il ne voit rien.
Mais il voit bien les trames plus petites?
J'ai jeté un oeil dans le code de winpcap et je ne vois pas de limitation, et théoriquement il ne devrait pas y en avoir non plus au niveau de Windows. Tu peux essayer d'activer 802.1p par contre, en théorie ça devrait forcer le driver à virer l'en-tête 802.1Q et à le mettre ailleurs, mais bon, c'est la théorie :-)
Sinon tu télécharges les sources de winpcap, tu compiles en mode debug, tu lances windump, et tu regardes les logs pour voir ce qu'il raconte. Tiens, d'ailleurs, le journal d'événements de Windows ne dit rien d'intéressant je suppose?
Je ne penses pas que cela soit IP, mais plutôt au niveau 2, car cela clignote bien au passage des trames Ipx.
Question idiote, tu n'as rien entre l'équipement qui envoie les trames tagguées 802.1Q et ton PC qui risquerait de ne pas laisser passer les trames trop longues, par hasard? La LED d'activité de ta carte clignote bien quand tu reçois de telles trames?
Sur la compatibilité des carte, je ne sais pas, mais j'ai vu que l'on pouvait gérer les Vlan sur un Linux. Donc cela signifie que la carte Ethernet du Linux sait gérer des trames suppérieurs à 1518 !
Oui, a priori la carte supporte les trames longues, et on peut faire des VLANs avec, même si le driver Windows ne semble pas les gérer. Mais il devrait au moins recevoir les trames et les balancer aux protocoles supérieurs... Sinon il ne te reste plus qu'à installer un bon *BSD ou Linux :-)
Jacques. -- Interactive Media Factory Création, développement et hébergement de services interactifs: SMS, SMS+, Audiotel... http://www.imfeurope.com/
Fontaine Sebastien
"Jacques Caron" a écrit dans le message de news:
Mais il voit bien les trames plus petites?
Oui les trois analyseurs voient les trames inférieurs à 1496. Ce qui me permet de décoder les quatres octets.
J'ai jeté un oeil dans le code de winpcap et je ne vois pas de limitation, et théoriquement il ne devrait pas y en avoir non plus au niveau de Windows. Tu peux essayer d'activer 802.1p par contre, en théorie ça devrait forcer le driver à virer l'en-tête 802.1Q et à le mettre ailleurs, mais bon, c'est la théorie :-)
Sinon tu télécharges les sources de winpcap, tu compiles en mode debug, tu lances windump, et tu regardes les logs pour voir ce qu'il raconte.
C'est une bonne idée, pas évidant à faire, mais je vais voir si je trouve un creno pour m'y pencher.
Tiens, d'ailleurs, le journal d'événements de Windows ne dit rien d'intéressant
je suppose?
Je n'ai pas vérifié, je vais le faire.
Question idiote, tu n'as rien entre l'équipement qui envoie les trames tagguées 802.1Q et ton PC qui risquerait de ne pas laisser passer les trames trop longues, par hasard?
Non je suis en croisé directement sur le port Trunck
La LED d'activité de ta carte clignote bien quand tu reçois de telles trames?
Pas vérifié, bonne idée
Oui, a priori la carte supporte les trames longues, et on peut faire des VLANs avec, même si le driver Windows ne semble pas les gérer. Mais il devrait au moins recevoir les trames et les balancer aux protocoles supérieurs...
Oui, Sauf si la carte ne les redistribue pas physiquement.
Sinon il ne te reste plus qu'à installer un bon *BSD ou Linux :-)
:)
Sebastien Fontaine
"Jacques Caron" <jc@imfeurope.com> a écrit dans le message de news:
oprxib2lx4q1hokb@news.free.fr...
Mais il voit bien les trames plus petites?
Oui les trois analyseurs voient les trames inférieurs à 1496. Ce qui me
permet de décoder les quatres octets.
J'ai jeté un oeil dans le code de winpcap et je ne vois pas de limitation,
et théoriquement il ne devrait pas y en avoir non plus au niveau de
Windows. Tu peux essayer d'activer 802.1p par contre, en théorie ça
devrait forcer le driver à virer l'en-tête 802.1Q et à le mettre ailleurs,
mais bon, c'est la théorie :-)
Sinon tu télécharges les sources de winpcap, tu compiles en mode debug, tu
lances windump, et tu regardes les logs pour voir ce qu'il raconte.
C'est une bonne idée, pas évidant à faire, mais je vais voir si je trouve un
creno pour m'y pencher.
Tiens, d'ailleurs, le journal d'événements de Windows ne dit rien
d'intéressant
je suppose?
Je n'ai pas vérifié, je vais le faire.
Question idiote, tu n'as rien entre l'équipement qui envoie les trames
tagguées 802.1Q et ton PC qui risquerait de ne pas laisser passer les
trames trop longues, par hasard?
Non je suis en croisé directement sur le port Trunck
La LED d'activité de ta carte clignote
bien quand tu reçois de telles trames?
Pas vérifié, bonne idée
Oui, a priori la carte supporte les trames longues, et on peut faire des
VLANs avec, même si le driver Windows ne semble pas les gérer. Mais il
devrait au moins recevoir les trames et les balancer aux protocoles
supérieurs...
Oui, Sauf si la carte ne les redistribue pas physiquement.
Sinon il ne te reste plus qu'à installer un bon *BSD ou
Linux :-)
Oui les trois analyseurs voient les trames inférieurs à 1496. Ce qui me permet de décoder les quatres octets.
J'ai jeté un oeil dans le code de winpcap et je ne vois pas de limitation, et théoriquement il ne devrait pas y en avoir non plus au niveau de Windows. Tu peux essayer d'activer 802.1p par contre, en théorie ça devrait forcer le driver à virer l'en-tête 802.1Q et à le mettre ailleurs, mais bon, c'est la théorie :-)
Sinon tu télécharges les sources de winpcap, tu compiles en mode debug, tu lances windump, et tu regardes les logs pour voir ce qu'il raconte.
C'est une bonne idée, pas évidant à faire, mais je vais voir si je trouve un creno pour m'y pencher.
Tiens, d'ailleurs, le journal d'événements de Windows ne dit rien d'intéressant
je suppose?
Je n'ai pas vérifié, je vais le faire.
Question idiote, tu n'as rien entre l'équipement qui envoie les trames tagguées 802.1Q et ton PC qui risquerait de ne pas laisser passer les trames trop longues, par hasard?
Non je suis en croisé directement sur le port Trunck
La LED d'activité de ta carte clignote bien quand tu reçois de telles trames?
Pas vérifié, bonne idée
Oui, a priori la carte supporte les trames longues, et on peut faire des VLANs avec, même si le driver Windows ne semble pas les gérer. Mais il devrait au moins recevoir les trames et les balancer aux protocoles supérieurs...
Oui, Sauf si la carte ne les redistribue pas physiquement.
Sinon il ne te reste plus qu'à installer un bon *BSD ou Linux :-)
:)
Sebastien Fontaine
Vincent Bernat
OoO En cette aube naissante du jeudi 23 octobre 2003, vers 07:15, Jacques Caron disait:
Nope, mais je pense que c'est une question de génération, et j'ai tendance à penser qu'une 920 c'est plus récent qu'une 905, donc ça devrait avoir un chip "cyclone". Mais ce n'est que pure conjecture...
Une 920, c'est une 905 mais en ASIC. A priori, pas de raison particulière que ce soit plus récent qu'une 905 récente (donc C). Cela dit, il est possible que les 920 soient toutes à base de cyclone. -- die_if_kernel("Whee... Hello Mr. Penguin", current->tss.kregs); 2.2.16 /usr/src/linux/arch/sparc/kernel/traps.c
OoO En cette aube naissante du jeudi 23 octobre 2003, vers 07:15,
Jacques Caron <jc@imfeurope.com> disait:
Nope, mais je pense que c'est une question de génération, et j'ai
tendance à penser qu'une 920 c'est plus récent qu'une 905, donc ça
devrait avoir un chip "cyclone". Mais ce n'est que pure
conjecture...
Une 920, c'est une 905 mais en ASIC. A priori, pas de raison
particulière que ce soit plus récent qu'une 905 récente (donc C). Cela
dit, il est possible que les 920 soient toutes à base de cyclone.
--
die_if_kernel("Whee... Hello Mr. Penguin", current->tss.kregs);
2.2.16 /usr/src/linux/arch/sparc/kernel/traps.c
OoO En cette aube naissante du jeudi 23 octobre 2003, vers 07:15, Jacques Caron disait:
Nope, mais je pense que c'est une question de génération, et j'ai tendance à penser qu'une 920 c'est plus récent qu'une 905, donc ça devrait avoir un chip "cyclone". Mais ce n'est que pure conjecture...
Une 920, c'est une 905 mais en ASIC. A priori, pas de raison particulière que ce soit plus récent qu'une 905 récente (donc C). Cela dit, il est possible que les 920 soient toutes à base de cyclone. -- die_if_kernel("Whee... Hello Mr. Penguin", current->tss.kregs); 2.2.16 /usr/src/linux/arch/sparc/kernel/traps.c
T0t0
"Fontaine Sebastien" wrote in message news:3f98052e$0$245$
D'où ma question d'origine qui est comment faire pour visualiser une trame Ethernet suppérieur à1518 ?
Il faut que la MTU de ta carte lui permette de remonter des trames de plus de 1518 octets.
En gros, si je refais le raisonnement. Ta carte reçoit une trame. Elle commence la lecture, regarde l'adresse MAC de destination, c'est elle donc elle continue la lecture. Arrivée au 1518 octet, elle doit cesser de lire, ou rejeter la trame d'une façon ou d'une autre, et peut-être même renvoyer un code d'erreur quelque part (il faudrait voir au niveau du driver) Donc la trame reçue est perdue, donc pas renvoyée à la couche NDIS, ton sniffer ne peut donc rien voir.
Je crois que sniffer pro propose des packages avec une carte réseau intégrée qui permet de faire ce qu'on veut au niveau réseau, à voir.
A mon avis, tant que les trames ont une taille plus grande que la MTU configurée, aucune chance de les voir...
Sur la compatibilité des carte, je ne sais pas, mais j'ai vu que l'on pouvait gérer les Vlan sur un Linux. Donc cela signifie que la carte Ethernet du Linux sait gérer des trames suppérieurs à 1518 !
Le driver implémenté sous linux permet surement de gérer la MTU. D'ailleurs, il doit aussi pouvoir le faire sous windows, mais ce n'est peut-être pas accessible par l'interface graphique. Gogo code...
Une autre solution peut être de diminuer la MTU de 4 octets sur les machines participant au dialogue, ou routeurs intermédiaires, pour avoir une trame qui fait bien 1518 octets au niveau du port monitoré. Ca ressemble à une ruse de Sioux pas très propre, mais bon... Oui, mais ce n'est pas possible, par exemple, je voudrais sniffer un lien
backbone Internet "Vlélanéisé" (avec des Vlan).
Il suffit de diminuer la MTU des routeurs situés en entrée et sortie du réseau que tu sniffes.
De plus, c'est aussi pour comprendre l'interaction générale du matériel du marché avec les Vlan.
Effectivement, c'est une problématique que je n'avais jamais rencontré. Je vais essayer de trouver de la doc cet aprem... Tes retours si tu t'en sors intéresseront sûrement le groupe :-)
Sinon, est-ce que quelqu'un a une carte réseau dont le driver sous windows permet de modifier la MTU ? J'en ai déjà eu, mais je ne me rappelle plus où :-(
-- Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
"Fontaine Sebastien" <Fontaine.Sebastien@nonononoLaposte.net> wrote in
message news:3f98052e$0$245$4d4eb98e@read.news.fr.uu.net
D'où ma question d'origine qui est comment faire pour visualiser une trame
Ethernet suppérieur à1518 ?
Il faut que la MTU de ta carte lui permette de remonter des trames de
plus de 1518 octets.
En gros, si je refais le raisonnement.
Ta carte reçoit une trame. Elle commence la lecture, regarde l'adresse
MAC de destination, c'est elle donc elle continue la lecture.
Arrivée au 1518 octet, elle doit cesser de lire, ou rejeter la trame
d'une façon ou d'une autre, et peut-être même renvoyer un code
d'erreur quelque part (il faudrait voir au niveau du driver)
Donc la trame reçue est perdue, donc pas renvoyée à la couche NDIS,
ton sniffer ne peut donc rien voir.
Je crois que sniffer pro propose des packages avec une carte réseau
intégrée qui permet de faire ce qu'on veut au niveau réseau, à voir.
A mon avis, tant que les trames ont une taille plus grande que la MTU
configurée, aucune chance de les voir...
Sur la compatibilité des carte, je ne sais pas, mais j'ai vu que l'on
pouvait gérer les Vlan sur un Linux. Donc cela signifie que la carte
Ethernet du Linux sait gérer des trames suppérieurs à 1518 !
Le driver implémenté sous linux permet surement de gérer la MTU.
D'ailleurs, il doit aussi pouvoir le faire sous windows, mais ce n'est
peut-être pas accessible par l'interface graphique.
Gogo code...
Une autre solution peut être de diminuer la MTU de 4 octets sur les
machines participant au dialogue, ou routeurs intermédiaires, pour
avoir une trame qui fait bien 1518 octets au niveau du port monitoré.
Ca ressemble à une ruse de Sioux pas très propre, mais bon...
Oui, mais ce n'est pas possible, par exemple, je voudrais sniffer un lien
backbone Internet "Vlélanéisé" (avec des Vlan).
Il suffit de diminuer la MTU des routeurs situés en entrée et sortie
du réseau que tu sniffes.
De plus, c'est aussi pour comprendre l'interaction générale du matériel du
marché avec les Vlan.
Effectivement, c'est une problématique que je n'avais jamais rencontré.
Je vais essayer de trouver de la doc cet aprem...
Tes retours si tu t'en sors intéresseront sûrement le groupe :-)
Sinon, est-ce que quelqu'un a une carte réseau dont le driver sous
windows permet de modifier la MTU ?
J'en ai déjà eu, mais je ne me rappelle plus où :-(
--
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
"Fontaine Sebastien" wrote in message news:3f98052e$0$245$
D'où ma question d'origine qui est comment faire pour visualiser une trame Ethernet suppérieur à1518 ?
Il faut que la MTU de ta carte lui permette de remonter des trames de plus de 1518 octets.
En gros, si je refais le raisonnement. Ta carte reçoit une trame. Elle commence la lecture, regarde l'adresse MAC de destination, c'est elle donc elle continue la lecture. Arrivée au 1518 octet, elle doit cesser de lire, ou rejeter la trame d'une façon ou d'une autre, et peut-être même renvoyer un code d'erreur quelque part (il faudrait voir au niveau du driver) Donc la trame reçue est perdue, donc pas renvoyée à la couche NDIS, ton sniffer ne peut donc rien voir.
Je crois que sniffer pro propose des packages avec une carte réseau intégrée qui permet de faire ce qu'on veut au niveau réseau, à voir.
A mon avis, tant que les trames ont une taille plus grande que la MTU configurée, aucune chance de les voir...
Sur la compatibilité des carte, je ne sais pas, mais j'ai vu que l'on pouvait gérer les Vlan sur un Linux. Donc cela signifie que la carte Ethernet du Linux sait gérer des trames suppérieurs à 1518 !
Le driver implémenté sous linux permet surement de gérer la MTU. D'ailleurs, il doit aussi pouvoir le faire sous windows, mais ce n'est peut-être pas accessible par l'interface graphique. Gogo code...
Une autre solution peut être de diminuer la MTU de 4 octets sur les machines participant au dialogue, ou routeurs intermédiaires, pour avoir une trame qui fait bien 1518 octets au niveau du port monitoré. Ca ressemble à une ruse de Sioux pas très propre, mais bon... Oui, mais ce n'est pas possible, par exemple, je voudrais sniffer un lien
backbone Internet "Vlélanéisé" (avec des Vlan).
Il suffit de diminuer la MTU des routeurs situés en entrée et sortie du réseau que tu sniffes.
De plus, c'est aussi pour comprendre l'interaction générale du matériel du marché avec les Vlan.
Effectivement, c'est une problématique que je n'avais jamais rencontré. Je vais essayer de trouver de la doc cet aprem... Tes retours si tu t'en sors intéresseront sûrement le groupe :-)
Sinon, est-ce que quelqu'un a une carte réseau dont le driver sous windows permet de modifier la MTU ? J'en ai déjà eu, mais je ne me rappelle plus où :-(
-- Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
T0t0
"Fontaine Sebastien" wrote in message news:3f98052e$0$245$
D'où ma question d'origine qui est comment faire pour visualiser une trame Ethernet suppérieur à1518 ?
