La Fibre
Fournisseurs d'accès à Internet fixe en France métropolitaine => Orange / Sosh => 
Actus Orange => Discussion démarrée par: fair le 01 avril 2018 à 16:43:12
-
Cloudflare a aujourd'hui officialisé le lancement de son service DNS, via les adresses IPv4 1.1.1.1 et 1.0.0.1.
Cependant il m'est impossible d'accéder à cette adresse IP (1.1.1.1) depuis mon routeur orange.
En effet quand je ping cette IP j'ai une réponse sous 0.4ms, de plus traceroute ne me décris pas de sortie via la gateway. Je pense donc que le router répond à cette adresse.
D'ailleurs quand je tente d'accéder à cette IP sur le port 443, le certificat décrit le nom de domaine suivant:
Livebox4-xxxxxxxxxxxx-xxxxxxxxxxxxxxx.livebox.dns-orange.fr (avec des nombres en hexadécimal à la place des 'x')
Je suis donc confus, mon routeur utiliserait-t-il une adresse IPv4 usurpée, contrairement à ce que préconise la RFC 1918 ?
-
Bonjour,
Comme vous avez peu le voir, Cloudflare a désormais un service de résolveur DNS. (https://blog.cloudflare.com/dns-resolver-1-1-1-1/ (https://blog.cloudflare.com/dns-resolver-1-1-1-1/)).
Bref, je me suis dis que cela pourrait être interessant d'essayer, car ils sont soit disant performant et respectueux de la vie privée.
Je me suis donc rendu sur leur site http://1.1.1.1 (http://1.1.1.1) et la, j'ai une erreur de chrome me disant: "ERR_EMPTY_RESPONSE" comme lorsque je tente d’accéder ma livebox via mon ip public.
Je me pose donc la question, puis je tente d'y acceder via https, et la j'ai une erreur de certificat, donc je me suis dis: Hum etrange.
Et la, quand je regarde qui a émis ce certificat:
(https://amaury-db.fr/51561.PNG)
Intrigué, j'ai donc fait un traceroute et la, le traceroute semble s’arrêter vraiment trop tot.
Traceroute vers 1.1.1.1:
|------------------------------------------------------------------------------------------|
| WinMTR statistics |
| Host - % | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
| 192.168.1.1 - 0 | 2 | 2 | 0 | 0 | 0 | 0 |
| 192.168.3.1 - 0 | 2 | 2 | 1 | 1 | 1 | 1 |
| 1.1.1.1 - 0 | 2 | 2 | 1 | 1 | 2 | 1 |
|________________________________________________|______|______|______|______|______|______|
WinMTR v0.92 GPL V2 by Appnor MSP - Fully Managed Hosting & Cloud Provider
Traceroute vers 8.8.8.8
|------------------------------------------------------------------------------------------|
| WinMTR statistics |
| Host - % | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
| 192.168.1.1 - 0 | 2 | 2 | 0 | 1 | 2 | 2 |
| 192.168.3.1 - 0 | 2 | 2 | 1 | 1 | 2 | 2 |
| 192.168.2.1 - 0 | 2 | 2 | 1 | 1 | 2 | 1 |
| 80.10.232.221 - 0 | 2 | 2 | 8 | 9 | 10 | 8 |
| 193.253.85.38 - 0 | 2 | 2 | 7 | 7 | 8 | 8 |
| 193.252.101.130 - 0 | 2 | 2 | 9 | 10 | 11 | 9 |
| 81.253.184.86 - 0 | 2 | 2 | 13 | 13 | 14 | 13 |
| 193.251.131.34 - 0 | 2 | 2 | 13 | 13 | 14 | 13 |
| 193.251.255.170 - 0 | 2 | 2 | 12 | 12 | 13 | 12 |
| 108.170.252.227 - 0 | 2 | 2 | 13 | 13 | 14 | 13 |
| 216.239.35.207 - 0 | 2 | 2 | 19 | 19 | 20 | 19 |
| 216.239.51.110 - 0 | 2 | 2 | 24 | 24 | 24 | 24 |
| 108.170.236.27 - 0 | 2 | 2 | 24 | 24 | 24 | 24 |
| 216.239.56.189 - 0 | 2 | 2 | 25 | 26 | 27 | 25 |
| No response from host - 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| 8.8.8.8 - 0 | 2 | 2 | 24 | 24 | 25 | 24 |
|________________________________________________|______|______|______|______|______|______|
WinMTR v0.92 GPL V2 by Appnor MSP - Fully Managed Hosting & Cloud Provider
Je me demande donc, si c'est un problème de configuration du coté d'orange, du miens (mais j'en doute) ou si c'est une violation de la neutralité du net.
-
Réponse de Ólafur Guðmundsson (CloudFlare) sur le blogpost de l'annonce :
> Due to various reasons 1.1.1.1 does not work for fraction of the internet; We are working in fixing that. The issues involved include; Network filters; various devices that use 1.1.1.1 internally; etc. Stay tuned for followup blogs and for now use 1.0.0.1 or our IPv6 addresses 2606:4700:4700::1111, 2606:4700:4007::1001
-
Pas de problème pour moi en fibre Orange
-
Bonjour,
J'ai la même chose :
(http://pix.toile-libre.org/upload/original/1522600513.png)
Et je suis également en VDSL Orange.
-
Ca vient de la Livebox 4, quel que soit le réseau. Les modèles plus anciens n'ont pas le problème.
Compte tenu de la cause, je ne serais pas surpris que certains routeurs wifi (Asus RT-AC87U par exemple) présentent le même bug.
-
J'ai le même problème via une Livebox 4, en revanche ça fonctionne avec une Livebox 3. ???
-
Le DNS en 1.1.1.1 ont été annoncés le 1er avril, je pensais que c'était un poisson...
Je vois que non...
Traceroute IPv4 depuis mon mobile SFR 4G (je suis dans le TER, ne pas tenir compte de la latence) :
$ mtr -zrwc100 1.1.1.1
Start: Mon Apr 2 19:48:26 2018
HOST: vivien Loss% Snt Last Avg Best Wrst StDev
1. AS??? ? ? 100.0 100
2. AS??? ? ? 100.0 100
3. AS??? 10.4.1.12 1.0% 100 33.8 59.4 29.8 490.1 59.7
AS??? 10.4.2.12
AS??? 10.4.0.12
4. AS??? 172.19.160.252 1.0% 100 39.8 54.5 30.3 389.9 54.9
5. AS15557 181.231.154.77.rev.sfr.net 1.0% 100 39.4 53.2 29.0 289.6 38.6
6. AS15557 210.69.26.109.rev.sfr.net 0.0% 100 32.4 51.8 31.3 351.0 40.0
7. AS15557 237.122.3.109.rev.sfr.net 0.0% 100 36.6 54.0 32.4 287.9 36.7
8. AS15557 242.122.3.109.rev.sfr.net 0.0% 100 35.3 53.4 33.1 193.6 30.5
9. AS15557 77.10.136.77.rev.sfr.net 0.0% 100 64.5 49.0 30.9 141.9 19.9
10. AS4565 1dot1dot1dot1.cloudflare-dns.com 0.0% 100 30.1 54.0 30.1 329.7 42.8
Traceroute IPv4 depuis Adeli puis Cogent, c'est un serveur sur Marseille qui répond :
$ mtr -bzrwc100 1.1.1.1
Start: Mon Apr 2 19:57:20 2018
HOST: lafibre Loss% Snt Last Avg Best Wrst StDev
1. AS43142 portevlan.adeli.biz (46.227.16.1) 0.0% 100 0.2 2.3 0.2 83.6 10.8
2. AS174 gi0-0-0-16.219.agr12.lys01.atlas.cogentco.com (149.6.118.241) 0.0% 100 8.2 8.3 8.1 10.5 0.2
3. AS174 te0-0-1-6.rcr21.lys01.atlas.cogentco.com (130.117.2.33) 0.0% 100 8.1 8.1 7.9 10.1 0.2
4. AS174 be2473.ccr21.mrs01.atlas.cogentco.com (130.117.50.57) 0.0% 100 12.5 12.6 12.3 14.2 0.3
5. AS174 149.6.154.130 0.0% 100 11.7 11.9 11.6 15.5 0.4
6. AS4565 1dot1dot1dot1.cloudflare-dns.com (1.1.1.1) 0.0% 100 11.2 11.2 11.1 11.4 0.0
Traceroute IPv6 depuis Adeli, c'est un serveur sur Paris qui répond :
$ mtr -zrwc100 2606:4700:4700::1111
Start: Mon Apr 2 20:03:19 2018
HOST: lafibre Loss% Snt Last Avg Best Wrst StDev
1. AS43142 bgp1.adeli.biz 0.0% 100 0.3 0.6 0.2 6.8 1.0
2. AS43142 bgpcontroles17.maxnod.com 0.0% 100 0.2 0.1 0.1 0.2 0.0
3. AS??? equinix-paris.cloudflare.com 0.0% 100 6.1 13.0 5.9 226.5 34.1
4. AS13335 1dot1dot1dot1.cloudflare-dns.com 0.0% 100 5.9 5.9 5.8 6.0 0.0
Tracroute IPv4 depuis Bouyues Telecom, c'est un serveur sur Paris qui répond :
$ mtr -bzrwc100 1.1.1.1
Start: Mon Apr 2 19:58:16 2018
HOST: Loss% Snt Last Avg Best Wrst StDev
1. AS5410 194.158.119.185 0.0% 100 0.5 5.9 0.3 374.7 41.1
2. AS5410 be11.cbr01-ntr.net.bbox.fr (212.194.171.4) 0.0% 100 1.8 2.6 1.5 3.7 0.3
3. AS5410 la13.rpt02-ix2.net.bbox.fr (212.194.171.90) 80.0% 100 1.1 1.1 1.1 1.3 0.0
4. AS??? cloudflare.par.franceix.net (37.49.237.49) 0.0% 100 1.3 1.6 1.3 17.6 2.0
5. AS4565 1dot1dot1dot1.cloudflare-dns.com (1.1.1.1) 0.0% 100 1.2 1.2 1.2 1.9 0.0
Tracroute IPv6 depuis Bouyues Telecom, c'est un serveur sur Paris qui répond :
$ mtr -zrwc100 2606:4700:4700::1111
Start: Mon Apr 2 20:03:25 2018
HOST: Loss% Snt Last Avg Best Wrst StDev
1. AS5410 2001:860:f70a::1 0.0% 100 0.4 1.6 0.4 22.1 4.3
2. AS5410 2001:860:bbee:4e::1 0.0% 100 1.3 1.3 1.2 1.5 0.0
3. AS??? cloudflare.par.franceix.net 0.0% 100 1.4 1.4 1.3 2.6 0.1
4. AS13335 1dot1dot1dot1.cloudflare-dns.com 0.0% 100 1.4 1.4 1.3 2.3 0.0
-
pas de souci avec https://1.1.1.1/fr/
-
Salut,
D'après un commentaire de l'article payant de nextinpact, il y aurait le même problème avec une Box de SFR câble:
Etre_Libre - Le mardi 3 avril 2018 à 09:22:08 #2
Bonjour,
J'ai des résulats un peu bizarres :
1.1.1.1 OK depuis connexion OVH, mais KO depuis connexion SFR Câble.
1.0.0.1 OK (Cloudflare aussi) en DNS depuis SFR Câble.
Même leur sitehttps://1.1.1.1 HS sur SFR Câble, mais OK sur OVH.
Et vous ?
Source: un commentaire de https://www.nextinpact.com/news/106399-1-1-1-1-cloudflare-annonce-son-resolveur-dns-rapide-securise-et-respectueux-vie-privee.htm#/page/1
-
je confirme, pas de soucis avec une Livebox 3.
-
Passage par un transitaire entre Orange et Cloudflare ?
-
Passage par un transitaire entre Orange et Cloudflare ?
Oui, OpenTransit au moins depuis Orange France, et ensuite je ne crois pas qu'OpenTransit peer avec Cloudflare. Un mtr depuis chez moi, Orange sans livebox montre NTT dans le path :
$ mtr -ezrwc1 1.1.1.1
HOST: omega.synhacx.eu.org Loss% Snt Last Avg Best Wrst StDev
1. AS??? 80.10.237.121 0.0% 1 16.0 16.0 16.0 16.0 0.0
2. AS??? lag-112.ncren201.Rennes.francetelecom.net 0.0% 1 15.9 15.9 15.9 15.9 0.0
3. AS??? ae43-0.niidf301.Paris15eArrondissement.francetelecom.net 0.0% 1 20.7 20.7 20.7 20.7 0.0
4. AS??? ae40-0.niidf302.Paris13eArrondissement.francetelecom.net 0.0% 1 21.0 21.0 21.0 21.0 0.0
5. AS??? 193.252.137.78 0.0% 1 26.5 26.5 26.5 26.5 0.0
6. AS??? et-18-1-0-0.pastr3.paris03.opentransit.net 0.0% 1 21.0 21.0 21.0 21.0 0.0
7. AS2914 ae-26.r04.parsfr01.fr.bb.gin.ntt.net 0.0% 1 21.8 21.8 21.8 21.8 0.0
8. AS2914 ae-5.r03.parsfr02.fr.bb.gin.ntt.net 0.0% 1 21.8 21.8 21.8 21.8 0.0
9. AS2914 185.84.18.74 0.0% 1 32.2 32.2 32.2 32.2 0.0
10. AS4565 1dot1dot1dot1.cloudflare-dns.com 0.0% 1 31.3 31.3 31.3 31.3 0.0
-
Bon, il semble qu'un webconseiller d'Orange est fait remonter ce problème des Livebox 4:
Webconseiller FabienJ
Webconseiller
Bonjour,
Notre service expertise analyse la situation concernant le comportement de la Livebox.
Nous reviendrons vers vous afin de vous communiquer plus d'informations à ce sujet.
Bonne journée à vous.
Fabien
Exactement ce même message dans plusieurs sujets, dont:
- https://communaute.orange.fr/t5/ma-connexion/Resolveur-DNS-Cloudflare-1-1-1-1-inaccessible/td-p/1538142
- https://communaute.orange.fr/t5/ma-connexion/Routage-d-adresses-publiques-IPv4-erron%C3%A9/td-p/1537841
Affaire à suivre...
-
On m'a fait suivre ceci sur twitter : https://twitter.com/yangrunenberger/status/980483238891278339 :
Oh! J’ai une explication. Si le chip wifi 5Ghz est quantenna c’est du au bridge interne qui utilise 1.1.1.1/1.1.1.2 comme méthode de communication.
Je n'ai pas plus d'infos que vous, mais ça semble intéressant comme piste.
-
On m'a fait suivre ceci sur twitter : https://twitter.com/yangrunenberger/status/980483238891278339 :
Je n'ai pas plus d'infos que vous, mais ça semble intéressant comme piste.
C'est plus qu'une piste, c'est la cause (c'est pour ça que j'ai parlé du Asus RT-AC87U).
Le décodeur 4 est exactement dans le même cas, mais il n'a pas besoin d'accéder à 1.1.1.1 (puisque les DNS de la Livebox ne peuvent pas être changés par le client).
Le problème est qu'il n'y a pas d'adresses réservées pour ce genre d'usage, toutes les adresses privées (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) sont susceptibles d'être utilisées par le client sur son LAN.
-
Le problème est qu'il n'y a pas d'adresses réservées pour ce genre d'usage, toutes les adresses privées (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) sont susceptibles d'être utilisées par le client sur son LAN.
Certes, après ce qu'il faudrait c'est customiser ces modules + le routeur pour utiliser un bloc au choix du client. Dans le cas d'Orange il aurait été facile de réserver un /30 dans un pool public qui aurait été utilisé sur chaque livebox.
La question c'est plutôt de savoir s'il est seulement possible de modifier la conf IP du module radio...
-
La question c'est plutôt de savoir s'il est seulement possible de modifier la conf IP du module radio...
Peut-être que c'est possible dans son bootloader, mais à moins d'une mise à jour en deux temps ça me semble difficile à implèmenter.
La solution sera probablement d'avoir des règles iptables pour que les paquets routés par la Livebox (LAN<=>WAN) soient traités différemment que ceux qui sont émis en interne.
-
Peut-être que c'est possible dans son bootloader, mais à moins d'une mise à jour en deux temps ça me semble difficile à implèmenter.
La solution sera probablement d'avoir des règles iptables pour que les paquets routés par la Livebox (LAN<=>WAN) soient traités différemment que ceux qui sont émis en interne.
Ou sinon utiliser une vrf / un network namespace pour isoler tout cela dans le linux de la box... ?
-
Oh! J’ai une explication. Si le chip wifi 5Ghz est quantenna c’est du au bridge interne qui utilise 1.1.1.1/1.1.1.2 comme méthode de communication.
Sur ma Freebox, ça marche, mais après un redémarrage, je me retrouve au même point qu'ici (https://lafibre.info/bistro-sujet-libre/dns-un-coup-tu-les-vois-un-coup-tu-ne-les-vois-pas/msg533274/#msg533274) ! (https://lafibre.info/images/smileys/@GregLand/bk.gif)
-
Jolie le poisson ;D
-
Jolie le poisson ;D
Quel poisson?
Derrière une livebox 3 le site https://1.1.1.1/ est bien accessible.
Si ce n'est pas ton cas, tu peux le voir sur https://1.0.0.1/
Le DNS est actif à ce jour...
-
Ah oui, j'ai vraiment que c'était un poisson, mais non.
-
c'est du marketing habile, profiter de buzz 'poisson d'avril' pour avoir plus de couverture médiatique.
S'ils avaient lancer ca n'importe quel autre jour on en aurait nettement moins parler.
en plus 1.1.1.1 = 4/1 = 1er avril en date anglaise.
-
Nouvel article de NextINpact : https://www.nextinpact.com/news/106438-orange-repond-sur-detournement-adresse-1-1-1-1-par-livebox-4.htm
Orange travaille à changer les IPv4 1.1.1.1 et 1.1.1.2 par d'autres IP sur sa Livebox v4.
L'article termine en disant "Selon LaFibre.info, le problème affecterait aussi des clients SFR, que nous avons contacté pour en avoir confirmation."
alors que turold citait un commentaire de NextINpact en source du fait que SFR est aussi impacté :
Salut,
D'après un commentaire de l'article payant de nextinpact, il y aurait le même problème avec une Box de SFR câble:
Etre_Libre - Le mardi 3 avril 2018 à 09:22:08 #2
Bonjour,
J'ai des résulats un peu bizarres :
1.1.1.1 OK depuis connexion OVH, mais KO depuis connexion SFR Câble.
1.0.0.1 OK (Cloudflare aussi) en DNS depuis SFR Câble.
Même leur sitehttps://1.1.1.1 HS sur SFR Câble, mais OK sur OVH.
Et vous ?
Source: un commentaire de https://www.nextinpact.com/news/106399-1-1-1-1-cloudflare-annonce-son-resolveur-dns-rapide-securise-et-respectueux-vie-privee.htm#/page/1
-
OUi on tourne en rond !!
-
Je crois qu'on vient de détecter une boucle...
-
A priori soucis plutôt sur le fibrocoax :
https://twitter.com/Sniperovitch/status/980482322138091520
1.1.1.1 pas joignable à partir de ma box SFR :)
(une LaBox over coaxial)
https://twitter.com/Sniperovitch/status/980483438212976641
Je peux dig @1.1.1.1 mais le site est injoignable via la box
-
alors que turold citait un commentaire de NextINpact en source du fait que SFR est aussi impacté :
Oui bien vu, moment de faiblesse de ma part, alors que j'avais bien lu le message. Je reprends un café et corrige ça, merci ! :)
-
Trop bu de chouchen ? 8)
-
Pas assez on dirait !
Je me rends compte que c'est la deuxième erreur que je mets sur le compte du café ici. :p
-
Pour préciser, je n'ai pas de problème pour accéder à https://1.1.1.1 sur ma box câble Red Sagem F@ast3284 DC.
J'en profite pour dire mon entière satisfaction de cette offre à 10€/mois: débit de 100 Mb/s stable, WiFi 5 Ghz de qualité, peering que je n'ai pas pris en défaut.
Il ne manque que l'IPv6 et un peu plus d'upload...
-
Cloudflare vient de poster un article de blog sur le sujet : https://blog.cloudflare.com/fixing-reachability-to-1-1-1-1-globally/
Il y est fait mention du cas d'Orange :
We noticed similar behaviour on a large portion of probes connected to Orange France, we contacted them and received a swift response that the CPE team was investigating the issue. After providing more details they came back to us with a statement.
We have escalated your alert inside ORANGE France.
Our CPE team has analyzed the issue which is now well understood. This problem only impacts a subset of our CPEs. The commitment of the fix is currently on going and a deployment on our CPEs will follow.
In case of complaints notified by our customers in the meantime we have prepared a communication to inform them that we are currently fixing the issue.
The CPE in question is the Livebox, although it's not clear which versions are affected, it should be resolved by Orange across all affected devices. Users in Poland reported the same issues as users in France, likely due to Orange deploying the same models across multiple networks.
-
Je viens de refaire le test suite au message de vivien et j'ai maintenant bien accès au site alors que pas plus qu'hier cela n'était pas le cas.
Je faisais des tests réguliers depuis le 1 avril.
Je suis chez red en coax.
Off-topic
Il y a semble-t-il une promo sur l'option débit plus à 2€/mois disponible aussi pour l'offre à 10€/mois.
-
Des nouvelles concernant la mise à jours? Passage sur Livebox 4 aujourd’hui, 1.1.1.1 toujours HS.
-
Des nouvelles concernant la mise à jours? Passage sur Livebox 4 aujourd’hui, 1.1.1.1 toujours HS.
Ça marche sur Freebox. (https://lafibre.info/images/smileys/@GregLand/ay.gif)
-
Ça marche sur Freebox. (https://lafibre.info/images/smileys/@GregLand/ay.gif)
OSEF. La personne parle de la Livebox et toi tu parles de Free :o
-
J'avais en effet remarqué le problème il y a quelques mois, sans savoir quoi en penser. Comme il y a eu une mise à jour de la Livebox 4 il y a une semaine, j'ai retesté à l'instant, mais le problème est toujours présent.
-
Orange est bien moins rapide que SFR pour patcher...
Les FAI qui bloquent 1.1.1.1 ont été avertis avant le lancement du service et SFR a fait en sorte que les mises à jour soient poussées avant ou juste après la sortie du service 1.1.1.1
-
[...] Comme il y a eu une mise à jour de la Livebox 4 il y a une semaine, j'ai retesté à l'instant, mais le problème est toujours présent.
Sauf erreur de ma part, la dernière mise à jour est la 3.4.10 qui date de début avril... J'ai loupé un truc ?
-
Oui, elle n'a pas encore dû être déployée automatiquement chez toi, j'ai la 3.32.8.
-
OSEF. La personne parle de la Livebox et toi tu parles de Free :o
Toutes mes excuses, mais je pensais qu'il pouvait être intéressant pour la personne ayant ce problème de savoir que cette solution existe toujours. Et heureusement que cette solution existe car, sinon, je n'aurais pas accès à Internet (https://lafibre.info/bistro-sujet-libre/dns-un-coup-tu-les-vois-un-coup-tu-ne-les-vois-pas/msg533274/#msg533274). (https://lafibre.info/images/smileys/Confus/Confus_83.gif)
-
« Orange travaille à changer les IPv4 1.1.1.1 et 1.1.1.2 par d'autres IP sur sa Livebox v4 »
C'était il y a six mois... quelqu'un a des infos ?
-
non pas de news, ils doivent être sur le coup 8)
-
J'avais en effet remarqué le problème il y a quelques mois, sans savoir quoi en penser. Comme il y a eu une mise à jour de la Livebox 4 il y a une semaine, j'ai retesté à l'instant, mais le problème est toujours présent.
Oui, elle n'a pas encore dû être déployée automatiquement chez toi, j'ai la 3.32.8.
La correction devrait être présente dans cette version pourtant.
J'essaye de me renseigner en interne.
-
Des informations ? :-\
-
Hello,
J'ai mis les DNS 1.1.1.1 et 1.0.0.1 et cela fonctionne. Livebox 4 no soucy. Changement de DNS via Win10 et no problemo, par contre le tracert ne fonctionne pas ouais
-
Bonne nouvelle.
Pour rappel cela fonctionne depuis une Livebox v3 :
$ mtr -zrwc100 1.1.1.1
Start: 2018-12-08T16:42:27+0100
HOST: Orange Loss% Snt Last Avg Best Wrst StDev
1. AS??? livebox.home 0.0% 100 0.6 0.5 0.3 0.6 0.0
2. AS??? 80.10.233.189 0.0% 100 2.8 2.1 1.9 2.8 0.1
3. AS??? ae116-0.ncidf303.Aubervilliers.francetelecom.net 0.0% 100 2.6 3.0 2.6 10.8 1.1
4. AS??? ae42-0.niidf301.Paris15eArrondissement.francetelecom.net 0.0% 100 2.9 3.6 2.8 24.9 2.9
5. AS??? ae40-0.niidf302.Paris13eArrondissement.francetelecom.net 0.0% 100 4.9 5.2 2.9 31.4 5.4
6. AS??? 193.252.137.78 0.0% 100 3.5 3.5 3.2 4.7 0.2
7. AS??? et-14-1-0-0.pastr3.paris.opentransit.net 0.0% 100 10.1 6.8 3.2 42.9 6.8
8. AS2914 ae-26.r04.parsfr01.fr.bb.gin.ntt.net 0.0% 100 3.6 3.8 3.2 4.5 0.2
9. AS2914 ae-3.r03.parsfr02.fr.bb.gin.ntt.net 0.0% 100 3.9 3.9 3.7 4.6 0.2
10. AS2914 185.84.18.174 0.0% 100 3.9 4.3 3.7 29.6 2.6
11. AS13335 one.one.one.one 0.0% 100 3.7 3.7 3.6 5.1 0.2
-
Livebox 4 fibre version 3.4.10 (la dernière d'après Orange) et le traceroute vers 1.1.1.1 s'arrête toujours à la Livebox ...
Seul le 1.0.0.1 fonctionne correctement.
-
Livebox 4 fibre version 3.4.10 (la dernière d'après Orange) et le traceroute vers 1.1.1.1 s'arrête toujours à la Livebox ...
Seul le 1.0.0.1 fonctionne correctement.
"dig lafibre.info @1.1.1.1" c'est le meilleur test. Traceroute peut ne pas marcher tout en ayant DNS qui marche.
-
Heuuu, non. Clairement pas.
Sachant que la Livebox contient un serveur DNS, forcèment que ça peut marcher. Mais c'est la Livebox qui répond.
D'ailleurs ça ne marche même pas chez moi.
-
Quand tu mets @1.1.1.1 dans les paramètres de dig, ça ne passe plus par le résolveur DNS de la box hein...
-
Sur LB4 ca ne marche pas.
Seul le 1.0.0.1 fonctionne.
-
Quand tu mets @1.1.1.1 dans les paramètres de dig, ça ne passe plus par le résolveur DNS de la box hein...
Bah si, vu que la Livebox 4 "intercepte" l'IP 1.1.1.1, donc c'est elle qui répond.
Que ce soit dig ou traceroute, le trajet des paquets IP reste le même !
-
Qu'elle intercepte le traffic pour 1.1.1.1 ne veut pas dire qu'elle y répond.
Bon de toute facon, rien n'a changé, comme déjà dit, même avec la dernière version du firmware 3.4.10, le traffic vers 1.1.1.1 est intercepté par la livebox 4.
$ dig lafibre.info @1.0.0.1
; <<>> DiG 9.10.3-P4-Debian <<>> lafibre.info @1.0.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47858
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1452
;; QUESTION SECTION:
;lafibre.info. IN A
;; ANSWER SECTION:
lafibre.info. 900 IN A 46.227.16.8
;; Query time: 50 msec
;; SERVER: 1.0.0.1#53(1.0.0.1)
;; WHEN: Sat Dec 08 19:55:05 CET 2018
;; MSG SIZE rcvd: 57
$ dig lafibre.info @1.1.1.1
; <<>> DiG 9.10.3-P4-Debian <<>> lafibre.info @1.1.1.1
;; global options: +cmd
;; connection timed out; no servers could be reached
-
1.1.1.1 c'est l'IP de la carte Wi-Fi 5Ghz de la livebox v4, donc elle ne va pas répondre au DNS.
Le nouveau firmware doit changer l'IP de la carte Wi-Fi.
-
Mais donc une ip routable était utilisé pour une adresse locale? :o
-
Mais donc une ip routable était utilisé pour une adresse locale? :o
C'est bien ça le problème ;D
-
Mais donc une ip routable était utilisé pour une adresse locale? :o
C'est l'IP par défaut du chipset Quantenna utilisé pour le wifi 5Ghz.
-
Le problème est résolu par le firmware 3.41.12, reçu cette nuit.
C:\>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 lan.home [192.168.1.1]
2 2 ms 6 ms 1 ms 80.10.235.129
3 4 ms 3 ms 3 ms ae118-0.ncidf203.Aubervilliers.francetelecom.net [193.253.81.138]
4 8 ms 3 ms 5 ms ae41-0.niidf201.Aubervilliers.francetelecom.net [193.252.98.161]
5 3 ms 5 ms 3 ms 81.253.184.182
6 3 ms 7 ms 7 ms hundredgige0-12-0-2.auvtr4.aubervilliers.opentransit.net [193.251.242.180]
7 7 ms 2 ms 2 ms et-19-0-6-0.pastr3.paris.opentransit.net [193.251.129.84]
8 3 ms 2 ms 2 ms ae-26.r04.parsfr01.fr.bb.gin.ntt.net [129.250.66.141]
9 5 ms 3 ms 7 ms ae-3.r03.parsfr02.fr.bb.gin.ntt.net [129.250.5.39]
10 7 ms 7 ms 6 ms 185.84.18.174
11 2 ms 2 ms 2 ms one.one.one.one [1.1.1.1]
Itinéraire déterminé.
C:\>nslookup lafibre.info 1.1.1.1
Serveur : one.one.one.one
Address: 1.1.1.1
Réponse ne faisant pas autorité :
Nom : lafibre.info
Addresses: 2a01:6e00:10:410::2
46.227.16.8
Comparaison avec le 1.0.0.1 :
C:\>tracert 1.0.0.1
Détermination de l'itinéraire vers one.one.one.one [1.0.0.1]
avec un maximum de 30 sauts :
1 3 ms 1 ms 2 ms lan.home [192.168.1.1]
2 3 ms 1 ms 11 ms 80.10.235.129
3 4 ms 4 ms 1 ms ae118-0.ncidf203.Aubervilliers.francetelecom.net [193.253.81.138]
4 5 ms 4 ms 4 ms ae41-0.niidf201.Aubervilliers.francetelecom.net[193.252.98.161]
5 2 ms 2 ms 2 ms 81.253.184.182
6 7 ms 7 ms 6 ms hundredgige0-13-0-0.auvtr4.aubervilliers.opentransit.net [193.251.242.194]
7 2 ms 3 ms 7 ms et-18-0-6-0.pastr3.paris.opentransit.net [193.251.128.250]
8 5 ms 2 ms 2 ms ae-26.r04.parsfr01.fr.bb.gin.ntt.net [129.250.66.141]
9 4 ms 2 ms 3 ms ae-3.r03.parsfr02.fr.bb.gin.ntt.net [129.250.5.39]
10 3 ms 3 ms 3 ms 185.84.18.174
11 2 ms 2 ms 3 ms one.one.one.one [1.0.0.1]
Itinéraire déterminé.
C:\>nslookup lafibre.info 1.0.0.1
Serveur : one.one.one.one
Address: 1.0.0.1
Réponse ne faisant pas autorité :
Nom : lafibre.info
Addresses: 2a01:6e00:10:410::2
46.227.16.8
-
Euh... j'ai également le firmware 3.41.12 (LB4 Sercomm), et le problème n'est clairement pas résolu :
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 tomato [192.168.1.1]
2 <1 ms <1 ms <1 ms one.one.one.one [1.1.1.1]
-
Bizarre, ça marche ici.
(j'ai testé avec un PC en wifi sur une LB4 (Sercomm) reliée directement à Orange sans passer par mon routeur.)
https://1.1.1.1 répond bien maintenant, contrairement à avant la maj du firmware :
-
https://1.1.1.1 répond aussi ici (je ne me souviens plus ce que ça donnait avant la maj), mais le tracert s'arrête toujours à la box... étrange ???
EDIT : je viens de tester en wifi directement depuis la LB4 (wifi que je n'utilise normalement pas, préférant celui de mon routeur), donc a priori dans les mêmes conditions que toi : pas mieux, le traceroute s'arrête net, alors que 1.0.0.1 répond normalement.
Si d'autres ayant reçu le firmware 3.41.12 peuvent confirmer/infirmer...
-
Livebox 4 version 3.4.12
$ dig orange.fr @1.1.1.1
; <<>> DiG 9.10.3-P4-Debian <<>> orange.fr @1.1.1.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50583
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1452
;; QUESTION SECTION:
;orange.fr. IN A
;; ANSWER SECTION:
orange.fr. 978 IN A 193.252.133.34
orange.fr. 978 IN A 193.252.148.140
;; Query time: 29 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Mon Jan 14 14:20:24 CET 2019
;; MSG SIZE rcvd: 70
mais...
$ mtr -c 10 --report 9.9.9.9
Start: Mon Jan 14 14:15:14 2019
HOST: doctor Loss% Snt Last Avg Best Wrst StDev
1.|-- lan.home 0.0% 10 0.4 0.5 0.4 0.6 0.0
2.|-- 80.10.235.249 0.0% 10 9.9 10.4 9.9 10.9 0.0
3.|-- ae117-0.ncnic102.Nice.fra 0.0% 10 10.5 10.5 9.9 11.4 0.3
4.|-- ae43-0.nimar102.Marseille 0.0% 10 14.1 13.7 13.1 14.3 0.0
5.|-- 193.252.137.54 0.0% 10 29.9 23.6 22.3 29.9 2.3
6.|-- et-18-1-8-0.pastr3.paris. 0.0% 10 24.2 23.2 21.7 27.3 1.5
7.|-- ae-26.r04.parsfr01.fr.bb. 0.0% 10 23.5 23.4 22.4 27.0 1.2
8.|-- 81.25.197.162 0.0% 10 24.5 25.8 22.9 31.0 2.4
9.|-- dns.quad9.net 0.0% 10 22.7 22.5 21.9 22.8 0.0
$ mtr -c 10 --report 1.1.1.1
Start: Mon Jan 14 14:15:38 2019
HOST: doctor Loss% Snt Last Avg Best Wrst StDev
1.|-- one.one.one.one 0.0% 10 0.5 0.5 0.5 0.7 0.0
C'est comme le firewall de la livebox: chez Orange IP se limite a TCP/UDP...
-
Idem ici, le traceroute s'arrête à la box mais https://1.1.1.1 fonctionne. Orange ne laisserait passer vers l'extérieur que le https/dns sur 1.1.1.1 et pas les pings?
-
Quand bien même ce serait le cas, pourquoi @Catalyst parvient-il à faire un traceroute ?
-
Effectivement après maj, cela fonctionne
moon@Freeze:[~] > host lafibre.info 1.1.1.1
Using domain server:
Name: 1.1.1.1
Address: 1.1.1.1#53
Aliases:
lafibre.info has address 46.227.16.8
lafibre.info has IPv6 address 2a01:6e00:10:410::2
lafibre.info mail is handled by 100 mxb.ovh.net.
lafibre.info mail is handled by 1 mx1.ovh.net.
lafibre.info mail is handled by 5 mx2.ovh.net.
moon@Freeze:[~] > host google.fr 1.1.1.1
Using domain server:
Name: 1.1.1.1
Address: 1.1.1.1#53
Aliases:
google.fr has address 216.58.201.195
google.fr has IPv6 address 2a00:1450:4006:808::2003
google.fr mail is handled by 50 alt4.aspmx.l.google.com.
google.fr mail is handled by 10 aspmx.l.google.com.
google.fr mail is handled by 20 alt1.aspmx.l.google.com.
google.fr mail is handled by 30 alt2.aspmx.l.google.com.
google.fr mail is handled by 40 alt3.aspmx.l.google.com.
Ça ping assez haut mais seulement en wifi (~20 ms) et très bas ~0.80 ms en filaire.
Bon après moi j'm'en sers pas donc m'en fiche :)
-
Quand bien même ce serait le cas, pourquoi @Catalyst parvient-il à faire un traceroute ?
J'ai depuis dumpé le trafic côté WAN et constaté que :
* nslookup lafibre.info 1.1.1.1 marche à tous les coups et sort bien de la LB4 jusqu'à Cloudfare
* telnet 1.1.1.1 80 (ou https://1.1.1.1) pareil, va systématiquement jusqu'à Cloudfare
* tracert 1.1.1.1 et là, je ne reproduis pas, il s'arrête à la LB. Heureusement que j'ai copié le screen du 1er tracert car ???
-
Bonjour tlm,
Pour info, ça ne fonctionnait pas chez moi et après avoir lu le topic, j'ai lancé la mise à jour sur lb4 et depuis le site répond bien en 1.1.1.1. Donc la mise à jour règle bien le soucis.
@+
-
Sur la Livebox 4, l'avant-dernier firmware (3.41.12) amenait la correction du problème de connexion à 1.1.1.1 pour TCP et UDP ... mais pas pour ICMP, qui marchait de façon aléatoire.
Pour info, le dernier firmware (3.44.16) a corrigé ce dernier problème.
Edit : chez moi en tout cas (à Paris) mais ce n'est visiblement pas le cas partout. 13 mois depuis que le problème a été remonté ...
-
Sur la Livebox 4, l'avant-dernier firmware (3.41.12) amenait la correction du problème de connexion à 1.1.1.1 pour TCP et UDP ... mais pas pour ICMP, qui marchait de façon aléatoire.
Pour info, le dernier firmware (3.44.16) a corrigé ce dernier problème.
euh...
$ ./sysbus/sysbus.py
SoftwareVersion : SG40_sip-fr-3.44.16.1_7.21.3.1
UpTime : 9 days, 2:58:15 (NumberOfReboots: 2)
$ ping 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
64 bytes from 1.1.1.1: icmp_seq=1 ttl=64 time=0.497 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=64 time=0.437 ms
64 bytes from 1.1.1.1: icmp_seq=3 ttl=64 time=0.459 ms
$ ping 1.0.0.1
PING 1.0.0.1 (1.0.0.1) 56(84) bytes of data.
64 bytes from 1.0.0.1: icmp_seq=1 ttl=55 time=147 ms
64 bytes from 1.0.0.1: icmp_seq=2 ttl=55 time=37.9 ms
64 bytes from 1.0.0.1: icmp_seq=3 ttl=55 time=53.0 ms
tcp/udp c'est (toujours) bon:
$ dig lafibre.info @1.1.1.1
; <<>> DiG 9.10.3-P4-Debian <<>> lafibre.info @1.1.1.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34773
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1452
;; QUESTION SECTION:
;lafibre.info. IN A
;; ANSWER SECTION:
lafibre.info. 479 IN A 46.227.16.8
;; Query time: 36 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Fri Apr 12 19:47:39 CEST 2019
;; MSG SIZE rcvd: 57
-
Et pourtant, j'atteins maintenant 1.1.1.1 systématiquement.
Alors qu'avec la version précédente de firmware c'était aléatoire et tapait la plupart du temps sur la LB.
C:\>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 2 ms 2 ms <mon routeur>
2 * * * Délai d'attente de la demande dépassé.
3 4 ms 2 ms 4 ms 80.10.235.129
4 4 ms 5 ms 2 ms ae118-0.ncidf203.Aubervilliers.francetelecom.net[193.253.81.138]
5 23 ms 10 ms 4 ms ae41-0.niidf201.Aubervilliers.francetelecom.net[193.252.98.161]
6 11 ms 2 ms 7 ms 81.253.184.182
7 5 ms 7 ms 7 ms hundredgige0-13-0-2.auvtr4.aubervilliers.opentransit.net [193.251.242.198]
8 5 ms 9 ms 3 ms et-16-0-2-0.pastr3.paris.opentransit.net [193.251.131.250]
9 * * * Délai d'attente de la demande dépassé.
10 * 6 ms 3 ms ae-1-3103.ear3.Paris1.Level3.net [4.69.161.66]
11 12 ms 4 ms 4 ms 212.73.205.22
12 5 ms 3 ms 4 ms one.one.one.one [1.1.1.1]
Itinéraire déterminé.
-
Perso ça semble ne (toujours) pas marcher depuis Windows ;
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 <mon routeur> [192.168.1.1]
2 <1 ms <1 ms <1 ms one.one.one.one [1.1.1.1]
Itinéraire déterminé.
... mais en testant depuis le routeur :
traceroute to 1.1.1.1 (1.1.1.1), 30 hops max, 38 byte packets
1 * * *
2 80.10.238.37 (80.10.238.37) 1.745 ms 1.571 ms 1.325 ms
3 ae112-0.ncidf103.puteaux.francetelecom.net (193.253.80.214) 1.851 ms 1.794 ms 1.701 ms
4 ae41-0.niidf101.paris3earrondissement.francetelecom.net (193.252.159.42) 2.041 ms 1.963 ms 2.037 ms
5 193.252.137.10 (193.252.137.10) 3.131 ms 6.307 ms 6.586 ms
6 ae-35.ear2.paris1.level3.net (4.68.127.233) 2.797 ms 2.721 ms 3.112 ms
7 * * *
8 212.73.205.22 (212.73.205.22) 3.991 ms 3.521 ms 4.087 ms
9 one.one.one.one (1.1.1.1) 2.670 ms 2.647 ms 2.663 ms
-
Une histoire de fou :-)
Et un traceroute avec -I donne un résultat identique ?
-
Sous Linux traceroute est en UDP par défaut, alors que tracert sous Windows c'est de l'ICMP.
-
C:\Users\Chistophe\Desktop>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 192.168.0.1
2 * * * Délai d’attente de la demande dépassé.
3 21 ms 30 ms 20 ms 80.10.127.85
4 20 ms 21 ms 21 ms 10.123.193.202
5 43 ms 26 ms 26 ms ae43-0.niidf302.paris13earrondissement.francetelecom.net [193.252.159.161]
6 26 ms 26 ms 26 ms 193.252.137.78
7 29 ms 29 ms 54 ms hundredgige0-11-0-3.auvtr4.aubervilliers.opentransit.net [193.251.242.168]
8 35 ms 26 ms 27 ms et-5-0-3-0.pastr3.paris.opentransit.net [193.251.128.184]
9 * * 27 ms ae-35.ear2.paris1.level3.net [4.68.127.233]
10 27 ms 27 ms 41 ms ae-2-3203.ear3.Paris1.Level3.net [4.69.161.126]
11 28 ms 37 ms 28 ms 212.73.205.22
12 30 ms 27 ms 26 ms one.one.one.one [1.1.1.1]
Ça passe. :)
-
Ca fonctionne chez moi avec une LB4 suite à la mise à jour en version 3.44.16, alors que ça ne fonctionnait pas avant. Traceroute, ping, requêtes DNS, tout marche. D'autres peuvent confirmer ?
-
Je ne sais pas ce que ça faisait avant mais en 3.44.16 ça fonctionne aussi chez moi:
:~$ traceroute 1.1.1.1
traceroute to 1.1.1.1 (1.1.1.1), 30 hops max, 60 byte packets
1 * * *
2 80.10.236.117 (80.10.236.117) 2.269 ms 2.275 ms 2.494 ms
3 ae109-0.ncidf104.Paris15eArrondissement.francetelecom.net (193.253.80.246) 2.888 ms 2.887 ms 2.892 ms
4 ae41-0.niidf102.Aubervilliers.francetelecom.net (193.252.159.46) 6.862 ms 6.877 ms 6.900 ms
5 ae40-0.niidf101.Paris3eArrondissement.francetelecom.net (81.253.129.137) 2.984 ms 2.893 ms 2.956 ms
6 193.252.137.10 (193.252.137.10) 2.984 ms 1.953 ms 2.119 ms
7 * * *
8 * * *
9 212.73.205.22 (212.73.205.22) 9.636 ms 9.807 ms 8.773 ms
10 one.one.one.one (1.1.1.1) 2.041 ms 2.819 ms 2.460 ms
-
Je ne sais pas ce que ça faisait avant mais en 3.44.16 ça fonctionne aussi chez moi:
:~$ traceroute 1.1.1.1
traceroute to 1.1.1.1 (1.1.1.1), 30 hops max, 60 byte packets
1 * * *
2 80.10.236.117 (80.10.236.117) 2.269 ms 2.275 ms 2.494 ms
3 ae109-0.ncidf104.Paris15eArrondissement.francetelecom.net (193.253.80.246) 2.888 ms 2.887 ms 2.892 ms
[...]
linux -> traceroute en udp par defaut, l'udp et tcp vers 1.1.1.1 passent correctement depuis la version 3.41.12.
C'est l'ICMP qui ne passe toujours pas.
Si tu testes en ICMP:
$ sudo traceroute -I 1.1.1.1
traceroute to 1.1.1.1 (1.1.1.1), 30 hops max, 60 byte packets
1 one.one.one.one (1.1.1.1) 0.428 ms 0.491 ms 0.598 ms
Si tu testes sous windows, comme montré au dessus, tracert fait de l'ICMP et ça ne passe pas.
Donc rien de nouveau ;)
-
Comme je l'ai mentionné plus haut, même en ICMP cela fonctionne chez moi :
▶ sudo traceroute -I 1.1.1.1
traceroute to 1.1.1.1 (1.1.1.1), 30 hops max, 60 byte packets
1 * * *
2 80.10.238.37 (80.10.238.37) -1026.653 ms -1008.472 ms -1001.288 ms
3 ae112-0.ncidf103.puteaux.francetelecom.net (193.253.80.214) 14.981 ms 14.980 ms -1026.678 ms
4 ae41-0.niidf101.paris3earrondissement.francetelecom.net (193.252.159.42) -1026.681 ms -1026.685 ms -1024.696 ms
5 193.252.137.10 (193.252.137.10) -1024.697 ms -1022.730 ms -1022.731 ms
6 * * *
7 * * *
8 212.73.205.22 (212.73.205.22) 16.085 ms 14.142 ms 14.112 ms
9 one.one.one.one (1.1.1.1) 12.119 ms 14.093 ms 12.456 ms
-
Chez moi, depuis le routeur, en UDP par défaut :
# traceroute 1.1.1.1
traceroute to 1.1.1.1 (1.1.1.1), 30 hops max, 38 byte packets
1 * * *
2 80.10.238.37 (80.10.238.37) 1.767 ms 1.526 ms 1.370 ms
3 ae112-0.ncidf103.Puteaux.francetelecom.net (193.253.80.214) 1.928 ms 1.840 ms 1.759 ms
4 ae41-0.niidf101.Paris3eArrondissement.francetelecom.net (193.252.159.42) 1.978 ms 2.127 ms 2.333 ms
5 193.252.137.10 (193.252.137.10) 2.267 ms 2.180 ms 2.381 ms
6 * * *
7 * * *
8 212.73.205.22 (212.73.205.22) 3.429 ms 3.326 ms 3.824 ms
9 one.one.one.one (1.1.1.1) 2.754 ms 3.763 ms 2.585 ms
... et en forçant l'ICMP :
# traceroute -I 1.1.1.1
traceroute to 1.1.1.1 (1.1.1.1), 30 hops max, 38 byte packets
1 one.one.one.one (1.1.1.1) 0.524 ms 0.222 ms 0.151 ms
???
-
Bonjour, je déterre un peu le post.
Pareil chez moi (je sais... OSEF :o), ça passe.
-
Justement non, ton screen montre que ça passe en UDP mais pas en ICMP (ce que le dernier firmware était censé corriger...).
-
Oui, je viens de voir justement qu'il manque le pas dans mon pst ;)
-
Bonjour, sinon y a t il une explication logique du pourquoi ça passe chez certain et pas d'autre ?
-
Peut etre le modele de livebox?
Sur une LB4 Sercomm en 3.44.16 ça ne passe toujours pas sous windows, ping et tracert me renvoient vers la livebox
-
j'ai une LB4 Sercomm aussi et tout marche bien : ICMP, UDP, TCP.
Que ce soit par le LAN de la LB ou son Wifi.
-
J'ai une Sercomm en 3.44.16 et l'ICMP ne passe pas:
[:~]# traceroute -I 1.1.1.1
traceroute to 1.1.1.1 (1.1.1.1), 30 hops max, 60 byte packets
1 one.one.one.one (1.1.1.1) 0.466 ms 0.552 ms 0.624 ms
[:~]# traceroute -T 1.1.1.1
traceroute to 1.1.1.1 (1.1.1.1), 30 hops max, 60 byte packets
1 * * *
2 80.10.236.117 (80.10.236.117) 2.223 ms 2.322 ms 2.656 ms
3 ae109-0.ncidf104.Paris15eArrondissement.francetelecom.net (193.253.80.246) 2.703 ms 2.740 ms 2.766 ms
4 ae41-0.niidf102.Aubervilliers.francetelecom.net (193.252.159.46) 10.586 ms 10.610 ms 10.637 ms
5 ae40-0.niidf101.Paris3eArrondissement.francetelecom.net (81.253.129.137) 2.780 ms 2.806 ms 2.838 ms
6 193.252.137.10 (193.252.137.10) 3.556 ms 3.083 ms 3.087 ms
7 ae-35.ear2.Paris1.Level3.net (4.68.127.233) 2.864 ms 3.242 ms 3.652 ms
8 * * *
9 212.73.205.22 (212.73.205.22) 5.931 ms 5.241 ms 4.416 ms
10 one.one.one.one (1.1.1.1) 2.895 ms 2.809 ms 2.526 ms
[:~]# traceroute 1.1.1.1
traceroute to 1.1.1.1 (1.1.1.1), 30 hops max, 60 byte packets
1 * * *
2 80.10.236.117 (80.10.236.117) 2.067 ms 2.220 ms 2.407 ms
3 ae109-0.ncidf104.Paris15eArrondissement.francetelecom.net (193.253.80.246) 15.245 ms 15.269 ms 15.297 ms
4 ae41-0.niidf102.Aubervilliers.francetelecom.net (193.252.159.46) 2.789 ms 2.807 ms 2.837 ms
5 ae40-0.niidf101.Paris3eArrondissement.francetelecom.net (81.253.129.137) 2.871 ms 2.885 ms 2.912 ms
6 193.252.137.10 (193.252.137.10) 3.735 ms 1.859 ms 1.732 ms
7 * * *
8 * * *
9 212.73.205.22 (212.73.205.22) 3.330 ms 2.846 ms 3.401 ms
10 one.one.one.one (1.1.1.1) 2.330 ms 2.778 ms 2.851 ms
-
j'ai une LB4 Sercomm aussi et tout marche bien : ICMP, UDP, TCP.
Que ce soit par le LAN de la LB ou son Wifi.
Même version de livebox pourtant.
Modèle : Livebox 4 Sercomm
Firmware : SR40_sip-fr-3.44.16.1_7.21.3.1
-
Peut être cela a t il déjà été évoqué dans une autre discution mais qu'est ce que cela change concrètement que en ICMP cela ne fonctionne pas (oui je m'intéresse à la discution tout en essayant d'apprendre).
En gros, j'aime bien le principe de changer le dns de mes paramètres de connexion du pc sur lequel je fais le plus gros de "mon travail". Passer par des serveurs neutres qui evitent d'après de ce que je comprends que "les serveurs de mon FAI" enregistre mes requêtes (c'est bien cela ?). Mais le fait que par le protocole ICMP ne fonctionne pas avec 1.1.1.1 (mais fonctionne chez moi avec 1.0.0.1, ce que j'ai mis en dns primaire) change réellement quelque chose ?
-
Suite à d'autres problèmes la livebox a été remplacée, j'ai maintenant une Sagemcom firmware g0-f-sip-fr version 3.44.16 et c'est identique.
En soit oui, que l'icmp ne passe pas ne gène pas les requetes dns sur le port 53. Mais il peut arriver que des logiciels ou autres utilisent les serveurs dns pour tester une connexion via un ping. Et là la réponse n'est pas celle attendue.