Réseau, 2 PC connectés ensemblent et à un routeur

Bonjour,

Après avoir parcouru un moment le web, quelques forum, http://www.debian.org/doc/manuals/reference/ch-gateway.fr.html et n’ayant toujours pas trouvé de solutions je viens faire un post ici.

J’ai deux PC l’un a coté de l’autre, un laptot avec debian squeeze et vista qui possède une carte wifi relié au routeur et une carte ethernet relié au PC, et un PC avec windows 7.

voici un schéma :


image en grand http://nsa10.casimages.com/img/2009/12/30/091230055934846524.png

Mon problème est le suivant, avant (quand j’utilisais vista) je pouvais choisir de transférer mes donnée (samba) et d’utiliser un programme pour partager le clavier et la souris (synergy) via le câble ethernet.

Maintenant je n’arrive plus qu’a le faire via wifi et le problème est que j’ai de la latence par wifi car le débit est de 54Mbit/s tandis que par le câble c’est 1Gbit/s.

Ma question est la suivante, voyez vous quelque chose de faux la dedans ou connaissez vous un documentation qui pourrait m’aider ?

voici /etc/network/interfaces

[code]# The loopback network interface
auto lo
iface lo inet loopback

#wifi
auto wlan0

Config statique

iface wlan0 inet static
address 192.168.1.33
netmask 255.255.255.0
gateway 192.168.1.1
dns-nameservers 195.186.1.162 195.186.4.162
wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf

#eth0
auto eth0
iface eth0 inet static
address 192.168.2.33
netmask 255.255.255.0
[/code]

route

Table de routage IP du noyau Destination Passerelle Genmask Indic Metric Ref Use Iface 192.168.2.0 * 255.255.255.0 U 0 0 0 eth0 192.168.1.0 * 255.255.255.0 U 0 0 0 wlan0 default 192.168.1.1 0.0.0.0 UG 0 0 0 wlan0

ping 192.168.2.60 (sur laptop debian)

PING 192.168.2.60 (192.168.2.60) 56(84) bytes of data.
From 192.168.2.33 icmp_seq=1 Destination Host Unreachable
From 192.168.2.33 icmp_seq=2 Destination Host Unreachable
From 192.168.2.33 icmp_seq=3 Destination Host Unreachable

ifconfig

[code]eth0 Link encap:Ethernet HWaddr
inet adr:192.168.2.33 Bcast:192.168.2.255 Masque:255.255.255.0
adr inet6: fe80::216:d4ff:fede:ef97/64 Scope:Lien
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:78 errors:0 dropped:0 overruns:0 frame:0
TX packets:92 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:1000
RX bytes:9298 (9.0 KiB) TX bytes:10491 (10.2 KiB)
Interruption:18

lo Link encap:Boucle locale
inet adr:127.0.0.1 Masque:255.0.0.0
adr inet6: ::1/128 Scope:Hôte
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:40 errors:0 dropped:0 overruns:0 frame:0
TX packets:40 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:0
RX bytes:4052 (3.9 KiB) TX bytes:4052 (3.9 KiB)

wlan0 Link encap:Ethernet HWaddr
inet adr:192.168.1.33 Bcast:192.168.1.255 Masque:255.255.255.0
adr inet6: fe80::219:d2ff:fecf:212f/64 Scope:Lien
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:39730 errors:0 dropped:0 overruns:0 frame:0
TX packets:31391 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:1000
RX bytes:3869174 (3.6 MiB) TX bytes:3026687 (2.8 MiB)

wmaster0 Link encap:UNSPEC HWaddr
UP RUNNING MTU:0 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
[/code]

Merci d’avoir pris du temps de lire, et merci de bien vouloir m’éclairer :bulb:

ton routeur propose un réseau différent pour les connexions wifi (192.168.1.0/24) et pour les connexions cablées (192.168.2.0/24) cela m’étonne car ce serait plutot une execption que la norme, c’est possible mais je pense plutot à une erreur qui est la cause de tes problèmes de communication entre les 2 PC.

