|Re: [chrony-users] firewalling chrony|
[ Thread Index |
| More chrony.tuxfamily.org/chrony-users Archives
On Thu, 27 Feb 2014, Leo Baltus wrote:
Op 11/02/2014 om 09:31:36 +0100, schreef Leo Baltus:
Op 10/02/2014 om 12:39:19 +0100, schreef Miroslav Lichvar:
On Fri, Feb 07, 2014 at 06:30:52PM +0100, Leo Baltus wrote:
It seems that chronyd, when acting as a client uses both srcport 1024
through 65535 as well as port 123 to query external ntp-servers.
The port above 1024 is used with the initstepslew option.
It makes discriminating between server traffic and client traffic
hard as both use packets with dstport=123 and srcport=123
I think ntpd does this as well, so I wonder is this mandated by
I think it's not required by NTP specification to use source port 123
for client requests.
If not how can I tell chronyd not to use srcport=123 when querying
external servers while still serve ntp on port 123 to its clients?
With the current code you can't. There is only one socket per address
family used for all NTP networking. You could inspect the packets in
the firewall to see which mode they are, or you could run two
instances of chronyd, one configured as a client and the other as a
server with "local stratum" enabled.
Interesting suggestion, thanks.
That seems to work nicely, thanks again for the suggestion.
One thing though, when running two instances the 'local stratum'
instance no longer get upstream information like leap seconds, how
bad is that?
It means that once every couple of years or so, on Jan1 or Jul 1 the client system
will suddenly be out by one second and will take a while to get rid of that
time offset ( most likely a few maxpoll intervals).
William G. Unruh | Canadian Institute for| Tel: +1(604)822-3273
Physics&Astronomy | Advanced Research | Fax: +1(604)822-5324
UBC, Vancouver,BC | Program in Cosmology | unruh@xxxxxxxxxxxxxx
Canada V6T 1Z1 | and Gravity | www.theory.physics.ubc.ca/
To unsubscribe email chrony-users-request@xxxxxxxxxxxxxxxxxxxx
with "unsubscribe" in the subject.
For help email chrony-users-request@xxxxxxxxxxxxxxxxxxxx
with "help" in the subject.
Trouble? Email listmaster@xxxxxxxxxxxxxxxxxxxx.