NTPD not receiving any response from timservers - NTP

This is a discussion on NTPD not receiving any response from timservers - NTP ; Hi all, I'm trying to set up NTPD on a gentoo box to serve time to my network. Needless to say, it's not working. It remains as a stratum 16 server, because it is not syncing. Below is lots of ...

+ Reply to Thread
Results 1 to 14 of 14

Thread: NTPD not receiving any response from timservers

  1. NTPD not receiving any response from timservers

    Hi all,

    I'm trying to set up NTPD on a gentoo box to serve time to my network.
    Needless to say, it's not working.
    It remains as a stratum 16 server, because it is not syncing.

    Below is lots of information on what ntp is doing, hopefully some of it
    will be useful.

    -----------------------------------------------------------------------------------

    # ntpq -p -c rv

    remote refid st t when poll reach delay offset
    jitter
    ================================================== ============================
    ntp.demon.co.uk .INIT. 16 u - 64 0 0.000 0.000
    0.000
    box2.martinradf .INIT. 16 u - 64 0 0.000 0.000
    0.000
    hall.inhouse-so .INIT. 16 u - 64 0 0.000 0.000
    0.001

    assID=0 status=c011 sync_alarm, sync_unspec, 1 event, event_restart,
    version="ntpd 4.2.2p3@1.1577-o Mon Nov 6 19:31:48 UTC 2006 (1)",
    processor="i686", system="Linux/2.6.11-gentoo-r4", leap=11, stratum=16,
    precision=-20, rootdelay=0.000, rootdispersion=0.915, peer=0,
    refid=INIT, reftime=00000000.00000000 Thu, Feb 7 2036 6:28:16.000,
    poll=6, clock=c8fa16a7.725e7096 Mon, Nov 6 2006 20:16:39.446,
    state=1,
    offset=0.000, frequency=-15.882, jitter=0.001, noise=0.001,
    stability=0.000, tai=0

    -----------------------------------------------------------------------------------

    # ntpd -d
    ntpd 4.2.2p3@1.1577-o Mon Nov 6 19:31:48 UTC 2006 (1)
    addto_syslog: precision = 1.000 usec
    create_sockets(123)
    addto_syslog: no IPv6 interfaces found
    addto_syslog: ntp_io: estimated max descriptors: 1024, initial socket
    boundary: 16
    bind() fd 16, family 2, port 123, addr 0.0.0.0, flags=9
    Added addr 0.0.0.0 to list of addresses
    addto_syslog: Listening on interface wildcard, 0.0.0.0#123 Disabled
    bind() fd 17, family 2, port 123, addr 127.0.0.1, flags=5
    Added addr 127.0.0.1 to list of addresses
    addto_syslog: Listening on interface lo, 127.0.0.1#123 Enabled
    bind() fd 18, family 2, port 123, addr 192.168.1.200, flags=25
    Added addr 192.168.1.200 to list of addresses
    addto_syslog: Listening on interface eth0, 192.168.1.200#123 Enabled
    bind() fd 19, family 2, port 123, addr 192.168.0.200, flags=25
    Added addr 192.168.0.200 to list of addresses
    addto_syslog: Listening on interface eth1, 192.168.0.200#123 Enabled
    bind() fd 20, family 2, port 123, addr xxx.xxx.xxx.120, flags=19
    Added addr xxx.xxx.xxx.120 to list of addresses
    addto_syslog: Listening on interface ppp0, xxx.xxx.xxx.120#123 Enabled
    init_io: maxactivefd 20
    local_clock: time 0 base 0.000000 offset 0.000000 freq 0.000 state 0
    addto_syslog: frequency initialized -15.882 PPM from
    /var/lib/ntp/ntp.drift
    key_expire: at 0
    peer_clear: at 0 next 1 assoc ID 29972 refid INIT
    newpeer: xxx.xxx.xxx.120->158.152.1.76 mode 3 vers 4 poll 6 10 flags
    0x281 0x1 ttl 0 key 00000000
    key_expire: at 0
    peer_clear: at 0 next 2 assoc ID 29973 refid INIT
    newpeer: xxx.xxx.xxx.120->81.187.65.110 mode 3 vers 4 poll 6 10 flags
    0x201 0x1 ttl 0 key 00000000
    key_expire: at 0
    peer_clear: at 0 next 3 assoc ID 29974 refid INIT
    newpeer: xxx.xxx.xxx.120->213.170.141.38 mode 3 vers 4 poll 6 10 flags
    0x201 0x1 ttl 0 key 00000000
    local_clock: time 0 base 0.000000 offset 0.000000 freq -15.882 state 1
    report_event: system event 'event_restart' (0x01) status 'sync_alarm,
    sync_unspec, 1 event, event_unspec' (0xc010)
    transmit: at 1 xxx.xxx.xxx.120->158.152.1.76 mode 3
    auth_agekeys: at 1 keys 1 expired 0
    timer: refresh ts 0
    transmit: at 2 xxx.xxx.xxx.120->81.187.65.110 mode 3
    transmit: at 3 xxx.xxx.xxx.120->213.170.141.38 mode 3
    transmit: at 3 xxx.xxx.xxx.120->158.152.1.76 mode 3
    transmit: at 4 xxx.xxx.xxx.120->81.187.65.110 mode 3
    transmit: at 5 xxx.xxx.xxx.120->213.170.141.38 mode 3
    transmit: at 5 xxx.xxx.xxx.120->158.152.1.76 mode 3
    transmit: at 6 xxx.xxx.xxx.120->81.187.65.110 mode 3
    transmit: at 7 xxx.xxx.xxx.120->213.170.141.38 mode 3
    transmit: at 7 xxx.xxx.xxx.120->158.152.1.76 mode 3
    transmit: at 8 xxx.xxx.xxx.120->81.187.65.110 mode 3
    and so on and so forth. Occasionally keys expire.

    -----------------------------------------------------------------------------------

    # ntpdate -q 81.187.65.110
    server 81.187.65.110, stratum 3, offset -0.003914, delay 0.06453
    6 Nov 20:18:40 ntpdate[7338]: adjust time server 81.187.65.110 offset
    -0.003914 sec

    # ntpdate -q 213.170.141.38
    server 213.170.141.38, stratum 2, offset -0.001053, delay 0.06541
    6 Nov 20:19:09 ntpdate[7342]: adjust time server 213.170.141.38 offset
    -0.001053 sec

    -----------------------------------------------------------------------------------

    # cat /etc/ntp.conf
    restrict default ignore
    restrict 127.0.0.1

    restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap nopeer
    restrict 192.168.0.0 mask 255.255.255.0 nomodify notrap nopeer

    driftfile /var/lib/ntp/ntp.drift
    logfile /var/log/ntp.log

    server ntp.demon.co.uk prefer iburst
    restrict 158.152.1.76 nomodify noserve
    server 81.187.65.110 iburst
    restrict 81.187.65.110 nomodify noserve noquery notrap
    server 213.170.141.38 iburst
    restrict 213.170.141.38 nomodify noserve noquery notrap

    -----------------------------------------------------------------------------------

    # dig +short ntp.demon.co.uk
    158.152.1.76

    -----------------------------------------------------------------------------------

    There is nothing interesting in /var/log/ntp.log

    I have iptables running, and although I believe as long as established
    connections are allowed through it should need no special
    configuration, it my first port of call. However, after flushing and
    setting its default policy to accept for everything, the results were
    no different. I am not an iptables wizard though, so could have missed
    something.

    Can anyone shed any light on the matter?

    As an aside, how do I prevent ntpd from listening on a particular
    interface?

    Cheers,
    Ling


  2. Re: NTPD not receiving any response from timservers

    lingsmail@gmail.com wrote:

    > Hi all,
    >
    > I'm trying to set up NTPD on a gentoo box to serve time to my network.
    > Needless to say, it's not working.
    > It remains as a stratum 16 server, because it is not syncing.
    >
    > Below is lots of information on what ntp is doing, hopefully some of it
    > will be useful.
    >
    > -----------------------------------------------------------------------------------
    >
    > # ntpq -p -c rv
    >
    > remote refid st t when poll reach delay offset
    > jitter
    > ================================================== ============================
    > ntp.demon.co.uk .INIT. 16 u - 64 0 0.000 0.000
    > 0.000
    > box2.martinradf .INIT. 16 u - 64 0 0.000 0.000
    > 0.000
    > hall.inhouse-so .INIT. 16 u - 64 0 0.000 0.000
    > 0.001
    >
    > assID=0 status=c011 sync_alarm, sync_unspec, 1 event, event_restart,
    > version="ntpd 4.2.2p3@1.1577-o Mon Nov 6 19:31:48 UTC 2006 (1)",
    > processor="i686", system="Linux/2.6.11-gentoo-r4", leap=11, stratum=16,
    > precision=-20, rootdelay=0.000, rootdispersion=0.915, peer=0,
    > refid=INIT, reftime=00000000.00000000 Thu, Feb 7 2036 6:28:16.000,
    > poll=6, clock=c8fa16a7.725e7096 Mon, Nov 6 2006 20:16:39.446,
    > state=1,
    > offset=0.000, frequency=-15.882, jitter=0.001, noise=0.001,
    > stability=0.000, tai=0
    >
    > -----------------------------------------------------------------------------------
    >
    > # ntpd -d
    > ntpd 4.2.2p3@1.1577-o Mon Nov 6 19:31:48 UTC 2006 (1)
    > addto_syslog: precision = 1.000 usec
    > create_sockets(123)
    > addto_syslog: no IPv6 interfaces found
    > addto_syslog: ntp_io: estimated max descriptors: 1024, initial socket
    > boundary: 16
    > bind() fd 16, family 2, port 123, addr 0.0.0.0, flags=9
    > Added addr 0.0.0.0 to list of addresses
    > addto_syslog: Listening on interface wildcard, 0.0.0.0#123 Disabled
    > bind() fd 17, family 2, port 123, addr 127.0.0.1, flags=5
    > Added addr 127.0.0.1 to list of addresses
    > addto_syslog: Listening on interface lo, 127.0.0.1#123 Enabled
    > bind() fd 18, family 2, port 123, addr 192.168.1.200, flags=25
    > Added addr 192.168.1.200 to list of addresses
    > addto_syslog: Listening on interface eth0, 192.168.1.200#123 Enabled
    > bind() fd 19, family 2, port 123, addr 192.168.0.200, flags=25
    > Added addr 192.168.0.200 to list of addresses
    > addto_syslog: Listening on interface eth1, 192.168.0.200#123 Enabled
    > bind() fd 20, family 2, port 123, addr xxx.xxx.xxx.120, flags=19
    > Added addr xxx.xxx.xxx.120 to list of addresses
    > addto_syslog: Listening on interface ppp0, xxx.xxx.xxx.120#123 Enabled
    > init_io: maxactivefd 20
    > local_clock: time 0 base 0.000000 offset 0.000000 freq 0.000 state 0
    > addto_syslog: frequency initialized -15.882 PPM from
    > /var/lib/ntp/ntp.drift
    > key_expire: at 0
    > peer_clear: at 0 next 1 assoc ID 29972 refid INIT
    > newpeer: xxx.xxx.xxx.120->158.152.1.76 mode 3 vers 4 poll 6 10 flags
    > 0x281 0x1 ttl 0 key 00000000
    > key_expire: at 0
    > peer_clear: at 0 next 2 assoc ID 29973 refid INIT
    > newpeer: xxx.xxx.xxx.120->81.187.65.110 mode 3 vers 4 poll 6 10 flags
    > 0x201 0x1 ttl 0 key 00000000
    > key_expire: at 0
    > peer_clear: at 0 next 3 assoc ID 29974 refid INIT
    > newpeer: xxx.xxx.xxx.120->213.170.141.38 mode 3 vers 4 poll 6 10 flags
    > 0x201 0x1 ttl 0 key 00000000
    > local_clock: time 0 base 0.000000 offset 0.000000 freq -15.882 state 1
    > report_event: system event 'event_restart' (0x01) status 'sync_alarm,
    > sync_unspec, 1 event, event_unspec' (0xc010)
    > transmit: at 1 xxx.xxx.xxx.120->158.152.1.76 mode 3
    > auth_agekeys: at 1 keys 1 expired 0
    > timer: refresh ts 0
    > transmit: at 2 xxx.xxx.xxx.120->81.187.65.110 mode 3
    > transmit: at 3 xxx.xxx.xxx.120->213.170.141.38 mode 3
    > transmit: at 3 xxx.xxx.xxx.120->158.152.1.76 mode 3
    > transmit: at 4 xxx.xxx.xxx.120->81.187.65.110 mode 3
    > transmit: at 5 xxx.xxx.xxx.120->213.170.141.38 mode 3
    > transmit: at 5 xxx.xxx.xxx.120->158.152.1.76 mode 3
    > transmit: at 6 xxx.xxx.xxx.120->81.187.65.110 mode 3
    > transmit: at 7 xxx.xxx.xxx.120->213.170.141.38 mode 3
    > transmit: at 7 xxx.xxx.xxx.120->158.152.1.76 mode 3
    > transmit: at 8 xxx.xxx.xxx.120->81.187.65.110 mode 3
    > and so on and so forth. Occasionally keys expire.
    >
    > -----------------------------------------------------------------------------------
    >
    > # ntpdate -q 81.187.65.110
    > server 81.187.65.110, stratum 3, offset -0.003914, delay 0.06453
    > 6 Nov 20:18:40 ntpdate[7338]: adjust time server 81.187.65.110 offset
    > -0.003914 sec
    >
    > # ntpdate -q 213.170.141.38
    > server 213.170.141.38, stratum 2, offset -0.001053, delay 0.06541
    > 6 Nov 20:19:09 ntpdate[7342]: adjust time server 213.170.141.38 offset
    > -0.001053 sec
    >
    > -----------------------------------------------------------------------------------
    >
    > # cat /etc/ntp.conf
    > restrict default ignore
    > restrict 127.0.0.1
    >
    > restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap nopeer
    > restrict 192.168.0.0 mask 255.255.255.0 nomodify notrap nopeer
    >
    > driftfile /var/lib/ntp/ntp.drift
    > logfile /var/log/ntp.log
    >
    > server ntp.demon.co.uk prefer iburst
    > restrict 158.152.1.76 nomodify noserve
    > server 81.187.65.110 iburst
    > restrict 81.187.65.110 nomodify noserve noquery notrap
    > server 213.170.141.38 iburst
    > restrict 213.170.141.38 nomodify noserve noquery notrap
    >
    > -----------------------------------------------------------------------------------
    >
    > # dig +short ntp.demon.co.uk
    > 158.152.1.76
    >
    > -----------------------------------------------------------------------------------
    >
    > There is nothing interesting in /var/log/ntp.log
    >
    > I have iptables running, and although I believe as long as established
    > connections are allowed through it should need no special
    > configuration, it my first port of call. However, after flushing and
    > setting its default policy to accept for everything, the results were
    > no different. I am not an iptables wizard though, so could have missed
    > something.
    >
    > Can anyone shed any light on the matter?
    >
    > As an aside, how do I prevent ntpd from listening on a particular
    > interface?
    >
    > Cheers,
    > Ling
    >


    Remove the restrict statements!

    Test.

    If it works now, your restrict statements were incorrect. If this is
    the case re-read the documentation for the restrict statement CAREFULLY!

    I don't think you CAN prevent ntpd from listening on a particular
    interface. Ntpd will listen on every configured interface. This is not
    a problem for most people. What problem are YOU trying to solve?

  3. Re: NTPD not receiving any response from timservers

    In article <1162844895.422061.160540@k70g2000cwa.googlegroups. com>
    lingsmail@gmail.com writes:
    >
    >I'm trying to set up NTPD on a gentoo box to serve time to my network.
    >Needless to say, it's not working.


    Pessimist.:-)

    >It remains as a stratum 16 server, because it is not syncing.
    >
    >Below is lots of information on what ntp is doing, hopefully some of it
    >will be useful.


    [snip]

    >0x201 0x1 ttl 0 key 00000000
    >local_clock: time 0 base 0.000000 offset 0.000000 freq -15.882 state 1
    >report_event: system event 'event_restart' (0x01) status 'sync_alarm,
    >sync_unspec, 1 event, event_unspec' (0xc010)
    >transmit: at 1 xxx.xxx.xxx.120->158.152.1.76 mode 3
    >auth_agekeys: at 1 keys 1 expired 0
    >timer: refresh ts 0
    >transmit: at 2 xxx.xxx.xxx.120->81.187.65.110 mode 3
    >transmit: at 3 xxx.xxx.xxx.120->213.170.141.38 mode 3
    >transmit: at 3 xxx.xxx.xxx.120->158.152.1.76 mode 3
    >transmit: at 4 xxx.xxx.xxx.120->81.187.65.110 mode 3
    >transmit: at 5 xxx.xxx.xxx.120->213.170.141.38 mode 3
    >transmit: at 5 xxx.xxx.xxx.120->158.152.1.76 mode 3
    >transmit: at 6 xxx.xxx.xxx.120->81.187.65.110 mode 3
    >transmit: at 7 xxx.xxx.xxx.120->213.170.141.38 mode 3
    >transmit: at 7 xxx.xxx.xxx.120->158.152.1.76 mode 3
    >transmit: at 8 xxx.xxx.xxx.120->81.187.65.110 mode 3
    >and so on and so forth. Occasionally keys expire.


    I think that you can guess that for a normally functioning server, there
    would be some number of "receive"s reported along with the "transmit"s
    (ideally the numbers should be the same...) - and that would happen
    regardless of whether the packets were subsequently discarded due to
    "restrict" statements. I.e. your ntpd is simply not receiveing any
    responses to its queries - not a ntpd problem.

    >I have iptables running, and although I believe as long as established
    >connections are allowed through it should need no special
    >configuration, it my first port of call. However, after flushing and
    >setting its default policy to accept for everything, the results were
    >no different. I am not an iptables wizard though, so could have missed
    >something.


    Yes, iptables or equivalent is a primary suspect, and yes, flushing and
    setting default policy to accept for everything should deal with that.
    Perhaps there is some other packet filtering going on, e.g. at the
    router that connects you to the Internet?

    >As an aside, how do I prevent ntpd from listening on a particular
    >interface?


    You can't, search the group archives for lengthy discussions on the
    subject. But you can use iptables to block packets coming in on
    interfaces where you don't want them to come in...

    --Per Hedeland
    per@hedeland.org

  4. Re: NTPD not receiving any response from timservers

    In article "Richard
    B. Gilbert" writes:
    >lingsmail@gmail.com wrote:


    [full quote of 150-line posting snipped]

    >Remove the restrict statements!


    PLEASE trim your quoting - frankly, you post like a top-poster who never
    understood that putting the response at the top was only one part of the
    problem, and just obliges by doing the same thing at the bottom. In such
    cases, I almost think top-posting is better...

    And just a suggestion, but maybe you should limit your posting to a
    level where you actually have time to give a response that is based on
    the problem description rather than auto-sending FAQ-responses. It is
    quite clear from the extensive information provided by the OP that
    restrict statements are *not* the problem.

    --Per Hedeland
    per@hedeland.org

  5. Re: NTPD not receiving any response from timservers

    On 2006-11-06, lingsmail@gmail.com wrote:

    > I'm trying to set up NTPD on a gentoo box to serve time to my network.
    > Needless to say, it's not working. It remains as a stratum 16 server,
    > because it is not syncing.




    > remote refid st t when poll reach delay offset jitter
    >================================================== ===================
    > ntp.demon.co.uk .INIT. 16 u - 64 0 0.000 0.000 0.000
    > box2.martinradf .INIT. 16 u - 64 0 0.000 0.000 0.000
    > hall.inhouse-so .INIT. 16 u - 64 0 0.000 0.000 0.001


    This is showing that your ntpd has not received any NTP packets from
    those time servers.

    And here's why:

    > server ntp.demon.co.uk prefer iburst
    > restrict 158.152.1.76 nomodify NOSERVE
    > server 81.187.65.110 iburst
    > restrict 81.187.65.110 nomodify NOSERVE noquery notrap
    > server 213.170.141.38 iburst
    > restrict 213.170.141.38 nomodify NOSERVE noquery notrap


    noserve == Deny all packets except ntpq and ntpdc queries.

    noquery == Deny all ntpq and ntpdc queries.

    You've told ntpd to completely ignore your time servers. Try removing
    the noserve and restarting ntpd.

    Please take a look at http://ntp.isc.org/Support/AccessRestrictions (a
    HOWTO-style document for configuring your ntpd access restrictions) and / or
    http://www.eecis.udel.edu/~mills/ntp/html/accopt.html (the official
    Access Control Options documentation).

    > As an aside, how do I prevent ntpd from listening on a particular
    > interface?


    Use your firewall (i.e. iptables) to block port 123/UDP on that
    interface.

    Use restrict statements to control what IP addresses / subnets are able
    to access your ntpd.

    --
    Steve Kostecke
    NTP Public Services Project - http://ntp.isc.org/

  6. Re: NTPD not receiving any response from timservers

    On Nov 6, 9:38 pm, p...@hedeland.org (Per Hedeland) wrote:
    > In article <1162844895.422061.160...@k70g2000cwa.googlegroups. com>
    >
    > lingsm...@gmail.com writes:
    >
    > >I'm trying to set up NTPD on a gentoo box to serve time to my network.
    > >Needless to say, it's not working.


    > I think that you can guess that for a normally functioning server, there
    > would be some number of "receive"s reported along with the "transmit"s
    > (ideally the numbers should be the same...) - and that would happen
    > regardless of whether the packets were subsequently discarded due to
    > "restrict" statements. I.e. your ntpd is simply not receiveing any
    > responses to its queries - not a ntpd problem.
    >


    Thanks for the speedy response.

    I have just tested it running against a different ntp server in the
    network (fudged to itself, if that's the correct terminology!), and it
    does indeed 'receive' some messages from it.
    transmit: at 1 192.168.1.200->192.168.1.8 mode 3
    receive: at 1 192.168.1.200<-192.168.1.8 mode 4 code 1 auth 0
    peer 192.168.1.8 event 'event_reach' (0x84) status 'unreach, conf, 1
    event, event_reach' (0x8014)
    clock_filter: n 1 off 1.256802 del 0.000628 dsp 7.937501 jit 0.000001,
    age 0
    transmit: at 2 62.56.76.120->158.152.1.76 mode 3
    transmit: at 3 62.56.76.120->81.187.65.110 mode 3peer 192.168.1.8 event
    'event_reach' (0x84) status 'unreach, conf, 1 event, event_reach'
    (0x8014)
    clock_filter: n 1 off 1.256802 del 0.000628 dsp 7.937501 jit 0.000001,
    age 0
    transmit: at 2 62.56.76.120->158.152.1.76 mode 3
    transmit: at 3 62.56.76.120->81.187.65.110 mode 3
    transmit: at 4 62.56.76.120->213.170.141.38 mode 3
    ....

    aside from the other transmits not receiving a response, does that look
    ok? If so, then it must be some kind of internet connectivity problem.

    > >I have iptables running, and although I believe as long as established
    > >connections are allowed through it should need no special
    > >configuration, it my first port of call. However, after flushing and
    > >setting its default policy to accept for everything, the results were
    > >no different. I am not an iptables wizard though, so could have missed
    > >something.Yes, iptables or equivalent is a primary suspect, and yes, flushing and

    > setting default policy to accept for everything should deal with that.
    > Perhaps there is some other packet filtering going on, e.g. at the
    > router that connects you to the Internet?


    If this was the case, wouldn't ntpdate also fail? This machine (and
    this iptables) /is/ the router that connects me to the internet.

    >
    > >As an aside, how do I prevent ntpd from listening on a particular
    > >interface?

    > You can't, search the group archives for lengthy discussions on the
    > subject. But you can use iptables to block packets coming in on
    > interfaces where you don't want them to come in...


    That is what I have it currently set up as, I only asked as I noticed
    it binding to an interface/port that I know it will never receive a
    request on (because of the iptables policy), and thought that was a bit
    pointless. No harm in it though I suppose.

    --
    Ling


  7. Re: NTPD not receiving any response from timservers

    On Nov 6, 9:58 pm, Steve Kostecke wrote:
    > On 2006-11-06, lingsm...@gmail.com wrote:
    >
    > > I'm trying to set up NTPD on a gentoo box to serve time to my network.
    > > Needless to say, it's not working. It remains as a stratum 16 server,
    > > because it is not syncing.

    >
    > > remote refid st t when poll reach delay offset jitter
    > >================================================== ===================
    > > ntp.demon.co.uk .INIT. 16 u - 64 0 0.000 0.000 0.000
    > > box2.martinradf .INIT. 16 u - 64 0 0.000 0.000 0.000
    > > hall.inhouse-so .INIT. 16 u - 64 0 0.000 0.000 0.001This is showing that your ntpd has not received any NTP packets from

    > those time servers.
    >
    > And here's why:
    >
    > > server ntp.demon.co.uk prefer iburst
    > > restrict 158.152.1.76 nomodify NOSERVE
    > > server 81.187.65.110 iburst
    > > restrict 81.187.65.110 nomodify NOSERVE noquery notrap
    > > server 213.170.141.38 iburst
    > > restrict 213.170.141.38 nomodify NOSERVE noquery notrapnoserve == Deny all packets except ntpq and ntpdc queries.

    >
    > noquery == Deny all ntpq and ntpdc queries.
    >
    > You've told ntpd to completely ignore your time servers. Try removing
    > the noserve and restarting ntpd.


    Heh heh, thank you. I was under the (obviously mistaken) impression
    that noserve meant 'don't serve time to this server'.
    Hm, and re-reading the document you referenced
    (http://ntp.isc.org/Support/AccessRestrictions), I can see why:
    "noserve -- "Do not serve time to this host/subnet.""
    To be fair that is trimming the article, it goes on to say:
    "This option is really intended to be used when you want to allow
    a host/subnet to access your ntpd only for monitoring and/or remote
    configuration." ... which I clearly ignored

    However the official documentation (which I hadn't read) is nicely
    unambiguous:
    "noserve
    Deny all packets except ntpq and ntpdc queries."

    Cheers,
    Ling


  8. Re: NTPD not receiving any response from timservers

    In article per@hedeland.org (Per Hedeland) writes:
    >In article "Richard
    >B. Gilbert" writes:
    >>lingsmail@gmail.com wrote:

    >
    >[full quote of 150-line posting snipped]
    >
    >>Remove the restrict statements!


    >And just a suggestion, but maybe you should limit your posting to a
    >level where you actually have time to give a response that is based on
    >the problem description rather than auto-sending FAQ-responses. It is
    >quite clear from the extensive information provided by the OP that
    >restrict statements are *not* the problem.


    OK, egg on my face - after actually testing it, I can confirm that at
    least in this case you were right - restrict statements that cause the
    packets to be rejected will actually also cause the "receive" lines to
    be missing from the debug output (at least in 4.2.0) - I think this is
    at least counter-intuitive.

    --Per Hedeland
    per@hedeland.org

  9. Re: NTPD not receiving any response from timservers

    >OK, egg on my face - after actually testing it, I can confirm that at
    >least in this case you were right - restrict statements that cause the
    >packets to be rejected will actually also cause the "receive" lines to
    >be missing from the debug output (at least in 4.2.0) - I think this is
    >at least counter-intuitive.


    Restrict lines cause enough trouble (like this) that it's probably
    worth adding some debug printout to the path that drops them due
    to restrictions.

    --
    The suespammers.org mail server is located in California. So are all my
    other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited
    commercial e-mail to my suespammers.org address or any of my other addresses.
    These are my opinions, not necessarily my employer's. I hate spam.


  10. Re: NTPD not receiving any response from timservers

    In article <1162853523.696083.78710@h48g2000cwc.googlegroups.c om>,
    lingsmail@gmail.com wrote:

    > > >I have iptables running, and although I believe as long as established
    > > >connections are allowed through it should need no special


    There are no connections involved.

    > If this was the case, wouldn't ntpdate also fail? This machine (and
    > this iptables) /is/ the router that connects me to the internet.


    Not if used in diagnostic mode, as it uses an unprivileged source
    port, which is typically allowed back in by the default firewall
    configuration. This is a common cause of confusion when debugging
    this problem (which typically happens on Red Hat when someone installs
    the official ntpd).

  11. Re: NTPD not receiving any response from timservers

    Hal Murray wrote:
    >>OK, egg on my face - after actually testing it, I can confirm that at
    >>least in this case you were right - restrict statements that cause the
    >>packets to be rejected will actually also cause the "receive" lines to
    >>be missing from the debug output (at least in 4.2.0) - I think this is
    >>at least counter-intuitive.

    >
    >
    > Restrict lines cause enough trouble (like this) that it's probably
    > worth adding some debug printout to the path that drops them due
    > to restrictions.
    >


    That could cause problems of its own! How many messages would you get,
    per day?

  12. Re: NTPD not receiving any response from timservers

    >> Restrict lines cause enough trouble (like this) that it's probably
    >> worth adding some debug printout to the path that drops them due
    >> to restrictions.


    >That could cause problems of its own! How many messages would you get,
    >per day?


    Sorry, I was thinking of only in debug mode. I think that case is
    already printing out a line for each packet sent so one per received
    packet dropped due to restrictions seems reasonable. If you get too
    much printout in that mode you probably have other problems and/or
    might like to know about it if that isn't the problem you are chasing.

    --
    The suespammers.org mail server is located in California. So are all my
    other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited
    commercial e-mail to my suespammers.org address or any of my other addresses.
    These are my opinions, not necessarily my employer's. I hate spam.


  13. Re: NTPD not receiving any response from timservers


    hmurray@suespammers.org (Hal Murray) writes:
    > Restrict lines cause enough trouble (like this) that it's probably
    > worth adding some debug printout to the path that drops them due
    > to restrictions.


    I wonder if it would be useful to have a implied restrict opening for
    each server and peer statement. I've gotten bitten a few times over
    the years when the restricts were by IP and the server/peer lines were
    name and the IP address of the host eventually changed. Adding a
    restrict by name never worked very well. When you least expected it
    some multi-homed host would get you.

    -wolfgang
    --
    Wolfgang S. Rupprecht http://www.wsrcc.com/wolfgang/

  14. Re: NTPD not receiving any response from timservers

    Wolfgang,

    I have heard rumors that "things should be better" with the new config
    file processing code.

    This may not be true, but if it's not true I believe it will be easier to
    address then.

    H

+ Reply to Thread