Bonjour,
Voilà une semaine que je me tracasse avec une histoire de dns sur mon OTB intel (la toute 1ere avec nuc intel prise lors de la "béta" offre boost) suite test sur dnsleak.com je retrouvais des dns d'orange en plus de 2 d'ovh bon soit, le soucis c'est que la navigation est extrêmement lente à des moments type résolution dns foireuse et des timeout qui apparaissent aléatoirement alors que le débit est bon en ftp/sftp sur une ip directe.
Contexte :
1 nuc intel OTB (e26ee5f8-37ad-4355-b3a9-6acd1fa1d227)
1 vdsl orange livebox 4 20Mbits/s (if4 qui gère le wifi)
1 vdsl boost ovh 24Mbit/s (if3)
+- 1 connex 4g+ pour l'upload ou failover au cas où. (dhcp_usb0)
n'ayant pas trouver comment résoudre le problème j'en étais au point de me demander si je n'avais pas meilleur compte de résilier et garder une seule ligne orange tant le service était devenu bancal (sachant que la ligne orange seule est à 7ms de ping contre 30 derrière OTB).
J'ai tenté maj img et packets rien n'a changé et la seule solution trouvé pour avoir résolution dns sur les périphériques wifi est de fixer 54.38.80.225 en dur sur chaque interface dans Use custom DNS servers.
Mais est-ce que les dns passent bien par le tunnel chiffré finalement ? j'ai lu sur autres post que le service dsnmasq gère dhcp + dns mais est-ce le cas sur nuc intel ? je ne trouve pas ce service ? bref je suis paumé et se retrouver avec des resolutions dns qui foirent aléatoirement sur les périphérique est très handicapant.
Bref au secours je ne sais plus quoi faire pour retrouver la stabilité que j'avais (+-) depuis plusieurs années maintenant.
voilà tracert dns google depuis pc connecté rj45 sur livebox :
Détermination de l’itinéraire vers google-public-dns-a.google.com [8.8.8.8]
avec un maximum de 30 sauts :
1 <1 ms <1 ms <1 ms 192.168.100.1
2 20 ms 19 ms 20 ms 10.166.178.11
3 * * * Délai d’attente de la demande dépassé.
4 30 ms 26 ms 26 ms spine-201-10.otb.ovh [193.70.14.120]
5 26 ms 25 ms 26 ms 10.22.201.43
6 27 ms 25 ms 27 ms 145.239.153.139
7 27 ms 29 ms 26 ms be100-45.th2-1-a9.fr.eu [178.33.100.179]
8 * * * Délai d’attente de la demande dépassé.
9 26 ms 26 ms 30 ms 108.170.244.161
10 26 ms 25 ms 26 ms 209.85.250.143
11 26 ms 26 ms 26 ms google-public-dns-a.google.com [8.8.8.8]
Itinéraire déterminé.
Dernier point j'ai ça dans les log system (au bas mots plusieurs milliers de lignes...):
Tue Apr 30 17:40:08 2019 daemon.err graph[31631]: curl: (6) Could not resolve host: opentsdb.gra1.metrics.ovh.net
Tue Apr 30 17:40:09 2019 daemon.err otb-tracker[1155]: curl: (28) Resolving timed out after 1511 milliseconds
Tue Apr 30 17:40:10 2019 daemon.err otb-tracker[1159]: curl: (28) Resolving timed out after 1511 milliseconds
Tue Apr 30 17:40:11 2019 daemon.err otb-tracker[1156]: curl: (28) Resolving timed out after 1511 milliseconds
Tue Apr 30 17:40:11 2019 daemon.err otb-tracker[1158]: curl: (28) Resolving timed out after 1511 milliseconds
Tue Apr 30 17:40:11 2019 daemon.err otb-tracker[1159]: curl: (28) Resolving timed out after 1510 milliseconds
Tue Apr 30 17:40:12 2019 daemon.err otb-tracker[1156]: curl: (28) Resolving timed out after 1510 milliseconds
Tue Apr 30 17:40:12 2019 daemon.err otb-tracker[1158]: curl: (28) Resolving timed out after 1520 milliseconds
Tue Apr 30 17:40:13 2019 daemon.err otb-tracker[1155]: curl: (28) Resolving timed out after 1510 milliseconds
Tue Apr 30 17:40:14 2019 daemon.err otb-tracker[1155]: curl: (28) Resolving timed out after 1509 milliseconds
Tue Apr 30 17:40:15 2019 daemon.err otb-tracker[1159]: curl: (28) Resolving timed out after 1511 milliseconds
Tue Apr 30 17:40:16 2019 daemon.err otb-tracker[1156]: curl: (28) Resolving timed out after 1511 milliseconds
Tue Apr 30 17:40:16 2019 daemon.err otb-tracker[1158]: curl: (28) Resolving timed out after 1511 milliseconds
Tue Apr 30 17:40:16 2019 daemon.err otb-tracker[1159]: curl: (28) Resolving timed out after 1510 milliseconds
Tue Apr 30 17:40:17 2019 daemon.err otb-tracker[1156]: curl: (28) Resolving timed out after 1510 milliseconds
Tue Apr 30 17:40:18 2019 daemon.err otb-tracker[1158]: curl: (28) Resolving timed out after 1510 milliseconds
Tue Apr 30 17:40:18 2019 daemon.err otb-tracker[1155]: curl: (28) Resolving timed out after 1511 milliseconds
Probleme DNS OTB intel connexion inacessible
Related questions
- Débit sur DMZ très faibles
26396 
09.01.2026 11:04
- [Résolu] Routeur Ubiquiti Unifi USG‑PRO‑4 + Overthebox (OVH & Freebox)
24928 16.04.2017 16:44
- OTB en 4G uniquement
21064 21.10.2016 18:21
- Problèmes de ping avec Discord
20546 15.02.2018 22:12
- Perte Upload 4G
20404 03.04.2019 20:57
- Liste de tous mes bugs rencontrés avec OTB
17968 14.01.2017 14:53
- [Résolu] OverTheBox qui récupère l'ip public de ma box au lieu de la sienne
17440 26.07.2018 10:37
- [Résolu] Installation sur raspberry PI 3
16559 14.12.2017 00:51
- [Résolu] Redirection de ports OTB
16244 03.01.2017 21:38
- Version et mise à jour
15843 21.11.2017 16:49
Bonjour @PhilippeR33
Le type de matériel n'a pas d'impacte sur le service, l'ensemble des otb utilise la même version de syteme. C'est bien le paquet DNSmasq qui gère le DHCP ainsi que le DNS.
Les requêtes DNS ne passe pas encore par le tunnel VPN chiffré, cette fonctionnalité arrive avec la prochaine mise a jour (0.7) qui sera déployée prochainement.
Je ne vois pas par contre a première vu d'erreurs de résolution DNS, les requêtes son bien effectuées par ta livebox et les DNS OVH (dans notre système actuel, chaque modem interroge ses DNS et le premier à répondre à la requête est utilisé).
Il est tout a fait normale d'avoir des "Delai d'attente dépassé" sur un MTR, certains équipements que tu traverse, ne répondent pas au requête ICMP)
Le plus important est la dernière ligne. En l’occurrence sur ce tracert, il fait bien la liaison 8.8.8.8 avec 1a.google.com.a.google.com.
Comme tu à activé les LOG dns, ceux -ci sont bien remplie, et j'ai du mal à déterminer des périodes avec des erreur.
Pourrais tu me fournir un horodatage à la prochaine coupure, afin que je puisse cibler mes recherches ?
@SebastienS14
Peux tu me donner ton device ID que je vérifie ta configuration ?
édit : @SebastienS14, je viens de voir ton autre post avec le device ID, je regarde ton otb et te ferais un retour dessus.
merci
Bonne journée
Benoit
Bonjour,
Je vous remercie pour la réponse, ce qui est embêtant pour moi est que si je ne mets pas de preferred dns en dur dans chaque if les dns ne passe pas sur mes péripheriques wifi comme si les ips des boxs ne remontait pas.
Je viens d'enlever les log dns et les dns preferred dans chaque if et j'ai une multitude de fois :
Fri May 3 16:05:14 2019 daemon.err graph[27722]: curl: (6) Could not resolve host: opentsdb.gra1.metrics.ovh.net
même une installation de htop via ssh n'aboutit en passant directement via le nuc intel...
Et plus embêtant je n'ai plus aucune requête dns qui passe via le wifi sans les dns en dur dans chaque if alors que je n'ai pas souvenir d'avoir déjà eu ce problème depuis le lancement de l'offre quand j'ai souscris. Comment se fait-il que les requêtes ne passent pas alors qu'il y a bien les adresses dns et dans modem ovh et livebox 4 ?
merci à vous,
Cordialement.
Bonjour,
Les DNS indiqué sur les IF servent a construire le fichier resolv.conf.auto, qui va se generé a chaque changement d'etat d'une interface (ceci permet de supprimé les DNS de modem déconnecté)
Pour le htop il faut renseigner la commande suivante :
otb-action-updateReleaseChannel && opkg update && opkg install htop
Si tu ne renseigne pas cette commande complette, il va te répondre qu'il ne trouve pas le paquet Htop.
Je check pourquoi les DNS ne sont pas optimale.
Bonsoir,
oui j'avais compris le principe du resolv.conf.auto (je ne trouvais pas car cherchais resolv.conf tout court) par contre sans insiquer de dns preferred les ips dns des box ne remontent plus dans mon cas d'ou les connexion impossible sur periph wifi et plus curieux encore en ssh sur l'otb directement.
La mise à jour paquet me retourne cela :
Downloading http://downloads.overthebox.net/stable/packages/x86_64/base/Packages.gz
Failed to establish connection
*** Failed to download the package list from http://downloads.overthebox.net/stable/packages/x86_64/base/Packages.gz
Alors qu'en fixant les dns en dur ras, il a a bien un soucis du coup mais à quelle niveau je n'en sait rien...
Autre question concernant l'utilité de la Qos ne me servant pas des lignes tel ip y a-t-il un intêret à limiter la bande passante à 80% de la synchro en upload et ou download pour avoir un download le plus stable possible ? en ftp les pings montent à +300 à 500 ms. Par contre les charges cpu dépassent les 2 sur le nuc intel à moins de 50Mbits/s j'ai comme un doute sur la capacité de ce cpu à chiffrer plus...