Re: [ntp:questions] PC DCF-77 signal emulation?
FWIW, it's possible that the antenna/receiver modules are manufactured by this company: http://www.hkw-elektronik.de/ ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] PC DCF-77 signal emulation?
Hi there pc wrote: FWIW, it's possible that the antenna/receiver modules are manufactured by this company: http://www.hkw-elektronik.de/ http://www.hkw-elektronik.de/englisch/products/products.php http://www.hkw-elektronik.de/englisch/products/assemblys.php Regards, Rob -- There are 709 days until Central Registry IPv4 address exhaustion. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
[ntp:questions] ntpd: time reset problem
Hello *, strange happening yesterday. See this logfile lines: Sep 10 20:45:52 seymour ntpd[9104]: synchronized to 192.53.103.108, stratum 1 Sep 10 20:58:07 seymour ntpd[9104]: synchronized to 134.34.3.18, stratum 1 Sep 10 21:21:02 seymour dovecot: dovecot: Fatal: Time just moved backwards by 434 seconds. [ ... ] Sep 10 21:26:36 seymour ntpd[9104]: no servers reachable Sep 10 21:42:56 seymour ntpd[9104]: synchronized to 192.53.103.104, stratum 1 Sep 10 21:50:55 seymour ntpd[9104]: time reset +434.824810 s Sep 10 21:54:09 seymour ntpd[9104]: synchronized to 130.149.7.71, stratum 2 Sep 10 21:55:07 seymour ntpd[9104]: synchronized to 129.69.1.153, stratum 1 What happened to the clock between 20:58:07 and 21:42:56? I guess ntpd should never set the time the hard way. The software is ntp-4.2.4p2-1.fc6. Yes, I know it's old. The dovecot issue is not a topic, it just triggered my attention :-) --Frank Elsner ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Autokey users - please read
I don't use autokey in production, but I would also suggest that if the issue causes the reference implementation to violate RFCs and also creates a security issue with key shortening, it should be fixed without any options to go back to the bad behavior. Actually, the security issue might in fact be major, if the a zero is randomly generated in the first few bytes of the key, correct? Please don't take the Microsoft route, where praying to the altar of backwards compatibility means you are stuck with ugly hacks for decades. That might make sense for MSFT and its customers, but I don't think it makes sense here. The experts in this forum routinely advise questioners that's too old, upgrade to a newer release; this situation should prove no different. -- RPM ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] ntpd: time reset problem
Frank Elsner wrote: Hello *, strange happening yesterday. See this logfile lines: Sep 10 20:45:52 seymour ntpd[9104]: synchronized to 192.53.103.108, stratum 1 Sep 10 20:58:07 seymour ntpd[9104]: synchronized to 134.34.3.18, stratum 1 Sep 10 21:21:02 seymour dovecot: dovecot: Fatal: Time just moved backwards by 434 seconds. [ ... ] Sep 10 21:26:36 seymour ntpd[9104]: no servers reachable Sep 10 21:42:56 seymour ntpd[9104]: synchronized to 192.53.103.104, stratum 1 Sep 10 21:50:55 seymour ntpd[9104]: time reset +434.824810 s Sep 10 21:54:09 seymour ntpd[9104]: synchronized to 130.149.7.71, stratum 2 Sep 10 21:55:07 seymour ntpd[9104]: synchronized to 129.69.1.153, stratum 1 What happened to the clock between 20:58:07 and 21:42:56? I guess ntpd should never set the time the hard way. The software is ntp-4.2.4p2-1.fc6. Yes, I know it's old. The dovecot issue is not a topic, it just triggered my attention :-) --Frank Elsner Your clock got yanked around by at least one rogue server! This sort of thing is the reason for configuring four, five, or seven servers. It might be helpful if you post your ntp.conf file. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] ntpd: time reset problem
On 2009-09-11, Frank Elsner els...@tubit.tu-berlin.de wrote: strange happening yesterday. See this logfile lines: Is this a VM? Sep 10 20:45:52 seymour ntpd[9104]: synchronized to 192.53.103.108, stratum 1 Sep 10 20:58:07 seymour ntpd[9104]: synchronized to 134.34.3.18, stratum 1 Sep 10 21:21:02 seymour dovecot: dovecot: Fatal: Time just moved backwards by 434 seconds. [ ... ] That's 7.25 minutes. Note that the last message from ntpd was ~23 minutes prior to the message from dovecot. Sep 10 21:26:36 seymour ntpd[9104]: no servers reachable Sep 10 21:42:56 seymour ntpd[9104]: synchronized to 192.53.103.104, stratum 1 Sep 10 21:50:55 seymour ntpd[9104]: time reset +434.824810 s This is where ntpd realized the the time was off. Sep 10 21:54:09 seymour ntpd[9104]: synchronized to 130.149.7.71, stratum 2 Sep 10 21:55:07 seymour ntpd[9104]: synchronized to 129.69.1.153, stratum 1 What happened to the clock between 20:58:07 and 21:42:56? I'd be more concerned about what happened between the ntpd log entry at Sep 10 20:58:07 and the dovecot error message at Sep 10 21:21:02. That's the period where something pushed the clock back by ~7.25 minutes. I guess ntpd should never set the time the hard way. It only did so because the clock was pushed so far off in such a short time. The software is ntp-4.2.4p2-1.fc6. Yes, I know it's old. It's a little old. But not ancient. -- Steve Kostecke koste...@ntp.org NTP Public Services Project - http://support.ntp.org/ ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Autokey users - please read
On Fri, Sep 11, 2009 at 1:37 PM, Ryan Malayter wrote: I don't use autokey in production, but I would also suggest that if the issue causes the reference implementation to violate RFCs and also creates a security issue with key shortening, it should be fixed without any options to go back to the bad behavior. Actually, the security issue might in fact be major, if the a zero is randomly generated in the first few bytes of the key, correct? Incorrect. While the behavior violates the Autokey spec, I doubt there is any security issue. The session keys are each used once, in a sequence that is predictable only to the two parties involved, thanks to a seed securely negotiated using a higher level of Autokey, and to using the generated key list backwards. Shortened individual session keys can not be reused even if correctly guessed by a 3rd party listener. The session keys are used to sign traffic, not encrypt it, FYI. Please don't take the Microsoft route, where praying to the altar of backwards compatibility means you are stuck with ugly hacks for decades. [...] Even if a runtime workaround were used to allow a single ntpd to Autokey with both corrected and uncorrected ntpd peers simultaneously, the ugly hack would not mean ntpd is stuck with it -- unless you intend to use Autokey with uncorrected ntpd forever. The workaround could be disabled from the start, even when enabled was used only when necessary. Even when it was used with a configured peer, where ntpd remembered that the peer needed shortened session keys, it would be disabled on receipt of the first traffic signed by a complete key subject to shortening, meaning the remote ntpd could be upgraded to a corrected version while the local one stayed up without perpetuating workaround's use any more than necessary. It seems likely the runtime workaround will not be in ntpd because the added complexity is not worth the benefit. Instead, a configure knob will allow building a new ntpd with the old behavior. It may never be used, and as with the runtime workaround option, it can be excised at any time -- there is no reason ntpd would be stuck with it. Cheers, Dave Hart Cheers, Dave Hart ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Autokey users - please read
Dave, Better do this quickly, cleanly and with minimum wiggle room. Otherwise, somebody who doesn't know anything will call it a security flaw, call the CERT and create an Incident. This has happened before when somebody claimed a stack vulnerability which in fact was true in a most unlikely case. Although the reporter submitted a script allegedly proving this could occur, the script was defective and nobody was able to verify it. I'd like this not to happen again. My point being, fix the bug, put in a conditional to temporarily revert to past behavior and leave it be. Dave Hart wrote: On Fri, Sep 11, 2009 at 1:37 PM, Ryan Malayter wrote: I don't use autokey in production, but I would also suggest that if the issue causes the reference implementation to violate RFCs and also creates a security issue with key shortening, it should be fixed without any options to go back to the bad behavior. Actually, the security issue might in fact be major, if the a zero is randomly generated in the first few bytes of the key, correct? Incorrect. While the behavior violates the Autokey spec, I doubt there is any security issue. The session keys are each used once, in a sequence that is predictable only to the two parties involved, thanks to a seed securely negotiated using a higher level of Autokey, and to using the generated key list backwards. Shortened individual session keys can not be reused even if correctly guessed by a 3rd party listener. The session keys are used to sign traffic, not encrypt it, FYI. Please don't take the Microsoft route, where praying to the altar of backwards compatibility means you are stuck with ugly hacks for decades. [...] Even if a runtime workaround were used to allow a single ntpd to Autokey with both corrected and uncorrected ntpd peers simultaneously, the ugly hack would not mean ntpd is stuck with it -- unless you intend to use Autokey with uncorrected ntpd forever. The workaround could be disabled from the start, even when enabled was used only when necessary. Even when it was used with a configured peer, where ntpd remembered that the peer needed shortened session keys, it would be disabled on receipt of the first traffic signed by a complete key subject to shortening, meaning the remote ntpd could be upgraded to a corrected version while the local one stayed up without perpetuating workaround's use any more than necessary. It seems likely the runtime workaround will not be in ntpd because the added complexity is not worth the benefit. Instead, a configure knob will allow building a new ntpd with the old behavior. It may never be used, and as with the runtime workaround option, it can be excised at any time -- there is no reason ntpd would be stuck with it. Cheers, Dave Hart Cheers, Dave Hart ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] ntpd: time reset problem
Frank, The message Sep 10 21:21:02 seymour dovecot: dovecot: Fatal: Time just moved backwards by 434 seconds. [ ... ] Is not in the software distribution from here. Apparently, your version of ntpd has been modified. Even so, the probably cause is a defective server your protostats file should have more detailed information. Dave Frank Elsner wrote: Hello *, strange happening yesterday. See this logfile lines: Sep 10 20:45:52 seymour ntpd[9104]: synchronized to 192.53.103.108, stratum 1 Sep 10 20:58:07 seymour ntpd[9104]: synchronized to 134.34.3.18, stratum 1 Sep 10 21:21:02 seymour dovecot: dovecot: Fatal: Time just moved backwards by 434 seconds. [ ... ] Sep 10 21:26:36 seymour ntpd[9104]: no servers reachable Sep 10 21:42:56 seymour ntpd[9104]: synchronized to 192.53.103.104, stratum 1 Sep 10 21:50:55 seymour ntpd[9104]: time reset +434.824810 s Sep 10 21:54:09 seymour ntpd[9104]: synchronized to 130.149.7.71, stratum 2 Sep 10 21:55:07 seymour ntpd[9104]: synchronized to 129.69.1.153, stratum 1 What happened to the clock between 20:58:07 and 21:42:56? I guess ntpd should never set the time the hard way. The software is ntp-4.2.4p2-1.fc6. Yes, I know it's old. The dovecot issue is not a topic, it just triggered my attention :-) --Frank Elsner ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] ntpd: time reset problem
Is not in the software distribution from here. Apparently, your version of ntpd has been modified. David - Dovecot is the same application I use to POP3 mail from my SMTP gateway to my portal. All it is doing is squawking about the problem because it remembers what time it was the last time it checked the mail, then when it checks again it raises a warning flag. Phil span style=font-size:78%;span style=font-family:arial;strongNotice:/strong This e-mail message and its attachments are the property of Wendy's/Arby's Group Inc. /span span style=font-family:arial;or one of its subsidiaries and may contain confidential or legally privileged information intended/span span style=font-family:arial;solely for the use of the addressee(s). If you are not an intended recipient, then any use, copying or/span span style=font-family:arial;distribution of this message or its attachments is strictly prohibited. If you received this message in/span span style=font-family:arial;error, please notify the sender and delete this message entirely from your system./span/span ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
