[Bug] ntpd: handling of associd wraparound

[ASSI]

The initialization for the peer association ID uses a random number
non-equal to zero:

--8<---------------cut here---------------start------------->8---
	/*
	 * Initialize our first association ID
	 */
	do
		current_association_ID = ntp_random() & ASSOCID_MAX;
	while (!current_association_ID);
--8<---------------cut here---------------end--------------->8---

I've recently ran into  the situation where that happened to be a number
very close to ASSOCID_MAX and after some pool ppers got pruned and
renewed the associd wrapped around zero, triggering this piece of code
that avoids giving out an association ID of exactly zero:

--8<---------------cut here---------------start------------->8---
	/*
	 * Assign an association ID and increment the system variable.
	 */
	peer->associd = current_association_ID;
	if (++current_association_ID == 0)
		++current_association_ID;
--8<---------------cut here---------------end--------------->8---

However, these low numbers then collide with the ability to look at
indexed associations (like refclocks), which should always get numbered
from 1 on since they get mobilized before the network peers, so
something like

ntpq -c "cv &1"

stops working.  The refclock was still correctly shown in the peers
display of ntpq, but since the display obviously got sorted by the
association ID the refclocks showed up inbetween the servers from after
and before the wraparound.  If I count the number of lines until the
refclock I can use that index, so it's just that the order of things got
mucked up.

The correct way to handle the associations would be to always start the
peer list at the initial_association_ID instead of the numerically
lowest value.  I've not yet found the place where the association list
gets sorted by ID, but ntpq from classic sees the same thing, so it
either happens somewhere in ntpd when it sends the list of peers to the
client (it just traverses the peer_list in ntp_control.c, so unless that
list is sorted somewhere it should always be sent in order of creation)
or classic ntpq has the same bug of sorting the received list.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf Blofeld V1.15B11:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada