Bon, je vais me hasarder à faire un point sur ce qu'on lit sur pfa, sachant que je suis simple utilisateur, non spécialiste de la techno ADSL, mais que j'aime free (et ses avancées techniques régulières) mais également les situations claires...
Autant dire que là ...la situation n'est pas encore clarifiée.
On a attendu 24h...pas bon,
On est en train d'attendre 48h...à voir
Sur pfa, on a deux infos....complémentaires dans l'absence
de certitude des gens de free :
- l'une aboutit à la conclusion attendons le résultat des tickets GAMOT lancés vendredi,
- l'autre à la conclusion inverse (un GAMOT ne sert à rien);
LA QUESTION serait éventuellement; est-ce que FT traite des tickets GAMOT le week-end??? (koko???)
En tout cas on a un bel exemple de l'absence de communication FT-Free, sinon de la comm aurait été organisée autour de l'événement (y compris ici)
...on est quand même très nombreux, sans connexion.
Ci-dessous les 2 fils issus de proxad.free.adsl :
=======abstract1=======
> La phase d'authentication est un p'tit peut complexe... Un fois qu'on a la synchro (rectangle clignotant sur la FB, led vert ou autre sur les autres modems) on passe a la phase d'authentication.
> Pour faire ca, la FB va contacter un proxy radius (qui est a FT) qui se trouve sur la reseaux FT apres le BAS. Selon le destinataire du login (le @freeadsl qu'on a dans les identifiants qu'on utilise avec les autres modems), le proxy s'adresse au bon server radius qui se trouve chez le ISP et qui est gere par l'ISP.
> C'est donc le server radius (dans notre cas celui de Free) qui verifie notre compte et qui donne le feux vert (via le proxy FT) au modem et au BAS et qui retourne l'adresse IP (donc, la route VPN BAS-LNS).
> Donc, FT est coupable si le proxy radius (ou sa config) est different entre une ligne max et classique.
brina répond : Ou si la config au niveau du BAS a merdé lors de la migration et n'envoie pas vers le bon radius (ie ce n'est pas envoyé vers les radius Free)
> Vu qu'a partir du meme NRA les comptes free 2048 marchent sur une ligne 2048 mais pas sur une ligne max (avant c'etait possible -mais formalment interdit- de s'exchanger les logins entre 512/1024/204
et que depuis une ligne max on peut quand meme se logguer avec les identifiants de n'importe quel autre ISP, ca sonne comme si il y a une manip qui s'est mal passe dans les scripts de FT (config proxy radius?).
brina answered : a priori c'est ça
> Free peut voir les logs sur leur server radius, donc il peut voir ce qui se passe (ou ce qui ne se passe pas) avec les proxys, et il paie une fortune a FT pour ca. Possible qu'il ne peut pas pretendre que FT fasse un effort (le WE) pour investiguer ou ca coince?
brina hasarde les éléments suivants : La seule possibilité est de voir ce que vont donner les GAMOT déjà lancés vendredi et qui ne sont toujours pas traités par FT
=======abstract2========
(t]
> je n arrete pas de lire les posts ici et j aimerais savoir si on doit demander un GAMOT pour ce probleme de PPP a cause de la migration ou es ce que FT va regler son plantage tout seul ?
brina dit : A priori non, un GAMOT n'a pas lieu d'être : si l'on arrive au PPP, c'est que la ligne est bien raccordée. Certes, une freebox raccordée à un DSLAM
qui ne répond pas en PPP afficherait aussi "PPP" clignotant, donc l'erreur de câblage n'est pas à exclure totalement, mais l'hypothèse la plus simple demeure : problème d'authentification concernant les BAS, les proxy RADIUS ou les RADIUS de Free (1), donc hors du champ d'action du GAMOT.
(1) encore que Free a vérifié ses RADIUS, et qu'ils contiennent bien les logins/mdp, donc ce n'est pas du côté de la base d'utilisateurs sur le RADIUS qu'il faut chercher.[/quote]
======end of quotation=======
