mayer at gis.net
Fri Jun 10 06:24:19 PDT 2005
----- Original Message Follows -----
> Hi John,
> >You might still need a little more info if you start the "session",
> >iow you don't react to a packet. Also reacting to broadcast and
> >multicast packets will need more interface info.
The specific problem with *cast packets is that you have to decide
first which interface to bind to listen for *cast packets. Also
you need to decide which interface to go out on to send packets
to the servers listed in your configuration file.
> Ok, given that condition I'd say that finding out the interface
> whenever you want to start a session would be the best idea. Very few
> people use the public key functions these days and I think it's not
> necessary to try to find out something for each and every server line
> which is only used by a small percentage afterwards.
Don't even go there. You may think that this is true, but the
requirements are such that we won't make any changes that violate
the IETF RFC's and prevent usage of autokey. That's not even
up for discussion. Interface lookups almost always happen just
at the start.
> My specific interest in that started when a customer of us who is
> still using NT4-SP6 servers (don't ask ...) found out that in recent
> versions of NTP this mechanism seems not to work anymore under NT.
> See https://ntp.isc.org/bugs/show_bug.cgi?id=450 ...
> Maybe it would be OK to simply skip the interface detection for every
> association which does not need public key crypto magic.
No, the chances are that the system only has one IPv4 interface/
IP address outside of the wildcard interface and the loopback
interface. In that case you can shortcut the search and just return
that one interface. It's easy enough for IPv4. It gets more complicated
with IPv6 since you always have multiple addresses to deal with.
So try that, NT doesn't support IPv6 so at least we will have a fix
for the majority of current systems.
> Kind regards,
More information about the hackers