[ntp:questions] Re: Multicast TTL and FreeBSD trouble

Danny Mayer mayer at gis.net
Sun Aug 21 00:08:24 UTC 2005

Per Hedeland wrote:
> In article <1124513969.545098.307150 at g44g2000cwa.googlegroups.com>
> wa6zvp at gmail.com writes:
>>Regardless of past or present usage, can someone explain why a config
>>file that has 'TTL 2' in the broadcast statement result in:
>>0x02 in linux and 0x40 in FreeBSD on the wire?
>>Should I be taking this to a FBSD group?
> No - I can verify the FreeBSD behaviour you're seeing, on FreeBSD
> 5.3-RELEASE with the included ntpd (which calls itself 4.2.0-a) - tried
> 1 => 32 and 3 => 96 (btw, if you give -v to tcpdump it will parse out
> the ttl for you). But with a 4.1.1a version (tarball from ntp.org IIRC)
> that I happened to have laying around, I get the configured ttl on the
> wire (same FreeBSD). Are you testing the same ntp version on Linux and
> FreeBSD?
> Anyway, looking through the 4.2.0 sources, I see that it does indeed
> apply a mapping to the ttl value, that amounts to multiplying by 32 by
> default:
> 	for (i = 0; i < MAX_TTL; i++) {
> 		sys_ttl[i] = (u_char)((i * 256) / MAX_TTL);
> 		sys_ttlmax = i;
> 	}

This is bizarre. I have no idea what it does or rather why. I'd need to 
follow this code to understand what's happening. This, however, would be 
no different on Linux than FreeBSD. You should get the same numbers.

> (MAX_TTL is 8). Also I see that this mapping can be modified with the
> 'ttl' command in the config - this creates an identity mapping:
> ttl 0 1 2 3 4 5 6 7
> The ttl command is documented in the current html pages, but the fact
> that its settings are applied to the ttl option of the broadcast command
> is not (nor the consequence that the max value of the ttl option is 7 -
> in fact it is claimed that the default is 127) - maybe it's a bug.

Quite possibly.


> --Per Hedeland
> per at hedeland.org

More information about the questions mailing list