Ntpdate et IPv6

Dans le message
<news:Pine.LNX.4.58.0404281718280.1728@pbeanf.raft.vacy-anapl.se>,
*Remi Moyen* tapota sur f.c.o.l.configuration :

Salut,

Bonjour,

$ sudo usr/sbin/ntpdate -u ntp.serveur.local
28 Apr 17:22:21 ntpdate[2118]: setsockopt() IPV6_V6ONLY failed: Protocol
not available

[J'ai aussi le même message en utilisant les serveurs NTP indiqués sur
ntp.org, donc je pense pas que ça vienne du serveur]

Euh... Je soupçonne que ça a quelque chose à voir avec IPv6, genre mon
ntpdate (ou autre chose ?) veut à tout prix utiliser IPv6, mais le serveur
n'est pas prévu pour.

Mais ça me dit absolument pas comment je résoud mon problème !

Je dirais que la commande 'ntpdate' est compilée avec le support IPv6 (ce
qui est systématiquement le cas sur les versions récentes de la glibc) et
tente d'écouter en IPv6 mais que votre système (le noyau en fait) ne
supporte pas l'IPv6.
Si la commande 'ntpdate' tente d'écouter en IPv6 c'est qu'il y a de forte
chance que le nom d'hôte du serveur ntp distant resolve en IPv6. On peut le
vérifier avec la commande 'host -t aaaa ntp.server' ou la commande 'dig
ntp.server aaaa'.
Pour forcer la commande 'ntpdate' à fonctionner en IPv4, on peut utiliser
l'option '-4'.

--
TiChou

On Wed, 28 Apr 2004, TiChou wrote:

$ sudo usr/sbin/ntpdate -u ntp.serveur.local
28 Apr 17:22:21 ntpdate[2118]: setsockopt() IPV6_V6ONLY failed: Protocol
not available

Je dirais que la commande 'ntpdate' est compilée avec le support IPv6 (ce
qui est systématiquement le cas sur les versions récentes de la glibc) et
tente d'écouter en IPv6 mais que votre système (le noyau en fait) ne
supporte pas l'IPv6.

Moui, c'est une explication qui me semble raisonnable.
Sauf que vu que ntpdate comme noyau sont des paquets standards Debian, je
suis étonné de ça, mais bon, c'est possible.

Si la commande 'ntpdate' tente d'écouter en IPv6 c'est qu'il y a de forte
chance que le nom d'hôte du serveur ntp distant resolve en IPv6. On peut le
vérifier avec la commande 'host -t aaaa ntp.server' ou la commande 'dig
ntp.server aaaa'.
Pour forcer la commande 'ntpdate' à fonctionner en IPv4, on peut utiliser
l'option '-4'.

Marche pô. Je n'ai pas vu cette option dans la doc (mais elle ne provoque
pas de message d'erreur spécifique, donc elle doit bien exister), et elle
ne change rien à la réponse, j'ai le même message d'erreur.

Au fait et au passage, j'ai le même message d'erreur si je spécifie un
serveur par son adresse IP (en IPv4, bien sûr !) et non pas par son nom.
Je suppose qu'il fait les conversions tout seul en interne.
--
Rémi Moyen
"Malgré les apparences, le temps est très varié à Nancy :
pluie, nuages, neige, brouillard, grêle, ..."

Dans le message
<news:Pine.LNX.4.58.0404290950350.1728@pbeanf.raft.vacy-anapl.se>,
*Remi Moyen* tapota sur f.c.o.l.configuration :

Si la commande 'ntpdate' tente d'écouter en IPv6 c'est qu'il y a de forte
chance que le nom d'hôte du serveur ntp distant resolve en IPv6. On peut
le vérifier avec la commande 'host -t aaaa ntp.server' ou la commande
'dig ntp.server aaaa'. Pour forcer la commande 'ntpdate' à fonctionner en
IPv4, on peut utiliser l'option '-4'.

Marche pô.

Arg !

Je n'ai pas vu cette option dans la doc

Oui, la documentation de la commande 'ntpdate' est assez pauvre.

