4

I'm trying to get a system with no outside internet access (A) to get the time from another system on the LAN that does (B).

In A's ntp.conf (the whole thing is at bottom), I've added:

server 192.168.2.102
restrict 192.168.2.102

Referring to B's IP. After an hour of reading man pages, looking at online examples, etc., as far as I can tell this should mean it will use that local server, and trust it for anything.

However, it doesn't work. I can watch the two exchange times in wireshark, and running ntpq -p on A shows:

remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
192.168.2.102   .INIT.      16 u   16   64    0    0.000    0.000   0.000

If I stop ntpd on A and try ntpd -gq, I can again watch a back and forth in wireshark, but after a minute or two the command times out with "No servers found".

I've even tried adding to A's conf:

fudge 192.168.2.102 stratum 1

Doesn't make any difference.

How can I force ntpd to set the time from a specific server? It looks like this used to be easy enough using ntpdate -- which is depreciated and does not exist on the system.

Here's the entire ntp.conf for machine A. This is stock Debian wheezy. The only changes I made were to add the lines involving 192.168.2.102, and comment out the debian pool servers to try and eliminate confusion there, so they are unreachable anyway.

# /etc/ntp.conf, configuration for ntpd; see ntp.conf(5) for help

driftfile /var/lib/ntp/ntp.drift

# Enable this if you want statistics to be logged.
#statsdir /var/log/ntpstats/

statistics loopstats peerstats clockstats
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
filegen clockstats file clockstats type day enable


# You do need to talk to an NTP server or two (or three).
#server ntp.your-provider.example
server 192.168.2.102
restrict 192.168.2.102
fudge 192.168.2.102 stratum 1

# pool.ntp.org maps to about 1000 low-stratum NTP servers.  Your server will
# pick a different set every time it starts up.  Please consider joining the
# pool: <http://www.pool.ntp.org/join.html>
#server 0.debian.pool.ntp.org iburst
#server 1.debian.pool.ntp.org iburst
#server 2.debian.pool.ntp.org iburst
#server 3.debian.pool.ntp.org iburst


# Access control configuration; see /usr/share/doc/ntp-doc/html/accopt.html for
# details.  The web page <http://support.ntp.org/bin/view/Support/AccessRestrictions>
# might also be helpful.
#
# Note that "restrict" applies to both servers and clients, so a configuration
# that might be intended to block requests from certain clients could also end
# up blocking replies from your own upstream servers.

# By default, exchange time with everybody, but don't allow configuration.
restrict -4 default kod notrap nomodify nopeer noquery
restrict -6 default kod notrap nomodify nopeer noquery

# Local users may interrogate the ntp server more closely.
restrict 127.0.0.1
restrict ::1

# Clients from this (example!) subnet have unlimited access, but only if
# cryptographically authenticated.
#restrict 192.168.123.0 mask 255.255.255.0 notrust


# If you want to provide time to your local subnet, change the next line.
# (Again, the address is an example only.)
#broadcast 192.168.123.255

# If you want to listen to time broadcasts on your local subnet, de-comment the
# next lines.  Please do this only if you trust everybody on the network!
#disable auth
#broadcastclient
Improve this question
4
  • Is the ntp server on B definitely working, and allows other clients on the same LAN to connect successfully (testing with ntpdate on another system maybe, it's still in Debian/Ubuntu/Mint)?
    – Xen2050
    Commented Jan 7, 2015 at 19:25
  • Like I said, they exchange messages with timestamps in them (wireshark breaks down the protocol). So they both work and communicate back and forth.
    – goldilocks
    Commented Jan 7, 2015 at 19:41
  • How about test with sntp -d (A)? Anything else that might give some more useful error messages. The "No servers found" message implies something's up with the server.
    – Xen2050
    Commented Jan 7, 2015 at 20:32
  • 1
    @Xen2050 sntp works and did lead me to a solution -- although machine B synced itself, it reports otherwise (ntpq -p -crv shows no starred server and sync_unspec). Adding a fudged 127.127 entry to machine B fixed that, and now A accepts it. O_o
    – goldilocks
    Commented Jan 7, 2015 at 21:06

2 Answers 2

Reset to default
4

Something like the following should work.

restrict default ignore
restrict 127.0.0.1 nomodify

restrict 192.168.2.102 mask 255.255.255.0 nomodify notrap noquery
server 192.168.2.102 burst iburst

server 127.127.1.0
fudge  127.127.1.0 stratum 10
Improve this answer
5
  • Why would that work? It doesn't look any different than what I already have, beyond the fact that the loopback is listed. I'm not saying you are wrong, but I don't want to start randomly cut n' pasting/cargo culting a config someone else cut n' paste/cargo culted. There's hundreds of these online already.
    – goldilocks
    Commented Jan 7, 2015 at 19:21
  • I actually just took it from a working example (from my work, not online) of what you're wanting to do. I don't actually know what this has in it that you might be missing.
    – Jeight
    Commented Jan 7, 2015 at 19:23
  • Okay, I did try replacing my whole conf with this. The only difference it makes is LOCAL is now listed with ntpq -p.
    – goldilocks
    Commented Jan 7, 2015 at 20:03
  • +1 Because this did help me toward a solution. However, I had to get rid of the last two lines since stratum 10 for the local server still seems to have taken priority from machine B when unfudged.
    – goldilocks
    Commented Jan 7, 2015 at 21:01
  • burst and iburst are mutually exclusive. Pick one or the other. In general iburst is preferred for public servers but if this is a local server you can use burst
    – dfc
    Commented Jan 8, 2015 at 3:03
3

I did get it working, so for posterity, someone on #ntp (freenode) said machine A may not be happy if B does not report itself as synced. This can be observed with ntpq -p on B not showing any servers prefixed with an asterisk.

Fudging a local source on B (which actually does sync, by examination of the system clock) corrected that:

server 127.127.1.0
fudge  127.127.1.0 stratum 10

However, it's important to not do that on A since it will trust stratum 10 more than whatever it counts the "locally synced" machine B as.

Improve this answer
1
  • This exact issue was bugging me for months. This exact solution was the only one that worked for me. Haven't seen it anywhere else on the internet.
    – felipeduque
    Commented Feb 13, 2020 at 17:30

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .