Trouble creating symmetric connection

I have trouble getting two ntp servers to peer with each other.
What I do is first

ntpdc -c 'restrict B.B.B.B 255.255.255.255 nomodify notrap' A.A.A.A
ntpdc -c 'restrict A.A.A.A 255.255.255.255 nomodify notrap' B.B.B.B

after which ntpdc -creslist echoes back appropriate restrict lines
with the only flags being nomodify and notrap - so I'm reasonably sure
that the servers do allow each others as peers, and that my remote
configuration commands are being carried out. Now:

ntpdc -c 'addpeer B.B.B.B' A.A.A.A

and wait a few minutes for packets to be exchanged; then

ntpdc -c peers A.A.A.A
ntpdc -c peers B.B.B.B

After this A.A.A.A does list B.B.B.B as an association in
'symmetric-active' mode, and it appears to get nontrivial time
variables over this association, som B.B.B.B must be answering.

However, I had expected that B.B.B.B would list A.A.A.A as an
association in 'symmetric-passive' mode, but it doesn't. Shouldn't it?
The peer listing of B.B.B.B does not mention A.A.A.A at all.

Furthermore, if I unconfigure all of the servers the B.B.B.B used
to get time from, it will eventually revert to its undisciplined
local clock at stratum 13, rather than use the stratum-4-or-so time
it could have gotten from A.A.A.A. So it's actually not recognizing
A.A.A.A as a peer; it is not just the ntpdc listing that is buggy.

Both servers run Debian 'sarge' with its default ntp-server package.

I suspect I'm missing something really basic, but what? I have read
the ntp documentation and googled many possible search-term
combinations to no avail.

--
Henning Makholm "Det er jo svært at vide noget når man ikke ved det, ikke?"

Henning Makholm <henning@makholm.net> wrote:
[color=blue]
> I have trouble getting two ntp servers to peer with each other.[/color]

[snip]
[color=blue]
> ntpdc -c 'addpeer B.B.B.B' A.A.A.A
>
> and wait a few minutes for packets to be exchanged; then
>
> ntpdc -c peers A.A.A.A
> ntpdc -c peers B.B.B.B
>
> After this A.A.A.A does list B.B.B.B as an association in
> 'symmetric-active' mode, and it appears to get nontrivial time
> variables over this association, som B.B.B.B must be answering.
>
> However, I had expected that B.B.B.B would list A.A.A.A as an
> association in 'symmetric-passive' mode, but it doesn't. Shouldn't it?[/color]

Only if you have authentication turned off, which is inadvisable.
Better to make both symmetric-active:

ntpdc -c 'addpeer B.B.B.B' A.A.A.A
ntpdc -c 'addpeer A.A.A.A' B.B.B.B

[more snip]

--
Ronan Flood <usenet@umbral.org.uk>

Scripsit Ronan Flood <usenet@umbral.org.uk>[color=blue]
> Henning Makholm <henning@makholm.net> wrote:[/color]
[color=blue][color=green]
>> However, I had expected that B.B.B.B would list A.A.A.A as an
>> association in 'symmetric-passive' mode, but it doesn't. Shouldn't it?[/color][/color]
[color=blue]
> Only if you have authentication turned off, which is inadvisable.
> Better to make both symmetric-active:[/color]
[color=blue]
> ntpdc -c 'addpeer B.B.B.B' A.A.A.A
> ntpdc -c 'addpeer A.A.A.A' B.B.B.B[/color]

I though the point of "addpeer" was that a single association could
transfer time in any direction (and I still have trouble reading
the documentation any other way). If I need to make two associations,
then why not just do

ntpdc -c 'addserver B.B.B.B' A.A.A.A
ntpcd -c 'addserver A.A.A.A' B.B.B.B

i.e. what is the difference between a client connection and a peer
connection if both are unidirectional?


Hm, on further experimentation it does work in two directions with
authentified messages. I tried this before without success, but it
works after I switched to a 'M' (md4) key instead of an 'A' (des) key
with the same password for the authentication. Are there known bugs
in the DES authentication code?

--
Henning Makholm "Jeg køber intet af Sulla, og selv om uordenen griber
planmæssigt om sig, så er vi endnu ikke nået dertil hvor
ordentlige mennesker kan tillade sig at stjæle slaver fra
hinanden. Så er det ligegyldigt, hvor stærke, politiske modstandere vi er."

>>> In article <87y7m8ap7g.fsf@kreon.lan.henning.makholm.net>, Henning Makholm <henning@makholm.net> writes:

Henning> Hm, on further experimentation it does work in two directions with
Henning> authentified messages. I tried this before without success, but it
Henning> works after I switched to a 'M' (md4) key instead of an 'A' (des)
Henning> key with the same password for the authentication. Are there known
Henning> bugs in the DES authentication code?

No, but md5 code is freely available and exportable, while DES is not.

I'd have to dig into the code to see if DES is still supported for private
key usage (ntp.keys file).

H

Henning,

'M' stands for MD5; the DES crypto code is no longer in the
distribution. I haven't tried using a DES key with the MD5 crypto code.
Goshdarn it might even work sorta, but not a good idea.

