La Fibre
Fournisseurs d'accès à Internet fixe en France métropolitaine => Bouygues Telecom => 
Incidents Bouygues => Discussion démarrée par: nasdak le 20 février 2016 à 15:50:54
-
EDIT du 23/02 : aucune connexion depuis le 16/02 malgré l'aide de Boris sur ce forum ; je commence à perdre patiente...
----
bonjour à tous
Abonné Bbox fibre FTTH depuis plusieurs mois tout marchait très bien (sauf la tv qui a toujours mal marché mais je ne la regarde pas) avec un débit proche de 1gbps, le bonheur quoi :D
Jusqu'au 15 février ou suitement 90% des sites sont devenus injoignables (seuls quelques sites marchent encore épisodiquement par exemple le forum hfr fonctionne,mais le monde par exemple est injoignable)
C'est la même chose sur 3 ordis différents, en ethernet ou wifi. Je suis sûr que ce n'est pas un problème de config
j'ai bien sûr vérifié mes branchements,résetté la box...
le téléphone fonctionne.
J'ai appelé le service client qui m'a fourni une clé 4G, certes cela dépanne mais n'a rien à voir avec la fibre.
Depuis le 16 février je suis en "incident déclaré". Pas de nouvelles depuis.
Ca vous parle ce type d'incident ? Bizarre d'avoir encore un trafic ?
merci !
Merci !
-
Intéressant comme problème.
Pouvez-vous me donner le point commun des sites qui marches et de ceux qui bloquent ?
Le protocole a une influence ? Voici une même page dispo en http et https et sans dns :
- http://ipv4.lafibre.info/ fonctionne ?
- https://ipv4.lafibre.info/ fonctionne ?
- http://46.227.16.8/ fonctionne ?
Si un des 3 pages fonctionnent, je suis intéressé par votre IP publique envoyé par message privé.
Que donne un traceroute vers un site qui ne fonctionne pas ? (je précise que lemonde.fr répond au ping normalement)
-
merci,
je vous réponds par mp
-
Les différents tests que j'ai fait ne montrent aucun problème de latence ou pertes de paquets.
en fait la plupart des sites finissent par s'afficher après plusieurs minutes d'attente (dont le monde). Quelques uns (hfr par exemple) s'affichent beaucoup plus vite la première fois mais après 2 ou 3 pages le chargement s'arrête.
J'ai réussi à me connecter en direct sur l'ONT sans la box - le résultat est identique.
Je vois que vous avez de bonnes connaissances en réseau si vous avez réussi une connexion en direct sur l'ONT.
Serait-il possible de faire une capture wireshark d'un site qui fonctionne mal ?
Tant qu'a faire en direct sur l'ONT avec le vlan200, cela élimine un pb sur la Bbox.
Vous pouvez tenter avec une MTU plus faible ?
Si vous êtes sous Linux, cela donne qq chose de ce genre pour /etc/network/interfaces pour une connection direct ONT avec une MTU de 1240 :
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet manual
auto eth0.200
iface eth0.200 inet static
address [IP]
netmask [MASQUE]
gateway [PASSERELLE]
hwaddress ether [ADRESSE MAC]
vlan-raw-device eth0
dns-nameservers 194.158.122.10 194.158.122.15
mtu 1240
Que donne un test de débit sur un serveur Bouygues Telecom ?
wget -O /dev/null http://1.testdebit.info/fichiers/100Mo.dat
-
Je vais essayer sans ont mais je n'ai reussi qu'une fois (en DHCP) apres pas mal de bidouillages...
Je void plein de pings sur wireshark est ce vous ?
-
En DHCP ? C'est étonnant que ce soit passé, normalement, il faut tout mettre en dur : IP, masque, passerelle et reprendre l'adresse mac de votre Bbox. C'est info sont à récupérer en réalisant une capture entre votre Bbox et l'ONT.
Ne vous embêtez pas : mettez la Bbox.
Les ping ce n'est pas moi (j'en ai fait une centaine entre 17h55 et 18h00 mais rien depuis)
-
J'ai lancé le test de debit (avec la box) ca a commence a 100ko/sec pendant 10 secondes puis debit nul plus rien nenpasse et cela reste a 0 pourcents
-
J'ai enregistré le log de wireshark mais je ne vois pas comment vous envoyer le fichier?
-
Fichiers joints, dans la création de post.
-
Oui mais comme il y a mon ip dedans je ne voudrais l'envoyer qu'a boris :)
-
fichier envoyé à boris par mp :)
-
Dans votre capture, votre ip publique n’apparaît pas, c'est l'IP de votre Bbox ur le lan (192.168.1.1) qui apparaît.
Je vois effectivement des paquets qui arrivent en retard (out of order) et des TCP Keep-Alive, ces derniers sembles juste là pour laisser la connexion ouverte.
Difficile de comprendre le pb.
Serait-il possible de de faire 2 autres captures :
- vous démarrez la capture wireshark (je souhaites avoir le début du transfert)
- vous lancez wget -O /dev/null http://1.testdebit.info/fichiers/100Mo.dat
- après deux minutes vous coupez la capture si il n'a pas terminé.
- vous démarrez une seconde capture wireshark
- vous lancez wget -O /dev/null https://2.testdebit.info/fichiers/100Mo.dat
- après une minute, vous coupez la capture si il n'a pas terminé et vous m'envoyez les 2 fichiers.
Merci.
-
et voici les 2 fichiers
en http il y a eu quelques secondes de transfert ; en https rien du tout
-
Il y a beaucoup de pertes de paquets, a un tel point que TCP/IP semble ne plus arriver à faire face.
Si vous réalisez un ping 1.testdebit.info vous avez quoi ?
Un exemple quand tout se passe bien :
$ ping 1.testdebit.info
PING 1.testdebit.info (194.158.102.114) 56(84) bytes of data.
64 bytes from 194.158.102.114: icmp_seq=1 ttl=60 time=6.80 ms
64 bytes from 194.158.102.114: icmp_seq=2 ttl=60 time=6.73 ms
64 bytes from 194.158.102.114: icmp_seq=3 ttl=60 time=6.74 ms
64 bytes from 194.158.102.114: icmp_seq=4 ttl=60 time=6.78 ms
64 bytes from 194.158.102.114: icmp_seq=5 ttl=60 time=6.76 ms
64 bytes from 194.158.102.114: icmp_seq=6 ttl=60 time=6.73 ms
64 bytes from 194.158.102.114: icmp_seq=7 ttl=60 time=6.68 ms
64 bytes from 194.158.102.114: icmp_seq=8 ttl=60 time=6.81 ms
64 bytes from 194.158.102.114: icmp_seq=9 ttl=60 time=6.81 ms
64 bytes from 194.158.102.114: icmp_seq=10 ttl=60 time=6.80 ms
64 bytes from 194.158.102.114: icmp_seq=11 ttl=60 time=6.78 ms
64 bytes from 194.158.102.114: icmp_seq=12 ttl=60 time=6.72 ms
64 bytes from 194.158.102.114: icmp_seq=13 ttl=60 time=6.71 ms
64 bytes from 194.158.102.114: icmp_seq=14 ttl=60 time=6.74 ms
64 bytes from 194.158.102.114: icmp_seq=15 ttl=60 time=6.74 ms
64 bytes from 194.158.102.114: icmp_seq=16 ttl=60 time=6.83 ms
64 bytes from 194.158.102.114: icmp_seq=17 ttl=60 time=6.73 ms
64 bytes from 194.158.102.114: icmp_seq=18 ttl=60 time=6.76 ms
64 bytes from 194.158.102.114: icmp_seq=19 ttl=60 time=6.76 ms
64 bytes from 194.158.102.114: icmp_seq=20 ttl=60 time=6.78 ms
64 bytes from 194.158.102.114: icmp_seq=21 ttl=60 time=6.78 ms
64 bytes from 194.158.102.114: icmp_seq=22 ttl=60 time=6.72 ms
^C
--- 1.testdebit.info ping statistics ---
22 packets transmitted, 22 received, 0% packet loss, time 21038ms
rtt min/avg/max/mdev = 6.683/6.762/6.832/0.083 ms
J'imagine que dans votre cas il va y avoir des "icmp_seq" sans réponse.
Pouvez-vous nous faire un mtr pour voir si ces pertes démarrent dés le début ?
La commande : mtr -rwc100 1.testdebit.info
Cela va mettre un peu de temps (il n'affiche le traceroute qu'a la fin)
-
Les pings passent tous sans aucun problème... Le mtr est en cours
-
root@kali:~# mtr -rwc100 1.testdebit.info
Start: Sat Feb 20 20:56:55 2016
HOST: kali Loss% Snt Last Avg Best Wrst StDev
1.|-- bbox.lan 0.0% 100 0.6 0.6 0.6 0.6 0.0
2.|-- static-212-194-108-2.ftth.abo.bbox.fr 0.0% 100 1.9 3.3 1.4 15.3 2.9
3.|-- be44.cbr01-lyo.net.bbox.fr 0.0% 100 3.5 3.4 1.3 5.5 1.0
4.|-- be5.cbr01-cro.net.bbox.fr 0.0% 100 9.7 11.7 7.8 15.8 2.2
5.|-- la43.rpt06-th2.net.bbox.fr 80.0% 100 7.8 7.9 7.7 8.3 0.0
6.|-- 194.158.102.114 0.0% 100 7.7 7.7 7.6 8.1 0.0
-
Je profite de tester la commande mtr moi aussi, car j'ai des lenteurs de connexion inexpliquées par moment. Et si les gros pourcentages de perte sont une explication ou pas. Si ce n'est pas le cas, j'en termine sur ce HS ;)
david@Kodi:~$ sudo mtr -rwc100 1.testdebit.info
Start: Sat Feb 20 21:19:29 2016
HOST: Kodi Loss% Snt Last Avg Best Wrst StDev
1.|-- router 0.0% 100 0.2 0.2 0.2 0.5 0.0
2.|-- gestionbbox.lan.home 0.0% 100 0.5 0.5 0.4 0.9 0.0
3.|-- 10.34.128.1 0.0% 100 7.1 7.2 5.7 11.5 0.6
4.|-- pal1rj-ge-2-1-0.200.numericable.net 0.0% 100 8.0 8.1 5.9 40.0 4.2
5.|-- ??? 100.0 100 0.0 0.0 0.0 0.0 0.0
6.|-- lag101.350.ncc-cbv.net.bbox.fr 0.0% 100 8.4 11.2 7.0 69.1 9.6
7.|-- 350.la101.bsr01-cbv.net.bbox.fr 90.0% 100 9.6 10.3 8.3 18.4 3.0
8.|-- be16.cbr01-ntr.net.bbox.fr 0.0% 100 12.5 12.8 7.8 29.3 3.1
9.|-- la42.rpt06-th2.net.bbox.fr 90.0% 100 10.2 11.1 9.4 17.8 2.3
10.|-- 194.158.102.114 0.0% 100 15.3 9.8 8.1 21.3 1.5
-
Ils n'en sont pas, ce sont juste des routeurs qui n'ont pas envie de répondre à l'ICMP.
-
Pour le 100% je m'en doute, mais pour ceux qui répondent à 90%?
C'est pas tout ou rien normalement?
-
Certains routeurs ne répondent qu'a une partie des ping reçu (rate-limited)
Si il n'y a pas de perte sur la destination finale, il n'y a pas de perte avant (les paquets sont bien routés)
Si il y a des pertes, cela nécessite un peu d'habitude pour tenter de discerner les non réponses au ping de vraies pertes.
-
Merci pour la réponse.
-
nasdak, une des hypothèse à ce point de l’enquête, est que les gros paquets de 1500 octets posent problèmes. Je voudrais vérifier ce point.
Serait-il possible de refaire une capture en configurant une MTU à 1240 ?
Voici une configuration de /etc/network/interfaces qui force une mtu à 1240 (le point important, c'est la ligne mtu 1240) :
auto eth0
iface eth0 inet static
address 192.168.1.100
netmask 255.255.255.0
gateway 192.168.1.254
dns-nameservers 194.158.122.10 194.158.122.15
mtu 1240
Pour la capture, il faudrait la lancer, avant de télécharger le fichier suivant :
wget -O /dev/null http://2.testdebit.info/fichiers/20Mo.dat
Si au bout de 2 minutes, il n'a pas terminé, vous pouvez arrêter l'expérience.
-
mtu à 1240 (via ifconfig ethO mtu 1240, je ne sais pas pourquoi quand je modifie etc/network/interfaces ça n'est jamais pris en compte, je sous kali) ça ne change pas grand chose (via la bbox - j'ai du mal à me connecter en direct à l'ONT)
-
Encore une fausse piste.
Cela serait possible de refaire une capture qui montre chaque paquets ? (là il y a des paquets agrégés en un seul par la carte réseau, d'où des tailles de plusieurs milliers d’octets pour certains paquets. Le but est diminuer la charge CPU cf TCP offload engine - Segmentation et Checksum réalisée par la carte réseau pour décharger le CPU (https://lafibre.info/tutoriels-linux/tcp-offload-engine/))
Sous linux, il faut installer le paquet "ethtool" (sudo apt install ethtool)
Et taper en ligne de commande :
sudo ethtool -K eth0 tso off gso off
C'est actif uniquement jusqu'au prochain reboot du PC.
Ensuite, refaire une capture avec wget -O /dev/null http://2.testdebit.info/fichiers/20Mo.dat
Merci.
-
fichier ci joint :)
et si tout simplement l'ONT déconnait ?
-
Je vais remonter votre problème aux équipes FTTH. Un grand merci pour les tests qui permettent d'exclure de nombreuses causes.
Serait-il possible de compléter votre profil avec le N° de client Bbox ?
Vous trouverez ce N° sur votre espace client Bouygues Telecom : http://www.espaceclient.bbox.bouyguestelecom.fr/ (http://www.espaceclient.bbox.bouyguestelecom.fr/)
(https://lafibre.info/images/bbox/Bbox_num_client_1.png)
Recopiez le N° de client sur votre profil LaFibre.info accessible via ce lien : https://lafibre.info/profile/?area=forumprofile (https://lafibre.info/profile/?area=forumprofile)
(https://lafibre.info/images/bbox/Bbox_num_client_3.png)
Cordialement,
Boris de Bouygues Telecom
-
J'ai ajouté mon numéro de client.
merci de votre aide !
sinon, j'ai retenté de me connecter sur l'ont en direct en static mais cela ne fonctionne plus. Etes vous capable de m'envoyer la passerelle (à priori j'ai toutes les autres infos mais je ne suis pas sur de la passerelle)
pierre
-
Désolé, mais je n'ai pas les infos...
Je viens d'envoyer le mail pour transmettre le dossier.
-
Wahou!!! C'est revenu cet apres midi 8)
Le test wget me donne un peu plus 100MB/sec soutenus.
Avez vous moyen de savoir de quoi il s'agissait ?
Un enorme merci en tout cas !
-
J'ai parlé trop vite, là je n'ai plus de connection du tout (pas d'ip) :D
-
aucune connexion et @ clignote en rouge depuis 2 heures :-[
-
Mon contact a transféré votre cas à une cellule qui va régler votre problème.
Je sais seulement que votre dossier a bien été transféré.
Boris.
-
Merci :)
A suivre !
-
Voici 2 jours que la box alterne clignotage blanc, rose et rouge... pas de connexion depuis le 16/02 et aucune info "officielle" de Bouygues depuis cette date cela commence à faire long!
-
ce soir l'incident semble résolu
8.6 secondes pour 1giga cela semble irréel :)
root@kali:~# wget -O /dev/null https://2.testdebit.info/fichiers/1000Mo.dat
--2016-02-26 19:29:01-- https://2.testdebit.info/fichiers/1000Mo.datroot@kali:~# wget -O /dev/null https://2.testdebit.info/fichiers/1000Mo.dat
--2016-02-26 19:29:01-- https://2.testdebit.info/fichiers/1000Mo.dat
Résolution de 2.testdebit.info (2.testdebit.info)… 89.84.127.49, 2001:860:f70b::49
Connexion à 2.testdebit.info (2.testdebit.info)|89.84.127.49|:443… connecté.
requête HTTP transmise, en attente de la réponse… 200 OK
Taille : 1000000000 (954M)
Sauvegarde en : « /dev/null »
/dev/null 100%[===================>] 953,67M 112MB/s in 8,6s
2016-02-26 19:29:10 (111 MB/s) — « /dev/null » sauvegardé [1000000000/1000000000]
Résolution de 2.testdebit.info (2.testdebit.info)… 89.84.127.49, 2001:860:f70b::49
Connexion à 2.testdebit.info (2.testdebit.info)|89.84.127.49|:443… connecté.
requête HTTP transmise, en attente de la réponse… 200 OK
Taille : 1000000000 (954M)
Sauvegarde en : « /dev/null »
/dev/null 100%[===================>] 953,67M 112MB/s in 8,6s
2016-02-26 19:29:10 (111 MB/s) — « /dev/null » sauvegardé [1000000000/1000000000]