Journal DHCP et heure système

Posté par  . Licence CC By‑SA.
14
22
nov.
2020

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 range

Mê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  . Évalué à 1 (+4/-4).

    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;
    (Et toujours penser à choisir un stratum d'au moins '3' pour son usage personnel :-) )

    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  . Évalué à 2 (+1/-0).

      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  (site Web personnel) . Évalué à 8 (+7/-1).

      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  . Évalué à 2 (+1/-0).

        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  . Évalué à 2 (+0/-0).

          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  . Évalué à 2 (+0/-0).

            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  . Évalué à 0 (+0/-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  . Évalué à 6 (+4/-0).

      "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  . Évalué à 2 (+1/-0). Dernière modification le 22/11/20 à 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  . Évalué à 4 (+2/-0). Dernière modification le 22/11/20 à 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  . Évalué à 1 (+1/-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.

          • [^] # Re: Eh oui...

            Posté par  . Évalué à 3 (+1/-0). Dernière modification le 22/11/20 à 16:28.

            Il démarrent au 1 janvier 1970, ou à la date de la dernière extinction si fake-hwclock est utilisé. La date est ensuite ajustée via NTP.

            Je ne me souviens pas avoir vu de cas ou une machine n'obtenait pas d'adresse via DHCP même en démarrant au 1 janvier 1970.
            Si c'est un bug, c'est plutôt du côté du serveur DHCP, pas du client.

          • [^] # Re: Eh oui...

            Posté par  . Évalué à 3 (+2/-0).

            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  . Évalué à 2 (+0/-0).

              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  . Évalué à 2 (+1/-1).

            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  . Évalué à 3 (+1/-0). Dernière modification le 22/11/20 à 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  . Évalué à 2 (+0/-0).

                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  . Évalué à 4 (+2/-0).

      C'est pour cela aussi qu'une ligne de ce type dans le fichier dhcpd.conf est importante

      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  (site Web personnel) . Évalué à 2 (+1/-1).

    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.

  • # Mises à jour

    Posté par  (site Web personnel) . Évalué à 1 (+1/-1). Dernière modification le 22/11/20 à 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  . Évalué à 4 (+2/-0).

      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  . Évalué à 4 (+2/-0).

    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

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n’en sommes pas responsables.