ntp Server antwortet nicht

dost0011 schrieb:
> Wenn ich nun den NTP Server de.pool.ntp.org anfrage, bekomme ich keine
> Antwort

Du machst ja auch kein NTP, sondern nur SNTP (Simple ...). Das kann 
keinen Pool nach der Zeit fragen, sondern nur einzelne Server.

Nimm gezielt einen NTP-Server und es sollte gehen.

dost0011 schrieb:
> sendNTPpacket(timeServerIP); // send an NTP packet to a time server
>   // wait to see if a reply is available
>   delay(3000);
>
>   int cb = udp.parsePacket();

Das ist unschön. UDP ist ein verbindungsloses Protokoll. Du kannst keine 
unmittelbare Antwort erwarten. Diese kommt irgendwann... oder auch gar 
nicht.

Ich mache das beim ESP so, dass ich einmal den Request abfeuere und dann 
in loop() zyklisch frage, ob was über UDP reinkommt.

1

void

2

loop() 

3

{

4

    ... // some other stuff

5

    ntp_poll_time ();                

6

    ... // some other stuff

7

}

wobei:

1

void

2

ntp_poll_time (void)

3

{

4

    int packetsize;

5

6

    packetsize = ntp_udp.parsePacket();

7

8

    if (packetsize)

9

    {

10

        ntp_udp.read(ntp_packet_buffer, packetsize);                   // read packet

11

12

        if (packetsize == NTP_PACKET_SIZE)

13

        {

14

            unsigned long hi = word(ntp_packet_buffer[40], ntp_packet_buffer[41]);

15

            unsigned long lo = word(ntp_packet_buffer[42], ntp_packet_buffer[43]);

16

            unsigned long secsSince1900 = hi << 16 | lo;

17

18

            Serial.print ("TIME ");

19

            Serial.println(secsSince1900);

20

        }

21

        else

22

        {

23

            Serial.println("- wrong packet size");

24

        }

25

26

        Serial.flush ();

27

    }

28

}

Den kompletten Source findestg Du unter 
https://www.mikrocontroller.net/svnbrowser/wordclock24h/ESP8266/ESP-WordClock/

Frank M. schrieb:
> Du machst ja auch kein NTP, sondern nur SNTP (Simple ...). Das kann
> keinen Pool nach der Zeit fragen, sondern nur einzelne Server.

Der DNS-Name de.pool.ntp.org liefert bei Übersetzung in eine IP-Adresse 
eine von mehreren Adressen und ist daher in Programmen, die DNS-Namen 
verstehen, üblicherweise direkt nutzbar. Oder hat die ESP-Lib spezielle 
Probleme damit?

A. K. schrieb:
> Oder hat die ESP-Lib spezielle Probleme damit?

Ich hatte es damals beim ESP8266 mit de.pool.ntp.org und SNTP nicht 
hinbekommen. Ich hatte dann als Server 192.53.103.103 (ntp3.ptb.de) 
probiert. Das ging sofort. Deshalb habe ich es dann auf den Pool im 
Zusammenhang mit SNTP geschoben.

Eben habe ich es aber nochmal (unter Linux, habe gerade keinen ESP 
parat) mit einem SNTP-Client probiert:

1

$ sntp de.pool.ntp.org

2

sntp 4.2.8p11@1.3728-o (1)

3

2018-05-18 13:29:31.010213 (-0100) +0.000558 +/- 0.023336 de.pool.ntp.org 212.18.3.19 s2 no-leap

Das funktioniert. Kann sein, dass es damals ein anderes temporäres 
Problem gab. Ich nehme daher meine Behauptung zurück ;-)

Ich werde es heute abend aber trotzdem nochmal auf dem ESP ausprobieren.

dost0011 schrieb:
> IPAddress timeServerIP(192,53,103,103);
>
> funktioniert auch nicht.

Dies wollte ich Dir gerade auch vorschlagen, hätte ja sein können, dass 
die Namensauflösung aus irgendeinem Grund nicht klappt. Obwohl, Du 
könntest Dir ja mal die IP-Adresse ausgeben lassen, die von 
WiFi.hostByName(ntpServerName, timeServerIP) ermittelt wird.