Think of peer (symmetric mode) as each machine functioning
simultaneously as a client and a server for the other machine. Time
flows from the machine at the lower stratum to the other machine.
Usually, both peers are clients of different lower stratum servers and
usually operate at the same stratum, so time doesn't flow between them.
However, if a lower stratum server fails, then the orphan peer switches
to the other peer.

Dave

Henning Makholm wrote:
[color=blue]
> Scripsit Ronan Flood <usenet@umbral.org.uk>
>[color=green]
>>Henning Makholm <henning@makholm.net> wrote:[/color]
>
>[color=green][color=darkred]
>>>However, I had expected that B.B.B.B would list A.A.A.A as an
>>>association in 'symmetric-passive' mode, but it doesn't. Shouldn't it?[/color][/color]
>
>[color=green]
>>Only if you have authentication turned off, which is inadvisable.
>>Better to make both symmetric-active:[/color]
>
>[color=green]
>> ntpdc -c 'addpeer B.B.B.B' A.A.A.A
>> ntpdc -c 'addpeer A.A.A.A' B.B.B.B[/color]
>
>
> I though the point of "addpeer" was that a single association could
> transfer time in any direction (and I still have trouble reading
> the documentation any other way). If I need to make two associations,
> then why not just do
>
> ntpdc -c 'addserver B.B.B.B' A.A.A.A
> ntpcd -c 'addserver A.A.A.A' B.B.B.B
>
> i.e. what is the difference between a client connection and a peer
> connection if both are unidirectional?
>
>
> Hm, on further experimentation it does work in two directions with
> authentified messages. I tried this before without success, but it
> works after I switched to a 'M' (md4) key instead of an 'A' (des) key
> with the same password for the authentication. Are there known bugs
> in the DES authentication code?
>[/color]

Henning Makholm <henning@makholm.net> wrote:
[color=blue][color=green]
> > Better to make both symmetric-active:[/color]
>[color=green]
> > ntpdc -c 'addpeer B.B.B.B' A.A.A.A
> > ntpdc -c 'addpeer A.A.A.A' B.B.B.B[/color]
>
> I though the point of "addpeer" was that a single association could
> transfer time in any direction (and I still have trouble reading
> the documentation any other way). If I need to make two associations,
> then why not just do
>
> ntpdc -c 'addserver B.B.B.B' A.A.A.A
> ntpcd -c 'addserver A.A.A.A' B.B.B.B
>
> i.e. what is the difference between a client connection and a peer
> connection if both are unidirectional?[/color]

I've nothing to add to Dave Mills' answer; I don't know what real
difference there is, but at least it makes it obvious what you
expect to happen, and both ends are clear about the relationship.

Side comment: why are you doing all the config via ntpdc rather
than putting it into the ntp.conf file?

--
Ronan Flood <usenet@umbral.org.uk>

Ronan Flood wrote:[color=blue]
> Henning Makholm <henning@makholm.net> wrote:
>
>[color=green][color=darkred]
>>>Better to make both symmetric-active:[/color]
>>[color=darkred]
>>> ntpdc -c 'addpeer B.B.B.B' A.A.A.A
>>> ntpdc -c 'addpeer A.A.A.A' B.B.B.B[/color]
>>
>>I though the point of "addpeer" was that a single association could
>>transfer time in any direction (and I still have trouble reading
>>the documentation any other way). If I need to make two associations,
>>then why not just do
>>
>> ntpdc -c 'addserver B.B.B.B' A.A.A.A
>> ntpcd -c 'addserver A.A.A.A' B.B.B.B
>>[/color][/color]
<snip>[color=blue]
>
> Side comment: why are you doing all the config via ntpdc rather
> than putting it into the ntp.conf file?
>[/color]

Perhaps because he does not want to shut down ntpd and restart. Why do
even a warm restart if you don't have to?

Scripsit [email]mills@udel.edu[/email]
[color=blue]
> 'M' stands for MD5;[/color]

Of course. Typo on my part.
[color=blue]
> the DES crypto code is no longer in the distribution.[/color]

Whoops. I worked from the NTP FAQ which uses DES keys freely in
section 6.2.2, and only mentions the absence of DES as an aside
in 6.1.3.3 (which is not even where one would expect to find
important caveats like that).
[color=blue]
> Think of peer (symmetric mode) as each machine functioning
> simultaneously as a client and a server for the other machine. Time
> flows from the machine at the lower stratum to the other
> machine.[/color]

I gathered at much from the docmentation, but it was not clear to me
that it only works as described when the communication is
authentified. On reflection I can see that it does make excellent
sense to require authentification here, but it would have helped me
if, say, the description of the 'nopeers' restriction keyword and/or
the "peer" configuration command had included a short caveat that the
association will only really be bidirectional if authentified (or if
the auth flag is off).
[color=blue]
> Usually, both peers are clients of different lower stratum
> servers and usually operate at the same stratum, so time doesn't flow
> between them.[/color]

Hmm, yes. Is there a way to specify that time should flow in the
direction of larger synchronization distance, even at the possible
expense of one of the servers operating on a higher stratum?
Or is that a situation that is just expected not to happen?

--
Henning Makholm "... and that Greek, Thucydides"