Couldn't resolve host à la 1ère tentative, pas à la 2ème

Support Debian
#1

Bonjour à tous,

J’utilise un petit programme utilisant libcurl qui marche très bien depuis quelques temps, sous Debian stable, connecté en filaire à une Livebox. Ce week-end j’ai mis à jour les paquets qui pouvaient l’être (toujours en stable), ce qui doit se limiter à des corrections de bugs ou failles. Et depuis, mon programme me renvoie une erreur curl 6 : CURLE_COULDNT_RESOLVE_HOST à la première tentative. Si je le relance à la main, la connexion a bien lieu avec le premier site cherché, puis à nouveau une erreur sur le 2ème site. Si je le relance à la main une 3ème fois, le programme marche (il n’accède qu’à 2 sites différents). Et ensuite rebelote en cas de redémarrage.

Comme c’est un programme lancé par cron, c’est très désagréable. Ma première idée a été de mettre à la main les DNS d’Orange plutôt que la redirection pourrie de la Livebox. Et là miracle ça a marché lors de mes tentatives manuelles. Par contre j’ai obtenu ce matin une erreur 56 CURLE_RECV_ERROR (Failure with receiving network data), qui ne me dit pas grand chose.

J’ai donc plusieurs questions :

  • est-ce que Debian aurait envoyé une mise à jour envahissante en stable ? curl n’attend même pas une seconde avant de me renvoyer une erreur 6. Ça fait pas long comme timeout.
  • est-ce que ça n’a aucun rapport avec ma mise à jour, et c’est juste Orange qui fait n’importe quoi ?
  • est-ce que vous connaissez la signification de l’erreur 56 ? (et pas 42)

Merci d’avance

#2

peut être ce post?:

http://www.debian-fr.org/connexions-pages-internet-difficles-t37509.html

#3

En effet la description correspond exactement au problème déclenché par la mise à jour du resolver de la libc.

Ça a un rapport avec la mise à jour, mais la cause primaire est qu’Orange fait n’importe quoi avec le relais DNS de la livebox. Problème connu, ce n’est pas la première fois. Rappelez-vous les problèmes signalés lors de l’activation de l’IPv6 par défaut dans Debian. Une fois de plus la mise à jour ne fait que révéler le bug de la livebox.

#4

Merci, ce qui me manquait c’était effectivement le fait que le resolver de la libc a été mis à jour.

#5

@pascal:

le “blacklistage” de ipv6 dans /etc/modprobe.d/blacklist.conf est il une solution possible de ces pb de livebox et libc?

#6

Non : sur les noyaux Debian depuis Squeeze car l’IPv6 est compilé en dur et non plus en module, donc empêcher modprobe de charger un module qui n’existe plus n’a plus aucun effet.

Il y a déjà eu des discussions à ce sujet. On peut désactiver l’IPv6 au démarrage en ajoutant l’option “ipv6.disable=1” (ou éventuellement plus soft, le désactiver sur toutes les interfaces avec “ipv6.disable_ipv6=1”) sur la ligne de commande du noyau dans la configuration du chargeur d’amorçage. Mais c’est faire l’autruche : le vrai problème est dans le DNS buggé de la box, pas dans IPv6, la libc ni Debian.

#7

merci pour ta réponse claire,finalement pour contourner ce pb de dns buggé dans la livebox j’ai utilisé la solution proposée par dyoba dans http://www.debian-fr.org/connexions-pages-internet-difficles-t37509.html

ce contournement fonctionne mais est il satisfaisant dans le sens où “chattr +i /etc/resolv.conf” ne l’est pas?

#8

Si tu fais allusion au recours à resolvconf pour ajouter une ligne d’options à /etc/resolv.conf, alors oui je trouve que c’est une solution très satisfaisante contrairement à rendre le fichier immodifiable avec chattr.

J’utilise resolvconf parce que le contenu de /etc/resolv.conf provient de deux sources différentes : dhclient (qui récupère les DNS IPv4 dans la réponse du serveur DHCPv4) et rdnssd (qui récupère les DNS IPv6 dans les annonces du routeur IPv6). Sinon, les deux s’écraseraient l’un l’autre.

#9

Juste un mot pour signaler qu’une mise à jour de la libc corrigeant le problème vient d’arriver dans le dépôt squeeze-updates (qui remplace le dépôt “volatile” des précédentes versions).
http://lists.debian.org/debian-stable-announce/2012/02/msg00001.html