1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

How to: Set up NTP timeserver on Tomato for your small office

Discussion in 'Tomato Firmware' started by philess, May 7, 2013.

  1. philess

    philess Networkin' Nut Member

    Hey guys,

    i know, not anoter NTP on Tomato thread! Ok ok, i just wanted to post a quick and simple
    tutorial to show how it can be done and some optional additions for finetuning.
    Please lets not get into a discussion again that Tomato´s internal clock gets out of sync
    quickly and a GPS attached by serialcable is a lot more precise.
    If you set Tomato to sync every 1-2 hours it is only off by very few seconds between that.

    In the latest betas Victek has updated Busybox to a new version which comes with
    a builtin NTP server and he already has integrated it into the Tomato WebUI.
    So if you want to use a very simple NTP server, look at that. If you want more
    options to customize it yourself, using a seperate NTPd binary can still be useful.


    Purpose?

    In some scenarions it can be useful, or required, to have the same time on all clients,
    even if that time is not 100% correct with the actual time. For example in retail sales:
    It is important that all computers that are acting as the sales/cash terminals have
    the same time as the computers in the backoffice area where employes for example
    look up receipts etc in the Datawarehouse system.
    Now in such a scenario it is a different question if you chose to run NTP on the router
    or another, actual, computer. That is up to you. I am just pointing out the possibilities here.


    I am using the precompiled binary by ringer004 he has posted here:
    http://www.linksysinfo.org/index.php?threads/at-last-an-ntp-server-daemon-for-tomato.31599/
    (Alternatively you can install ntpd from Entware, should work just as well)

    Uploading the ntpd binary

    Download the zip and extract it. Upload the file "ntpd" from it to your router over (S)FTP,
    for example to /opt or /cifs (whatever extra storage you use). Then make it executable:

    Code:
    chmod +x /opt/ntpd

    Creating the config file

    Now create a config file that it will use later, here is a simple basic version:

    Code:
    # /opt/ntpd.conf
     
    # driftfile required to save learned time-adjustments for servers
    driftfile "/opt/ntpd_drift"
     
    # logfile
    logfile "/opt/ntpd.log"
    logconfig -allinfo -allevents -allstatistics -allstatus -clockinfo -clockevents -clockstatistics -clockstatus -clockall +syncinfo +syncevents +syncstatistics +syncstatus +syncall -sysinfo +sysevents -sysstatistics -sysstatus -sysall
     
    # interfaces
    broadcast 192.168.1.255
    broadcastclient
    interface drop ipv6
    interface listen 192.168.1.1
     
    # ntp servers to get time from
    server 129.143.2.23 prefer true
    server 131.188.3.220
    server 194.25.134.196
    server 127.127.1.0
     
    # default access settings
    restrict default kod nomodify notrap noquery nopeer
    restrict 127.0.0.1 mask 255.255.255.255
    restrict 127.127.1.0 mask 255.255.255.255
    restrict 192.168.1.1 mask 255.255.255.0 nomodify
    Change the following to match your own setup:
    - path for drift & log files (make sure the folders exist, the files will be created automatically)
    - adjust the broadcast and listening IP to whatever your router is
    - replace the ntp servers with a few of your own that are relatively close to you
    - adjust the restriction in the last line to match your network

    Save the file as "ntpd.conf" and upload it to your router too.


    Starting the daemon

    Thats it basically. Now you can start the server with:

    Code:
    /opt/ntpd -c ntpd.conf
    (if you put the file in the same folder, else add the path obviously)


    Testing

    If your client(s) are Windows based, you can test it the following way:
    Set your clients clock to a wrong time. Make sure the "Windows Time" service
    is running. From a command prompt type:

    Code:
    w32tm /config /syncfromflags:manual /manualpeerlist:192.168.1.1
    w32tm /config /update
    (Replace the IP with your routers IP)

    Your clients clock should then adjust itself to the correct time (according to the set timezone).

    To have the daemon run at startup of the router, i chose to put it
    in the WANUP script (Administration, Scripts, WAN UP):
    Code:
    killall ntpd
    sleep 1
    /opt/ntpd -c ntpd.conf


    Optional

    You can give out the adress of you NTP server by DHCP to all your clients.
    If you want to do that, add the following line to you DNSmasq custom config in the Tomato WebUI:

    Code:
    dhcp-option=br0,ntp-server,192.168.1.1
    Now your DHCP server will inform your clients on br0 that there is a NTP server on that IP.

    Unfortunately, Windows & Mac clients do not request and make use of that information.
    They have to be told manually. But most Linux OS´s should request the NTP and use it.

    Now you could either set all of your clients manually to use your routers IP for timesyncingthrough the Time & Date options.
    Or you can redirect the default timeserver DNS to your router.
    Windows 7 (and i think Vista too) uses "time.windows.com" as the default NTP server.

    You can add the following additional line to your DNSmasq custom config in the Tomato WebUI:
    Code:
    address=/time.windows.com/192.168.1.1
    That will redirect all queries to that DNS name to your router. It saves you configuring
    all your clients manually. Of course if you are using Group Policies/Active Directoy that is not needed.

    You can do the same if you have Apple Mac clients:
    Code:
    address=/time.apple.com/192.168.1.1
    address=/time.europe.apple.com/192.168.1.1
    address=/time.asia.apple.com/192.168.1.1
    Alternatively you can redirect every NTP Port 123 packet to your router. That is a bit more elegant. You could use this line in Administration/Scripts/Firewall:

    Code:
    # redirect NTP packets to router
    iptables -t nat -I PREROUTING -p tcp --dport 123 -j DNAT --to 192.168.1.1
    Note that this would redirect your whole network´s NTP requests to your router,
    regardless of what OS the client is using.

    Now when you enable "Internet time-syncing" on those clients, it will get the time from
    your router instead of somewhere else.

    Thats it. All very simple and nothing special at all. I hope this can be a useful post for
    some beginners who want to use a Tomato router in a small office network or something
    similar. Or just to play around with at home. If not, consider it just another pointless spam thread ;)
    Any input is very much appreciated!
     
    mmosoll and Monk E. Boy like this.
  2. MercuryV

    MercuryV Networkin' Nut Member

    FYI: Entware repository has ntpd, ntp-utils, ntp-keygen, ntpdate packages
     
  3. philess

    philess Networkin' Nut Member

    Thanks for mentioning that!
    Yes, Entware does, but when i used Optware about two months ago, there wasnt one.
     
  4. gfunkdave

    gfunkdave LI Guru Member

    Nifty. :cool:

    It's also worth noting that this won't do anything if you are running a Windows domain. Domain workstations use the AD server as their time server, since they must be synced with it for Kerberos authentication to work. You could set the AD server to sync from the router, but it's just as easy to sync it directly to a "real" NTP server.
     
    philess likes this.
  5. HunterZ

    HunterZ LI Guru Member

    Does this also keep the router's system time synchronized?

    If so, can/should one also turn off the synchronizing in the router's web GUI?


    Edit 1:

    Also, it seems odd to me that the entware ntp.conf is so drastically different from the typical Ubuntu one. Here's the customized one (via http://ubuntuforums.org/showthread.php?t=862620) that I have on my Ubuntu box:
    Code:
    # /etc/ntp.conf, configuration for ntpd; see ntp.conf(5) for help
     
    # 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
     
    # Specify one or more NTP servers.
     
    # Use servers from the NTP Pool Project. Approved by Ubuntu Technical Board
    # on 2011-02-08 (LP: #104525). See http://www.pool.ntp.org/join.html for
    # more information.
     
    # Use Ubuntu's ntp server as a fallback.
     
    # 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
    restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap
     
    # 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
    server time-nw.nist.gov iburst
    server time4.google.com
    server time2.google.com
    server nist-time-server.eoni.com
    #server enigma.wiredgoats.com
    server greenwix.netlobo.com
    #server ntp.ubuntu.com
    #server 0.ubuntu.pool.ntp.org
    #server 1.ubuntu.pool.ntp.org
    #server 2.ubuntu.pool.ntp.org
    #server 3.ubuntu.pool.ntp.org
    server 127.127.1.0
     
    fudge 127.127.1.0 stratum 10

    Edit 2:

    Suggestions based on trying to merge my Ubuntu config with your example one:
    1. Comment out the "broadcastclient" line, unless you are running other trusted NTP broadcast servers on the LAN that you want the router to implicitly listen to.
    2. Add "iburst" before "prefer true" on the "server" line for the preferred server. This will cause ntpd to exchange a burst of traffic with that server on startup to try to perform an initial sync that takes only ~10 seconds.
    3. Add "fudge 127.127.1.0 stratum 10" after the "server 127.127.1.0" line, so that the local system time gets a lower priority than the remote NTP servers (you only want to fall back on local system time as an authoritative time source if you have no other option). NOTE: 127.127.1.0 is a special IP address that ntpd interprets as localhost-as-a-time-source.
    4. Nitpick: Change "restrict 192.168.1.1" to "restrict 192.168.1.0" because you are using it to define a subnet and not an IP.
    5. Add "notrap" to the "restrict 192.168.1.x" line. This is recommended by a number of tutorials; I think it just disables the ability to attach a remote monitoring client, so it's probably a nitpick.
    6. Instead of restricting interface listening to 192.168.1.1, listen to everything except the WAN interface (vlan2 on toastman's tomato, may be different on other firmware/hardware).
    7. Add "restrict ::1", as entware's ntpq seems to want to use that (ipv6?) address by default.

    Here's what I've worked up for the entware version of ntpd:
    Code:
    # /opt/etc/ntp.conf
     
    # driftfile required to save learned time-adjustments for servers
    driftfile /opt/var/lib/ntp/ntp.drift
     
    # logfile
    logfile "/opt/var/log/ntp.log"
    logconfig -allinfo -allevents -allstatistics -allstatus -clockinfo -clockevents -clockstatistics -clockstatus -clockall +syncinfo +syncevents +syncstatistics +syncstatus +syncall -sysinfo +sysevents -sysstatistics -sysstatus -sysall
     
    # interfaces
    #broadcast 192.168.1.255
    interface listen all
    interface drop vlan2
     
    # ntp servers to get time from
    server 131.107.13.100  iburst prefer true
    server 216.239.38.15  iburst
    server 216.239.34.15  iburst
    server 216.228.192.69  iburst
    server 173.255.240.184 iburst
    server 127.127.1.0
     
    fudge  127.127.1.0 stratum 10
     
    # default access settings
    restrict default    kod nomodify notrap noquery nopeer
    restrict 127.0.0.1
    restrict ::1
    restrict 127.127.1.0 mask 255.255.255.255
    restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap

    Edit 3:

    Issues I've noticed:
    - Sometimes it seems to get stuck on an offset of ~500ms. Killing ntpd and running ntpdate several times seems to have helped. Turning off synchronization in the web UI may have helped too? I'd like to try rebooting but my wife is on Facebook and it's Mother's Day :p
    - Sometimes it seems to take several minutes to evaluate the remote NTP servers and decide to prefer one over localhost. Fixing the path to my driftfile to be a valid one may have helped here :)
    - Having the localhost 127.127.0.1 set as a server seems to prevent nptd from setting the initial time, as the fact that the router always has POSIX time 0 at startup means that the difference between system and remote server time is much much greater than the difference between system time and 127.127.0.1 time (obviously). Running without a 127.127.1.0 entry, and with the -g parameter (ntpd -gc /opt/etc/ntpinit.conf) to allow large jumps on initial correction seems to fix the issue.
     
    MercuryV likes this.
  6. MercuryV

    MercuryV Networkin' Nut Member

    It's just default OpenWrt config.
    Thank you for your suggestions and explanations about it.
     
  7. Monk E. Boy

    Monk E. Boy Network Guru Member

    Rather than faking specific DNS names, you could create a iptables entry that redirects any port 123 UDP traffic from LAN/WLAN sources to the local NTP server.

    Find/take a look at the DNS Intercept rule for inspiration, an NTP rule should be identical except for the port.
     
    philess likes this.
  8. philess

    philess Networkin' Nut Member

    Good idea Monk. E Boy! Thank you! That is more elegant, true. I just added it to the original post.

    Only issue i can think of tho, iptables doesnt take DNS names, right? What if the clients resolves
    time.windows.com and it resolves to a different IP every now and then?

    Edit: Just as i thought, everytime i do nslookup on it i get a different IP.
    Now someone could either create iptables rules for all those IPs, or just redirect
    the whole subdomain. I doubt time.windows.com is being used for much else, but of course,
    nobody outside MS will really know for sure if redirecting that could cause other problems.
     
  9. Monk E. Boy

    Monk E. Boy Network Guru Member

    The DNS Intercept rule works by redirecting all port 53 UDP packets to the router. It doesn't matter what DNS name they're looking up, if the client tries to talk to the DNS server over port 53 UDP it gets redirected to the router's DNS server. If you created a similar NTP rule, that worked similarly, it would redirect all port 123 UDP traffic to the router. No need to worry about DNS names, just a simple destination port and packet type will work.

    I forget what chain the DNS rule works off of though, if you're not careful - in terms of which chain the NTP rule gets added to, and the scope of the traffic source - you could end up redirecting NTP traffic from the router (back to the router), which would obviously be bad. That's why I recommend finding the DNS rule so you can mimic its configuration.
     
    philess likes this.
  10. philess

    philess Networkin' Nut Member

    Ohhhh my bad! I thought about that redirecting the wrong way. Sure, redirecting all NTP Port 123 packets to the router, WITHOUT the condition of the destination ip. That makes sense, thanks Monk E. Boy!!
     
  11. koitsu

    koitsu Network Guru Member

    Poking my head out of hiatus for a moment, solely to educate users / inform them of an extremely bad thing to do. Quoting:

    Responding to each of these individually:

    1. This is caused by improper use of ntpd. When a system boots up, before ntpd is started, the system is supposed to run ntpdate to exclusively set the system clock, then after that has completed, launch ntpd. It's very important to understand that ntpd is not the equivalent of running ntpdate in a cronjob (the latter is a very, VERY bad idea). ntpd actually has a crapload of smarts in it, where it adjusts the system clock gradually" (usually in very fine granularity, i.e. microsecond) to ensure that underlying applications/daemons do not "freak out" (you should see how many programs/daemons break badly if the clock goes backwards 1+ full second). So for ntpd to behave correctly from start-up, the clock needs to be properly synced with an NTP source / set administratively. That's what ntpdate can be used for. After that, let ntpd manage the time properly/sanely. This will also be touched on in (3b) below.

    2. This is normal behaviour, given the ntp.conf you provided (specifically lack of iburst in your server lines). EDIT: I see you have since gone back and edited your post to include iburst on your server lines. This should no longer be a problem for you.

    3a. This 127.127.0.1 crap is utter complete nonsense. Remove it from your configuration entirely. I have reviewed your config and it serves absolutely no purpose. Really. Nobody does this on production NTP servers -- and I am someone who has been doing UNIX administration for almost 20 years (and at my past job, NTP management was one of the things I had to deal with regularly). ntpd should never "fall back" to the "local system clock" as a time sync source, ever, and indicates misunderstanding of NTP in general.

    3b. DO NOT EVER START ntpd WITH THE -g FLAG. YOU DO NOT WANT THIS EVER. If the router's timecounter freaks out and begins to misbehave, deltas of +/-500ms will happen and are a firm indicator that something is wrong at the hardware level. Use of -g also has a major side effect that has bit many people on the Internet badly time and time again: if an NTP server begins screwing up (say, it's timecounter breaks!) and begins spitting out wrong/invalid times, use of -g will cause ntpd on your system to honour this time change -- which you do not want. Believe it or not this actually happened not too long ago (last year), where a public NTP server (badly configured at that) went haywire and began spitting out crazy timestamps to clients (something like in the year 2023), which clients using -g honoured, causing all sorts of software on those networks to break (imagine what would happen to a SQL INSERT/UPDATE statement that contained a timestamp...).

    4. Regarding your server list -- a good server list consists of two things: 1) geographic diversity and 2) diversity of stratums. I haven't verified #2, but consider using stratum 2 (or 3) servers and one stratum 1 server. Using a total of 5-8 servers is good, as long as they're diversified like I said. For example, for systems in California, I have used these for many years (note the comments too):

    Code:
    # Originally we used north-america.pool.ntp.org, but the list
    # of servers returned from that pool varied, and would regularly
    # include stratum 1 servers.  Therefore, we prefer a series of
    # stratum 2 servers, with a single stratum 1 as a stable base
    # comparison
    #
    # http://support.ntp.org/bin/view/Servers/StratumOneTimeServers
    # http://support.ntp.org/bin/view/Servers/StratumTwoTimeServers
    #
    # clock.isc.org          strat 1, California
    # ntp-1.cso.uiuc.edu     strat 2, Illinois
    # clock.psu.edu          strat 2, Pennsylvania
    # tick.jrc.us            strat 2, New Jersey
    # 0.us.pool.ntp.org      random
    #
    server clock.isc.org          iburst
    server ntp-1.cso.uiuc.edu     iburst
    server clock.psu.edu          iburst
    server tick.jrc.us            iburst
    server 0.us.pool.ntp.org      iburst
    
    And on 2 of my systems, this is what I end up with:

    Code:
    icarus$ ntpq -p
         remote           refid      st t when poll reach   delay   offset  jitter
    ==============================================================================
    *clock.isc.org   .GPS.            1 u  933 1024  377   13.788    3.007   0.613
    -ntp-1.gw.illino 128.174.38.133   2 u  748 1024  377   98.523    1.413   1.218
    -otc2.psu.edu    128.118.2.33     2 u  762 1024  377   90.674    5.745   0.388
    +tick.jrc.us     172.23.7.200     2 u  743 1024  377   87.715    4.784   0.697
    +ntp1.Housing.Be 128.32.206.55    3 u  768 1024  377   15.828    4.168   0.963
     
    omake$ ntpq -p
         remote           refid      st t when poll reach   delay   offset  jitter
    ==============================================================================
    *clock.isc.org   .GPS.            1 u 1000 1024  377   10.361   -1.313   0.388
    +ntp-1.gw.illino 128.174.38.133   2 u  877 1024  357   58.820   -0.857   0.497
    -otc2.psu.edu    128.118.2.33     2 u 1008 1024  377   74.541    2.965   0.139
    -tick.jrc.us     172.23.7.200     2 u  790 1024  377   83.979    4.867   0.204
    +tenthcircle.net 128.59.39.48     2 u  840 1024  377   53.817    1.539   0.387
    
    Quite good and reliable, but as you can see the tally codes differ based on past criteria/situations/scenarios -- each of these systems has very different network access, and the latter is actually a VPS (so its timecounter hardware is often questionable since it's effectively a VM).

    Footnote: you should always be wary of what Ubuntu forum people say ~95% of the time. These are generic "Google Search warriors" and usually do not have years of real-world professional experience. This is especially the case with NTP -- there is a lot of misinformation on the web about NTP, I'm sorry to say, and that's nobody's fault per se. But NTP is a fairly complex/tricky thing, as "simple" as it might seem on the outside.

    I will not be responding to this thread past this point.
     
  12. philess

    philess Networkin' Nut Member

    koitsu! go back to real life! NOW! :D
     
  13. HunterZ

    HunterZ LI Guru Member

    Thanks for the info, koitsu! I know you don't plan to respond, but maybe someone else will:

    Thanks, I wish somebody had explained this somewhere before. I did a ton of googling just to learn what I had.

    I'm pretty sure I always had iburst on at least the preferred server, and then added it to the rest out of desperation (after seeing some other examples of people using it on multiple servers).

    Thanks, that supports my intuition. I also finally came across another site that also said not to use it, but there are a ton more (apparently bad) examples that suggest that you *should* use it.

    Thanks, I'll remove that and modify things to run ntpdate after cifs mounting and before starting ntpd in order to seed the system clock.

    Is there any advantage to using ntpdate over ntpd -gq for the initial time set?

    I was going for low latency, in hopes that it would help ntpd evaluate the servers more quickly. I think I am currently using two NIST stratum 1 servers and two Google stratum 2 servers.

    I'll try reducing to a single stratum 1 server and then find a few more low-latency stratum 2's.

    Right, but unfortunately it's not easy to find better info most of the time. Us noobs have to make do with what we have ;)
     
  14. HunterZ

    HunterZ LI Guru Member

    I've updated my config, and thought I would share some details since I decided to use Entware.

    I have a SMB/Samba/CIFS share on my Ubuntu workstation that my router (Asus RT-N16 with toastman TomatoUSB) is already configured to mount. I installed Entware to a subdirectory of that path and loop-mounted it's opt subdirectory to the router's empty /opt directory, then installed ntpd and ntp-utils.

    I then set the "Execute When Mounted" option in the router's cifs mounting settings to run the following script from the cifs mount point:
    Code:
    #!/bin/sh
    logger "ONMOUNT: Mounting cifs1 as /opt"
    mount -o bind /cifs1/entware/opt /opt 2>&1 | logger
    
    # wait for mount to complete
    while [ ! -e /opt/sbin ]
    do
            logger "ONMOUNT: Waiting for /opt mount to become available"
            sleep 1
    done
    
    # do NTP stuff
    logger "ONMOUNT: /opt successfully mounted; synchronizing time via ntpdate"
    egrep '^server' /opt/etc/ntp.conf | awk '{print $2}' | xargs ntpdate 2>&1 | logger
    sleep 1
    
    logger "ONMOUNT: Launching ntpd"
    /opt/sbin/ntpd -c /opt/etc/ntp.conf 2>&1 | logger
    
    logger "ONMOUNT: Done"
    My line for the ntpdate command parses the servers from my ntp.conf and feeds them to ntpdate as parameters, so that it will set the time based on whatever ntpd is going to use.

    Here is my updated ntp.conf:
    Code:
    # /opt/etc/ntp.conf
    
    # driftfile required to save learned time-adjustments for servers
    driftfile /opt/var/lib/ntp/ntp.drift
    
    # logfile
    logfile "/opt/var/log/ntp.log"
    logconfig -allinfo -allevents -allstatistics -allstatus -clockinfo -clockevents -clockstatistics -clockstatus -clockall +syncinfo +syncevents +syncstatistics +syncstatus +syncall -sysinfo +sysevents -sysstatistics -sysstatus -sysall
    
    # interfaces
    #broadcast 192.168.1.255
    interface listen all
    interface drop vlan2
    
    # default access settings
    restrict default     kod nomodify notrap noquery nopeer
    restrict 127.0.0.1
    restrict ::1
    restrict 127.127.1.0 mask 255.255.255.255
    restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap
    
    # ntp servers to get time from
    server 131.107.13.100  iburst #time-nw.nist.gov,      s1, ??ms (10-14)
    server 71.19.224.242   iburst #ntp1.innoscale.net,    s2, 14ms (10-26)
    server 204.13.164.164  iburst #tick.mtnlion.com,      s2, 13ms (10-17)
    server 216.239.34.15   iburst #time2.google.com,      s2, 21ms (17-29)
    server 216.239.38.15   iburst #time4.google.com,      s2, 21ms (17-36)
    server 173.255.240.184 iburst #greenwix.netlobo.com,  s2, 35ms (32-45)
    server 208.201.242.2   iburst #enigma.wiredgoats.com, s2, 50ms (37-60)
    I had some us.pool.ntp.org pool servers in there for variety as well, but I decided to dump them after one of them pointed me to a server with a bad offset.
     
    Monk E. Boy likes this.
  15. Monk E. Boy

    Monk E. Boy Network Guru Member

    I'm a pretty big fan of the regional ntp.org server pools - 0.us.pool.ntp.org, for instance. Instead of getting a server from halfway around the world you can get one fairly close to you. Depending on the region you may end up with fewer spotty NTP servers that way too. The importance of having multiple servers though is so that a single result doesn't skew your NTP server, their odd result just gets averaged away.
     
  16. HunterZ

    HunterZ LI Guru Member

    After further research, I'm going to disagree with this point. The -g option only applies to the first synchronization, and is by all accounts specifically meant as a way to obsolete the ntpdate utility: http://www.ntp.org/ntpfaq/NTP-s-config.htm#AEN2901

    Quote from the above link:
     
  17. HunterZ

    HunterZ LI Guru Member

    Revisiting this thread because I recently updated my LAN's ntpd configuration and have a question.

    I currently have 4 devices on my LAN running ntpd and synchronizing with each other. One of them is my Tomato-powered Asus RT-N66U gateway, which also synchronizes with other NTP servers on the WAN. In other words, the gateway is the primary NTP server for the LAN, but its time comes from WAN sources.

    At any rate, I was thinking it would be nice to set up iptables to intercept NTP connections from LAN machines to WAN IP addresses (i.e., non-192.168.x.x). Philess gave an example in his original post in this thread, but I'm concerned that it may also intercept the NTP traffic between LAN machines, which is undesirable because I want them to all sync with each other and not just with the gateway.

    Does anyone know iptables-fu enough to be able to provide some pointers off the top of their head on how I can redirect port 123 connections with non-192.168.x.x destination addresses to 192.168.1.1, while leaving connections to 192.168.x.x destination addresses alone? Thanks!
     
  18. PeterT

    PeterT Network Guru Member

    Surely as long as the request is to a machine on the same IP subnet, the router (and the iptables) will not be involved at all.
     
    HunterZ likes this.
  19. HunterZ

    HunterZ LI Guru Member

    That helps, thanks.
     
  20. HunterZ

    HunterZ LI Guru Member

    It should probably also be mentioned that the given iptables command in the OP may be ineffective, as most indications are that NTP operates over UDP rather than TCP.

    Edit: To be more helpful, here is the same command fixed to instead redirect UDP:
    Code:
    # redirect NTP packets to router
    iptables -t nat -I PREROUTING -p udp --dport 123 -j DNAT --to 192.168.1.1
    I was able to verify that this works by using "ntpq -p some WAN NTP server IP" and seeing that it was my gateway that responded with its status.

    I was also assured by the fact that iptables shows 'ntp' instead of '123' for the port when I list the rule.
     
    Last edited: Apr 18, 2014
    Monk E. Boy, philess and koitsu like this.
  21. mstombs

    mstombs Network Guru Member

    Note the conf file in this thread only makes sense with the full Entware ntpd, the tiny binary supplied by ringer004 just serves up router time assuming it isn't 1970 (or the router has been running for 2 years?) - router web gui occasional time update is assumed to work OK with other mods.

    The local 127 fudge is useful in standalone systems without Internet access where all that is needed is a number of machines have the same time as the server and the server time (from CMOS battery) is a sensible choice! Without this a Ubuntu server will not serve time at all by xinetd BTDTGTTS!
     

Share This Page