Je suis sur que si les 2 PC sont connectés en wifi alors les connexions marches entre eux et ont accès au net, que si l’un est connecté en wifi et l’autre en ethernet : là la communication entre 2 est impossible comme ils sont sur un réseau logique différent et que tu ne mentionne pas de passerelle pour l’interface ethernet…et que les 2 PC en ethernet ne peuvent pas non plus commnuniqués bien qu’étant sur le même réseau logique car ton routeur ne se comporte pas forcément comme un switch.

Quand même le ping le passe pas (et qu’on est sur de pas avoir les requetes ICMP bloqué dans le parefeu, pour Win 7 je regarderais quand même) il faut vérifier sa configuration tcp/ip avant le reste

Ben au faite le réseau 192.168.2.0 (le câble ethernet) ne passe pas par le routeur, c’est un câble croisé qui va directement du laptop au PC.

Et pour la config tcp/ip, ca fonctionnait avec vista sur seven (ping, transfert de données et synergy) donc il ne devrait pas y avoir de probleme de parfeu de windows seven

ok pour la connexion des 2PC avec le cable croisé, le cable est hors de cause il fonctionnait avant/la diode sur chaque carte réseau est bien allumée?

Pour le parefeu le mieux serait de vérifier car même entre un WinXP SP2 et un WinXP SP3, la mise à jour configure le pare feu pour bloquer les requêtes ICMP donc le ping (et donnera un Destination Host Unreachable au pc qui essait de pinguer). Il vaut mieux éliminer toutes les causes possibles.

Si tu es sur de ton cable, et que le ping n’est pas bloqué (d’ailleurs que donne un ping dans l’autre sens?), je testerais de désactiver la carte wifi (ifdown wlan0) et relancer la carte ethernet (ifdown eth0 puis ifup eth0) et sur Win7 verifier que c’est bien la connexion ethernet qui est connecté et la carte wifi non connectée

Merci pour ton aide,

J’ai essayé de coupé les 2 interfaces eth0 et wlan0 et réactiver eth0, et là je peux pinger mais :cry: dès que je veux faire un transfert de donné ou utiliser synergy ca plante et je ne peux plus pinger. C’est bien la preuve que ca doit être un petite m**** sur debian.
J’ai essayer en désactivant mon parfeu, mais ca n’a pas changé.

Je vais essayer d’aller voir sur le parfeu windows 7 mais j’y crois pas trop car un parfeu ca bloque des ports et étant donnée que ca fonctionne avec la carte sans fil il n’y aurait pas de raison que ca bloque un câble ethernet non ?

ps. le ping de windows 7 sur debian fonctionne quand celui de debian sur windows 7 fonctionne.

Ça me surprendrait beaucoup. Cette erreur signale un défaut de la résolution ARP (adresse IP -> adresse MAC), qui a lieu avant l’envoi d’un paquet IP (ICMP echo ou autre). Ça m’étonnerait beaucoup qu’un pare-feu fasse du filtrage ARP, ce n’est pas courant.

Normalement en 1000Base-T on n’a pas besoin de câble croisé car les 4 paires sont bidirectionnelles, mais si ça marchait avant ça ne doit pas gêner. Les compteurs d’erreur sur eth0 sont à 0 aussi. Les compteurs de paquets émis et reçus sont non nuls, donc du trafic est echangé, c’est bon signe. La configuration IP est correcte.

Pour essayer d’en savoir plus je ferais une capture de trafic sur les interfaces ethernet des deux machines pendant les essais de ping dans les deux sens.

Salut Pascal,

voici quelques captures de réseau eth0

ping de debian sur 7

ping de 7 sur debian

Je sais pas trop comment interpréter ces informations peut être tu sais me dire si c’est ok ?

Note : il aurait été plus pratique de faire une capture en mode texte (avec tcpdump ou tshark, sais pas si possible avec wireshark), ou un copier/coller en mode texte plutôt que des captures d’écran graphique.

AsustekC_d3:48:bf (00:15:f2:d3:48:bf), c’est 192.168.2.60, le PC fixe sous Windows.
CompalCo_de:ef:97 (00:16:d4:de:ef:97), c’est 192.168.2.33, eth0 du portable sous Debian (confirmé avec l’adresse IPv6 link-local affichée par ifconfig, inutile de masquer les adresses MAC).

