uk pool problem - NTP

This is a discussion on uk pool problem - NTP ; Harlan Stenn wrote: > I *think* this will be handled by the upcoming config file rewrite code. > Actually, no it won't. This requires changing the internals of ntpd and not the config file rewrite. Danny > That should appear ...

+ Reply to Thread
Page 4 of 4 FirstFirst ... 2 3 4
Results 61 to 80 of 80

Thread: uk pool problem

  1. Re: uk pool problem

    Harlan Stenn wrote:
    > I *think* this will be handled by the upcoming config file rewrite code.
    >


    Actually, no it won't. This requires changing the internals of ntpd and
    not the config file rewrite.

    Danny

    > That should appear in ntp-dev in a month or so (just after 4.2.4 is out).
    >
    > H
    > --
    >>>> In article <1157168655.826350.117260@m73g2000cwd.googlegroups. com>, "Eugen COCA" writes:

    >
    > Eugen> I think there where opinions redarding this "bug" on this group, but
    > Eugen> I'll repeat: it will be very useful for the ntpd to try to reload the
    > Eugen> conf file from time to time and try to connect to servers listed
    > Eugen> there. Now, when ntpd starts, it will try to connect to the servers
    > Eugen> listed, in the order of their appearance in the ntp.conf file. If one
    > Eugen> server fail to respond it will be eliminated for further checks. This
    > Eugen> will be very usefull as on some systems (mostly on Windows machines).
    >

    _______________________________________________
    questions mailing list
    questions@lists.ntp.isc.org
    https://lists.ntp.isc.org/mailman/listinfo/questions


  2. Re: uk pool problem

    Per Hedeland wrote:
    > So is it deprecated or not? If it is, it would seem very strange to
    > consider enhancements (which was the point of my tongue-in-cheek
    > question earlier). Or are you saying that the *only* reason it is
    > deprecated is that there is no maintainer? That would certainly be
    > news...
    >
    > FWIW, I can see several objectively valid reasons to deprecate ntpdate,
    > and even a subjective one like "we don't like it" would have to be
    > considered valid - obviously no one can *demand* that you support some
    > particular piece of software (at least not without handing over money).
    >


    No, my list of problems with ntpdate starts with IPv6 support and
    continues with major problems with the ability to maintain the code.
    Officially we want to get rid of it and replace it with something like
    the sntp which is more maintainable. I'd rather spend my time right now
    cleaning up ntpd and ntpq. We'd also like to get rid of ntpdc but that
    requires that ntpq supports some queries that it cannot currently
    handle. ntpdc uses private mode 7 packets which is much more difficult
    to maintain while ntpq uses mode 6 packets.

    Ultimately it is our goal to consolidate the software as much as
    possible. We need to examine peoples usage of ntpdate and see if we
    can't come up with something that will satisfy people needs. That's what
    holding up actually getting it out of the distribution. We can't get rid
    of it without having some alternative available.

    Danny
    _______________________________________________
    questions mailing list
    questions@lists.ntp.isc.org
    https://lists.ntp.isc.org/mailman/listinfo/questions


  3. Re: uk pool problem

    >>> In article <44FA4A86.7080905@ntp.isc.org>, mayer@ntp.isc.org (Danny Mayer) writes:

    Danny> We'd also like to get rid of
    Danny> ntpdc but that requires that ntpq supports some queries that it
    Danny> cannot currently handle. ntpdc uses private mode 7 packets which is
    Danny> much more difficult to maintain while ntpq uses mode 6 packets.

    ntpq does standard mode 6 queries and should be portable across versions and
    implementations.

    ntpdc uses vendor-specific mode 7 queries.

    There is no way to bring up new associations with mode 6 packets.

    This functionality *can* be done with a mode 7 packet.

    I would be happy to see ntpdc simplified (ie, get rid of anything that can
    be done with ntpq), but I can also see the value in having a single program
    that knows when to use a mode 6 packet and when to use a mode 7 packet.

    After all, it is most convenient to see the current peer list when adding or
    removing associations.

    H

  4. Re: uk pool problem

    In article Harlan Stenn
    writes:
    >
    >The last time I checked, both ntpdate and sntp will believe the first answer
    >they get back. I bet this is not *strictly* true, but I recall it was
    >good enough.


    Well, either you never checked ntpdate, or you have forgotten what you
    found - the first paragraph of the "Description" section in the html-man
    page says what it does (it was already quoted in this thread btw), and
    it's a long shot from "believe the first answer" - ntpdate never did
    that.

    Sntp on the other hand does indeed seem to do just that, which makes it
    basically useless in my opinion. And if you give it multiple servers to
    query, where the first one happens not to respond, it will stupidly keep
    on trying it 5 times and then give up, without ever attempting the
    others - worse than useless. (This was tested with 4.2.2p4-RC2.)

    --Per Hedeland
    per@hedeland.org

  5. Re: uk pool problem

    >>> In article , per@hedeland.org (Per Hedeland) writes:

    Per> In article Harlan Stenn
    Per> writes:
    >> The last time I checked, both ntpdate and sntp will believe the first
    >> answer they get back. I bet this is not *strictly* true, but I recall it
    >> was good enough.


    Per> Well, either you never checked ntpdate, or you have forgotten what you
    Per> found.

    I have years like that.

    Per> Sntp on the other hand does indeed seem to do just that, which makes it
    Per> basically useless in my opinion. And if you give it multiple servers to
    Per> query, where the first one happens not to respond, it will stupidly
    Per> keep on trying it 5 times and then give up, without ever attempting the
    Per> others - worse than useless. (This was tested with 4.2.2p4-RC2.)

    This is a bug - please open an issue on this.

    H

  6. Re: uk pool problem

    Harlan,

    Sachin Kamboj's new code can use ntpq for anything in the configuration
    file. Sachin has moved on to another job and his code, although working,
    needs test and fix. It first needs to survive the recent rewrite of the
    command line parsing, which has changed since he first merged with the
    distribution. A volunteer could have a lot of fun with the new code,
    which by the way has explicit support for the pool function plus a lot
    of other goodies folks have been asking for.

    I would suggest to a volunteer that a diff between Sachin's code and the
    base code he has been working on, then apply the diff to the current
    code and fix what breaks.

    By the way, the new code parses exactly the same syntax and semantics as
    the present configuration file, including non-reserved words. However,
    it's all syntax-driven and configuration commands can be issued anytime
    via ntpq. And yes, it is MD5 authenticated.

    Dave

    Harlan Stenn wrote:
    >>>>In article <44FA4A86.7080905@ntp.isc.org>, mayer@ntp.isc.org (Danny Mayer) writes:

    >
    >
    > Danny> We'd also like to get rid of
    > Danny> ntpdc but that requires that ntpq supports some queries that it
    > Danny> cannot currently handle. ntpdc uses private mode 7 packets which is
    > Danny> much more difficult to maintain while ntpq uses mode 6 packets.
    >
    > ntpq does standard mode 6 queries and should be portable across versions and
    > implementations.
    >
    > ntpdc uses vendor-specific mode 7 queries.
    >
    > There is no way to bring up new associations with mode 6 packets.
    >
    > This functionality *can* be done with a mode 7 packet.
    >
    > I would be happy to see ntpdc simplified (ie, get rid of anything that can
    > be done with ntpq), but I can also see the value in having a single program
    > that knows when to use a mode 6 packet and when to use a mode 7 packet.
    >
    > After all, it is most convenient to see the current peer list when adding or
    > removing associations.
    >
    > H


  7. Re: uk pool problem

    Harlan,

    Harlan Stenn wrote:
    > If somebody expressed an interest in fixing this problem, I'd be inclined
    > to ask them if they were interested in fixing the other problems with
    > ntpdate.
    >
    > If they said "yes" then we'd have a maintainer for ntpdate and this would
    > not be an issue.


    As already mentioned in another article in this thread, I also find ntpdate
    deprecated for its initial purpose, just to set the initial system time
    before ntpd is started.

    On the other hand ntpdate is really a great tool to run some quick tests
    against an NTP server. It also runs under Windows (which sntp does not
    yet), and I'm not aware of any major problems with ntpdate.

    So maybe it should just be renamed to somthing like ntpping or so, as Ronan
    has proposed, and it should just be taken as a test tool.

    Heiko and I have already supplied some patches for ntpdate in the past which
    fixed some problems under Windows, so I'd be happy if you pick me up as
    maintainer for ntpdate.

    Martin
    --
    Martin Burnicki

    Meinberg Funkuhren
    Bad Pyrmont
    Germany

  8. Re: uk pool problem

    In article <44FA1F44.6080305@ntp.isc.org>,
    mayer@ntp.isc.org (Danny Mayer) wrote:

    > As I recall, the protocol requires that the source port be 123 but the


    There is one mention of 123 in RFC 1305, but several places where it
    says that the response is sent to the actual source port (RFC 1305 is
    an atypical RFC, being written as an academic research paper, and that
    sort of detail seems to be peripheral to the main, maths, content).

    > ntpd reference server implementation does not enforce that. I don't


    For several years now, it has been almost essential that it does respond
    to client requests from other ports, because of network address translation.


  9. Re: uk pool problem

    David Woolley wrote:
    >
    > For several years now, it has been almost essential that it does respond
    > to client requests from other ports, because of network address translation.
    >


    I hope NAT does not REQUIRE different port numbers.

    Danny
    _______________________________________________
    questions mailing list
    questions@lists.ntp.isc.org
    https://lists.ntp.isc.org/mailman/listinfo/questions


  10. Re: uk pool problem

    Danny Mayer wrote:
    > David Woolley wrote:
    >
    >>For several years now, it has been almost essential that it does respond
    >>to client requests from other ports, because of network address translation.
    >>

    >
    >
    > I hope NAT does not REQUIRE different port numbers.
    >
    > Danny
    > _______________________________________________
    > questions mailing list
    > questions@lists.ntp.isc.org
    > https://lists.ntp.isc.org/mailman/listinfo/questions
    >


    NAT maps public address + port to (RFC 1918) private address + port. So
    a system with an RFC 1918 address 192.168.1.20 will send an NTP packet
    from port 123 and the NAT router will map it to 68.44.203.111 port
    xxxxx. When you reply to 68.44.203.111 port xxxxx the router knows to
    map it to 192.168.1.20 port 123.

    So yes, in a sense, NAT does require "different" port numbers. Speaking
    as one of the many behind a NAT router/firewall it all seems to work,
    however improbable it might seem.

    If IP V6 ever gets off the ground, there will be enough addresses to go
    around and this subterfuge will no longer be necessary. IP V6 does not
    appear to be going anywhere in a hurry though! About three years ago,
    my then boss (manager of network services) saw me answer "Yes" to the IP
    V6 support question asked by Solaris Installation and screamed "No!".
    I had to explain to him that the box would still speak IP V4 to anyone
    who wanted to talk to it using V4 and could speak IP V6 to anyone who
    wanted to use it. My little LinkSys Router hasn't a clue about IP V6.
    Comcast is IP V4. IP V6 may be coming but it's by no means here yet!!!

  11. Re: uk pool problem


    "Richard B. Gilbert" writes:
    > If IP V6 ever gets off the ground, there will be enough addresses to
    > go around and this subterfuge will no longer be necessary.


    This assumes the immediate problem is the actual IP shortage and not
    the ISP's holding IP's hostage for extra fees. Bulk IP addresses can
    still be bought from ARIN for a few pennies per year per IP.

    http://www.arin.net/billing/fee_schedule.html

    > IP V6 does not appear to be going anywhere in a hurry though! About
    > three years ago, my then boss (manager of network services) saw me
    > answer "Yes" to the IP V6 support question asked by Solaris
    > Installation and screamed "No!". I had to explain to him that the
    > box would still speak IP V4 to anyone who wanted to talk to it using
    > V4 and could speak IP V6 to anyone who wanted to use it. My little
    > LinkSys Router hasn't a clue about IP V6. Comcast is IP V4. IP V6
    > may be coming but it's by no means here yet!!!


    Get a better ISP and better firmware for your router. ;-)

    Sonic.net (SF Bay Area) gives you a v6 allocation along with a handful
    of v4 IP's in the upgraded plans.

    Your Linksys can probably have openwrt loaded on it. My wrt-54g
    happily routes v6 and even sets its time from my ntp server instead of
    pestering some network server it has not permission to pester (OB:
    ntp).

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

  12. Re: uk pool problem

    Wolfgang S. Rupprecht wrote:

    > "Richard B. Gilbert" writes:
    >
    >>If IP V6 ever gets off the ground, there will be enough addresses to
    >>go around and this subterfuge will no longer be necessary.

    >
    >
    > This assumes the immediate problem is the actual IP shortage and not
    > the ISP's holding IP's hostage for extra fees. Bulk IP addresses can
    > still be bought from ARIN for a few pennies per year per IP.
    >
    > http://www.arin.net/billing/fee_schedule.html
    >
    >
    >>IP V6 does not appear to be going anywhere in a hurry though! About
    >>three years ago, my then boss (manager of network services) saw me
    >>answer "Yes" to the IP V6 support question asked by Solaris
    >>Installation and screamed "No!". I had to explain to him that the
    >>box would still speak IP V4 to anyone who wanted to talk to it using
    >>V4 and could speak IP V6 to anyone who wanted to use it. My little
    >>LinkSys Router hasn't a clue about IP V6. Comcast is IP V4. IP V6
    >>may be coming but it's by no means here yet!!!

    >
    >
    > Get a better ISP and better firmware for your router. ;-)


    My choices are Comcast (broadband cable) and Verizon (ADSL). Other than
    those two there are no real choices in this area. If I thought I could
    afford $700/month I'd get T1 service. If I hit the lottery for a couple
    of million $ I just might do that.

    I'm hoping to find a Cisco router; e.g. Cisco 91 or 831 at a price I can
    afford; I don't think they support IP V6 either but at least they would
    have a full implementation of the DHCP protocol.



  13. Re: uk pool problem

    In article "Richard
    B. Gilbert" writes:
    >Danny Mayer wrote:
    >> David Woolley wrote:
    >>
    >>>For several years now, it has been almost essential that it does respond
    >>>to client requests from other ports, because of network address translation.

    >>
    >> I hope NAT does not REQUIRE different port numbers.

    >
    >NAT maps public address + port to (RFC 1918) private address + port. So
    >a system with an RFC 1918 address 192.168.1.20 will send an NTP packet
    >from port 123 and the NAT router will map it to 68.44.203.111 port
    >xxxxx. When you reply to 68.44.203.111 port xxxxx the router knows to
    >map it to 192.168.1.20 port 123.
    >
    >So yes, in a sense, NAT does require "different" port numbers.


    Well, it doesn't require *different* port numbers (not sure what you
    mean with the quotes), i.e. it's perfectly possible (and generally
    desirable IMHO) for xxxxx to be 123 - as long as there is only one
    internal address sending from 123. YMMV depending on the capabilities of
    your NAT device of course, but it's certainly technically possible, and
    trivial to do with something like ipfilter on a *nix box.

    --Per Hedeland
    per@hedeland.org

  14. Re: uk pool problem

    Per Hedeland wrote:
    > In article "Richard
    > B. Gilbert" writes:
    >
    >>Danny Mayer wrote:
    >>
    >>>David Woolley wrote:
    >>>
    >>>
    >>>>For several years now, it has been almost essential that it does respond
    >>>>to client requests from other ports, because of network address translation.
    >>>
    >>>I hope NAT does not REQUIRE different port numbers.

    >>
    >>NAT maps public address + port to (RFC 1918) private address + port. So
    >>a system with an RFC 1918 address 192.168.1.20 will send an NTP packet

    >
    >>from port 123 and the NAT router will map it to 68.44.203.111 port

    >
    >>xxxxx. When you reply to 68.44.203.111 port xxxxx the router knows to
    >>map it to 192.168.1.20 port 123.
    >>
    >>So yes, in a sense, NAT does require "different" port numbers.

    >
    >
    > Well, it doesn't require *different* port numbers (not sure what you
    > mean with the quotes), i.e. it's perfectly possible (and generally
    > desirable IMHO) for xxxxx to be 123 - as long as there is only one
    > internal address sending from 123. YMMV depending on the capabilities of
    > your NAT device of course, but it's certainly technically possible, and
    > trivial to do with something like ipfilter on a *nix box.
    >
    > --Per Hedeland
    > per@hedeland.org


    If there is only one system using NTP through the router/firewall, you
    are correct; port 123 can and probably will be used. If you have more
    than one then the others will be mapped to some other port. This only
    applies to NAT; if you have routable addresses and a real router, there
    is no need to change or map the original port numbers.

  15. Re: uk pool problem

    David,

    Academic or not, the source port was specified as 123 in order to make
    symmetric modes (active and passive) work. The operative NTPv4
    specification says the source port in other modes can be anything.

    Dave

    David Woolley wrote:
    > In article <44FA1F44.6080305@ntp.isc.org>,
    > mayer@ntp.isc.org (Danny Mayer) wrote:
    >
    >
    >>As I recall, the protocol requires that the source port be 123 but the

    >
    >
    > There is one mention of 123 in RFC 1305, but several places where it
    > says that the response is sent to the actual source port (RFC 1305 is
    > an atypical RFC, being written as an academic research paper, and that
    > sort of detail seems to be peripheral to the main, maths, content).
    >
    >
    >>ntpd reference server implementation does not enforce that. I don't

    >
    >
    > For several years now, it has been almost essential that it does respond
    > to client requests from other ports, because of network address translation.
    >


  16. Re: uk pool problem

    Hello Martin,

    On Tuesday, September 5, 2006 at 12:53:45 +0200, Martin Burnicki wrote:

    > So maybe [ntpdate] should just be renamed to somthing like ntpping or
    > so, as Ronan has proposed, and it should just be taken as a test tool.


    Renaming such a widely used tool is likely to confuse users and scripts.


    Serge.
    --
    Serge point Bets arobase laposte point net

  17. Re: uk pool problem

    In article <44FEB941.7010105@comcast.net> "Richard B. Gilbert"
    writes:
    >Per Hedeland wrote:
    >> In article "Richard
    >> B. Gilbert" writes:
    >>
    >>>Danny Mayer wrote:
    >>>
    >>>>David Woolley wrote:
    >>>>
    >>>>
    >>>>>For several years now, it has been almost essential that it does respond
    >>>>>to client requests from other ports, because of network address translation.
    >>>>
    >>>>I hope NAT does not REQUIRE different port numbers.
    >>>
    >>>NAT maps public address + port to (RFC 1918) private address + port. So
    >>>a system with an RFC 1918 address 192.168.1.20 will send an NTP packet

    >>
    >>>from port 123 and the NAT router will map it to 68.44.203.111 port

    >>
    >>>xxxxx. When you reply to 68.44.203.111 port xxxxx the router knows to
    >>>map it to 192.168.1.20 port 123.
    >>>
    >>>So yes, in a sense, NAT does require "different" port numbers.

    >>
    >>
    >> Well, it doesn't require *different* port numbers (not sure what you
    >> mean with the quotes), i.e. it's perfectly possible (and generally
    >> desirable IMHO) for xxxxx to be 123 - as long as there is only one
    >> internal address sending from 123. YMMV depending on the capabilities of
    >> your NAT device of course, but it's certainly technically possible, and
    >> trivial to do with something like ipfilter on a *nix box.

    >
    >If there is only one system using NTP through the router/firewall, you
    >are correct; port 123 can and probably will be used.


    Yes, that's what I think I said:-) ("as long as...").

    --Per Hedeland
    per@hedeland.org

  18. Re: uk pool problem

    >>> In article , Serge Bets writes:
    >> So maybe [ntpdate] should just be renamed to somthing like ntpping or so,
    >> as Ronan has proposed, and it should just be taken as a test tool.


    Serge> Renaming such a widely used tool is likely to confuse users and
    Serge> scripts.

    I think you are missing the point.

    At the moment, all I am seeing is that some people want to use some of the
    functionality that ntpdate provides (apparently -u) because that is a
    sometimes useful way to see if there is a firewall in the way.

    As I understand it, ntpdate is being deprecated because it has bugs. In
    particular, the selection code is both out of date and buggy.

    If some of ntpdate remains, it will, in all likelihood, not be able to set
    the time. Therefore, it should not have the same name as it did before, as
    any existing scripts will rightly expect a program called ntpdate to set the
    time.

    I have already said that there will probably be a shell script that can
    stand in for ntpdate.

    So, to summarize what I have said before:

    - If anybody thinks there are bugs in ntpd or sntp they should open
    bug reports at http://ntp.isc.org/bugs
    - If anybody thinks of potential enhancements to ntpd or sntp they should
    open "enh" reports at http://ntp.isc.org/bugs
    - If people want to discuss/track thoughts on the deprecation of ntpdate,
    until these thoughts become bugs or enhancements (see the previous 2
    bits), people can discuss these wherever they like and I would prefer
    to see at least summaries of the discussion at:

    http://ntp.isc.org/Dev/DeprecatingNtpdate

    H

  19. Re: uk pool problem

    Per Hedeland wrote:
    > In article <44FEB941.7010105@comcast.net> "Richard B. Gilbert"
    > writes:
    >
    >>Per Hedeland wrote:
    >>
    >>>In article "Richard
    >>>B. Gilbert" writes:
    >>>
    >>>
    >>>>Danny Mayer wrote:
    >>>>
    >>>>
    >>>>>David Woolley wrote:
    >>>>>
    >>>>>
    >>>>>
    >>>>>>For several years now, it has been almost essential that it does respond
    >>>>>>to client requests from other ports, because of network address translation.
    >>>>>
    >>>>>I hope NAT does not REQUIRE different port numbers.
    >>>>
    >>>>NAT maps public address + port to (RFC 1918) private address + port. So
    >>>>a system with an RFC 1918 address 192.168.1.20 will send an NTP packet
    >>>
    >>>>from port 123 and the NAT router will map it to 68.44.203.111 port
    >>>
    >>>
    >>>>xxxxx. When you reply to 68.44.203.111 port xxxxx the router knows to
    >>>>map it to 192.168.1.20 port 123.
    >>>>
    >>>>So yes, in a sense, NAT does require "different" port numbers.
    >>>
    >>>
    >>>Well, it doesn't require *different* port numbers (not sure what you
    >>>mean with the quotes), i.e. it's perfectly possible (and generally
    >>>desirable IMHO) for xxxxx to be 123 - as long as there is only one
    >>>internal address sending from 123. YMMV depending on the capabilities of
    >>>your NAT device of course, but it's certainly technically possible, and
    >>>trivial to do with something like ipfilter on a *nix box.

    >>
    >>If there is only one system using NTP through the router/firewall, you
    >>are correct; port 123 can and probably will be used.

    >
    >
    > Yes, that's what I think I said:-) ("as long as...").
    >
    > --Per Hedeland
    > per@hedeland.org


    I think I stated it badly. Try this. If there is more than one system
    using NTP through a NAT router only one of them can use port 123
    externally; the router must map the second user to some port other than 123.

  20. Re: uk pool problem

    In article "Richard
    B. Gilbert" writes:
    >Per Hedeland wrote:
    >> In article <44FEB941.7010105@comcast.net> "Richard B. Gilbert"
    >> writes:
    >>
    >>>Per Hedeland wrote:
    >>>
    >>>>In article "Richard
    >>>>B. Gilbert" writes:
    >>>>
    >>>>
    >>>>>Danny Mayer wrote:
    >>>>>
    >>>>>
    >>>>>>David Woolley wrote:
    >>>>>>
    >>>>>>
    >>>>>>
    >>>>>>>For several years now, it has been almost essential that it does respond
    >>>>>>>to client requests from other ports, because of network address

    >translation.
    >>>>>>
    >>>>>>I hope NAT does not REQUIRE different port numbers.
    >>>>>
    >>>>>NAT maps public address + port to (RFC 1918) private address + port. So
    >>>>>a system with an RFC 1918 address 192.168.1.20 will send an NTP packet
    >>>>
    >>>>>from port 123 and the NAT router will map it to 68.44.203.111 port
    >>>>
    >>>>
    >>>>>xxxxx. When you reply to 68.44.203.111 port xxxxx the router knows to
    >>>>>map it to 192.168.1.20 port 123.
    >>>>>
    >>>>>So yes, in a sense, NAT does require "different" port numbers.
    >>>>
    >>>>
    >>>>Well, it doesn't require *different* port numbers (not sure what you
    >>>>mean with the quotes), i.e. it's perfectly possible (and generally
    >>>>desirable IMHO) for xxxxx to be 123 - as long as there is only one
    >>>>internal address sending from 123. YMMV depending on the capabilities of
    >>>>your NAT device of course, but it's certainly technically possible, and
    >>>>trivial to do with something like ipfilter on a *nix box.
    >>>
    >>>If there is only one system using NTP through the router/firewall, you
    >>>are correct; port 123 can and probably will be used.

    >>
    >>
    >> Yes, that's what I think I said:-) ("as long as...").


    >I think I stated it badly. Try this. If there is more than one system
    >using NTP through a NAT router only one of them can use port 123
    >externally; the router must map the second user to some port other than 123.


    I still think that's what I said (though maybe *I* worded it badly), but
    please let's end this thread now...

    --Per Hedeland
    per@hedeland.org


+ Reply to Thread
Page 4 of 4 FirstFirst ... 2 3 4