(mais elle ne provoque
pas de message d'erreur spécifique, donc elle doit bien exister),

Oui elle existe bien. Vous pouvez le vérifier en faisant un 'ntpdate -h' qui
devrait alors vous renvoyer la liste des options possibles.

et elle
ne change rien à la réponse, j'ai le même message d'erreur.

Au fait et au passage, j'ai le même message d'erreur si je spécifie un
serveur par son adresse IP (en IPv4, bien sûr !) et non pas par son nom.
Je suppose qu'il fait les conversions tout seul en interne.

Alors je ne vois vraiment pas d'où peut venir le problème, car en analysant
le source de cette commande on voit :

if (setsockopt(fd[nbsock], SOL_SOCKET, SO_REUSEADDR, (void*) &optval,
sizeof(optval)) < 0) {
netsyslog(LOG_ERR, "setsockopt() SO_REUSEADDR failed: %m");
exit(1);
}
#ifdef IPV6_V6ONLY
/* Restricts AF_INET6 socket to IPv6 communications (see RFC
2553bis-03) */
if (res->ai_family == AF_INET6)
if (setsockopt(fd[nbsock], IPPROTO_IPV6, IPV6_V6ONLY, (void*) &optval,
sizeof(optval)) < 0) {
netsyslog(LOG_ERR, "setsockopt() IPV6_V6ONLY failed: %m");
exit(1);
}

ce qui laisse à croire que ntpdate définit le socket à écouter en IPv6
seulement si l'adresse est de type IPv6.

Une solution serait de recompiler le paquetage ntp en supprimant le support
IPV6_V6ONLY.

--
TiChou

On Mon, 3 May 2004, TiChou wrote:

Pour forcer la commande 'ntpdate' à fonctionner en
IPv4, on peut utiliser l'option '-4'.

Marche pô.

Arg !

Comme tu dis...

Alors je ne vois vraiment pas d'où peut venir le problème, car en analysant
le source de cette commande on voit :
[...]

ce qui laisse à croire que ntpdate définit le socket à écouter en IPv6
seulement si l'adresse est de type IPv6.

Moui, en effet.

Une solution serait de recompiler le paquetage ntp en supprimant le support
IPV6_V6ONLY.

Grmbmlbl... En règle générale, j'essaye d'éviter de recompiler trop de
trucs (pas que ce soit dur, mais ça évite de se prendre la tête à chaque
mise à jour -- repatcher les nouvelles sources et recompiler), mais bon,
là, va p'têt falloir y venir.

Merci quand même.
--
Rémi Moyen
"Malgré les apparences, le temps est très varié à Nancy :
pluie, nuages, neige, brouillard, grêle, ..."

On Wed, 28 Apr 2004, Remi Moyen wrote:

$ sudo usr/sbin/ntpdate -u ntp.serveur.local
28 Apr 17:22:21 ntpdate[2118]: setsockopt() IPV6_V6ONLY failed: Protocol
not available

Bon, le problème s'est reglé tout seul, je pense que le paquet a été mis à
jour (oui, bon, j'ai fait une grosse mise à jour de mon système, et j'ai
pas vérifié si ntpdate faisait partie des paquets changés. Je crois que
oui, mais bon, peu importe, à la limite).

Sauf que, maintenant, j'ai :

$ sudo usr/sbin/ntpdate -u ntp.serveur.local
5 May 11:04:38 ntpdate[7793]: no server suitable for synchronization found

Grr...

J'ai essayé tous les serveurs de strate 2 situés en France et indiqués par
ntp.org, et tous me disent la même chose, que j'utilise l'adresse IP ou le
nom du serveur.

J'ai aussi essayé de mettre le -4 pour forcer l'IPv4 (on sait jamais, vu
les problèmes précédents), pas mieux...

Si ça peut aider, voilà ce que me dit ntpdate -d (sur un serveur de la
tuxfamily) :

$ sudo ntpdate -u -b -d ntp.tuxfamily.net
5 May 11:04:33 ntpdate[7793]: ntpdate 4.2.0a@1:4.2.0a-8-r Fri Apr 9
06:12:11 CEST 2004 (1)
transmit(80.67.179.98)
transmit(80.67.179.98)
transmit(80.67.179.98)
transmit(80.67.179.98)
transmit(80.67.179.98)
80.67.179.98: Server dropped: no data
server 80.67.179.98, port 123
stratum 0, precision 0, leap 00, trust 000
refid [80.67.179.98], delay 0.00000, dispersion 64.00000
transmitted 4, in filter 4
reference time: 00000000.00000000 Thu, Feb 7 2036 7:28:16.000
originate timestamp: 00000000.00000000 Thu, Feb 7 2036 7:28:16.000
transmit timestamp: c4432ca5.1884a515 Wed, May 5 2004 11:04:37.095
filter delay: 0.00000 0.00000 0.00000 0.00000
0.00000 0.00000 0.00000 0.00000
filter offset: 0.000000 0.000000 0.000000 0.000000
0.000000 0.000000 0.000000 0.000000
delay 0.00000, dispersion 64.00000
offset 0.000000

5 May 11:04:38 ntpdate[7793]: no server suitable for synchronization
found

Clairement, il n'arrive pas à établir la connexion avec le serveur (qui
est bien vivant), mais ça ne me dit pas d'où vient le problème...

Reste une vague piste, j'ai vu des posts sur des archives de mailing-lists
qui parlent de problèmes de firewall ? Il y en a bien un entre ma machine
et l'extérieur, mais il me semble que l'option -u est faite pour régler ça
? À moins que le firewall ne soit vraiment paranoïaque ?? Est-ce que ça
peut venir d'ici, et dans ce cas, comment puis-je le savoir ?
--
Rémi Moyen
"Malgré les apparences, le temps est très varié à Nancy :
pluie, nuages, neige, brouillard, grêle, ..."

Dans le message
<news:Pine.LNX.4.58.0405051108460.1190@pbeanf.raft.vacy-anapl.se>,
*Remi Moyen* tapota sur f.c.o.l.configuration :