> Liegt vermutlich nicht an den tausenden Servern
> sondern an meinem Code ;-)

Den habe ich schon mit meinem Code

  https://www.mikrocontroller.net/svnbrowser/wordclock24h/ESP8266/ESP-WordClock/

verglichen. Ich kann keinen größeren Unterschied erkennen, bis auf das 
Delay. Wie gesagt: Schick das Paket einmal ab und führe den Aufruf von 
udp.parsePacket() & Co. zyklich in der Hauptschleife aus, ich hatte das 
oben schon so skizziert.

Frank M. schrieb:
> Wie gesagt: Führe den Aufruf von udp.parsePacket() & Co. zyklich
> in der Hauptschleife aus, ich hatte das oben schon so skizziert.

Wobei der ESP eigentlich für ereignisorientiertes Arbeiten ausgelegt 
ist, nicht für sequentielles Arbeiten mit Warterei. Also nicht
   Anfrage senden
   warten
   Antwort auswerten
sondern
   Anfrage senden
und unabhängig davon
   Wenn ein UDP Paket eintrifft, dann
      Paket auswerten

Damit habe ich bessere Erfahrungen gemacht. Allerdings war das in LUA.

A. K. schrieb:
> Wobei der ESP eigentlich für ereignisorientiertes Arbeiten ausgelegt
> ist, nicht für sequentielles Arbeiten mit Warterei.

Dann passt das ja zu meinem Vorschlag.

Hallo,

nur am Rande: zu den ESP8266 Extensions, die Bestandteil des SDK sind, 
gehört auch die nahezu vollständige Implemetierung der Posix-Time-Lib.

1

#include <ESP8266WiFi.h>

2

#include <time.h>

3

4

setup()

5

{

6

// Start Time service.

7

  configTime(timezone * 3600, 0, "pool.ntp.org", "time.nist.gov");

8

}

9

10

Mit

11

  time_t now = time(nullptr);

12

  struct tm * timeinfo;

13

  timeinfo = localtime(&now);

14

füllt man z.B. die Struktur.

15

 Serial.printf("%02d:%02d:%02d",timeinfo->tm_hour,timeinfo->tm_min,timeinfo->tm_sec);

16

  Serial.println();

Es läuft komplett asyncron im Hintergrund, aktualisiert wird per default 
alle Stunde.

Genaueres kann man sich z.B. hier raussuchen.
https://github.com/esp8266/Arduino/blob/master/tools/sdk/libc/xtensa-lx106-elf/include/time.h

Gruß aus Berlin
Michael

fchk schrieb:
> Du musst hier als Client eine 3 reinschreiben, der Server muss mit
> Mode=4 antworten. Mode=5 ist für Broadcasts.

Ich habe das mal unter Linux ausprobiert.

Sowohl

1

   packetBuffer[0] = 0b11100011;  // vom TO verwendet

als auch

1

   packetBuffer[0] = 0b00011011;  // findet man in diversen Quellen

2

                                  // LI = 0, NV = 3, MODE = 3

werden von us.pool.ntp.org, de.pool.ntp.org und ntp3.ptb.de ohne Mucken 
geschluckt. Offenbar interessiert sich keiner für die LI, NV und 
MODE-Bits. Naja, nicht ganz: bei packetBuffer[0] = 0x00 antwortet keiner 
mehr.

Ich habe sonst überhaupt keine Felder im Paket mehr gefüllt, also alles 
bei 0 gelassen (durch memset).

Verwendeter Source:

https://lettier.github.io/posts/2016-04-26-lets-make-a-ntp-client-in-c.html

dost0011 schrieb:
> Das bedeutet, dass es einmal funktioniert hat und dann nicht mehr.

Kann es sein, dass der Timeserver dicht macht, wenn Du ihn so zuknallst? 
Wie groß sind die zeitlichen Abstände?

Warum nimmst Du nicht Deinen eigenen Server? Den ntpd gibts notfalls 
auch für Windows, und 'nen Wireshark kann man so auch gleich mit 
ansetzen.

foobar schrieb:
> Den lokalen Server benutzt du zum Testen und Debuggen.

Vor allem kannst Du dort problemlos einen Wireshark aktivieren oder 
tcpdump laufen lassen.