> Tech > Tests de communication de base

Tests de communication de base

Tech - Par Renaud ROSSET - Publié le 24 juin 2010
email

Si le problème se résume au fait qu'une ou plusieurs unités ne peuvent pas communiquer sur le réseau, voici une courte liste de contrôle des tests de base pour vous aider à  circonscrire le problème :

1. Vérifiez que votre appareil client a établi une association Wi-Fi.
Vous pouvez vérifier

Tests de communication de base

ce point dans le panneau
de contrôle Network Adapter du client et dans la liste des AP des appareils associés. Cette
dernière vérification suppose que
vous connaissiez l’adresse MAC
(Media Access Control) du client en
difficulté. Faute d’une association,
rien d’autre ne résoudra le problème.
Il faut en premier lieu établir
une association. Vérifiez que le SSID
du client correspond à  l’AP, que l’AP
ne filtre pas les clients par adresse
MAC, et que le client et l’AP communiquent
sur le même canal 802.
11. Chaque réseau Wi-Fi devrait employer
l’authentification et le cryptage
de données bidirectionnels,
donc vérifiez que vos valeurs d’authentification
(ID et mot de passe
utilisateur VPN ou certificat numérique)
et clés de cryptage sont corrects.
Ne comptez pas sur WEP ou
WPA pour la sécurité Wi-Fi (voir l’encadré
« WEP et WPA peuvent être
nuisibles », ci-après). Assurez-vous
également que le signal est assez
fort. Si possible, rapprochez le
client concerné de l’AP pour voir si
cela résout le problème.

2. Vérifiez l’adresse du client.
Dans
Windows, utilisez la commande IPCONFIG
de la ligne de commande
pour afficher l’adresse IP attribuée.
Si l’IP est configuré de manière statique,
assurez-vous que le masque
subnet est correctement défini. Si
l’IP est attribué dynamiquement par
DHCP (Dynamic Host Configuration
Protocol), vérifiez que le bon
serveur DHCP a fourni l’adresse. Si
le client n’a pas reçu une attribution
DHCP, ou s’il a une adresse 169.
254.x.x auto-attribuée, essayez d’attribuer
temporairement une
adresse IP statique libre pour voir si
cela rétablit la connectivité. Vous
pourrez ensuite vous concentrer
sur le diagnostic du problème
DHCP. Dans les deux cas, confirmez
le fait que l’interface active est bien
l’adaptateur sans fil. Sur la plupart
des clients, si une interface câblée
est disponible, elle aura priorité sur
toute autre voie sans fil.

3. Vérifiez l’adresse passerelle du
client.

client. Si l’adresse passerelle n’est
pas définie correctement, vous ne
pourrez pas communiquer par l’intermédiaire
du LAN câblé local.
Dans Windows, vous pouvez vérifier
ce point avec la commande IPCONFIG
ou avec la commande NETSTAT
-R. A noter que l’adresse passerelle
doit être dans le même subnet logique que l’adresse IP du client. Inspectez de près le
masque subnet du client pour vérifier que la passerelle est
bien dans le même subnet.

4. Vérifiez les paramètres du serveur des noms de
clients.

Souvent la connectivité d’un client est satisfaisante,
mais les serveurs de noms configurés sont soit incorrects
soit inatteignables. Vous vérifierez l’atteignabilité
dans une prochaine étape, mais vous devriez pouvoir
d’ores et déjà  confirmer, par une inspection, que les serveurs
de noms sont correctement configurés.

5. Envoyez un ping à  l’AP.
Si vos AP sont sur le même réseau
logique que vos clients (pas obligatoirement dans
une configuration pontée), essayez d’envoyer un ping à 
l’AP à  partir du client. Si vous ne pouvez pas obtenir de réponse,
il est probable qu’un problème de qualité du signal
RF empêche la communication. Consultez les dernières
suggestions pour identifier les problèmes
de conception et d’interférence
réseau. Si vous pouvez envoyer un ping
à  l’AP, vous savez au moins que la liaison
RF fonctionne. Vérifiez qu’en faisant varier
la taille des paquets ping dans la
commande ping, vous ne constatez pas
une importante perte de paquets (mais
n’essayez pas des paquets dépassant le
maximum Ethernet : 1 500 octets).

