La Fibre
Fournisseurs d'accès à Internet fixe en France métropolitaine => Free => 
Incidents Free => Discussion démarrée par: Mat753 le 10 novembre 2020 à 20:09:01
-
Bonsoir,
Depuis que je suis rentré vers 19h j'ai remarqué que discord n'arrive pas a charger des images ; et certains sites ne marchent plus, de même je n'ai plus de connectivité ipv4 en regardant sur https://ip.lafibre.info/ J'ai demandé l'ipv4 full stack depuis le début sans problème
Bizarre tout de même.
-
Oh, le bug intéressant pour promouvoir IPv6 sur les sites web !
Tiens nous informé.
-
Reboot de la box tjr pareil
;D Ouais n'empêche je ne plus télécharger sur 1fichier en forçant l'ipv6 c'est ok ; pour le site marche et youtube rame et le site client free aussi :D 'sont fort
-
1fichier.com est en IPv6, ils me font de beaux pics sur mes graphs ;)
-
1fichier.com est en IPv6, ils me font de beaux pics sur mes graphs ;)
Claire sa doit se voir de ouff ;D
-
Oui j'ai forcé l'ipv6
-
C'est le DHCP IPv4 qui ne fonctionne plus ? Il doit être possible de rentrer manuellement une IPv4.
Chez moi, pas de problème.
C'est quelle box ?
-
la révolution , on rentre ou le dhcp sur l'ordi ou la box ?
-
Le DHCP, cest sur la box, mais on n'entre rien, c'est normalement automatique. Tu peux rebooter ta box pour redémarrer le service.
Sinon, sur le PC, tu peux fixer une adresse IPv4. Par exemple 192.168.0.10/255.255.255.0. Provisoirement...
-
La box à été reboot, le pc aussi j'ai bien mon ipv4/ipv6 d'affichée sur l'interface de la box; j'ai affecté une ipv4 fixe sur le pc => tjr rien
-
Tu ping 192.168.0.254, c'est à dire la passerelle, la box ? J'ai oublié, mais il faut aussi l'ajouter en fixe, ainsi que des DNS, par exemple ceux Google, 8.8.8.8.
-
ping box ok ; ping 8.8.8.8 =15ms ; ping google.fr, free.fr, lafibre.info ne marchent pas c'est bizarre pourtant j'y ai bien accès ???
-
Et quand tu ping google.fr, free.fr..., il t'affiche l'adresse en IPv4 ou en IPv6 ?
-
en ipv6 ; par contre j'ai ping sagesse.fr il m'affiche bien l'ipv4 ??? c'est quoi le délire ? et j'ai 15ms (serveur à paris)
-
Alors c'est bizarre que cela ne marche pas.
Et si tu ping l'adresse IPv4, par exemple de Google ?
$ host google.fr
google.fr has address 216.58.213.163
google.fr has IPv6 address 2a00:1450:4007:806::2003
-
Oui c'est ça
-
par contre j'ai ping sagesse.fr il m'affiche bien l'ipv4 ??? c'est quoi le délire ? et j'ai 15ms (serveur à paris)
En ce qui me concerne :
~$ ping sagesse.fr
PING sagesse.fr (194.60.240.17) 56(84) bytes of data.
64 bytes from sagesse.crypteo.net (194.60.240.17): icmp_seq=1 ttl=58 time=2.85 ms
64 bytes from sagesse.crypteo.net (194.60.240.17): icmp_seq=2 ttl=58 time=2.58 ms
Si tu essayes un traceroute (ou tracert sous windows) sur sagesse.fr, il passe par où ?
-
j'ai activer le serveur DHCPv6 et désactivé j'ai réussi à ping google.fr et sagesse.fr ??? et ensuite plus rien
-
Oui, donc valeurs normales. Je pense que ta box a un petit souci, ou l'OLT du DSLAM en face. C'est quoi la version de firmware ?
-
Freebox server r1 ; firmware 4.2.5 ; j'ai reboot l'ont aussi
Je passe par un vpn là j'ai une ipv4 et l'ipv6 de free donc ça marche bien ^^
-
J'avoue ne rien comprendre à ce topic.
Il faudrait la configuration réseau du système, avec la commande : ipconfig /all
Ensuite, pour les IPv6, il faut cacher la fin (à droite) et non le début, sinon ça ne nous apporte rien.
-
OK j'ai viré le message;
-
Je ne vois rien de problématique dans la configuration de l'interface réseau.
Il n'y a pas un logiciel dégueulasse de filtrage réseau, d'optimisation réseau, de protection réseau ou je ne sais quoi d'autre ? Il faudrait essayer en mode sans échec pour en être sûr.
-
Cela fait 2 mois que une de mes adresses Ipv4 publique réponds pas à icmp sur la révolution.
ping statistics ---
8 packets transmitted, 0 received, +6 errors, 100% packet loss, time 7009ms
Tant que les services tournent cela ne me pose pas de soucis.
PORT STATE SERVICE
53/tcp open domain
80/tcp open http
Je me dis que cela fait une bonne protection anti DDOS
Enfin bon, ce n'est pas normal, mais j'y vois un avantage.
-
Non j'ai rien de tout ça, c'est une carte réseau intel, j'ai fait des tests avec le logiciel tout est ok ; lundi ça marchait niquel et hop hier soir ça à commencé; Je vais aller tester en mode sans échec
Sur free j'ai ça
NRO : 12202FOR
Adresse IP : 82.65.***.*** (full stack)
Votre préfixe IPv6 : 2a01:e0a:5fb:7790::/64
-
Cela fait 2 mois que une de mes adresses Ipv4 publique réponds pas à icmp sur la révolution.
ping statistics ---
8 packets transmitted, 0 received, +6 errors, 100% packet loss, time 7009ms
Tant que les services tournent cela ne me pose pas de soucis.
PORT STATE SERVICE
53/tcp open domain
80/tcp open http
Je me dis que cela fait une bonne protection anti DDOS
Enfin bon, ce n'est pas normal, mais j'y vois un avantage.
Bon les gars on va essayer de ne pas tout mélanger svp, ça n'a rien à voir avec le sujet ça ! Vous êtes tout simplement sur la nouvelle infra réseau de Free et les IPv4 ne sont plus directement sur les box mais sur des passerelles intermédiaires, qui ne répondent pas au ping. Bref rien à voir.
-
Bon les gars on va essayer de ne pas tout mélanger svp, ça n'a rien à voir avec le sujet ça ! Vous êtes tout simplement sur la nouvelle infra réseau de Free et les IPv4 ne sont plus directement sur les box mais sur des passerelles intermédiaires, qui ne répondent pas au ping. Bref rien à voir.
Histoire que je comprenne et ne mélange pas tout.
Tiens, tu peux nous en dire un peu plus ?
-
Ce sujet en parle : https://lafibre.info/free-la-fibre/cgn-14-chez-free-une-ipv4-partagee-par-4-clients/
-
Ce sujet en parle : https://lafibre.info/free-la-fibre/cgn-14-chez-free-une-ipv4-partagee-par-4-clients/
Ha, même quand on a une IP full-stack ?
-
C'est le même principe de tunnel, mais je ne sais pas si l'ip full stack est configurée sur la box ou bien à l'autre bout du tunnel, ni si elle répond au ping (y'a un paramètre de réponse au ping chez free, peut être fonctionne-t-il en full stack)
-
C'est le même principe de tunnel, mais je ne sais pas si l'ip full stack est configurée sur la box ou bien à l'autre bout du tunnel, ni si elle répond au ping (y'a un paramètre de réponse au ping chez free, peut être fonctionne-t-il en full stack)
C'est bien ce que je me disais.
Jusqu'a il y a 2 mois cela fonctionnait avec une réponse icmp, plus depuis, même si cela ne me fais ni chaud, ni froid.
-
La box répond au ping quand tu as une IPv4 fullstack SI tu as bien activé la réponse au ping dans Freebox OS.
-
Petite correction il s'agit plutôt de la perte de mon reverse DNS ipv4 non ? Plutôt que de l'adresse ipv4 elle-même ? Même s'il les 2 sont liés
-
Euh, il me semble pas que ce que tu dises là ait un sens... M'enfin je crois que je n'ai toujours pas vraiment compris quel est le problème à la base.
En tout cas, le reverse DNS c'est la traduction en un nom de domaine de ton adresse IP et ça importe généralement assez peu.
Par exemple avec mon IP :
nslookup 82.64.XXX.XXX
XXX.XXX.64.82.in-addr.arpa name = 82-64-XXX-XXX.subs.proxad.net.
-
Je n'ai plus de connectivité IPv4 => surement lié à un incident en cours a rodez ou dans l'Aveyron
-
On me souffle que c'est un problème de MTU.
https://dev.freebox.fr/bugs/task/33061
Vu dans le 81 et le 46.
-
Si je fais un reset de la box ? ça peut marcher ?
-
On me souffle que c'est un problème de MTU.
https://dev.freebox.fr/bugs/task/33061
Vu dans le 81 et le 46.
Ah, c'est déjà arrivé il y a pas longtemps : https://lafibre.info/free-espace-technique/dysfonctionnement-ssl-sur-free-fibre-probleme-de-fragmentation-mtu/.
-
C'est bon ! c'est revenu 8)
-
Le soir ça déconne : j'ai 15ms d'habitude et là 366ms ça passe par Londres et paloalto ???
Quelle utlité ce dns ?
-
Même constat ici :o :
C:\Windows\System32>ping 1.1.1.1
Envoi d’une requête 'Ping' 1.1.1.1 avec 32 octets de données :
Réponse de 1.1.1.1 : octets=32 temps=357 ms TTL=50
Réponse de 1.1.1.1 : octets=32 temps=357 ms TTL=50
Réponse de 1.1.1.1 : octets=32 temps=357 ms TTL=50
Réponse de 1.1.1.1 : octets=32 temps=357 ms TTL=50
Statistiques Ping pour 1.1.1.1:
Paquets : envoyés = 4, reçus = 4, perdus = 0 (perte 0%),
Durée approximative des boucles en millisecondes :
Minimum = 357ms, Maximum = 357ms, Moyenne = 357ms
C:\Windows\System32>tracert 1.1.1.1
Détermination de l’itinéraire vers one.one.one.one [1.1.1.1]
avec un maximum de 30 sauts :
1 <1 ms <1 ms <1 ms 10.0.0.1
2 * 5 ms 4 ms 194.149.169.57
3 5 ms 4 ms 5 ms 194.149.166.21
4 11 ms 11 ms 11 ms londres-asr9k-1-te-0-0-6.intf.routers.proxad.net [194.149.163.225]
5 84 ms 83 ms 83 ms newyork-6k-1-po1.intf.routers.proxad.net [212.27.58.206]
6 153 ms 153 ms 153 ms paloalto-6k-1-po1.intf.routers.proxad.net [212.27.58.222]
7 154 ms 153 ms 153 ms g5-0-0.plapx-dr1.ix.singtel.com [198.32.176.50]
8 153 ms 153 ms 153 ms 203.208.172.233
9 346 ms 322 ms 321 ms 203.208.158.177
10 327 ms 328 ms 327 ms 203.208.183.134
11 328 ms 327 ms 328 ms 203.208.182.250
12 329 ms 329 ms 329 ms 203.208.158.190
13 329 ms 329 ms 329 ms 203.208.174.246
14 358 ms 359 ms 358 ms TH-ICR-MTT1-241-209.trueintergateway.com [113.21.241.209]
15 356 ms 355 ms 356 ms TIG-Net247-165.trueintergateway.com [113.21.247.165]
16 355 ms 356 ms 356 ms TIG-Net245-111.trueintergateway.com [113.21.245.111]
17 357 ms 356 ms 356 ms one.one.one.one [1.1.1.1]
Itinéraire déterminé.
Pas de soucis pour joindre la version IPv6 par contre :
C:\Windows\System32>ping 2606:4700:4700::1111
Envoi d’une requête 'Ping' 2606:4700:4700::1111 avec 32 octets de données :
Réponse de 2606:4700:4700::1111 : temps=7 ms
Réponse de 2606:4700:4700::1111 : temps=6 ms
Réponse de 2606:4700:4700::1111 : temps=5 ms
Réponse de 2606:4700:4700::1111 : temps=6 ms
Statistiques Ping pour 2606:4700:4700::1111:
Paquets : envoyés = 4, reçus = 4, perdus = 0 (perte 0%),
Durée approximative des boucles en millisecondes :
Minimum = 5ms, Maximum = 7ms, Moyenne = 6ms
C:\Windows\System32>tracert 2606:4700:4700::1111
Détermination de l’itinéraire vers one.one.one.one [2606:4700:4700::1111]
avec un maximum de 30 sauts :
1 <1 ms <1 ms <1 ms 2a01:e0a:xxxx:xxxx::1
2 <1 ms <1 ms <1 ms 2a01:e0a:xxxx:xxxx::1
3 3 ms 2 ms 2 ms 2a01:e03:9:f836:c85d::ffff
4 * * * Délai d’attente de la demande dépassé.
5 * * * Délai d’attente de la demande dépassé.
6 * * * Délai d’attente de la demande dépassé.
7 * * * Délai d’attente de la demande dépassé.
8 * * * Délai d’attente de la demande dépassé.
9 * * 6 ms be3594.rcr21.b019498-0.par01.atlas.cogentco.com [2001:550:0:1000::9a36:3c7e]
10 * 20 ms * 2001:978:2:3d::18:2
11 5 ms 6 ms 6 ms one.one.one.one [2606:4700:4700::1111]
Itinéraire déterminé.
-
Du coup ça fait doublon avec ici ;D : https://lafibre.info/peering/le-peering-free-en-2020/msg809264/#msg809264
On va finir par être obligés d'utiliser celui de Google. :(
-
En effet ;D Je ne vais plus poster dans celui-ci du coup ;)
Pour les DNS, je suis déjà sur ceux de Google, et en IPv6 qui plus est. Donc avant de voir ce topic, je n'avais pas vu qu'il y avait un problème ;D
-
Euh, il me semble pas que ce que tu dises là ait un sens... M'enfin je crois que je n'ai toujours pas vraiment compris quel est le problème à la base.
En tout cas, le reverse DNS c'est la traduction en un nom de domaine de ton adresse IP et ça importe généralement assez peu.
Par exemple avec mon IP :
nslookup 82.64.XXX.XXX
XXX.XXX.64.82.in-addr.arpa name = 82-64-XXX-XXX.subs.proxad.net.
Le reverse DNS ne fonctionne plus chez FREE. De nombreux post en parles notamment sur le dev.
Je trouve ça très étonnant de la part de free de laisser la fonction active, de pouvoir l'activer et de ne pas rendre le service.
-
Le reverse DNS ne fonctionne plus chez FREE. De nombreux post en parles notamment sur le dev.
Je trouve ça très étonnant de la part de free de laisser la fonction active, de pouvoir l'activer et de ne pas rendre le service.
La "pression" des autorités régulatrices pour le passage en IPV6 semble "très bien supportée" par Free... Et petit à petit par les autres opérateurs...
Sur le fond, il semble clair que si l'on veut quelque peu "forcer" le passage en IPV6, il va falloir rendre l'utilisation de l'IPV4 de plus en plus compliquée...
Si la pression sur les détenteurs de sites qui ne font que de l'IPV4 n'est pas suffisante pour qu'il "franchissent le rubicon", petit à petit c'est la pression des utilisateurs qui finira par faire pencher la balance, dans le genre "J'ai de plus en plus de difficultés à accéder à votre site", où lorsque les administrateurs des sites en question se rendront compte que les stats de leurs sites se cassent la figure...
A terme, je ne pense pas trop me fourvoyer...
-
Pour ca je pense que google peut avoir un rôle a jouer par rapport au referencement.
Un peu comme la democratisation des sites en https pour de banals sites webs
-
Pour ca je pense que google peut avoir un rôle a jouer par rapport au referencement.
Un peu comme la democratisation des sites en https pour de banals sites webs
Je n'y crois pas trop...
Par contre, si un niveau de plus en plus important "d'incidents" qui ne concerneraient que l'IPV4 se faisait jour...
Je sais, ce sont des méthodes d'enfoiros! Mais vu ce que donne la "bonne volonté" au niveau des masses, faute de grives... ;) ;) ;)