capture 1 : une requête ARP de Windows, une réponse ARP de Debian.

capture 2 : deux fois la même chose que ci-dessus (en bleu), du trafic multicast IPv6 (UPnP je suppose) émis par Windows, sans rapport (en bleu). C’est affiché comment ? La fenêtre indique 25 paquets, mais on ne voit pas tout et ça n’a pas l’air dans l’ordre (15 et 16 avant 3 et 5). Je n’ai pas besoin du détail du contenu des paquets.

capture 3 : des requêtes ARP de Debian, sans réponse.

capture 4 : identique à capture 1

L’interface eth0 reçoit bien du trafic émis par Windows, mais c’est comme si ce qu’elle envoie n’était pas reçu par Windows. Il serait intéressant de faire la capture côté Windows aussi pour savoir ce qui se passe. Wireshark est aussi disponible pour Windows, en espérant qu’il fonctionne avec Windows 7. A défaut, surveiller le compteur de paquets reçus de l’interface ethernet (de mémoire sur les versions précédentes de Windows il faut activer un truc dans les propriétés de la carte pour y avoir accès).

Ça me surprendrait beaucoup. Cette erreur signale un défaut de la résolution ARP (adresse IP -> adresse MAC), qui a lieu avant l’envoi d’un paquet IP (ICMP echo ou autre). Ça m’étonnerait beaucoup qu’un pare-feu fasse du filtrage ARP, ce n’est pas courant.
[/quote]

J’aurais du être plus précis, ce ne sont que les requêtes d’écho entrantes qui ne sont plus autorisées (si on ne coche pas “autoriser les requêtes d’échos entrantes” dans les paramètres ICMP du parefeu), il ne bloque pas tout le trafic du protocole ICMP sinon effectivement certains mécanismes ne fonctionneraient plus, par contre je comprend pas trop le rapprochement entre le filtrage d’ICMP et le filtrage d’ARP si tu pouvais juste expliquer vite fait même avec un petit exemple car je pensais faire du filtrage ICMP dans des règles de parefeu.

Pour le cable 1000 Base-T, est ce qu’il ne faut pas remplir la condition d’avoir tout qui fonctionne en gigabit donc ici les cartes réseaux de part et d’autre pour profiter des 4 paires bidirectionnelles?

Le filtrage du ping (ICMP echo) se fait généralement en détruisant silencieusement les paquets ICMP echo, ce qui ne provoque pas de message d’erreur du côté de l’émetteur, juste l’absence de réponse au ping. Bien que pas impossible, il est très improbable qu’un pare-feu filtre le ping en renvoyant un ICMP host unreachable ; en effet ce serait une réponse quand même. D’autre part on voit que le message d’erreur a pour source l’adresse IP de la machine émettrice du ping elle-même, il faudrait donc qu’il soit produit par les règles iptables en sortie de la machine Debian. Il est beaucoup plus probable qu’il s’agisse d’un échec de la résolution ARP préalable à l’envoi d’un paquet IP comme le ping, soit parce que la requête ARP ne parvient pas à destination, soit parce que la réponse ARP ne parvient pas à destination, soit parce que le destinataire filtre les requêtes ARP mais c’est peu probable.

Tout d’abord bonne année 2010 !
:smt006 :smt006 :smt006 :smt006 :smt006 :smt006 :smt006 :smt006 :smt006

[quote]Note : il aurait été plus pratique de faire une capture en mode texte (avec tcpdump ou tshark, sais pas si possible avec wireshark), ou un copier/coller en mode texte plutôt que des captures d’écran graphique.

AsustekC_d3:48:bf (00:15:f2:d3:48:bf), c’est 192.168.2.60, le PC fixe sous Windows.
CompalCo_de:ef:97 (00:16:d4:de:ef:97), c’est 192.168.2.33, eth0 du portable sous Debian (confirmé avec l’adresse IPv6 link-local affichée par ifconfig, inutile de masquer les adresses MAC).

capture 1 : une requête ARP de Windows, une réponse ARP de Debian.

