Association FAImaison

Cette page est en lecture seule. Vous pouvez afficher le texte source, mais ne pourrez pas le modifier. Contactez votre administrateur si vous pensez qu'il s'agit d'une erreur.
====== Débugger une ligne ADSL pour les nuls ======

//**NB.** Les points de contact pour le support sont la liste **support at faimaison.net** et la ligne **07 82 32 42 38**.//

{{ :liste_problemes_fma.png?300 |}}

Les points listés vont du plus près de l'abonné au plus éloigné, ils ne sont pas pour autant à vérifier dans cet ordre très précisément.
On ne peut pas forcément intervenir directement ou indirectement sur tout les points et les responsabilités sont clairement définies.

{{ :etape_de_connexionfma.png?300 |}}

Pour déterminer d'où vient la cause du problème il convient de procéder par élimination, et de comprendre comment s'établit un lien ADSL afin de ne pas solliciter indûment l'adhérent ou Nerim. Par exemple inutile de demander à l'abonné de vérifier la tonalité sur sa ligne si on le voit encore connecté dans les logs des LNS, ou de lui demander de rentrer les login PPP de test mire s'il nous indique ne pas avoir de synchronisation ADSL.

Gitoyen ne pourra que compatir si nos LNS sont en carafe, mais pas nous aider.

Si il y a perte de synchronisation mais toujours une tonalité, France Télécom annonceras poliment à l'adhérent que c'est à lui de se démerder avec la hotline son FAI (nous, donc) et Nerim nous demanderas (un peu trop) systématiquement, de nous assurer que le problème se situe avant le point E.

On ne peut pas demander à FT de rétablir la tonalité sur une ligne, c'est à l'adhérent de faire la démarche.

====== Point A: ======

Quand un adhérent nous contacte, D'abord : 

  * vérifier que son RJ45 soit pas débranché,  
  * demander au passage si quelque chose a bougé dans sa configuration réseau.


====== Point B: ======

Un équipement réseau (modem, routeur) qui défaille, ça arrive et les causes sont multiples :

  * Le routeur a peut être juste pas aimé une déconnexion cavalière d'un LNS et a du mal à s'en remettre ; en général ce genre de souci arrive par vague. 
  * problème software qui soit en cause : 
    * une mise à jour du firmware
    * les paramètres du style login et password PPP se soient volatilisés (reset accidentel, orage, magie noire...), que l'abonné s'assure qu'il utilise bien la dernière configuration connue pour être fonctionnelle permet d'avancer vers l'élimination de la piste "modem/routeur défectueux".




**résolution**
plusieur cas de figure : 
  * L'abonné redémarre électriquement son routeur histoire de repartir de zéro et on n'en parle plus.
  * Si il est possible faire des test croisés, c'est pas plus mal.
  * Remplacer le modem de l'adhérent par un autre réputé fonctionner, ou mettre le modem de l'adhérent sur une ligne dont on sait qu'elle n'est pas down permet d'éliminer la piste "modem/routeur en cause"  
====== Point C: ======

**symptôme**

Le modem n'est pas tout et la desserte téléphonique interne mérite qu'on y jette un coup d'œil. 

  * Brancher le modem sur une autre prise téléphonique, 
    * s'assurer qu'une  rallonge téléphonique ne soit pas à l'origine du problème (cas arrivé dans un cinéma).
    * Le câble RJ11 est il en bon état, peut on le remplacer pour tester ? 
    * de même pour le filtre ?
    * Chaque prise de son domicile comportant un téléphone est-elle équipée d'un filtre ?
  * La présence de parasites, de bruit de craquelures sur la ligne peut venir également d'un souci sur la desserte interne. (mais aussi être imputables au point D)
  * Si déconnexions et les pertes de synchronisation semblent aléatoires ->il faut creuser de ce coté ci. 
    * Si les logs fournis par l'abonné établissent qu'il y a beaucoup de perte de paquets.

====== Point D: ======

Point essentiel à évoquer dès le premier contact avec l'abonné: 

**symptôme**

question à se poser : 
  * Est-ce qu'il y a une tonalité sur la ligne ? 
  * Y compris, si elles sont épisodiques, pendant les déconnexions ?
  * La ligne est elle exempte de bruits suspects, dont on aura vérifié qu'ils n'ont pas pour origine l'installation téléphonique personnelle de l'abonné ?

**résolution**

  * appeler le 1013

ou

  * se déplacer en agence France Télécom, et ne pas commencer par "J'ai un problème avec mon Internet" mais par "Je n'ai plus de tonalité sur ma ligne"

====== Point E: ======

Ici commence le domaine ou l'on peut ouvrir des tickets auprès de Nerim pour voir le problème se résoudre.

Si le lien est brisé avant le DSLAM mais qu'il y'a tonalité, une intervention commandée par Nerim permettra un retour de la connexion.

