possible bug: peerstats

[Eric S. Raymond]

Achim Gratz via devel <devel at ntpsec.org>:
> 
> I've updated to ntpsec-0.9.7+1104 ten days ago and just realized that
> the peerstats logging has changed format: if I use the new refclock
> syntax, then instead of the 127.127.<driver>.<unit> in the address
> field, I now get the driver name like NMEA(0).  I had written my scripts
> defensively enough to ignore these lines, so it only now dawned on me
> why the associated data went missing.
> 
> In principle I'd like a logging format that uses symbolic names for all
> peers (that'd solve the problem of peers getting new addresses via DHCP
> or IPv6 prefix changes), but please make that configurable and
> independent of the way the server / refclock gets specified in the
> config.

OK, that's weird.

The logging code shouldn't *know* what syntax was used to configure
the entry.  Internally, the new syntax is converted to the equivalent
magic IP address by the configuration parser with this code:

refclock_command
	:	T_Refclock T_String optional_unit option_list
		{
#ifdef REFCLOCK
			peer_node *my_node;
			address_node *fakeaddr;
			char addrbuf[1025];	/* NI_MAXHOSTS on Linux */
			int dtype;

			for (dtype = 1; dtype < (int)num_refclock_conf; dtype++)
			    if (refclock_conf[dtype]->basename != NULL && strcasecmp(refclock_conf[dtype]->basename, $2) == 0)
				goto foundit;
			 msyslog(LOG_ERR, "CONFIG: Unknown driver name %s", $2);
			 exit(1);
		foundit:
			snprintf(addrbuf, sizeof(addrbuf),
				 "127.127.%d.%d", dtype, $3);
			fakeaddr = create_address_node(estrdup(addrbuf),AF_INET);
			my_node = create_peer_node(T_Server, fakeaddr, $4);
			APPEND_G_FIFO(cfgt.peers, my_node);
#endif /* REFCLOCK */
		}
	;

Compare this:

server_command
	:	client_type address option_list
		{
			peer_node *my_node;

			my_node = create_peer_node($1, $2, $3);
			APPEND_G_FIFO(cfgt.peers, my_node);
		}


Note that in both the server and refclock cases, first argument will be
T_Server.  So I don't see how the difference can leak through even to the
config back end, let alone the logging code.

Are you sure there isn't some other variable here?  Would you mind using
gdb to see what create_peer_node() gets passed in those two cases?

I'd jump on this, but I'm dealing with an emergency.  One of our guys
broke the pool startup code and has since gone radio silent - I need to fix
that before I can focus on anything else.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Please consider contributing to my Patreon page at https://www.patreon.com/esr
so I can keep the invisible wheels of the Internet turning. Give generously -
the civilization you save might be your own.