On Thu, 25 Jan 2007, Christian Biere wrote:

> Woodchuck wrote:
> > I determined the fix empirically.  
>  
> > Print out sin.sin_port with and without the htons, observe
> > results of a "clockdiff" command with and without the htons.
>  
> > On a little-endian (i386) machine, the original code results in a
> > sin.sin_port value in the 63K range, and subsequent code that probes
> > the target host for time/udp will fail if the target expects a privileged
> > port.  perhaps htons belongs *here*, perhaps another one elsewhere is
> > spurious.
> 
> I checked all ocurrences of "port" in timed and timedc and couldn't find
> anything wrong. I've looked with tcpdump and the ports seem to be correct:
> 

Hmmmmm.  Did my tcpdump, and it contains no new information,
except as noted, no transcript is really necessary.

I agree that your results are what they are, and they are what I
get with the "old" socket ("with htons").  In fact they still don't
work.

The "new" code, without htons, gets an unprivileged socket, which *does*
work.  This is the WRONG WAY to make it work, and that patch should
be scrapped.

The OpenBSD code exhibited (and timedc run by root on an OpenBSD host on
the LAN) used an UNprivileged socket, and "worked".

Apparently the fix is *not* to drop htons, but to drop trying to use
a privileged socket, and my theorizing about the nature of that socket
was uninformed.

I am grateful to you for the correction.

In other words, the OpenBSD hosts are *rejecting* a connection attempt
from a privileged socket.  That makes a certain kind of paranoid sense.

I notice that timedc is setuid 0 on NetBSD, (obviously, to get that
privileged socket), but is not setuid on OpenBSD (which uses an unprivileged
one).  If an unprivileged socket is appropriate, then NetBSD could also
lose the setuid property, generally a good thing to lose if unnecessary.

Dave