Cher journal,
Je viens de passer plus d'une heure à résoudre un souci avec mon client DHCP, je pense que ça pourra aider certains. Je n'avais pas rallumé mon Chromebook, un Asus C300s, depuis des semaines. J'ai viré ChromeOS dessus, j'ai installé GalliumOS. Ancien, mais fonctionnel. Bien entendu, la batterie s'est entièrement vidée.
Une fois branché, impossible d'obtenir une connexion wifi. J'ai cru à un souci matériel, Vu que le ChromeBook s'était éteint sur batterie vide, j'ai pensé à une corruption de système de fichiers (quelques messages fsck au boot), mais non…
En poussant un peu plus, j'ai remarqué que, pour le wifi, l'association avec le point d'accès s'effectuait bien, mais que le problème était à l'acquisition de l'adresse IP. j'ai branché un adaptateur USB/Ethernet avec le même résultat. Une fouille des logs indique :
DHCPDISCOVER on wlp2s0 to 255.255.255.255 port 67 interval 3 (xid=0x995990e)
Unable to set up timer: out of rangeMême message avec un dhclient manuel pendant l'association avec le point d'accès.
Version du client: 4.3.5
Package: isc-dhcp-client 4.3.5-3ubuntu7.1
Malgré des modifications du fichier dhclient.conf, rien à faire. Puis mon oeil a été attiré par l'heure système: 05h07, alors qu'il était 11h07. Rien de grave en théorie. Mais… En voulant modifier l'heure, je remarque que je suis le 13 novembre (nous sommes le 20) non pas 2020, mais 2120 !!! En remettant manuellement l'heure, DHCP refonctionne. Je suis tombé sur ce rapport de bug:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=801805
Donc, sachez-le : pour pouvoir utiliser un client DHCP, l'heure courante de votre système ne doit pas avoir de décalage important dans le futur par rapport à l'heure du serveur DHCP.
# Eh oui...
Posté par redo_fr . Évalué à 1.
Je ne dirais pas que c'est un "bug", c'est plutôt une sécurité due au protocole NTP lui-même.
Si le décalage ("jitter") de la machine est trop important, le client local NTP ne réaligne pas la machine car cela peut être une volonté de l'opérateur d'être décalé.
Il appartient à l'admin de réaligner manuellement l'horloge de la machine avec 'ntpdate' puis de relancer le client NTP.
C'est pour cela aussi qu'une ligne de ce type dans le fichier dhcpd.conf est importante :
option ntp-servers ntp.laas.fr;
Celui qui pose une question est bête cinq minutes, celui qui n'en pose pas le reste toute sa vie.
[^] # Re: Eh oui...
Posté par Sébastien Rohaut . Évalué à 2.
Je veux bien forcer la date manuellement avec ntpdate, mais dans mon cas, je n'avais plus de réseau. J'ai remis à l'heure avec un hwclock --systohc.
[^] # Re: Eh oui...
Posté par Colin Pitrat (site web personnel) . Évalué à 8.
Il ne parle pas de NTP il parle de DHCP. Sans réseau il ne peut pas espérer que ntpd va mettre son ordi à l'heure …
[^] # Re: Eh oui...
Posté par redo_fr . Évalué à 2.
Tout à fait, je prenais le cas général.
Je réagissais surtout au fait de classer ce comportement comme "bug", ce qui ne semble pas pertinent.
La commande qu'il a utilisé (hwclock --systohc) est parfaite :-)
une autre méthode peut consister à positionner une date/heure approximative avec 'date -s'
relancer le client DHCP puis une fois le réseau acquis, laisser NTP régler précisément l'horloge.
Celui qui pose une question est bête cinq minutes, celui qui n'en pose pas le reste toute sa vie.
[^] # Re: Eh oui...
Posté par Sébastien Koechlin . Évalué à 2.
DHCP pouvant servir à bien plus de choses que la configuration d'une adresse IP (il peut aussi fournir les adresses des serveurs NTP par exemple), il est dommage que le client ne fonctionne pas si le système n'est pas à l'heure ou ne connaît pas l'heure.
Visiblement il existe des options permettant de transmettre l'heure (option 152 par exemple), je doute que ce soit activé sur tous les serveurs, et encore moins que les clients en tiennent compte.
[^] # Re: Eh oui...
Posté par freem . Évalué à 3.
Par exemple pour faire la 1ère installation d'une machine, qui par définition n'aura pas encore d'heure système (cas du journal, en fait).
Bref, ce comportement de isc-dhcp-client implique que PXE ne peut pas fonctionner selon le firmware, ou pire, si la mémoire stockant l'heure est corrompue.
DHCP n'est pas un protocole qui devrais nécessiter une synchronisation, donc pour moi c'est clairement un bug. Je pense que je vais faire un test "pour le fun" sur mes VMs, je suis curieux de savoir si le client que j'utilise le plus (udhcpc, l'applet busybox) est affecté par ce bug (car s'en est un)…
[^] # Re: Eh oui...
Posté par thepaka . Évalué à 0.
Par contre, je confirme qu'il existe encore un autre problème qui casse la mise à l'heure via NTP si la date du système est trop loin dans le futur.
J'ai moi même été confronté à ce problème sur des machines qui se retrouvent avec une date en 2100 (ou plus) quand la batterie est complétement déchargé. Et dans ce cas, il faut a la fois résoudre le problème de DHCP et de NTP …
Je n'ai plus les détails en tête mais j'avais noté ça :
Pour dhclient :
# dhclient will fail in 'isc_time_nowplusinterval' if system time is too big
# Error message should be "Unable to set up timer: out of range."
# In 2019, the error appears when system clock was set above year 2106
# so we can safely set the upper limit to be year 2100
Pour systemd-timesyncd :
# NTP Era 0 limit is the UNIX timestamp 2085978495 (Feb 7 06:28:15 UTC 2036)
# In 2020, NTP servers timed out (with systemd-timesyncd) when the
# current timestamp is above that limit.
# We can fix the clock unless the system is installed in next NTP era.
[^] # Re: Eh oui...
Posté par gUI (Mastodon) . Évalué à 6.
"Il dit qu'il voit pas le rapport". Je ne comprends pas pourquoi un client ne chope pas d'IP sous prétexte qu'il n'est pas à l'heure. Ces deux notions n'ont rien à voir.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Eh oui...
Posté par redo_fr . Évalué à 2. Dernière modification le 22 novembre 2020 à 15:20.
C'est probablement à cause de la "lease". Si ta machine est trop décalée dans le temps, impossible d'accorder un bail.
Celui qui pose une question est bête cinq minutes, celui qui n'en pose pas le reste toute sa vie.
[^] # Re: Eh oui...
Posté par gUI (Mastodon) . Évalué à 4. Dernière modification le 22 novembre 2020 à 15:31.
Le lease c'est une durée, donc quelle que soit mon heure je sais que j'ai X minutes pour relancer la procédure non ?
Et alors comment font les RaspberryPi par exemple qui n'ont pas de RTC ?
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Eh oui...
Posté par redo_fr . Évalué à 1.
Il me semble (mais je n'en suis pas certain), qu'ils demandent le réglage de l'heure lors du premier 'boot'.
Celui qui pose une question est bête cinq minutes, celui qui n'en pose pas le reste toute sa vie.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3. Dernière modification le 22 novembre 2020 à 16:28.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Eh oui...
Posté par redo_fr . Évalué à 3.
Je viens de faire le test à l'instant avec un raspberry4 :
En lui mettant une date/heure "bidon", il arrive quand même à obtenir une adresse IP, my bad :-)
Celui qui pose une question est bête cinq minutes, celui qui n'en pose pas le reste toute sa vie.
[^] # Re: Eh oui...
Posté par gUI (Mastodon) . Évalué à 2.
bidon dans le passé ou dans le futur ? il y a peut-être de ça aussi…
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Eh oui...
Posté par groumly . Évalué à 2.
Pour que la durée marche, il faut être d’accord sur la date à laquelle la durée commence, non?
Dit autrement « t’as cette ip pour 24 heures » ne veut pas dire grand chose si tu ne sais pas quand les 24 heures commencent.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Eh oui...
Posté par gUI (Mastodon) . Évalué à 4. Dernière modification le 22 novembre 2020 à 18:28.
bin si, elles commencent maintenant. que je sois le 22/11/2020 à 18h28 ou le 05/02/2130 à 11h12, c'est pareil. c'est dans 24h.
ah… sauf si entre temps je me remets à l'heure, et là…
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Eh oui...
Posté par freem . Évalué à 2.
Et la, c'est à l'OS de savoir exposer les diverses horloges, et au logiciel client de savoir laquelle utiliser. Si l'OS sait pas faire… dommage, mais je doute que ça existe en dehors d'un kernel embarqué ultra compact (avec moins de 20 megs pour l'os complet, je dirais qu'un système basé sur linux peut tenir, mais ça sera probablement pas une distro GNU/Linux par contre, mieux vaut se baser sur busybox ici (je pense à certains routeurs que j'ai vu, mais me souviens plus des tailles de rom/ram).
[^] # Re: Eh oui...
Posté par gUI (Mastodon) . Évalué à 4.
Cette ligne n'est utile que justement après avoir eu une IP. Sans IP, tu ne feras pas de NTP.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
# Bug isc-dhcp
Posté par Damien Thébault . Évalué à 2.
Je pense que c'est plutôt un bug isc-dhcp que dhcp en général, dhcpcd n'a peut-être pas ce problème par exemple.
[^] # Re: Bug isc-dhcp
Posté par SChauveau . Évalué à 4.
En effet. Le problème se situe probablement dans le code ISC. Je pense en particulier à leur API time.h
https://users.isc.org/~each/doxygen/bind9/isc_2unix_2include_2isc_2time_8h.html#806dda800c7f198aa373aab9d88e436f
Je remarque en particulier que la fonction isc_time_set représente le temps en secondes depuis le 1er jan 1970 avec un entier 32bit (donc le temps UNIX classique). C'est le fameux bug de l'an 2038.
# Mises à jour
Posté par vmagnin (site web personnel) . Évalué à 1. Dernière modification le 22 novembre 2020 à 14:35.
Idem pour mettre à jour un système. Sur un vieux PC, si la pile du BIOS est HS, on se retrouve avec une date bidon d'une année lointaine, et les serveurs de mises à jour peuvent refuser de servir les mises à jour. Un petit
$ date --set="une date"permet alors de se faire accepter.[^] # Re: Mises à jour
Posté par gUI (Mastodon) . Évalué à 5.
Là je comprends, notamment vis à vis des certificats SSL. J'ai déjà eu des soucis sur ces sujets, et un certificat ayant une date de validité, c'est cohérent.
Mais je ne vois pas le rapport avec une requête DHCP. Des appareils qui n'ont pas d'heure sont légion sur les réseaux (IoT), ils arrivent bien à choper une IP.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
# 2038
Posté par goeb . Évalué à 4.
Je suis surpris que l'OS puisse avoir une date si loin dans le futur, car je croyais qu'après 2038 le codage de time_t sur 4 octets (utilisé dans la GNU libc et dans le kernel) posait problème.
Ref : https://fr.wikipedia.org/wiki/Bug_de_l%27an_2038
[^] # Re: 2038
Posté par barmic 🦦 . Évalué à 3. Dernière modification le 22 novembre 2020 à 17:25.
Comme le dis ton lien, uniquement pour les OS 32 bits uniquement et linux commence à préparer le 32bits à utiliser une représentation du temps sur 64bits.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: 2038
Posté par Alexandre Belloni (site web personnel) . Évalué à 1.
Pour être exact, le noyau utilise 64bits pour l'heure système depuis longtemps. Et du côté interfaces userspace, le travail s'est terminé récemment.
Le reste du travail va plutôt concerner les libc et le reste de l'espace utilisateur.
[^] # Re: 2038
Posté par SChauveau . Évalué à 3. Dernière modification le 22 novembre 2020 à 22:25.
et ISC n'est visible pas «2038 ready» si on en crois la fonction isc_time_set dans https://users.isc.org/~each/doxygen/bind9/isc_2unix_2include_2isc_2time_8h.html#806dda800c7f198aa373aab9d88e436f
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.