Salut,

Il y a quelques jours encore, j'étais chez SFR en ADSL2+, je synchronisais à 22 Mb/s environ, de manière stable (je n'ai pas le souvenir d'avoir remarqué une désynchro inopinée depuis quelques mois), sur une ligne d'environ 450 m.

Vu les caractéristiques de ma ligne, je me suis dit qu'il pourrait être intéressant de passer au VDSL2, mais vu que ça impliquerait maintenant un changement de box taxé de 49 €, un réengagement incertain et une augmentation du tarif nette avec location box à 3 €/mois etc., je me suis dit que ça pourrait être une occasion intéressante de passer sur l'offre Bbox. Je me suis dit que ça pourrait être un atout matériel intéressant (en marge d'un changement de matériel informatique que j'opérais en parallèle) pour faire du petit auto-hébergement, en tous cas pas une grosse affaire.

J'ai donc fait la souscription en ligne, et 4 jours plus tard j'ai reçu une Bbox 5330b (chipset Broadcom récent) et été branché sur un DSLAM (corrigé : Huawei) dégroupé Bouygues en propre.

J'ai 1 arrivée et 2 prises FT dans mon appartement, toutes trois situées à quelques mètres l'une d'entre elles dans le salon. J'étais branché sur la 2nde prise jusqu'à là, j'en ai profité pour passer sur la 1ère, au passage en retirant les fils vers la suivante (en série) et en mettant de côté la balise RC 2 broches (pas utile dans l'immédiat j'imagine ), bref j'ai laissé le fil blanc et le fil gris, mais au passage en faisant partir et remettant, revissant les contacts correspondants.

Bref les fils sont sous les contacts et les vis sont vissées, à partir de ce moment j'imagine qu'il n'y a pas de problème à ce niveau-là ?

---

     

---

