depannage_adsl
Différences
Ci-dessous, les différences entre deux révisions de la page.
Les deux révisions précédentesRévision précédenteProchaine révision | Révision précédente | ||
depannage_adsl [2012/03/19 11:34] – thy | depannage_adsl [2024/06/25 10:55] (Version actuelle) – [Débugger une ligne ADSL pour les nuls] snifiboy | ||
---|---|---|---|
Ligne 1: | Ligne 1: | ||
- | (thy; page en brouillon, je vais structurer au fur et à mesure, no panic) | + | ====== Débugger une ligne ADSL pour les nuls ====== |
- | -Tonalité ? | + | //**NB.** Les points de contact pour le support sont la liste **suivi-xdsl at faimaison.net** et la ligne **07 82 32 42 38**.// |
- | -Synchro | + | {{ : |
- | -Etablissement d'une session PPP ? (padi/pado, padr/pads, LCP) | + | 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. | ||
- | -LNS | + | {{ : |
- | -Radius | + | Pour déterminer d'où vient la cause du problème il convient de procéder par élimination, |
- | http://mire.ipadsl.net | + | Gitoyen ne pourra que compatir si nos LNS sont en carafe, mais pas nous aider. |
- | login de FT (non dégroupé): adsl@adsl | + | Si il y a perte de synchronisation mais toujours une tonalité, France Télécom annonceras poliment à l' |
- | Login de SFR (dégroupé) : test@neufpnp ou adsl@mire.ipadsl | + | On ne peut pas demander à FT de rétablir la tonalité sur une ligne, c'est à l' |
- | (mot de passe: adsl dans les 3 cas) | + | ====== Point A: ====== |
+ | Quand un adhérent nous contacte, D' | ||
+ | * vérifier que son RJ45 soit pas débranché, | ||
+ | * demander au passage si quelque chose a bougé dans sa configuration réseau. | ||
- | https:// | ||
- | http:// | + | ====== Point B: ====== |
- | https:// | + | Un équipement réseau (modem, routeur) qui défaille, ça arrive et les causes sont multiples |
- | http://www.generation-nt.com/ | + | * 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' | ||
+ | |||
+ | |||
+ | |||
+ | **résolution** | ||
+ | plusieur cas de figure : | ||
+ | * L' | ||
+ | * Si il est possible faire des test croisés, c'est pas plus mal. | ||
+ | * Remplacer le modem de l' | ||
+ | ====== 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' | ||
+ | |||
+ | * Brancher le modem sur une autre prise téléphonique, | ||
+ | * s' | ||
+ | * 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' | ||
+ | |||
+ | ====== Point D: ====== | ||
+ | |||
+ | Point essentiel à évoquer dès le premier contact avec l' | ||
+ | |||
+ | **symptôme** | ||
+ | |||
+ | question à se poser : | ||
+ | * Est-ce qu'il y a une tonalité sur la ligne ? | ||
+ | * Y compris, si elles sont épisodiques, | ||
+ | * La ligne est elle exempte de bruits suspects, dont on aura vérifié qu'ils n'ont pas pour origine l' | ||
+ | |||
+ | **résolution** | ||
+ | |||
+ | * appeler le 1013 | ||
+ | |||
+ | ou | ||
+ | |||
+ | * se déplacer en agence France Télécom, et ne pas commencer par " | ||
+ | |||
+ | ====== 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' | ||
+ | |||
+ | Un cas un peu particulier et tordu est celui du défaut d' | ||
+ | La paire cuivre branchée sur le port dans le DSLAM ne sera pas celle qui est censée l' | ||
+ | Nerim peut ne pas se rendre compte du souci aussitôt. Pour eux s'ils voient de la synchronisation, | ||
+ | |||
+ | ====== Point F: ====== | ||
+ | |||
+ | De loin le plus courant. | ||
+ | Il y a tonalité mais pas synchronisation, | ||
+ | |||
+ | Points G & H : relativement analogues à E & F, excepté qu'au lieu d'une négociation entre modems pour obtenir une synchronisation, | ||
+ | |||
+ | Client vers serveur: Initiation (PADI) | ||
+ | Le routeur de l' | ||
+ | |||
+ | 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' | ||
+ | |||
+ | Client vers serveur: Request (PADR) | ||
+ | Le routeur de l' | ||
+ | |||
+ | 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' | ||
+ | |||
+ | (Optionnel, et initié par l'un ou l' | ||
+ | |||
+ | 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' | ||
+ | L' | ||
+ | |||
+ | Si le login user@fdn.nerim ne fonctionne pas, on peut tester d' | ||
+ | Login PPP de test: | ||
+ | Orange (pour les accès non dégroupés): | ||
+ | SFR (pour les accès dégroupés): | ||
+ | Password PPP, dans les 3 cas: ADSL | ||
+ | Une fois authentifié, | ||
+ | Prévenir Nerim que l' | ||
+ | |||
+ | Au delà de ce point, ce n'est plus de la responsabilité de Nerim, mais heureusement les point suivants sont au choix: anecdotiques, | ||
+ | |||
+ | ====== 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' | ||
+ | |||
+ | ====== Point K : ====== | ||
+ | |||
+ | En cas de défaillance de Gitoyen (on reste aussi dans l' | ||
+ | |||
+ | ====== Point L : ====== | ||
+ | |||
+ | Si c'est le reste d' | ||
depannage_adsl.1332156881.txt.gz · Dernière modification : 2013/01/01 22:59 (modification externe)