Il convient d'ouvrir un ticket auprès d'eux (en précisant bien qu'il n'y a plus de synchronisation ADSL, mais que la tonalité est OK, et que oui, on a vérifié le modem) et de demander à l'abonné de garder allumé son modem.

Un  cas un peu particulier et tordu est celui du défaut d'alignement. 
La paire cuivre branchée sur le port dans le DSLAM ne sera pas celle qui est censée l'être (comme une chemise fermée avec les mauvais bouton dans les mauvais trous), dans ce cas la synchronisation se fera, mais les séquences  de négociations PPP et/ou l'authentification échoueront, ou encore la  synchronisation ne se fera que d'un coté, abonné, ou DSLAM.
Nerim peut ne pas se rendre compte du souci aussitôt. Pour eux s'ils voient de la synchronisation, hop, c'est OK, affaire classée, donc il faut pouvoir leur balancer du log pour expliquer que non, c'est pas réglé.

====== Point F: ======

De loin le plus courant.
Il y a tonalité mais pas synchronisation, on ouvre un ticket chez Nerim, ils font faire un reset du port ADSL en DSLAM, ils nous préviennent, l'abonné redémarre son modem, la synchronisation est revenue, fin de l'histoire.

Points G & H : relativement analogues à E & F, excepté qu'au lieu d'une négociation entre modems pour obtenir une synchronisation, se met en place une séquence de négociation "PPPoE Discovery" (PAD*) avec plusieurs étapes:

Client vers serveur: Initiation (PADI)
Le routeur de l'abonné(e) envoie un message broadcast pour se faire entendre d'au moins un BAS.

Serveur vers client: Offer (PADO)
Tous les BAS ayant reçu la requête vont répondre au routeur, s'il y en a qu'un, facile, s'il y en a plusieurs le routeur de l'abonné(e) va en choisir un et lui répondre.

Client vers serveur: Request (PADR)
Le routeur de l'abonné(e) va alors demander aux BAS choisi une mise en relation.

Serveur vers client: Session-confirmation (PADS)
Le BAS accuse réception de la demande.
Client vers serveur: Ouverture de la session (LCP)

Début de l'authentification PPP

(Optionnel, et initié par l'un ou l'autre : Termination (PADT), pour fermer proprement une connexion)

Si les logs coté abonné indiquent que la connexion échoue à ce stade, un ticket chez Nerim permettra de résoudre le problème, du à un défaut de connectivité entre le DSLAM et le BAS.

====== Point I: ======
 
Si le problème se situe entre le BAS et la porte de collecte Nerim, alors l'authentification PPP n'aura pas lieu, on ne verra pas de trace de l'abonné(e) dans les logs du RADIUS de FDN.
L'authentification PPP qui est initié par le routeur de l'abonné et qui termine dans notre RADIUS passe par différents proxy qui, en fonction du login PPP, laissent passer ou pas, redirigent ou pas, vers l'opérateur adéquat (nous).

Si le login user@fdn.nerim ne fonctionne pas, on peut tester d'autres login pour savoir s'il s'agit d'un problème de proxy RADIUS en sortie de réseau de collecte.
Login PPP de test:
Orange (pour les accès non dégroupés): ADSL@ADSL 
SFR (pour les accès dégroupés): test@neufpnp ou ADSL@mire.ipadsl 
Password PPP, dans les 3 cas: ADSL
Une fois authentifié, le site http://mire.ipadsl.net doit être accessible à l'utilisateur.
Prévenir Nerim que l'authentification PPP ne passe pas le stade de leur porte de collecte en ouvrant un ticket, hop, au boulot les gens.

Au delà de ce point, ce n'est plus de la responsabilité de Nerim, mais heureusement les point suivants sont au choix: anecdotiques, réglés par les équipes compétentes parfois avant que l'abonné ne s'en rende compte ou tout simplement hautement improbables.

====== Point J: ======
 

Si par malheur un des LNS de FDN devait lâcher et que la mise en cluster ne fonctionne pas et que le deuxième LNS ne récupère par les sessions de celui qui a lâché, ça se verrait assez rapidement : la moitié du canal IRC #fdn partirait dans la minute en ping timeout.
Si ce sont les deux LNS, bin, ça sera alors tout FDN qui sera dans le noir. 
La situation est quand même exceptionnelle et suffisamment vite repérée par les adminsys pour que l'abonné(e) n'ai pas le temps d'écrire un mail avant le retour à la normale.

====== Point K : ======
 
En cas de défaillance de Gitoyen (on reste aussi dans l'ordre du très exceptionnel), on sera également assez vite renseigné : tout FDN sera dans le noir. 

====== Point L : ======
 
Si c'est le reste d'Internet qui en panne, il ne reste plus qu'à ouvrir un ticket auprès du Docteur, car c'est probablement la conséquence de l'invasion de la terre par les daleks.