capture 2 : deux fois la même chose que ci-dessus (en bleu), du trafic multicast IPv6 (UPnP je suppose) émis par Windows, sans rapport (en bleu). C’est affiché comment ? La fenêtre indique 25 paquets, mais on ne voit pas tout et ça n’a pas l’air dans l’ordre (15 et 16 avant 3 et 5). Je n’ai pas besoin du détail du contenu des paquets.

capture 3 : des requêtes ARP de Debian, sans réponse.

capture 4 : identique à capture 1

L’interface eth0 reçoit bien du trafic émis par Windows, mais c’est comme si ce qu’elle envoie n’était pas reçu par Windows. Il serait intéressant de faire la capture côté Windows aussi pour savoir ce qui se passe. Wireshark est aussi disponible pour Windows, en espérant qu’il fonctionne avec Windows 7. A défaut, surveiller le compteur de paquets reçus de l’interface ethernet (de mémoire sur les versions précédentes de Windows il faut activer un truc dans les propriétés de la carte pour y avoir accès).[/quote]

Désolé, je n’ai pas trouvé comment faire une capture en mode texte.
Donc après avoir installé wireshark sur windows 7 voici ce que j’obtiens :
(ping sur la machine windows 7 à la machine debian

Le contraire ne donne rien (de la machien debian sur windows 7)

j’ai lancé tourner un moment wireshark et voici le résultat

Donc à mon avis il doit y avoir quelque chose qui blocke sur windows 7.
Avez vous une idée ?
Si non je devrais peut être voir sur un forum pour windows ?

En tout cas ça confirme mes soupçons : Windows ne “voit” pas les paquets envoyés par la machine Debian. Je ne connais pas la pile réseau de Windows 7 et j’ignore à quel “endroit” s’insère wireshark pour écouter (sous Linux, c’est directement au niveau du pilote ethernet, donc même les paquets reçus et bloqués par iptables sont vus). C’est peut-être un problème ethernet, de carte ou de pilote, d’un côté ou de l’autre.

Tu as regardé l’évolution du compteur de paquets reçus de l’interface ethernet sous Windows comme je l’avais suggéré ? Je ne sais pas où trouver des compteurs d’erreurs comme ce qu’affiche ifconfig. Eventuellement, tu pourrais essayer de forcer la liaison en fast ethernet (100Base-TX) des deux côtés pour voir si ça change quelque chose.

T’adresser à un forum Windows pourrait effectivement être une bonne chose pour savoir comment mieux investiguer côté Windows.

D’accords ,

Donc ma config sur debian est ok.

J’irais voir sur un forum pour windows si je trouve une solution. Pour le compteur windows 7 les paquet envoyé augmente tandis que ceux reçu stagnent à 28.

Je regarderai pour forcer la liaison en 100Base-TX mais bon le but c’était quand même d’utiliser le câble pour avoir un plus grand débit.

En tout cas merci beaucoup pour votre aide.

:smt006

Pas sûr que tout soit bon côté Debian : le problème peut se situer aussi bien à l’émission côté Debian qu’à la réception côté Windows, voire dans le câble entre les deux.

Je comprends ton souci concernant la rétrogradation du débit, mais si ça marche ça pourrait au moins circonscrire le problème à la couche ethernet (câble, cartes ou pilotes), au moins ça élimine l’hypothèse d’un filtrage côté Windows.

à ta place je testerais avec un autre cable croisé si tu as/peux faire car quand le nombre de paquets reçus est inférieur au nombre de paquets envoyés voir même varient d’un test à l’autre ça peut être signe d’un mauvais cablage, j’ai eu le cas y a pas longtemps du cablage d’une prise réseau qui ne respectait aucune des 2 normes existantes (T568A T568B), par exemple dans ton cas d’un coté tu dois avoir les couleurs de la norme A puis la B de l’autre coté (cable croisé).

tu as déjà essayé sinon en passant par ton routeur, si il dispose de plusieurs port ethernet, il peut se comporter comme un switch. Si ça marche pas testes en configurant les 2pc pour etre sur le meme réseau que le routeur et essaye de pinguer l’ip du routeur histoire de pouvoir mettre hors de cause les carte réseaux/tcp-ip et le système et identifier un problème avec ton cable croisé.