Bug 29348

Summary: After upgrade from RH6.x ntp ignores client requests on aliases interfaces
Product: [Retired] Red Hat Linux Reporter: John Bass <jbass>
Component: ntpAssignee: Harald Hoyer <harald>
Status: CLOSED CURRENTRELEASE QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: medium    
Version: 7.0CC: dr
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2003-08-05 04:15:49 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Description John Bass 2001-02-25 04:15:33 EST
Upgraded our primary gateway from RH6.1 to RH7.0 and nearly all client
systems are ignored. Starting up ntpd by hand with debug enabled promptly
explains the problem:

# ntpd -A -d -d -l /tmp/ntp
25 Feb 01:38:53 ntpd[28751]: logging to file /tmp/ntp
25 Feb 01:38:53 ntpd[28751]: ntpd 4.0.99j Wed Aug 23 13:11:23 EDT 2000 (1)
interface <lo> OK
interface <eth0> OK
interface <eth1> OK
interface <eth1:0> ignored
interface <eth1:1> ignored
interface <eth1:2> ignored
interface <eth2> OK
interface <eth2:0> ignored
interface <eth2:1> ignored
interface <eth2:2> ignored
interface <eth2:3> ignored
interface <eth2:4> ignored
interface <eth2:5> ignored

All requests from those aliases are reported in the debug as received,
and are in fact ignored.

receive: at 93 xxx.xxx.xxx.xxx mode 3 code 2

The particular gateway routes for several bridged wireless networks
using several Class C's and partial Class C's. Aliased interfaces
are the only practical way to handle the mixture of subnets. It
doesn't make sense for ntp to ignore aliased interfaces - a very useful
Comment 1 John Bass 2001-02-28 06:09:19 EST
After some additional source level debugging, enabling aliases with an
undocumented command line option "-L" didn't make a difference.

In searching the code, the problem appears not with aliases, but rather
that the requests are clasified as "code 2", aka AM_FXMIT, and discarded
in a switch statement for AM_FXMIT in ntp_proto.c

Client requests from most clients are tagged with this code, and their
requests are discarded without a response. Only requests from other servers
configured are processed.

It's not clear what additional options in /etc/ntp.conf are now required
to allow the local machine to be a server for local clients. In previous
releases, simply suppling a server directive with the address of a functional
ntp server in /etc/ntp.conf replacing the default local clock was enough.
Comment 2 Preston Brown 2001-03-05 10:52:27 EST
you probably need to disable auth.
Comment 3 Harald Hoyer 2001-05-11 08:45:01 EDT
try to disable multicastclient or add multicast ability to the kernel
Comment 4 Harald Hoyer 2001-05-18 05:11:22 EDT
*** Bug 41155 has been marked as a duplicate of this bug. ***
Comment 5 Harald Hoyer 2001-09-04 05:20:23 EDT
could you please retry with ntp-4.1.0-3