Re: [ntp:questions] Strange refid
On 2013-11-12, John Hasler wrote: Brian Utterback writes: However, it begs the question of why somebody thought that printing M- before characters with the high order bit turned on would be a good idea. ASCII characters with the high bit turned on are control characters. No, they're not. Control characters are those with all but the lowest five bits set to 0. M- is a common notation for control as in M-J for control-J. M-J is 0xCA whereas Ctrl-J is 0x0A. Regards, Gary ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntp.conf on FreeBSD
On 2013-10-14, Rob wrote: unruh wrote: On 2013-10-14, Rob wrote: Steve Kostecke wrote: On 2013-10-12, unruh wrote: That is good to hear, but does not solve the problem that ntp.conf is there for the admin to make changes to in order to solve problems peculiar to his system. I may not want the freebsd pool servers-- because they are bad or because they are too far away. I may want to set up 5 (not 2) additional servers, some of which are refclock servers. To have to edit an init.d file, whose purpose is to start ntpd, not to configure it, is just supid. Somebody on the freebsd distro has no idea what he is doing. This is an issue with FreeNAS, not with FreeBSD. FreeNAS is an appliance, not a general purpose OS. These sorts of appliances often utilize a GUI to handle configuration tasks and store the resulting data in a custom data store. Configuration files, such as /etc/ntp.conf, are generated at the appropriate times from this data store. A real world example of the risks of relying on a GUI. No, a real world example of bad design. A GUI is fine but it should always manipulate the actual configuration files, not some generic storage used to generate the files. This mistake has been made many times in the Unix world. This is why the Windows Registry is such a good idea. You have a universally accepted configuration store that both the GUI tools and the relevant software can access and update. When FreeBSD (and Linux) had a registry, problems like this would not occur. ntpd would just read its configuration from the registry, and it would be a breeze to change poolservers with either the GUI or the generic registry editor, without confusing anyone. Linux has a registry. It is called /etc/ Easily edited, not by some registry tool, but by any editor the user might want to use. This has to be nominated the unruh stupid comment of the month. The Windows registry provides a mechanism for the saving and retrieval of values from a structured set of named values. So does /etc. Neither one enforces policy nor good design. I don't see how the registry offers any advantages over /etc with respect to the configuration of ntpd. To borrow from your paragraph above, ntpd just reads its configuration from /etc/ntp.conf, and it is a breeze to change pool servers with either a GUI (if you felt one was really necessary) or a generic text editor, without confusing anyone. Also, unlike the registry, which provides no means for annotating or providing any information at all about the meaning or effects of a value, /etc/ntp.conf can include comments to guide the inexperienced user. Regards, Gary ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntpd 4.2.6p5 will not synchronize to broadcast servers
Gary Johnson garyj...@eskimo.com wrote: Brian Utterback brian.utterb...@oracle.com wrote: I think this is a duplicate of bug 629. On 4/24/2013 9:54 PM, Harlan Stenn wrote: Gary, The short answer is I don't know. I believe we have successfully used broadcast clients in 4.2.6. Please see if ntp-dev works for you though - if there is a problem there we want to fix that before releasing 4.2.8. And having written the above: http://bugs.ntp.org/show_bug.cgi?id=2261 Thank you both! I had found those bug reports earlier, but I didn't think that wildcards and 255.255.255.255 applied in my case, so I didn't look closely at either one. I read the discussions associated with both last night and applied Dave Hart's suggestion at the bottom of the bug 629 discussion to add interface listen wildcard interface listen all to my /etc/ntp.conf. Broadcast now works! I changed the simple test case I posted originally to $ ntpd -4 -b -D2 -c /etc/ntp.conf.test where /etc/ntp.conf.test contains only those two interface commands. I will download and install ntp-dev later today and let you know how that goes. We had some issues with getting ntp-dev-4.2.7p367 compiled and installed on our system but we now have it running. When given a list of servers, it chooses and syncs to a system peer just fine. The bad news is that this version does not work at all with broadcast messages, not even with the interface commands added to /etc/ntp.conf. $ ntpq -crv associd=0 status=c016 leap_alarm, sync_unspec, 1 event, restart, version=ntpd 4.2.7p367@1.2483-o Mon Apr 29 21:01:02 UTC 2013 (1), processor=mips64, system=Linux/3.4.34, leap=11, stratum=16, precision=-17, rootdelay=0.000, rootdisp=7.575, refid=INIT, reftime=. Thu, Feb 7 2036 6:28:16.000, clock=d5297b65.cf1fce0d Mon, Apr 29 2013 23:06:13.809, peer=0, tc=3, mintc=3, offset=0.00, frequency=0.000, sys_jitter=0.00, clk_jitter=0.008, clk_wander=0.000 The debug output is now a little chatty with all the messages about select(). $ ntpd -4 -b -D2 -c /etc/ntp.conf.test 29 Apr 23:10:45 ntpd[3361]: ntpd 4.2.7p367@1.2483-o Mon Apr 29 21:01:02 UTC 2013 (1): Starting 29 Apr 23:10:45 ntpd[3361]: Command line: ntpd -4 -b -D2 -c /etc/ntp.conf.test ntp_rlimit: STACK: 50 4k pages ntp_rlimit: MEMLOCK: 32 MB 29 Apr 23:10:45 ntpd[3361]: set_process_priority: Leave priority alone: priority_done is 2 29 Apr 23:10:45 ntpd[3361]: proto: precision = 6.919 usec (-17) proto_config: code 1 value 1 dvalue 0.00 29 Apr 23:10:45 ntpd[3361]: Unable to listen for broadcasts, no broadcast interfaces available Finished Parsing!! create_sockets(123) move_fd: estimated max descriptors: 1024, initial socket boundary: 16 29 Apr 23:10:45 ntpd[3361]: Listen normally on 0 v4wildcard 0.0.0.0:123 created interface #0: fd=16, bfd=-1, name=v4wildcard, flags=0x89, ifindex=0, sin=0.0.0.0, bcast=0.0.0.0, mask=255.255.255.255, Enabled: create_interface(127.0.0.1#123) 29 Apr 23:10:45 ntpd[3361]: Listen normally on 1 lo 127.0.0.1:123 restrict: op 1 addr 127.0.0.1 mask 255.255.255.255 mflags 3000 flags 0001 created interface #1: fd=17, bfd=-1, name=lo, flags=0x5, ifindex=0, sin=127.0.0.1, mask=255.0.0.0, Enabled: create_interface(10.10.143.200#123) 29 Apr 23:10:45 ntpd[3361]: Listen normally on 2 eth0 10.10.143.200:123 restrict: op 1 addr 10.10.143.200 mask 255.255.255.255 mflags 3000 flags 0001 created interface #2: fd=18, bfd=-1, name=eth0, flags=0x19, ifindex=0, sin=10.10.143.200, bcast=10.10.143.255, mask=255.255.255.0, Enabled: create_interface(10.27.50.174#123) 29 Apr 23:10:45 ntpd[3361]: Listen normally on 3 remote 10.27.50.174:123 restrict: op 1 addr 10.27.50.174 mask 255.255.255.255 mflags 3000 flags 0001 created interface #3: fd=19, bfd=-1, name=remote, flags=0x19, ifindex=0, sin=10.27.50.174, bcast=10.27.50.255, mask=255.255.255.0, Enabled: 29 Apr 23:10:45 ntpd[3361]: peers refreshed create_sockets: Total interfaces = 4 29 Apr 23:10:45 ntpd[3361]: Listening on routing socket on fd #20 for interface updates loop_config: item 1 freq 0.00 event at 0 0.0.0.0 c01d 0d kern kernel time sync enabled event at 0 0.0.0.0 c012 02 freq_set kernel 0.000 PPM local_clock: mu 0 state 1 poll 3 count 0 event at 0 0.0.0.0 c011 01 freq_not_set event at 0 0.0.0.0 c016 06 restart select() returned -1: Interrupted system call auth_agekeys: at 1 keys 0 expired 0 select() returned -1: Interrupted system call timer: interface update select() returned -1: Interrupted system call select() returned -1: Interrupted system call select() returned -1: Interrupted system call select() returned -1: Interrupted system call select() returned -1: Interrupted system call ... To top it off
Re: [ntp:questions] ntpd 4.2.6p5 will not synchronize to broadcast servers
Brian Utterback brian.utterb...@oracle.com wrote: I think this is a duplicate of bug 629. On 4/24/2013 9:54 PM, Harlan Stenn wrote: Gary, The short answer is I don't know. I believe we have successfully used broadcast clients in 4.2.6. Please see if ntp-dev works for you though - if there is a problem there we want to fix that before releasing 4.2.8. And having written the above: http://bugs.ntp.org/show_bug.cgi?id=2261 Thank you both! I had found those bug reports earlier, but I didn't think that wildcards and 255.255.255.255 applied in my case, so I didn't look closely at either one. I read the discussions associated with both last night and applied Dave Hart's suggestion at the bottom of the bug 629 discussion to add interface listen wildcard interface listen all to my /etc/ntp.conf. Broadcast now works! I changed the simple test case I posted originally to $ ntpd -4 -b -D2 -c /etc/ntp.conf.test where /etc/ntp.conf.test contains only those two interface commands. It still emits the message 25 Apr 16:50:38 ntpd[31987]: Unable to listen for broadcasts, no broadcast interfaces available but broadcast works anyway. I then added those two interface commands to the top of our normal /etc/ntp.conf file and broadcast now works in the context of our application as well. Does it matter where in /etc/ntp.conf those commands are put? I will download and install ntp-dev later today and let you know how that goes. Thanks again, Gary ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
[ntp:questions] ntpd 4.2.6p5 will not synchronize to broadcast servers
We have a system that uses ntpd to synchronize the system clock. We allow the user to run ntpd in polling mode with a user-specified set of servers, or in broadcast mode, accepting any broadcast NTP messages received. This used to work fine with ntpd 4.2.4p7. Since upgrading to 4.2.6p5, polling mode continues to work fine but broadcast mode does not work at all--ntpd never sees any broadcast messages. The reason seems to be that ntpd 4.2.6p4 tries to initialize the broadcast interface before initializing its list of available interfaces. Here is a simple invocation of ntpd that exhibits the problem. Note the message about no broadcast interfaces available on the seventh line of output below. $ ntpd -4 -b -D2 -c /dev/null ntpd 4.2.6p5@1.2349-o Fri Apr 19 01:23:45 UTC 2013 (1) 24 Apr 23:58:35 ntpd[17867]: set_process_priority: Leave priority alone: priority_done is 2 24 Apr 23:58:35 ntpd[17867]: proto: precision = 5.380 usec loop_config: item 1 freq 0.00 event at 0 0.0.0.0 c01d 0d kern kernel time sync enabled proto_config: code 1 value 1 dvalue 0.00 24 Apr 23:58:35 ntpd[17867]: Unable to listen for broadcasts, no broadcast interfaces available 24 Apr 23:58:35 ntpd[17867]: line 1999510120 column 0 syntax error, unexpected $end Finished Parsing!! create_sockets(123) 24 Apr 23:58:35 ntpd[17867]: ntp_io: estimated max descriptors: 1024, initial socket boundary: 16 24 Apr 23:58:35 ntpd[17867]: Listen and drop on 0 v4wildcard 0.0.0.0 UDP 123 created interface #0: fd=16, bfd=-1, name=v4wildcard, flags=0x89, ifindex=0, sin=0.0.0.0, bcast=0.0.0.0, mask=255.255.255.255, Disabled: create_interface(127.0.0.1#123) 24 Apr 23:58:35 ntpd[17867]: Listen normally on 1 lo 127.0.0.1 UDP 123 restrict: op 1 addr 127.0.0.1 mask 255.255.255.255 mflags 3000 flags 0001 created interface #1: fd=17, bfd=-1, name=lo, flags=0x5, ifindex=0, sin=127.0.0.1, mask=255.0.0.0, Enabled: create_interface(10.10.143.200#123) 24 Apr 23:58:35 ntpd[17867]: Listen normally on 2 eth0 10.10.143.200 UDP 123 restrict: op 1 addr 10.10.143.200 mask 255.255.255.255 mflags 3000 flags 0001 created interface #2: fd=18, bfd=-1, name=eth0, flags=0x19, ifindex=0, sin=10.10.143.200, bcast=10.10.143.255, mask=255.255.255.0, Enabled: create_interface(10.27.50.174#123) 24 Apr 23:58:35 ntpd[17867]: Listen normally on 3 remote 10.27.50.174 UDP 123 restrict: op 1 addr 10.27.50.174 mask 255.255.255.255 mflags 3000 flags 0001 created interface #3: fd=19, bfd=-1, name=remote, flags=0x19, ifindex=0, sin=10.27.50.174, bcast=10.27.50.255, mask=255.255.255.0, Enabled: 24 Apr 23:58:35 ntpd[17867]: peers refreshed create_sockets: Total interfaces = 4 24 Apr 23:58:35 ntpd[17867]: Listening on routing socket on fd #20 for interface updates auth_setkey: key 65535 type 4 len 4 6ee30717 event at 0 0.0.0.0 c016 06 restart loop_config: item 2 freq 10.00 event at 0 0.0.0.0 c012 02 freq_set kernel 0.000 PPM local_clock: mu 0 state 1 poll 3 count 0 event at 0 0.0.0.0 c011 01 freq_not_set auth_agekeys: at 1 keys 1 expired 0 timer: interface update After waiting long enough for a broadcast message to have been sent by ntpd running on another host, $ ntpq -crv receive: at 96 127.0.0.1-127.0.0.1 flags 5 restrict 000 sendpkt(17, dst=127.0.0.1, src=127.0.0.1, ttl=-6, len=372) associd=0 status=c011 leap_alarm, sync_unspec, 1 event, freq_not_set, version=ntpd 4.2.6p5@1.2349-o Fri Apr 19 01:23:45 UTC 2013 (1), processor=mips64, system=Linux/3.4.34, leap=11, stratum=16, precision=-17, rootdelay=0.000, rootdisp=1.440, refid=INIT, reftime=. Thu, Feb 7 2036 6:28:16.000, clock=d522f08b.f70b1c35 Thu, Apr 25 2013 0:00:11.965, peer=0, tc=3, mintc=3, offset=0.000, frequency=0.000, sys_jitter=0.000, clk_jitter=0.008, clk_wander=0.000 I looked at the source code for both versions of ntpd and saw that in 4.2.4p7, the list of interfaces was initialized by the following cascade of function calls, ntpdmain() -- init_io() -- create_sockets() In 4.2.6p4, however, most of the contents of the function init_io() have been stripped out, including the call to create_sockets(). In 4.2.6p4, create_sockets() is not called until later, after the attempt to create the broadcast interface. Is ntpd 4.2.6p4 really broken w.r.t. receiving broadcasts, or do we have something configured incorrectly? Regards, Gary ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
