J'ai mis un bridge ethernet sur le passage de ce cable et 'iftop' ne
voit aucun traffic.
Ceci dit, tcpdump et les compteurs de paquets d'ifconfig voient
quelquechose qui passe.
http://www.google.com/search?q=iftop+vlan me laisse penser que par
defaut, iftop ne voit en effet pas de traffic quand on lui demande de
monitorer une interface par laquelle passe _des_ VLANs.
J'ai assez peu d'expérience des VLANs, mais est-ce normal qu'iftop ne
voit rien?
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
Alex Chauvin
Mihamina Rakotomandimby wrote:
Bonjour,
Par un cable reseau, il passe plusieurs VLANs
J'ai mis un bridge ethernet sur le passage de ce cable et 'iftop' ne voit aucun traffic.
Ceci dit, tcpdump et les compteurs de paquets d'ifconfig voient quelquechose qui passe.
http://www.google.com/search?q=iftop+vlan me laisse penser que par defaut, iftop ne voit en effet pas de traffic quand on lui demande de monitorer une interface par laquelle passe _des_ VLANs.
J'ai assez peu d'expérience des VLANs, mais est-ce normal qu'iftop ne voit rien?
Suivi sur fr.comp.reseaux.ethernet
il s'attend peut-être à voir de l'IP, or ce n'est pas le cas. Ils disent quoi dans la doc ?
alex.
Mihamina Rakotomandimby wrote:
Bonjour,
Par un cable reseau, il passe plusieurs VLANs
J'ai mis un bridge ethernet sur le passage de ce cable et 'iftop' ne
voit aucun traffic.
Ceci dit, tcpdump et les compteurs de paquets d'ifconfig voient
quelquechose qui passe.
http://www.google.com/search?q=iftop+vlan me laisse penser que par
defaut, iftop ne voit en effet pas de traffic quand on lui demande de
monitorer une interface par laquelle passe _des_ VLANs.
J'ai assez peu d'expérience des VLANs, mais est-ce normal qu'iftop ne
voit rien?
Suivi sur fr.comp.reseaux.ethernet
il s'attend peut-être à voir de l'IP, or ce n'est pas le cas. Ils disent
quoi dans la doc ?
J'ai mis un bridge ethernet sur le passage de ce cable et 'iftop' ne voit aucun traffic.
Ceci dit, tcpdump et les compteurs de paquets d'ifconfig voient quelquechose qui passe.
http://www.google.com/search?q=iftop+vlan me laisse penser que par defaut, iftop ne voit en effet pas de traffic quand on lui demande de monitorer une interface par laquelle passe _des_ VLANs.
J'ai assez peu d'expérience des VLANs, mais est-ce normal qu'iftop ne voit rien?
Suivi sur fr.comp.reseaux.ethernet
il s'attend peut-être à voir de l'IP, or ce n'est pas le cas. Ils disent quoi dans la doc ?
alex.
Pascal Hambourg
Salut,
Alex Chauvin a écrit :
il s'attend peut-être à voir de l'IP, or ce n'est pas le cas. Ils disent quoi dans la doc ?
Le changelog d'iftop dit qu'il est censé supporter les trames taggées depuis la version 0.17. D'après le code, il examine l'ethertype et si c'est celui d'une trame tagguée (0x8100) il examine l'ethertype situé après le tag.
Salut,
Alex Chauvin a écrit :
il s'attend peut-être à voir de l'IP, or ce n'est pas le cas. Ils disent
quoi dans la doc ?
Le changelog d'iftop dit qu'il est censé supporter les trames taggées
depuis la version 0.17. D'après le code, il examine l'ethertype et si
c'est celui d'une trame tagguée (0x8100) il examine l'ethertype situé
après le tag.
il s'attend peut-être à voir de l'IP, or ce n'est pas le cas. Ils disent quoi dans la doc ?
Le changelog d'iftop dit qu'il est censé supporter les trames taggées depuis la version 0.17. D'après le code, il examine l'ethertype et si c'est celui d'une trame tagguée (0x8100) il examine l'ethertype situé après le tag.
Mihamina Rakotomandimby
09/09/2009 02:34 PM, Pascal Hambourg:
il s'attend peut-être à voir de l'IP, or ce n'est pas le cas. Ils disent quoi dans la doc ?
Le changelog d'iftop dit qu'il est censé supporter les trames taggées depuis la version 0.17. D'après le code, il examine l'ethertype et si c'est celui d'une trame tagguée (0x8100) il examine l'ethertype situé après le tag.
Flute, j'ai la .17, mais il "voit" pas...: http://packages.debian.org/lenny/iftop
Bon,...
09/09/2009 02:34 PM, Pascal Hambourg:
il s'attend peut-être à voir de l'IP, or ce n'est pas le cas. Ils disent
quoi dans la doc ?
Le changelog d'iftop dit qu'il est censé supporter les trames taggées
depuis la version 0.17. D'après le code, il examine l'ethertype et si
c'est celui d'une trame tagguée (0x8100) il examine l'ethertype situé
après le tag.
Flute, j'ai la .17, mais il "voit" pas...:
http://packages.debian.org/lenny/iftop
il s'attend peut-être à voir de l'IP, or ce n'est pas le cas. Ils disent quoi dans la doc ?
Le changelog d'iftop dit qu'il est censé supporter les trames taggées depuis la version 0.17. D'après le code, il examine l'ethertype et si c'est celui d'une trame tagguée (0x8100) il examine l'ethertype situé après le tag.
Flute, j'ai la .17, mais il "voit" pas...: http://packages.debian.org/lenny/iftop
Bon,...
Pascal Hambourg
Mihamina Rakotomandimby a écrit :
09/09/2009 02:34 PM, Pascal Hambourg:
il s'attend peut-être à voir de l'IP, or ce n'est pas le cas. Ils disent quoi dans la doc ?
Le changelog d'iftop dit qu'il est censé supporter les trames taggées depuis la version 0.17. D'après le code, il examine l'ethertype et si c'est celui d'une trame tagguée (0x8100) il examine l'ethertype situé après le tag.
Flute, j'ai la .17, mais il "voit" pas...:
Après lecture plus attentive, je vois que le filtre de capture pcap défini dans la fonction set_filter_code() d'iftop.c est un ET logique entre la valeur de l'option -f et "ip", donc iftop ne voit que les paquets avec l'ethertype IPv4. Du coup le test de l'ethertype VLAN ne sert à rien. Il faut modifier le filtre résultant pour y intégrer le cas d'une trame VLAN :
--- iftop.c-orig 2009-09-10 11:36:22.000000000 +0200 +++ iftop.c 2009-09-10 12:10:55.000000000 +0200 @@ -452,10 +452,10 @@ char *set_filter_code(const char *filter) { char *x; if (filter) { - x = xmalloc(strlen(filter) + sizeof "() and ip"); - sprintf(x, "(%s) and ip", filter); + x = xmalloc(strlen(filter)*2 + sizeof "(ip and ()) or (vlan and ip and ())"); + sprintf(x, "(ip and (%s)) or (vlan and ip and (%s))", filter, filter); } else - x = xstrdup("ip"); + x = xstrdup("ip or (vlan and ip)"); if (pcap_compile(pd, &pcap_filter, x, 1, 0) == -1) { xfree(x); return pcap_geterr(pd);
(corriger les deux retours à la ligne intempestifs) J'ai été obligé de répéter %s parce que l'occurence de "vlan" introduit un offset dans les champs suivants, donc "ip or vlan" ne marchait pas toujours. Autre possibilité : ne pas ajouter "and ip".
Mihamina Rakotomandimby a écrit :
09/09/2009 02:34 PM, Pascal Hambourg:
il s'attend peut-être à voir de l'IP, or ce n'est pas le cas. Ils disent
quoi dans la doc ?
Le changelog d'iftop dit qu'il est censé supporter les trames taggées
depuis la version 0.17. D'après le code, il examine l'ethertype et si
c'est celui d'une trame tagguée (0x8100) il examine l'ethertype situé
après le tag.
Flute, j'ai la .17, mais il "voit" pas...:
Après lecture plus attentive, je vois que le filtre de capture pcap
défini dans la fonction set_filter_code() d'iftop.c est un ET logique
entre la valeur de l'option -f et "ip", donc iftop ne voit que les
paquets avec l'ethertype IPv4. Du coup le test de l'ethertype VLAN ne
sert à rien. Il faut modifier le filtre résultant pour y intégrer le cas
d'une trame VLAN :
--- iftop.c-orig 2009-09-10 11:36:22.000000000 +0200
+++ iftop.c 2009-09-10 12:10:55.000000000 +0200
@@ -452,10 +452,10 @@
char *set_filter_code(const char *filter) {
char *x;
if (filter) {
- x = xmalloc(strlen(filter) + sizeof "() and ip");
- sprintf(x, "(%s) and ip", filter);
+ x = xmalloc(strlen(filter)*2 + sizeof "(ip and ()) or (vlan and
ip and ())");
+ sprintf(x, "(ip and (%s)) or (vlan and ip and (%s))", filter,
filter);
} else
- x = xstrdup("ip");
+ x = xstrdup("ip or (vlan and ip)");
if (pcap_compile(pd, &pcap_filter, x, 1, 0) == -1) {
xfree(x);
return pcap_geterr(pd);
(corriger les deux retours à la ligne intempestifs)
J'ai été obligé de répéter %s parce que l'occurence de "vlan" introduit
un offset dans les champs suivants, donc "ip or vlan" ne marchait pas
toujours.
Autre possibilité : ne pas ajouter "and ip".
il s'attend peut-être à voir de l'IP, or ce n'est pas le cas. Ils disent quoi dans la doc ?
Le changelog d'iftop dit qu'il est censé supporter les trames taggées depuis la version 0.17. D'après le code, il examine l'ethertype et si c'est celui d'une trame tagguée (0x8100) il examine l'ethertype situé après le tag.
Flute, j'ai la .17, mais il "voit" pas...:
Après lecture plus attentive, je vois que le filtre de capture pcap défini dans la fonction set_filter_code() d'iftop.c est un ET logique entre la valeur de l'option -f et "ip", donc iftop ne voit que les paquets avec l'ethertype IPv4. Du coup le test de l'ethertype VLAN ne sert à rien. Il faut modifier le filtre résultant pour y intégrer le cas d'une trame VLAN :
--- iftop.c-orig 2009-09-10 11:36:22.000000000 +0200 +++ iftop.c 2009-09-10 12:10:55.000000000 +0200 @@ -452,10 +452,10 @@ char *set_filter_code(const char *filter) { char *x; if (filter) { - x = xmalloc(strlen(filter) + sizeof "() and ip"); - sprintf(x, "(%s) and ip", filter); + x = xmalloc(strlen(filter)*2 + sizeof "(ip and ()) or (vlan and ip and ())"); + sprintf(x, "(ip and (%s)) or (vlan and ip and (%s))", filter, filter); } else - x = xstrdup("ip"); + x = xstrdup("ip or (vlan and ip)"); if (pcap_compile(pd, &pcap_filter, x, 1, 0) == -1) { xfree(x); return pcap_geterr(pd);
(corriger les deux retours à la ligne intempestifs) J'ai été obligé de répéter %s parce que l'occurence de "vlan" introduit un offset dans les champs suivants, donc "ip or vlan" ne marchait pas toujours. Autre possibilité : ne pas ajouter "and ip".
Pascal Hambourg
Pascal Hambourg a écrit :
Mihamina Rakotomandimby a écrit :
Flute, j'ai la .17, mais il "voit" pas...:
[...] Il faut modifier le filtre résultant pour y intégrer le cas d'une trame VLAN :
Tu as pu tester si ça marche pour toi ?
Pascal Hambourg a écrit :
Mihamina Rakotomandimby a écrit :
Flute, j'ai la .17, mais il "voit" pas...:
[...]
Il faut modifier le filtre résultant pour y intégrer le cas
d'une trame VLAN :
