J'avais un serveur/passerelle avec 2 interfaces : eth0 en local, eth1 vers
Internet. J'y ai configuré plein de règles iptables pour pouvoir y accéder
depuis le réseau local, y accéder depuis Internet,le traverser et y faire
du NAT sur l'interface sortant vers Internet.
j'ai plein de règles avec -i eth0, -s eth0, -i eth1, -s eth1 et des
filtrages par ip.
Globalement j'ai bien compris comment marche iptables et je fais tout ce
que je veux avec.
J'ai ajouté une interface wlan0 et ai créé un pont ethernet (bridge) br0
composé de eth0 et wlan0.
Bêtement j'ai pensé que je devais juste changer dans mes règles iptables
eth0 en br0 et que tout allait bien fonctionner. J'ai juste ajouter une
regle FORWARD de br0 vers br0 pour que les machines côté wlan0 puissent
causer aux machines côté eth0 et inversement.
Bon en fait -j'aurais dû m'en douter- ça marche pas, les trames ethernet
se perdent dans le pont et des règles iptables ne fonctionnent pas.
J'ai fouillé le WEB avec mon ami Google et j'ai vu ebtables qui doit
servir à corriger tout ça mais je n'ai rien compris du tout. J'ai vu aussi
le match pysdev de iptables...
Comment dois-je procéder pour m'en sortir en gardant le bridge (je peux
aussi travailler avec 3 interfaces mais je vais devoir reconfigurer pas
mal de services et je préfèrerais que pour tout les services dans le
serveur, il n'y ait que 2 interfaces) ?
Merci de votre aide parce que je patauge.
Lolotte
PS: si je ne suis pas dans le bon forum, merci de me réaiguiller.
--
(enlever pasdespam pour répondre)
http://www.dansmongrenier.com/ : les pages du manuel, les newsgroups,
recherche whois, les codes postaux, des jeux et plein d'autres bêtises...
Par contre, je l'ai mise dans /etc/sysconfig/network-scripts/icfg-br0 et
De quelle façon (je ne connais pas bien le format de ces fichiers) ?
c'est en rebootant (c'est ça que j'ai appelé relancer les interfaces) que je me suis fait engueuler, il m'a dit qu'il était pas d'accord.
Quel message exactement ?
Attends, pas si vite ! Une autre possibilité serait de modifier l'adresse MAC d'eth0 avec une valeur supérieure ou égale à celle de wlan0 avant de l'ajouter au pont. Mais de toute façon cela ne règlera pas le problème des communications entre ethernet et wifi.
Je n'y avais pas pensé, je vais essayer ce soir (faut bien que je pense à bidouiller udev qui à tous les coups va me la renommer eth2).
Pas sûr. Si je ne m'abuse, udev n'intervient que lors de la découverte d'un périphérique.
Je m'en doutais (il faisait pareil avec eth0 et loopback et déjà). Je vais devoir dupliquer mes règles iptables, c'est pas léger ça...
Ça dépend comment tu as écrit tes règles. Si tu filtres uniquement sur l'interface d'entrée, alors rien à ajouter. Filtrer sur l'interface d'entrée et son adresse n'est pas forcément pertinent. A quoi bon ?
Idem pour mon apache qui écoute soit sur l'ip 192.168.2.1, soit sur l'ip Internet, devra-t-il aussi écouter sur 192.168.3.1 ?
Pas nécessairement, comme BIND.
Pas si sûr car j'ai des vhosts...
Et alors, qu'est-ce que ça change ? Ce n'est pas parce que le serveur a une adresse de plus qu'apache doit écouter sur cette adresse.
Faut vraiment que je regarde les adresses MAC des paquets reçus sur la machine Wifi parce que si ça se trouve le problème n'est même pas là...
Oui. Et aussi les paquets émis par la machine wifi, et reçus par le serveur.
PS: je n'ai pas pu regarder ebtables dans Mandriva, mais cet après-midi je demanderai à des utilisateurs réguliers de cette distribution.
Lolotte a écrit :
Par contre, je l'ai mise dans /etc/sysconfig/network-scripts/icfg-br0 et
De quelle façon (je ne connais pas bien le format de ces fichiers) ?
c'est en rebootant (c'est ça que j'ai appelé relancer les interfaces)
que je me suis fait engueuler, il m'a dit qu'il était pas d'accord.
Quel message exactement ?
Attends, pas si vite ! Une autre possibilité serait de modifier
l'adresse MAC d'eth0 avec une valeur supérieure ou égale à celle de
wlan0 avant de l'ajouter au pont. Mais de toute façon cela ne règlera
pas le problème des communications entre ethernet et wifi.
Je n'y avais pas pensé, je vais essayer ce soir (faut bien que je pense
à bidouiller udev qui à tous les coups va me la renommer eth2).
Pas sûr. Si je ne m'abuse, udev n'intervient que lors de la découverte
d'un périphérique.
Je m'en doutais (il faisait pareil avec eth0 et loopback et déjà). Je
vais devoir dupliquer mes règles iptables, c'est pas léger ça...
Ça dépend comment tu as écrit tes règles. Si tu filtres uniquement sur
l'interface d'entrée, alors rien à ajouter. Filtrer sur l'interface
d'entrée et son adresse n'est pas forcément pertinent. A quoi bon ?
Idem pour mon apache qui écoute soit sur l'ip 192.168.2.1, soit sur
l'ip Internet, devra-t-il aussi écouter sur 192.168.3.1 ?
Pas nécessairement, comme BIND.
Pas si sûr car j'ai des vhosts...
Et alors, qu'est-ce que ça change ?
Ce n'est pas parce que le serveur a une adresse de plus qu'apache doit
écouter sur cette adresse.
Faut vraiment que je regarde les adresses MAC des paquets reçus sur la
machine Wifi parce que si ça se trouve le problème n'est même pas là...
Oui. Et aussi les paquets émis par la machine wifi, et reçus par le serveur.
PS: je n'ai pas pu regarder ebtables dans Mandriva, mais cet après-midi
je demanderai à des utilisateurs réguliers de cette distribution.
Par contre, je l'ai mise dans /etc/sysconfig/network-scripts/icfg-br0 et
De quelle façon (je ne connais pas bien le format de ces fichiers) ?
c'est en rebootant (c'est ça que j'ai appelé relancer les interfaces) que je me suis fait engueuler, il m'a dit qu'il était pas d'accord.
Quel message exactement ?
Attends, pas si vite ! Une autre possibilité serait de modifier l'adresse MAC d'eth0 avec une valeur supérieure ou égale à celle de wlan0 avant de l'ajouter au pont. Mais de toute façon cela ne règlera pas le problème des communications entre ethernet et wifi.
Je n'y avais pas pensé, je vais essayer ce soir (faut bien que je pense à bidouiller udev qui à tous les coups va me la renommer eth2).
Pas sûr. Si je ne m'abuse, udev n'intervient que lors de la découverte d'un périphérique.
Je m'en doutais (il faisait pareil avec eth0 et loopback et déjà). Je vais devoir dupliquer mes règles iptables, c'est pas léger ça...
Ça dépend comment tu as écrit tes règles. Si tu filtres uniquement sur l'interface d'entrée, alors rien à ajouter. Filtrer sur l'interface d'entrée et son adresse n'est pas forcément pertinent. A quoi bon ?
Idem pour mon apache qui écoute soit sur l'ip 192.168.2.1, soit sur l'ip Internet, devra-t-il aussi écouter sur 192.168.3.1 ?
Pas nécessairement, comme BIND.
Pas si sûr car j'ai des vhosts...
Et alors, qu'est-ce que ça change ? Ce n'est pas parce que le serveur a une adresse de plus qu'apache doit écouter sur cette adresse.
Faut vraiment que je regarde les adresses MAC des paquets reçus sur la machine Wifi parce que si ça se trouve le problème n'est même pas là...
Oui. Et aussi les paquets émis par la machine wifi, et reçus par le serveur.
PS: je n'ai pas pu regarder ebtables dans Mandriva, mais cet après-midi je demanderai à des utilisateurs réguliers de cette distribution.
Pascal Hambourg
Lolotte a écrit :
je n'ai pas trouvé ebtables dans aucun package de Mandriva 2009.1, il y a ebtables-save et ebtables-restore mais pas ebtables, c'est bizarre...
J'ai vérifié dans le gestionnaire de paquetages d'une Mandriva 2009.0 (x86_64 mais ça doit être pareil en x86_32), il y a bien un paquetage nommé ebtables qui contient le programme ebtables, ainsi que les programmes ebtables-save et ebtables-restore évidemment. Ça m'étonnerait que ça ait changé dans la 2009.1.
Lolotte a écrit :
je n'ai pas
trouvé ebtables dans aucun package de Mandriva 2009.1, il y a
ebtables-save et ebtables-restore mais pas ebtables, c'est bizarre...
J'ai vérifié dans le gestionnaire de paquetages d'une Mandriva 2009.0
(x86_64 mais ça doit être pareil en x86_32), il y a bien un paquetage
nommé ebtables qui contient le programme ebtables, ainsi que les
programmes ebtables-save et ebtables-restore évidemment. Ça m'étonnerait
que ça ait changé dans la 2009.1.
je n'ai pas trouvé ebtables dans aucun package de Mandriva 2009.1, il y a ebtables-save et ebtables-restore mais pas ebtables, c'est bizarre...
J'ai vérifié dans le gestionnaire de paquetages d'une Mandriva 2009.0 (x86_64 mais ça doit être pareil en x86_32), il y a bien un paquetage nommé ebtables qui contient le programme ebtables, ainsi que les programmes ebtables-save et ebtables-restore évidemment. Ça m'étonnerait que ça ait changé dans la 2009.1.
newsreader
Précédemment, Pascal Hambourg a écrit :
Lolotte a écrit :
je n'ai pas trouvé ebtables dans aucun package de Mandriva 2009.1, il y a ebtables-save et ebtables-restore mais pas ebtables, c'est bizarre...
J'ai vérifié dans le gestionnaire de paquetages d'une Mandriva 2009.0 (x86_64 mais ça doit être pareil en x86_32), il y a bien un paquetage nommé ebtables qui contient le programme ebtables, ainsi que les programmes ebtables-save et ebtables-restore évidemment. Ça m'étonnerait que ça ait changé dans la 2009.1.
Bonjour,
J'ai abandonné le combat, y avait un truc qui merdait et je sais pas où finalement parce que les trames ethernet avaient la bonne adresse d'origine (celles du bridge) quand elles étaient reçues par la machine wifi. Je suis donc passé à l'option 2 réseaux.
Pour ce qui est de ebtables, il n'est pas présent dans la version 32 bits 2009.1 et 2009.0, avant je sais pas.
Maintenant, il faut juste que je recompile hostap pour utiliser le wifi n parce parce qu'il est compilé avec l'option désactivée.
Merci pour tout.
Lolotte! -- (enlever pasdespam pour répondre) http://www.dansmongrenier.com/ : les pages du manuel, les newsgroups, recherche whois, les codes postaux, des jeux et plein d'autres bêtises...
Précédemment, Pascal Hambourg a écrit :
Lolotte a écrit :
je n'ai pas
trouvé ebtables dans aucun package de Mandriva 2009.1, il y a
ebtables-save et ebtables-restore mais pas ebtables, c'est bizarre...
J'ai vérifié dans le gestionnaire de paquetages d'une Mandriva 2009.0
(x86_64 mais ça doit être pareil en x86_32), il y a bien un paquetage
nommé ebtables qui contient le programme ebtables, ainsi que les
programmes ebtables-save et ebtables-restore évidemment. Ça m'étonnerait
que ça ait changé dans la 2009.1.
Bonjour,
J'ai abandonné le combat, y avait un truc qui merdait et je sais pas où
finalement parce que les trames ethernet avaient la bonne adresse
d'origine (celles du bridge) quand elles étaient reçues par la machine
wifi. Je suis donc passé à l'option 2 réseaux.
Pour ce qui est de ebtables, il n'est pas présent dans la version 32 bits
2009.1 et 2009.0, avant je sais pas.
Maintenant, il faut juste que je recompile hostap pour utiliser le wifi n
parce parce qu'il est compilé avec l'option désactivée.
Merci pour tout.
Lolotte!
--
(enlever pasdespam pour répondre)
http://www.dansmongrenier.com/ : les pages du manuel, les newsgroups,
recherche whois, les codes postaux, des jeux et plein d'autres bêtises...
je n'ai pas trouvé ebtables dans aucun package de Mandriva 2009.1, il y a ebtables-save et ebtables-restore mais pas ebtables, c'est bizarre...
J'ai vérifié dans le gestionnaire de paquetages d'une Mandriva 2009.0 (x86_64 mais ça doit être pareil en x86_32), il y a bien un paquetage nommé ebtables qui contient le programme ebtables, ainsi que les programmes ebtables-save et ebtables-restore évidemment. Ça m'étonnerait que ça ait changé dans la 2009.1.
Bonjour,
J'ai abandonné le combat, y avait un truc qui merdait et je sais pas où finalement parce que les trames ethernet avaient la bonne adresse d'origine (celles du bridge) quand elles étaient reçues par la machine wifi. Je suis donc passé à l'option 2 réseaux.
Pour ce qui est de ebtables, il n'est pas présent dans la version 32 bits 2009.1 et 2009.0, avant je sais pas.
Maintenant, il faut juste que je recompile hostap pour utiliser le wifi n parce parce qu'il est compilé avec l'option désactivée.
Merci pour tout.
Lolotte! -- (enlever pasdespam pour répondre) http://www.dansmongrenier.com/ : les pages du manuel, les newsgroups, recherche whois, les codes postaux, des jeux et plein d'autres bêtises...
newsreader
Précédemment, Lolotte a écrit :
Précédemment, Pascal Hambourg a écrit :
Lolotte a écrit :
je n'ai pas trouvé ebtables dans aucun package de Mandriva 2009.1, il y a ebtables-save et ebtables-restore mais pas ebtables, c'est bizarre...
J'ai vérifié dans le gestionnaire de paquetages d'une Mandriva 2009.0 (x86_64 mais ça doit être pareil en x86_32), il y a bien un paquetage nommé ebtables qui contient le programme ebtables, ainsi que les programmes ebtables-save et ebtables-restore évidemment. Ça m'étonnerait que ça ait changé dans la 2009.1.
Bonjour,
J'ai abandonné le combat, y avait un truc qui merdait et je sais pas où finalement parce que les trames ethernet avaient la bonne adresse d'origine (celles du bridge) quand elles étaient reçues par la machine wifi. Je suis donc passé à l'option 2 réseaux.
Pour ce qui est de ebtables, il n'est pas présent dans la version 32 bits 2009.1 et 2009.0, avant je sais pas.
Maintenant, il faut juste que je recompile hostap pour utiliser le wifi n parce parce qu'il est compilé avec l'option désactivée.
Merci pour tout.
Lolotte!
Pour info, y a un bug répertorié https://qa.mandriva.com/show_bug.cgi?idQ015 pour le package ebtables.
Lolotte -- (enlever pasdespam pour répondre) http://www.dansmongrenier.com/ : les pages du manuel, les newsgroups, recherche whois, les codes postaux, des jeux et plein d'autres bêtises...
Précédemment, Lolotte a écrit :
Précédemment, Pascal Hambourg a écrit :
Lolotte a écrit :
je n'ai pas
trouvé ebtables dans aucun package de Mandriva 2009.1, il y a
ebtables-save et ebtables-restore mais pas ebtables, c'est bizarre...
J'ai vérifié dans le gestionnaire de paquetages d'une Mandriva 2009.0
(x86_64 mais ça doit être pareil en x86_32), il y a bien un paquetage
nommé ebtables qui contient le programme ebtables, ainsi que les
programmes ebtables-save et ebtables-restore évidemment. Ça m'étonnerait
que ça ait changé dans la 2009.1.
Bonjour,
J'ai abandonné le combat, y avait un truc qui merdait et je sais pas où
finalement parce que les trames ethernet avaient la bonne adresse
d'origine (celles du bridge) quand elles étaient reçues par la machine
wifi. Je suis donc passé à l'option 2 réseaux.
Pour ce qui est de ebtables, il n'est pas présent dans la version 32 bits
2009.1 et 2009.0, avant je sais pas.
Maintenant, il faut juste que je recompile hostap pour utiliser le wifi n
parce parce qu'il est compilé avec l'option désactivée.
Merci pour tout.
Lolotte!
Pour info, y a un bug répertorié
https://qa.mandriva.com/show_bug.cgi?idQ015 pour le package ebtables.
Lolotte
--
(enlever pasdespam pour répondre)
http://www.dansmongrenier.com/ : les pages du manuel, les newsgroups,
recherche whois, les codes postaux, des jeux et plein d'autres bêtises...
je n'ai pas trouvé ebtables dans aucun package de Mandriva 2009.1, il y a ebtables-save et ebtables-restore mais pas ebtables, c'est bizarre...
J'ai vérifié dans le gestionnaire de paquetages d'une Mandriva 2009.0 (x86_64 mais ça doit être pareil en x86_32), il y a bien un paquetage nommé ebtables qui contient le programme ebtables, ainsi que les programmes ebtables-save et ebtables-restore évidemment. Ça m'étonnerait que ça ait changé dans la 2009.1.
Bonjour,
J'ai abandonné le combat, y avait un truc qui merdait et je sais pas où finalement parce que les trames ethernet avaient la bonne adresse d'origine (celles du bridge) quand elles étaient reçues par la machine wifi. Je suis donc passé à l'option 2 réseaux.
Pour ce qui est de ebtables, il n'est pas présent dans la version 32 bits 2009.1 et 2009.0, avant je sais pas.
Maintenant, il faut juste que je recompile hostap pour utiliser le wifi n parce parce qu'il est compilé avec l'option désactivée.
Merci pour tout.
Lolotte!
Pour info, y a un bug répertorié https://qa.mandriva.com/show_bug.cgi?idQ015 pour le package ebtables.
Lolotte -- (enlever pasdespam pour répondre) http://www.dansmongrenier.com/ : les pages du manuel, les newsgroups, recherche whois, les codes postaux, des jeux et plein d'autres bêtises...
newsreader
Précédemment, Lolotte a écrit :
Bonjour,
J'ai abandonné le combat, y avait un truc qui merdait et je sais pas où finalement parce que les trames ethernet avaient la bonne adresse d'origine (celles du bridge) quand elles étaient reçues par la machine wifi. Je suis donc passé à l'option 2 réseaux. ...
Bon, après vérifications, en fait le problème n'a rien à voir ni avec les règles iptables, ni avec le bridge.
Sur un réseau indépendant 192.168.3.0/255.255.255.0, avec hostapd côté serveur (interface wlan0), que ce soit en version 0.6.7 en Wifi g ou 0.6.9 en Wifi g ou n, avec une carte D-Link DWA-510 (wifi g) ou DWA-547 (wifi n ou g), j'ai le même problème. Mon serveur avec le hostapd est sous Mandriva 2009.1. Côté serveur, tout est ouvert dans Netfilter (INPUT, OUTPUT, FORWARD)... Côté serveur, ifconfig wlan0 ne montre aucune erreur, collision, etc... Pas de déconnexion dans les logs d'hostapd. La machine Wifi est sous XP, j'y ai désactivé le pare-feu, Avast! et ai autorisé tout le ICMP. Les 2 machines sont à 1m l'une de l'autre sans obstacles, la connexion est qualifiée d'excellente par le PC XP (54Mb/s en g et 165Mb/s en n).
Depuis le PC XP minusw (192.168.3.34) , je fais un ping vers le serveur 192.168.3.1 ainsi : ping 192.168.3.1 -n 1 -w 10000
Voici les traces tcpdump côté serveur quand tout va bien (réponse vue côté XP en moins d'1s) : 20:02:20.618976 00:07:cb:0e:48:61 > 00:22:b0:ce:5d:22, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 128, id 6152, offset 0, flags [none], proto ICMP (1), length 60) 192.168.3.34 > 192.168.3.1: ICMP echo request, id 768, seq 24320, length 40 20:02:20.619099 00:22:b0:ce:5d:22 > 00:07:cb:0e:48:61, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 64, id 50664, offset 0, flags [none], proto ICMP (1), length 60) 192.168.3.1 > 192.168.3.34: ICMP echo reply, id 768, seq 24320, length 40
Dans ce cas, côté XP, tcpdump voit bien l'echo-request partir mais ne voit jamais l'echo-reply.
La liaison Wifi semble fonctionner de manière excellente dans le sens machine XP->serveur mais de manière aléatoire dans l'autre sens. Et c'est bien ce côté aléatoire que je n'explique pas...
Suis sec.
Merci de votre aide.
Lolotte -- (enlever pasdespam pour répondre) http://www.dansmongrenier.com/ : les pages du manuel, les newsgroups, recherche whois, les codes postaux, des jeux et plein d'autres bêtises...
Précédemment, Lolotte a écrit :
Bonjour,
J'ai abandonné le combat, y avait un truc qui merdait et je sais pas où
finalement parce que les trames ethernet avaient la bonne adresse
d'origine (celles du bridge) quand elles étaient reçues par la machine
wifi. Je suis donc passé à l'option 2 réseaux.
...
Bon, après vérifications, en fait le problème n'a rien à voir ni avec les
règles iptables, ni avec le bridge.
Sur un réseau indépendant 192.168.3.0/255.255.255.0, avec hostapd côté
serveur (interface wlan0), que ce soit en version 0.6.7 en Wifi g ou 0.6.9
en Wifi g ou n, avec une carte D-Link DWA-510 (wifi g) ou DWA-547 (wifi n
ou g), j'ai le même problème.
Mon serveur avec le hostapd est sous Mandriva 2009.1. Côté serveur, tout
est ouvert dans Netfilter (INPUT, OUTPUT, FORWARD)...
Côté serveur, ifconfig wlan0 ne montre aucune erreur, collision, etc...
Pas de déconnexion dans les logs d'hostapd.
La machine Wifi est sous XP, j'y ai désactivé le pare-feu, Avast! et ai
autorisé tout le ICMP.
Les 2 machines sont à 1m l'une de l'autre sans obstacles, la connexion est
qualifiée d'excellente par le PC XP (54Mb/s en g et 165Mb/s en n).
Depuis le PC XP minusw (192.168.3.34) , je fais un ping vers le serveur
192.168.3.1 ainsi :
ping 192.168.3.1 -n 1 -w 10000
Voici les traces tcpdump côté serveur quand tout va bien (réponse vue côté
XP en moins d'1s) :
20:02:20.618976 00:07:cb:0e:48:61 > 00:22:b0:ce:5d:22, ethertype IPv4
(0x0800), length 74: (tos 0x0, ttl 128, id 6152, offset 0, flags [none],
proto ICMP (1), length 60)
192.168.3.34 > 192.168.3.1: ICMP echo request, id 768, seq 24320,
length 40
20:02:20.619099 00:22:b0:ce:5d:22 > 00:07:cb:0e:48:61, ethertype IPv4
(0x0800), length 74: (tos 0x0, ttl 64, id 50664, offset 0, flags [none],
proto ICMP (1), length 60)
192.168.3.1 > 192.168.3.34: ICMP echo reply, id 768, seq 24320, length
40
Dans ce cas, côté XP, tcpdump voit bien l'echo-request partir mais ne voit
jamais l'echo-reply.
La liaison Wifi semble fonctionner de manière excellente dans le sens
machine XP->serveur mais de manière aléatoire dans l'autre sens. Et c'est
bien ce côté aléatoire que je n'explique pas...
Suis sec.
Merci de votre aide.
Lolotte
--
(enlever pasdespam pour répondre)
http://www.dansmongrenier.com/ : les pages du manuel, les newsgroups,
recherche whois, les codes postaux, des jeux et plein d'autres bêtises...
J'ai abandonné le combat, y avait un truc qui merdait et je sais pas où finalement parce que les trames ethernet avaient la bonne adresse d'origine (celles du bridge) quand elles étaient reçues par la machine wifi. Je suis donc passé à l'option 2 réseaux. ...
Bon, après vérifications, en fait le problème n'a rien à voir ni avec les règles iptables, ni avec le bridge.
Sur un réseau indépendant 192.168.3.0/255.255.255.0, avec hostapd côté serveur (interface wlan0), que ce soit en version 0.6.7 en Wifi g ou 0.6.9 en Wifi g ou n, avec une carte D-Link DWA-510 (wifi g) ou DWA-547 (wifi n ou g), j'ai le même problème. Mon serveur avec le hostapd est sous Mandriva 2009.1. Côté serveur, tout est ouvert dans Netfilter (INPUT, OUTPUT, FORWARD)... Côté serveur, ifconfig wlan0 ne montre aucune erreur, collision, etc... Pas de déconnexion dans les logs d'hostapd. La machine Wifi est sous XP, j'y ai désactivé le pare-feu, Avast! et ai autorisé tout le ICMP. Les 2 machines sont à 1m l'une de l'autre sans obstacles, la connexion est qualifiée d'excellente par le PC XP (54Mb/s en g et 165Mb/s en n).
Depuis le PC XP minusw (192.168.3.34) , je fais un ping vers le serveur 192.168.3.1 ainsi : ping 192.168.3.1 -n 1 -w 10000
Voici les traces tcpdump côté serveur quand tout va bien (réponse vue côté XP en moins d'1s) : 20:02:20.618976 00:07:cb:0e:48:61 > 00:22:b0:ce:5d:22, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 128, id 6152, offset 0, flags [none], proto ICMP (1), length 60) 192.168.3.34 > 192.168.3.1: ICMP echo request, id 768, seq 24320, length 40 20:02:20.619099 00:22:b0:ce:5d:22 > 00:07:cb:0e:48:61, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 64, id 50664, offset 0, flags [none], proto ICMP (1), length 60) 192.168.3.1 > 192.168.3.34: ICMP echo reply, id 768, seq 24320, length 40
Dans ce cas, côté XP, tcpdump voit bien l'echo-request partir mais ne voit jamais l'echo-reply.
La liaison Wifi semble fonctionner de manière excellente dans le sens machine XP->serveur mais de manière aléatoire dans l'autre sens. Et c'est bien ce côté aléatoire que je n'explique pas...
Suis sec.
Merci de votre aide.
Lolotte -- (enlever pasdespam pour répondre) http://www.dansmongrenier.com/ : les pages du manuel, les newsgroups, recherche whois, les codes postaux, des jeux et plein d'autres bêtises...