6. Envoyez un ping à  l’adresse IP locale.
Trouvez un autre appareil sur votre LAN câblé et envoyez-
lui un ping. Si cette manoeuvre échoue, l’AP a peutêtre
du mal à  communiquer avec le LAN. Soupçonnez un
câble défectueux et vérifiez la connectivité LAN dans votre
commutateur Ethernet. Les problèmes courants sont les
suivants : des valeurs de débit Ethernet incorrectes (10
Mbps vs 100 Mbps, par exemple) ou des valeurs duplex
discordantes (half-duplex vs full-duplex). En général, il
vaut mieux définir statiquement la vitesse Ethernet et le
mode duplex, plutôt que de compter sur les possibilités
d’auto-configuration douteuses du commutateur
Ethernet. Si vous pouvez envoyer correctement un ping à 
une adresse locale, la connexion est en bonne voie !

7. Envoyez un ping à  l’adresse passerelle.
Si vous ne
pouvez pas atteindre la passerelle, le client ne peut pas
communiquer à  l’extérieur du LAN local. Vérifiez que la
passerelle est opérationnelle et que le masque subnet
configuré dans la passerelle correspond à  celui qui est
configuré sur le client. Vérifiez aussi les appareils et câbles
intermédiaires pour éliminer l’hypothèse des défaillances
de transport dans votre LAN.

8. Envoyez un ping aux serveurs DNS.

Ce n’est pas toujours
possible, particulièrement si les serveurs DNS se
trouvent derrière un pare-feu, lequel bloque souvent les
pings pour des raisons de sécurité évidentes. Si vous ne
pouvez pas envoyer un ping aux serveurs DNS, alors que
d’autres clients sans fil y parviennent, soupçonnez un problème
de routage ou une défaillance du mécanisme de
transport sur le chemin qui conduit au serveur DNS. En
revanche, si vous pouvez envoyer un ping à  un serveur
DNS et s’il se trouve sur un réseau différent, vous aurez
confirmé le bon fonctionnement du routage hors réseau.

9. Effectuez une consultation de DNS.

DNS est essentiel
pour l’accès Internet général parce que, sans lui, le client
ne peut pas traduire entièrement les noms de domaines
qualifiés en adresses IP de destination. Même si vous pouvez
envoyer un ping à  un serveur DNS, celui-ci ne traite
peut-être pas correctement les requêtes DNS. Utilisez
l’outil NSLOOKUP en mode interactif pour envoyer une
requête connue au serveur DNS et vérifiez sa réponse. Par
exemple

NSLOOKUP
>server 192.168.5.10
>www.mit.edu
NAME: DANDELION-PATCH.mit.edu
ADDRESS: 18.181.0.31

En complément de cette liste de contrôle, recueillez tous
les documents de dépannage émis par le fournisseur à  propos
du client ou des unités AP que vous employez. Microsoft
a un guide de dépannage très complet pour des clients sans fil Windows XP (voir l’encadré « Outils
de dépannage Wi-Fi »). Si les éléments
fournis par la liste de contrôle ne permettent
pas d’isoler le problème, vérifiez
d’autres causes probables, comme
une conception de réseau déficiente
ou une interférence fréquence radio
(RF). Pour ces tests, il vous faudra
quelques outils de dépannage Wi-Fi
dont nous allons parler maintenant.

Téléchargez cette ressource

Guide de technologie 5G pour l’entreprise

Guide de technologie 5G pour l’entreprise

Pourquoi la 5G est-elle faite pour votre entreprise ? La 5G peut améliorer la vitesse, la fiabilité et la capacité de votre réseau, permettant ainsi une meilleure collaboration, une productivité accrue et une prise de décision plus rapide. Notre livre blanc " The Big Book of Enterprise 5G" vous fournit les informations stratégiques dont vous avez besoin pour prendre des décisions éclairées et préparer votre entreprise à prospérer dans l'ère de la 5G. Cradlepoint, part of Ericsson est le leader mondial des solutions de réseau sans fil 4G LTE et 5G fournies via le cloud. Connectez vos employés, lieux et objets avec la 4G LTE et la 5G pour un WAN sans fil d'entreprise.

Tech - Par Renaud ROSSET - Publié le 24 juin 2010