Ceci fait et déterminé, j'ai branché la Bbox pour la première fois et j'ai observé une première synchonisation en VDSL2 à environ 50 Mb/s descendants et 5 Mb/s montants. Mais ce fut de courte durée, après quelques minutes (ou une heure ch'ais pu), la box resynchronise et perd environ 10 Mb/s descendants, et passe à... 200 Kb/s montants après vérification sur la page d'administration WAN de la Bbox, la quantité d'erreurs (FEC/CRC) en "local" est faramineuse tandis qu'elle est quasi-nulle en "distant" (si j'ai bien compris c'est comme ça que le modem parle respectivement de voie montante et descendante). Le débit continue d'être baissé à plusieurs reprises, puis la nuit tombe et passe.

Le lendemain, il est stabilisé à 12 Mb/s et 7xx Kb/s montants, désormais en ADSL2+. Je remarque que les erreurs sont toujours en large nombre mais que le rapport des valeurs locales/distantes semble s'être pratiquement inversé (la cause du shift de fréquences ?).

Je décide d'essayer de supprimer un maximum de facteurs de parasitage locaux potentiels, je débranche tous les autres appareils reliés à l'électricité dans la pièce, passe du CPL en WiFi exclusivement, branche la box en direct sur une autre prise électrique, tend davantage le câble RJ11<->T. Je re-check que tout est bien vissé dans la prise. Je laisse comme ça quelques heures. Le débit n'augmente pas, des erreurs sont toujours générées et la box désynchronise de temps à autres.

Débit descendant : 12.00 Mbps
Débit montant : 793.00 kbps
Durée de synchronisation : 1 heure 10 minutes
Nombre de synchronisation : 1
Modulation : ADSL2+ (G.992.5-A)
Chipset du DSLAM : BDCM
Atténuation de ligne (montant) : 6.6 dB
Atténuation de ligne (descendant) : 11.0 dB
Marge signal/bruit (montant) : 4.2 dB
Marge signal/bruit (descendant) : 15.7 dB
FEC (local) : 14
FEC (distant) : 17 457
CRC (local) : 0
CRC (distant) : 820
HEC (montant) : 0
HEC (descendant) : 3 828
Retransmission : G.INP
Nitro : Activé

Dans la foulée, j'ai plusieurs moments de perturbation très forte où la box n'arrive même plus à resynchroniser, ou à passer l'étape du DHCP, ou à rester synchronisée plus de quelques minutes à secondes (mais la synchro reste invariablement à 12 Mb/s, cimer DLM). Dans ces conditions le facteur FEC/seconde est admirable :

Débit descendant : 12.00 Mbps
Débit montant : 799.00 kbps
Durée de synchronisation : 3 minutes
Nombre de synchronisation : 13
Modulation : ADSL2+ (G.992.5-A)
Chipset du DSLAM : BDCM
Atténuation de ligne (montant) : 6.6 dB
Atténuation de ligne (descendant) : 11.0 dB
Marge signal/bruit (montant) : 2.9 dB
Marge signal/bruit (descendant) : 14.6 dB
FEC (local) : 1
FEC (distant) : 15 569
CRC (local) : 0
CRC (distant) : 857
HEC (montant) : 0
HEC (descendant) : 7 166
Retransmission : G.INP
Nitro : Activé

J'en suis désormais là et me demande ce qui peut sincèrement se passer avec ce bout de cuivre.

• Rififi au NRA, le tech a fait tomber son Oasis sur la ligne en bougeant de DSLAM ?
• Rififi sur mes branchements locaux ?
• Rififi à l'extérieur, jamais vu mais venu sur cette période très précise de 4 jours de migration ?
• Un ou plus des facteurs ci-dessous dont les conséquences visibles sont en fait majorées par le système de DLM de Bouygues ?
• Ma box est éblouie par la puissance de ma ligne et refuse de se confronter à la réalité ?

Je remarque au passage que le passage en mode portail captif de la box dès qu'elle ne synchronise plus est légèrement gênant, ça pollue le cache du navigateur avec de fausses redirections, jette des erreurs de certificat et fait planter les mises à jour Arch. Mais tant que ce n'est pas en permanence ça va

Voilà, si vous avez des critères de test supplèmentaires à suggérer, n'hésitez pas.

Elle est propre ta prise ? J'ai l'impression de voir des traces (de platre ?) à l'intérieur..
Essaye de la remplacer par la 2eme qui est chez toi...

Chez moi j'ai viré la prise et j'ai utilisé des scotch lock avec un câble rj11 coupé à une des extrémités.

Essaye de la remplacer par la 2eme qui est chez toi...

Suite à ce message, je suis repassé sur la 2nde prise après l'avoir remise en série. Je n'ai pas observé de différence immédiate dans les valeurs (que ce soit erreurs/atténuations/marge de bruit, ou peut-être ± 1 dB).

Le lendemain, le DLM m'a encore fait perdre 1 Mb/s (je suis passé à 11 Mb/s down et 6xx Kb/s up) et le débit n'a pas bougé depuis. Je suis donc à la moitié de ce que j'avais avant.

Je rencontre encore des désynchronisations toutes les quelques heures à en constater le log de la box (mais il ne me semble plus avoir vu de gros rush de ligne inutilisable pendant x minutes).

Chez moi j'ai viré la prise et j'ai utilisé des scotch lock avec un câble rj11 coupé à une des extrémités.

vous pouvez également connecter directement à votre modem sans mettre de prise pour gagner quelques Mb/s, par exemple avec un câble RJ11 coupé et raccordé aux câbles 1 et 3 (ne plus les raccorder à la prise).

Merci, je vais étudier ces possibilités et le matériel nécessaire (câble/connecteur/pince à sertir...).

Je reviens sur des messages plus vieux dans lesquels le sujet avait été abordé :

Si tu souhaites avoir un débit maximal avec ta ligne, l'idéal est de tirer un câble directement depuis le petit boîtier d’arrivée FT jusqu'à ta box (il faut mettre un connecteur RJ11 au bout de ton câble). Aucune prise, c'est l'idéal après a toi de voir selon ton éloignement du NRA et le débit que tu souhaites avoir.

Citation de: Marin le 13 août 2014 à 17:38:06

Si besoin d'ouvrir le boîtier d'arrivée ( type "cercueil" dans le jargon), il est clipsé. Il faut juste tirer dessus. Comme il a été peint par dessus ça va résister un peu. C'est un modèle sans parafoudre avec des connexions à vis.

Essayer de tirer dessus en forçant pendant un petit moment ne semble pas donner de résultats. Est-ce qu'il faudrait d'abord utiliser un outil particulier pour essayer d'enlever la peinture autour ? (pour rappel, il est peu accessible, il se trouve derrière un radiateur et dans un angle)

Par contre le DSLAM n'est pas un Alcatel ISAM, si c'est un dégroupage en propre, mais un Huawei équipé lui aussi d'un chipset Broadcom de dernière génération.

Oui désolé, j'avais mélangé, étant également passé par un Huawei 5600 chez mon ancien opérateur.

Le VDSL est très très sensible a la qualité de l’installation téléphonique (sans comparaison avec l'ADSL) et le débit peu être moindre qu'en ADSL en cas d’installation de mauvaise qualité. (une ligne VDSL peut gagner du débit a basculer sur une modulation ADSL2+)

Le point est que la baisse de débit/sychro/stabilité même après re-passage en ADSL2+ par rapport à l'ancienne configuration m'a surpris (et je ne l'explique pas tout à fait). L'objectif premier serait de revenir au moins à ce dont je disposais avant.

Si vous améliorez votre installation après la phase d'optimisation, je peut relancer l'optimisation sur votre ligne (un profil différent est testé chaque jour)

Merci, ce sera certainement utile par la suite.

---

Sinon, voici quelques observations sur le fonctionnement de la Bbox :

• Point positif : l'ergonomie de l'interface d'administration web (par ailleurs assez soignée visuellement), une belle réalisation et notamment en étant parti du middleware Bewan
• Bug : l'ouverture de plusieurs connexion HTTP(S) en chaîne semble parfois déclencher l'envoi d'un paquet RST lors de l'initiation de celles-ci. Cela entrave le fonctionnement normal de certaines applications. Constaté au moins lors de : la navigation web (chargement d'une frame allant vers un site tiers), l'utilisation de mon gestionnaire de paquets système (archlinux/yaourt), l'utilisation d'un gestionnaire de paquets tiers (ruby/gems). Je ferai peut-être un rapport plus détaillé du problème plus tard.
• Bug : le portail captif qui se met en place lorsque la box ne synchronise pas semble polluer le cache du navigateur avec des redirections permanentes, comme mentionné plus haut.
• Bug : l'émission du hotspot ne s'active pas, malgré plusieurs désactivations/réactivations sur l'espace client Bouygues. L'interface d'administration (http://gestionbbox.lan/wally.html) indique : « Le service de Wifi Communautaire est désactivé », le site indique le contraire. Il me semblait avoir vu passer un tweet indiquant que le réseau de hotspots de Bouygues était en cours de dépréciation voire d'arrêt, est-ce exact ?
• Fonctionnalité absente : je pensais utiliser un tunnel HE.net en attendant le déploiement effectif de l'IPv6 sur le réseau Bouygues, les options d'administration du NAT de la box ne semblent pas rendre ça possible. Mais ce n'est pas une fonctionnalité très critique et je peux me contenter d'utiliser un serveur distant pour les diagnostics réseau.

Pour le portail captif qui se met en place lorsque la box ne synchronise pas, vous pensez à quelle solution ?

En premier lieu, ne pas capter le trafic sur le port 443. Effrayer l'utilisateur de base (puisque c'est lui qui est visé par ce système) avec un warning de sécurité qu'il ne contournera pas (puisque l'UI des navigateurs modernes est conçue pour ça) ne sert à rien. Autant laisser se dérouler le comportent normal en cas d'erreur réseau.

Ensuite, et si vous y tenez toujours, s'assurer que les codes d'état et les en-têtes HTTP constituant la redirection sur le port 80 ne déclenchent pas de comportement de mise en cache sur les principaux navigateurs et ne soient pas ambigus. Éventuellement, couper la connexion TCP après réception de la requête si l'User-Agent n'est pas celui d'un navigateur commun afin d'éviter de perturber son fonctionnement.

Ce n'est pas la Bbox qui fera le tunnel avec HE, mais quel est le pb pour mettre le tunnel HE sur votre PC ?

Si j'ai bien compris, et comme indiqué dans la FAQ, le protocole utilisé dans ce cas de figure est 6in4 (encapsulation directe du trafic sous l'en-tête IPv4) et non une forme de tunnel basée sur TCP ou UDP, ce qui nécessite la redirection d'une catégorie particulière des paquets :

I've tried to create a tunnel but did not succeed. Is there a basic guideline on how to set up a tunnel?

[....]
If you are using a NAT (Network Address Translation) appliance, please make sure it allows and forwards IP protocol 41.

What is IP Protocol 41?
    IP Protocol 41 is one of the Internet Protocol numbers. Within the IPv4 header, the IPv4 Protocol field is set to 41 to indicate an encapsulated IPv6 packet.

J'ai suivi la procédure donnée par le service web pour et sur une machine avec une distribution standard et le trafic ne passait pas.

Bug : l'ouverture de plusieurs connexion HTTP(S) en chaîne semble parfois déclencher l'envoi d'un paquet RST lors de l'initiation de celles-ci. Cela entrave le fonctionnement normal de certaines applications. Constaté au moins lors de : la navigation web (chargement d'une frame allant vers un site tiers), l'utilisation de mon gestionnaire de paquets système (archlinux/yaourt), l'utilisation d'un gestionnaire de paquets tiers (ruby/gems). Je ferai peut-être un rapport plus détaillé du problème plus tard.

Après avoir effectué davantage de recherche, ce problème semble concerner spécifiquement les services hébergés derrière le service de CDN Fastly (Imgur, Github...). Je me suis donc dirigé vers leur support pour commencer.