[ntp:questions] Re: Multicast TTL and FreeBSD trouble
David L. Mills
mills at udel.edu
Fri Aug 19 03:40:18 UTC 2005
Reset. Should you clip the TTL at any value, that would be
contraindicated by prior advice re IPv4 administrative scoping. Unless
you can tell me definitively that concept is totally deprecated by
culture, some means will be necessary to allow administrative scoping as
well as compatiblity with IPv6. My original plan was to provide a
mapping that could be specified by a configuration command.
Danny Mayer wrote:
> David L. Mills wrote:
>> There is a mapping table which converts integers to actual TTL
>> values. See at or near line 2954 of ntp_proto.c. This is intended to
>> follow guidelines for administrative scoping. I don't remember which
>> RFC and the implementation has never been tested for conformance to
>> my knowledge. What to do in IPv6 is even of more murk. I am happy to
>> listen to suggestions.
> In the ntp_io.c code the call to sendpkt() includes the ttl (or hop in
> IPv6) and a call to setsockopt() sets the ttl or hop. There appears to
> be nothing to check whether or not the value is too big, for some
> definition of "too big". I think that I should add a log message when
> the value is greater than say 4. It won't prevent it but it will allow
> us to gather data. I'll have to look at your ntp_proto code to see
> where it gets set. Right now the debug code will put out an "MCAST"
> message if the ttl is non-zero. debug > 1. I've certainly seen those
> messages go out that are NOT MCAST messages, but that's a different
> question where we are setting ttl on unicast messages. Ah, the code
> message is wrong, it's printing the message even when ttl = 0. I'll
> fix that buglet.
>> wa6zvp at gmail.com wrote:
>>> Multicast packets from NTPD in FreeBSD do not seem to have the correct
>>> TTL value. Here is a sample TCPDump from a machine with multcast TTL
>>> set to 2:
>>> 08:28:20.88 188.8.131.52.123 > 184.108.40.206.123: v4 bcast strat 2 poll
>>> 6 prec -19
>>> 4500 004c 5756 0000 4011 bd8d aaaa bbbb
>>> TTL is byte 9 of the header, displayed above as '40' or 64 decimal.
>>> Experiments have shown that the TTL always appears in the packet with a
>>> value 32x what is configured, or left shifted by 5 bits. It seems more
>>> than coincidental that the previous 2 bytes are really a 3 bit value
>>> and a 13 bit value. Perhaps they were formatted incorrectly, with the
>>> effect of left shifting the TTL.
>>> Current tests include FreeBSD versions 4.8, 5.3 and 5.4, along with NTP
>>> released versions as well as (almost) the most recent DEV version.
>>> The same test were also done on a couple of other platforms:
>>> RH Linux w/2.4 kernel works correctly, while the xNTP port in Multinet
>>> 4.3 on OpenVMS doesn't set the TTL at all (is 0).
>> questions mailing list
>> questions at lists.ntp.isc.org
More information about the questions