Sauf que, maintenant, j'ai :

$ sudo usr/sbin/ntpdate -u ntp.serveur.local
5 May 11:04:38 ntpdate[7793]: no server suitable for synchronization found

Grr...

J'ai essayé tous les serveurs de strate 2 situés en France et indiqués par
ntp.org, et tous me disent la même chose, que j'utilise l'adresse IP ou le
nom du serveur.

J'ai aussi essayé de mettre le -4 pour forcer l'IPv4 (on sait jamais, vu
les problèmes précédents), pas mieux...

Si ça peut aider, voilà ce que me dit ntpdate -d (sur un serveur de la
tuxfamily) :

[...]

Clairement, il n'arrive pas à établir la connexion avec le serveur (qui
est bien vivant), mais ça ne me dit pas d'où vient le problème...

Reste une vague piste, j'ai vu des posts sur des archives de mailing-lists
qui parlent de problèmes de firewall ?

Oui, il faut bien évidement que votre firewall laisse passer le trafic ntp.

Il y en a bien un entre ma machine et l'extérieur, mais il me semble que
l'option -u est faite pour régler ça ?

Non, l'option '-u' permet de ne pas utiliser les ports privilégiés (1-1024)
réservés généralement aux services système et peuvent être de ce fait
bloqués par des règles de firewall. Mais ici, il faut autoriser le firewall
à laisser entrer le trafic ntp, c'est-à-dire autoriser les connexions UDP à
se faire sur le port 123.

À moins que le firewall ne soit vraiment paranoïaque ?? Est-ce que ça
peut venir d'ici,

Oui.

et dans ce cas, comment puis-je le savoir ?

En stoppant le firewall dans un premier temps ?

--
TiChou

On Wed, 5 May 2004, TiChou wrote:

$ sudo usr/sbin/ntpdate -u ntp.serveur.local
5 May 11:04:38 ntpdate[7793]: no server suitable for synchronization found
[...]

Reste une vague piste, j'ai vu des posts sur des archives de mailing-lists
qui parlent de problèmes de firewall ?

Oui, il faut bien évidement que votre firewall laisse passer le trafic ntp.

Logique, remarque. Et que je confirme : ma machine maison, sur laquelle
y'a pas de firewall, se synchronise très bien en utilisant la même version
de ntpdate (Debian, dans les deux cas).

et dans ce cas, comment puis-je le savoir ?

En stoppant le firewall dans un premier temps ?

A peut pas, c'est pas moi qui le contrôle. C'est ma machine au bureau,
derrière le firewall du labo dont l'admin est, histoire de faciliter les
choses, présent que de temps en temps (et n'est pas un admin pro, non
plus...).

Bon, j'ai plus qu'à essayer de lui faire comprendre que ça serait sympa
d'ouvrir le port kivabien, puisque même le serveur ntp local est de
l'autre côté du firewall... Sauf si tu vois une autre solution
(éventuellement en installant un serveur ntp sur ma machine maison, mais
je ne pense pas qu'on puisse contourner le firewall comme ça) ?

Merci pour ton aide.
--
Rémi Moyen
"Malgré les apparences, le temps est très varié à Nancy :
pluie, nuages, neige, brouillard, grêle, ..."

Dans le message
<news:Pine.LNX.4.58.0405051322560.1190@pbeanf.raft.vacy-anapl.se>,
*Remi Moyen* tapota sur f.c.o.l.configuration :

$ sudo usr/sbin/ntpdate -u ntp.serveur.local
5 May 11:04:38 ntpdate[7793]: no server suitable for synchronization
found

[...]

Reste une vague piste, j'ai vu des posts sur des archives de
mailing-lists qui parlent de problèmes de firewall ?

Oui, il faut bien évidement que votre firewall laisse passer le trafic
ntp.

Logique, remarque. Et que je confirme : ma machine maison, sur laquelle
y'a pas de firewall, se synchronise très bien en utilisant la même version
de ntpdate (Debian, dans les deux cas).

et dans ce cas, comment puis-je le savoir ?

En stoppant le firewall dans un premier temps ?

A peut pas, c'est pas moi qui le contrôle. C'est ma machine au bureau,
derrière le firewall du labo dont l'admin est, histoire de faciliter les
choses, présent que de temps en temps (et n'est pas un admin pro, non
plus...).

Bon, j'ai plus qu'à essayer de lui faire comprendre que ça serait sympa
d'ouvrir le port kivabien, puisque même le serveur ntp local est de
l'autre côté du firewall... Sauf si tu vois une autre solution

Peut être en utilisant le vieux service time (via inetd) :), mais je ne suis
pas sûr que cela fonctionnerait correctement non plus.

(éventuellement en installant un serveur ntp sur ma machine maison, mais
je ne pense pas qu'on puisse contourner le firewall comme ça) ?

Ça ne résoudra pas le problème de la machine cliente qui doit pouvoir être
joignable par le serveur ntp.

Merci pour ton aide.

Pas de quoi.

--
TiChou