This is my /etc/ntp.comf file:

restrict default nomodify notrap
restrict 127.0.0.1
restrict 192.168.0.0 mask 255.255.255.0 notrust nomodify notrap
 
server ...
 
driftfile /etc/ntp.drift
logfile /var/log/ntp.log


I'm getting this message in the log file:

 7 Feb 16:31:34 ntpd[6920]: running as uid(123)/gid(123) euid(123)/egid(123).
 7 Feb 16:31:34 ntpd[6922]: signal_no_reset: signal 17 had flags 4000000
 7 Feb 16:31:37 ntpd[6920]: sendto ... : Operation not permitted
 7 Feb 17:31:34 ntpd[6920]: can't open /etc/ntp.drift.TEMP: Permission denied
 
Just another point.  I've configured my firewall so the ntpd can act as a
client, but not as a server.  I'm assuming that only needs to act as a
client in order to retrieve the time.

The question I have is, 
"Why is the operation not permitted?"

In article <pan.2004.02.08.15.59.07.590190@btinternet.com>,
Paul <squiz@btinternet.com> wrote:

>  7 Feb 16:31:34 ntpd[6920]: running as uid(123)/gid(123) euid(123)/egid(123).

> "Why is the operation not permitted?"

Only root can bind to port 123 or set the time.  The standard ntpd
has to be run as root.  If you are using the Red Hat version, you
should get support from them; even that version needs to be started
as root, as far as I know; it then uses Linux specific system calls
that allow it to retain permission to set the time, and has presumably
already bound to port 123, before changing user.

I don't believe you actually supplied the necesary version and platform
information.

I would say you were failing to bind to port 123, because of running
unprivileged.

Exactly how did you configure your firewall so "ntpd can act as a 
client, but not as a server"?  If you do not allow UDP on port 123, both 
inbound and outbound, the NTP protocol will not work!

Your client must send a packet from port 123 to port 123 on the server.  
The server modifies this packet and returns it to your client, again 
using port 123 on both ends.  Even if you are using a broadcast server, 
your client must still exchange packets with the server to establish the 
round trip delay.

If you really need to prevent your client acting as a server, you might 
try  "restrict default ignore" in your ntp.conf.
I've never done it, or needed to, but you might then have to use 
additional restrict statements to allow your server to serve you.

I think that blocking NTP at the firewall is a dead end!

Paul wrote:

>This is my /etc/ntp.comf file:
>
>restrict default nomodify notrap
>restrict 127.0.0.1
>restrict 192.168.0.0 mask 255.255.255.0 notrust nomodify notrap
> 
>server ...
> 
>driftfile /etc/ntp.drift
>logfile /var/log/ntp.log
>
>
>I'm getting this message in the log file:
>
> 7 Feb 16:31:34 ntpd[6920]: running as uid(123)/gid(123) euid(123)/egid(123).
> 7 Feb 16:31:34 ntpd[6922]: signal_no_reset: signal 17 had flags 4000000
> 7 Feb 16:31:37 ntpd[6920]: sendto ... : Operation not permitted
> 7 Feb 17:31:34 ntpd[6920]: can't open /etc/ntp.drift.TEMP: Permission denied
> 
>Just another point.  I've configured my firewall so the ntpd can act as a
>client, but not as a server.  I'm assuming that only needs to act as a
>client in order to retrieve the time.
>
>The question I have is, 
>"Why is the operation not permitted?"
>
>  
>

"Richard B. Gilbert" <rgilbert88@comcast.net> writes:

> Your client must send a packet from port 123 to port 123 on the
> server.  The server modifies this packet and returns it to your
> client, again using port 123 on both ends.  Even if you are using a
> broadcast server, your client must still exchange packets with the
> server to establish the round trip delay.

Why does NTP do it this way?  Why isn't everything shifted up to a
high port, like other protocols?

TIA
-- 
Lift me down, so I can make the Earth tremble.
                                --Bucky Katt

On Sun, 08 Feb 2004 15:27:45 +0000, David Woolley wrote:

> In article <pan.2004.02.08.15.59.07.590190@btinternet.com>,
> Paul <squiz@btinternet.com> wrote:
> 
>>  7 Feb 16:31:34 ntpd[6920]: running as uid(123)/gid(123) euid(123)/egid(123).
> 
>> "Why is the operation not permitted?"
> 
> Only root can bind to port 123 or set the time.  The standard ntpd
> has to be run as root. 

> I don't believe you actually supplied the necesary version and platform
> information.
> 
> I would say you were failing to bind to port 123, because of running
> unprivileged.

Thanks for response.

gentoo 1.4
linux i686 2.4.22

I'm not sure how to make it run as root.  I normally start it by using:
/etc/init.d/ntpd start, but I've had a similar message when using:
ntpd -q.  I thought you had to use -U to make it drop root privileges.

On Sun, 08 Feb 2004 13:04:50 -0500, Richard B. Gilbert wrote:

> Exactly how did you configure your firewall so "ntpd can act as a 
> client, but not as a server"?  If you do not allow UDP on port 123, both 
> inbound and outbound, the NTP protocol will not work!
> 
> Your client must send a packet from port 123 to port 123 on the server.  
> The server modifies this packet and returns it to your client, again 
> using port 123 on both ends.  Even if you are using a broadcast server, 
> your client must still exchange packets with the server to establish the 
> round trip delay.
> 
> If you really need to prevent your client acting as a server, you might 
> try  "restrict default ignore" in your ntp.conf.
> I've never done it, or needed to, but you might then have to use 
> additional restrict statements to allow your server to serve you.
> 
> I think that blocking NTP at the firewall is a dead end!
> 
> Paul wrote:
> 
>>This is my /etc/ntp.comf file:
>>
>>restrict default nomodify notrap
>>restrict 127.0.0.1
>>restrict 192.168.0.0 mask 255.255.255.0 notrust nomodify notrap
>> 

>>Just another point.  I've configured my firewall so the ntpd can act as a
>>client, but not as a server.  I'm assuming that only needs to act as a
>>client in order to retrieve the time.
>>
>>

Thanks for response.

gentoo 1.4
linux i686 2.4.22

I hadn't realised that ntp used udp not tcp.
I should be able to sort that part out now, but I'll give more details if I
can't.

Also could you clarify whether "restrict" only restricts nptd's
use as a server.  I had got the impression from another post that it would
also restrict its use of servers.

So, for example, if I use:

restrict default ignore
restrict 127.0.0.1
restrict 192.168.0.0 mask 255.255.255.0 notrust nomodify notrap

then can I still get the time from anywhere, but only my local network can
get the time from me?

This is a multi-part message in MIME format.
--------------010302060101060905030407
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

 NTP is not like Telnet or FTP where you can have N processes needing to 
receive packets addressed to them specifically.  With these protocols 
the port number directs the packets to the process that needs them.  The 
well known ports are used exclusively for establishing new connections.

Only one process per system receives NTP packets so only one port is needed.


Richard Hoskins wrote:

>"Richard B. Gilbert" <rgilbert88@comcast.net> writes:
>
>  
>
>>Your client must send a packet from port 123 to port 123 on the
>>server.  The server modifies this packet and returns it to your
>>client, again using port 123 on both ends.  Even if you are using a
>>broadcast server, your client must still exchange packets with the
>>server to establish the round trip delay.
>>    
>>
>
>Why does NTP do it this way?  Why isn't everything shifted up to a
>high port, like other protocols?
>
>TIA
>  
>

--------------010302060101060905030407
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
&nbsp;NTP is not like Telnet or FTP where you can have N processes needing
to receive packets addressed to them specifically.&nbsp; With these
protocols the port number directs the packets to the process that needs
them.&nbsp; The well known ports are used exclusively for establishing new
connections.<br>
<br>
Only one process per system receives NTP packets so only one port is
needed.<br>
<br>
<br>
Richard Hoskins wrote:<br>
<blockquote type="cite" cite="mid87smhlxt2f.fsf@adelphia.net">
  <pre wrap="">"Richard B. Gilbert" <a class="moz-txt-link-rfc2396E" href="mailto:rgilbert88@comcast.net">&lt;rgilbert88@comcast.net&gt;</a> writes:

  </pre>
  <blockquote type="cite">
    <pre wrap="">Your client must send a packet from port 123 to port 123 on the
server.  The server modifies this packet and returns it to your
client, again using port 123 on both ends.  Even if you are using a
broadcast server, your client must still exchange packets with the
server to establish the round trip delay.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
Why does NTP do it this way?  Why isn't everything shifted up to a
high port, like other protocols?

TIA
  </pre>
</blockquote>
</body>
</html>

--------------010302060101060905030407--

"Richard B. Gilbert" <rgilbert88@comcast.net> writes:

>  NTP is not like Telnet or FTP where you can have N processes
> needing to receive packets addressed to them specifically.  With
> these protocols the port number directs the packets to the process
> that needs them.  The well known ports are used exclusively for
> establishing new connections.
>
> Only one process per system receives NTP packets so only one port is
> needed.

Yes but, there is no shortage of high ports, and the UDP packet
carries the originating port anyway.  The client shifting it to a high
port would give the user the option of blocking port 123, and having
NTP still work.

I guess it doesn't really matter, but I'm curious.  Thanks for your
response.

-- 
Lift me down, so I can make the Earth tremble.
                                --Bucky Katt

This is a multi-part message in MIME format.
--------------000705010003040807080209
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

I just checked the man page for xntpd (Solaris 8).  I think that what 
you need to do is to add the flag "noserve" to your restrict default 
statement instead of using ignore.  The noserve flag denies time 
service, in this case, to anyone and everyone.  This should be less 
complicated than using the "ignore" flag and then relaxing the 
restriction for the server.

For further information, I'll refer you to the man pages if you have 
them or to the HTML documenation at ntp.org if you don't.

Paul wrote:

>On Sun, 08 Feb 2004 13:04:50 -0500, Richard B. Gilbert wrote:
>
>  
>
>>Exactly how did you configure your firewall so "ntpd can act as a 
>>client, but not as a server"?  If you do not allow UDP on port 123, both 
>>inbound and outbound, the NTP protocol will not work!
>>
>>Your client must send a packet from port 123 to port 123 on the server.  
>>The server modifies this packet and returns it to your client, again 
>>using port 123 on both ends.  Even if you are using a broadcast server, 
>>your client must still exchange packets with the server to establish the 
>>round trip delay.
>>
>>If you really need to prevent your client acting as a server, you might 
>>try  "restrict default ignore" in your ntp.conf.
>>I've never done it, or needed to, but you might then have to use 
>>additional restrict statements to allow your server to serve you.
>>
>>I think that blocking NTP at the firewall is a dead end!
>>
>>Paul wrote:
>>
>>    
>>
>>>This is my /etc/ntp.comf file:
>>>
>>>restrict default nomodify notrap
>>>restrict 127.0.0.1
>>>restrict 192.168.0.0 mask 255.255.255.0 notrust nomodify notrap
>>>
>>>      
>>>
>
>  
>
>>>Just another point.  I've configured my firewall so the ntpd can act as a
>>>client, but not as a server.  I'm assuming that only needs to act as a
>>>client in order to retrieve the time.
>>>
>>>
>>>      
>>>
>
>Thanks for response.
>
>gentoo 1.4
>linux i686 2.4.22
>
>I hadn't realised that ntp used udp not tcp.
>I should be able to sort that part out now, but I'll give more details if I
>can't.
>
>Also could you clarify whether "restrict" only restricts nptd's
>use as a server.  I had got the impression from another post that it would
>also restrict its use of servers.
>
>So, for example, if I use:
>
>restrict default ignore
>restrict 127.0.0.1
>restrict 192.168.0.0 mask 255.255.255.0 notrust nomodify notrap
>
>then can I still get the time from anywhere, but only my local network can
>get the time from me?
>
>  
>

--------------000705010003040807080209
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
I just checked the man page for xntpd (Solaris 8).&nbsp; I think that what
you need to do is to add the flag "noserve" to your restrict default
statement instead of using ignore.&nbsp; The noserve flag denies time
service, in this case, to anyone and everyone.&nbsp; This should be less
complicated than using the "ignore" flag and then relaxing the
restriction for the server.<br>
<br>
For further information, I'll refer you to the man pages if you have
them or to the HTML documenation at ntp.org if you don't.<br>
<br>
Paul wrote:<br>
<blockquote type="cite"
 cite="midpan.2004.02.08.20.40.29.613326@btinternet.com">
  <pre wrap="">On Sun, 08 Feb 2004 13:04:50 -0500, Richard B. Gilbert wrote:

  </pre>
  <blockquote type="cite">
    <pre wrap="">Exactly how did you configure your firewall so "ntpd can act as a 
client, but not as a server"?  If you do not allow UDP on port 123, both 
inbound and outbound, the NTP protocol will not work!

Your client must send a packet from port 123 to port 123 on the server.  
The server modifies this packet and returns it to your client, again 
using port 123 on both ends.  Even if you are using a broadcast server, 
your client must still exchange packets with the server to establish the 
round trip delay.

If you really need to prevent your client acting as a server, you might 
try  "restrict default ignore" in your ntp.conf.
I've never done it, or needed to, but you might then have to use 
additional restrict statements to allow your server to serve you.

I think that blocking NTP at the firewall is a dead end!

Paul wrote:

    </pre>
    <blockquote type="cite">
      <pre wrap="">This is my /etc/ntp.comf file:

restrict default nomodify notrap
restrict 127.0.0.1
restrict 192.168.0.0 mask 255.255.255.0 notrust nomodify notrap

      </pre>
    </blockquote>
  </blockquote>
  <pre wrap=""><!---->
  </pre>
  <blockquote type="cite">
    <blockquote type="cite">
      <pre wrap="">Just another point.  I've configured my firewall so the ntpd can act as a
client, but not as a server.  I'm assuming that only needs to act as a
client in order to retrieve the time.


      </pre>
    </blockquote>
  </blockquote>
  <pre wrap=""><!---->
Thanks for response.

gentoo 1.4
linux i686 2.4.22

I hadn't realised that ntp used udp not tcp.
I should be able to sort that part out now, but I'll give more details if I
can't.

Also could you clarify whether "restrict" only restricts nptd's
use as a server.  I had got the impression from another post that it would
also restrict its use of servers.

So, for example, if I use:

restrict default ignore
restrict 127.0.0.1
restrict 192.168.0.0 mask 255.255.255.0 notrust nomodify notrap

then can I still get the time from anywhere, but only my local network can
get the time from me?

  </pre>
</blockquote>
</body>
</html>

--------------000705010003040807080209--

This is a multi-part message in MIME format.
--------------080107000909060503050605
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

If you execute /etc/init.d/ntpd as root, you should be ok.  If this is 
executed when you boot, again, you are ok.  If you log in as joeuser and 
try to start ntpd, it won't work.

Paul wrote:

>On Sun, 08 Feb 2004 15:27:45 +0000, David Woolley wrote:
>
>  
>
>>In article <pan.2004.02.08.15.59.07.590190@btinternet.com>,
>>Paul <squiz@btinternet.com> wrote:
>>
>>    
>>
>>> 7 Feb 16:31:34 ntpd[6920]: running as uid(123)/gid(123) euid(123)/egid(123).
>>>      
>>>
>>>"Why is the operation not permitted?"
>>>      
>>>
>>Only root can bind to port 123 or set the time.  The standard ntpd
>>has to be run as root. 
>>    
>>
>
>  
>
>>I don't believe you actually supplied the necesary version and platform
>>information.
>>
>>I would say you were failing to bind to port 123, because of running
>>unprivileged.
>>    
>>
>
>Thanks for response.
>
>gentoo 1.4
>linux i686 2.4.22
>
>I'm not sure how to make it run as root.  I normally start it by using:
>/etc/init.d/ntpd start, but I've had a similar message when using:
>ntpd -q.  I thought you had to use -U to make it drop root privileges.
>
>
>  
>

--------------080107000909060503050605
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
If you execute /etc/init.d/ntpd as root, you should be ok.&nbsp; If this is
executed when you boot, again, you are ok.&nbsp; If you log in as joeuser
and try to start ntpd, it won't work.<br>
<br>
Paul wrote:<br>
<blockquote type="cite"
 cite="midpan.2004.02.08.20.30.34.490545@btinternet.com">
  <pre wrap="">On Sun, 08 Feb 2004 15:27:45 +0000, David Woolley wrote:

  </pre>
  <blockquote type="cite">
    <pre wrap="">In article <a class="moz-txt-link-rfc2396E" href="mailto:pan.2004.02.08.15.59.07.590190@btinternet.com">&lt;pan.2004.02.08.15.59.07.590190@btinternet.com&gt;</a>,
Paul <a class="moz-txt-link-rfc2396E" href="mailto:squiz@btinternet.com">&lt;squiz@btinternet.com&gt;</a> wrote:

    </pre>
    <blockquote type="cite">
      <pre wrap=""> 7 Feb 16:31:34 ntpd[6920]: running as uid(123)/gid(123) euid(123)/egid(123).
      </pre>
    </blockquote>
    <blockquote type="cite">
      <pre wrap="">"Why is the operation not permitted?"
      </pre>
    </blockquote>
    <pre wrap="">Only root can bind to port 123 or set the time.  The standard ntpd
has to be run as root. 
    </pre>
  </blockquote>
  <pre wrap=""><!---->
  </pre>
  <blockquote type="cite">
    <pre wrap="">I don't believe you actually supplied the necesary version and platform
information.

I would say you were failing to bind to port 123, because of running
unprivileged.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
Thanks for response.

gentoo 1.4
linux i686 2.4.22

I'm not sure how to make it run as root.  I normally start it by using:
/etc/init.d/ntpd start, but I've had a similar message when using:
ntpd -q.  I thought you had to use -U to make it drop root privileges.


  </pre>
</blockquote>
</body>
</html>

--------------080107000909060503050605--

On Sun, 08 Feb 2004 17:04:45 -0500, Richard B. Gilbert wrote:

> If you execute /etc/init.d/ntpd as root, you should be ok.  If this is 
> executed when you boot, again, you are ok.  If you log in as joeuser and 
> try to start ntpd, it won't work.
> 

I was logged on as root.
The problem eventually turned out to be with the firewall.

Thanks for the information anyway.  It's all useful.

On Sun, 08 Feb 2004 16:59:39 -0500, Richard B. Gilbert wrote:

> I just checked the man page for xntpd (Solaris 8).  I think that what 
> you need to do is to add the flag "noserve" to your restrict default 
> statement instead of using ignore.  The noserve flag denies time 
> service, in this case, to anyone and everyone.  This should be less 
> complicated than using the "ignore" flag and then relaxing the 
> restriction for the server.
> 
> For further information, I'll refer you to the man pages if you have 
> them or to the HTML documenation at ntp.org if you don't.
> 
> Paul wrote:
> 
>>On Sun, 08 Feb 2004 13:04:50 -0500, Richard B. Gilbert wrote:
>>
>>>Your client must send a packet from port 123 to port 123 on the server.  
>>>The server modifies this packet and returns it to your client, again 
>>>using port 123 on both ends.  Even if you are using a broadcast server, 
>>>your client must still exchange packets with the server to establish the 
>>>round trip delay.
>>>

>>I hadn't realised that ntp used udp not tcp.
>>I should be able to sort that part out now, but I'll give more details if I
>>can't.
>>
>>Also could you clarify whether "restrict" only restricts nptd's
>>use as a server.  I had got the impression from another post that it would
>>also restrict its use of servers.
>>
>>So, for example, if I use:
>>
>>restrict default ignore
>>restrict 127.0.0.1
>>restrict 192.168.0.0 mask 255.255.255.0 notrust nomodify notrap
>>
>>then can I still get the time from anywhere, but only my local network can
>>get the time from me?
>>
>>  

I've reconfigured the firewall to use udp for ntp.
Also implemented:
restrict default noserve

Problem solved thanks

This is a multi-part message in MIME format.
--------------050709040504030202010507
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Yes, you could block port 123, but to what purpose?  If you talk to port 
123, you can only talk to the ntp daemon and, if that is properly 
secured, there is little or nothing an intruder could do.

Richard Hoskins wrote:

>"Richard B. Gilbert" <rgilbert88@comcast.net> writes:
>
>  
>
>> NTP is not like Telnet or FTP where you can have N processes
>>needing to receive packets addressed to them specifically.  With
>>these protocols the port number directs the packets to the process
>>that needs them.  The well known ports are used exclusively for
>>establishing new connections.
>>
>>Only one process per system receives NTP packets so only one port is
>>needed.
>>    
>>
>
>Yes but, there is no shortage of high ports, and the UDP packet
>carries the originating port anyway.  The client shifting it to a high
>port would give the user the option of blocking port 123, and having
>NTP still work.
>
>I guess it doesn't really matter, but I'm curious.  Thanks for your
>response.
>
>  
>

--------------050709040504030202010507
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
Yes, you could block port 123, but to what purpose?&nbsp; If you talk to
port 123, you can only talk to the ntp daemon and, if that is properly
secured, there is little or nothing an intruder could do.<br>
<br>
Richard Hoskins wrote:<br>
<blockquote type="cite" cite="mid87oes9xmxs.fsf@adelphia.net">
  <pre wrap="">"Richard B. Gilbert" <a class="moz-txt-link-rfc2396E" href="mailto:rgilbert88@comcast.net">&lt;rgilbert88@comcast.net&gt;</a> writes:

  </pre>
  <blockquote type="cite">
    <pre wrap=""> NTP is not like Telnet or FTP where you can have N processes
needing to receive packets addressed to them specifically.  With
these protocols the port number directs the packets to the process
that needs them.  The well known ports are used exclusively for
establishing new connections.

Only one process per system receives NTP packets so only one port is
needed.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
Yes but, there is no shortage of high ports, and the UDP packet
carries the originating port anyway.  The client shifting it to a high
port would give the user the option of blocking port 123, and having
NTP still work.

I guess it doesn't really matter, but I'm curious.  Thanks for your
response.

  </pre>
</blockquote>
</body>
</html>

--------------050709040504030202010507--

Richard Hoskins <scuff@adelphia.net> wrote in message news:<87smhlxt2f.fsf@adelphia.net>...
> "Richard B. Gilbert" <rgilbert88@comcast.net> writes:
> 
> > Your client must send a packet from port 123 to port 123 on the
> > server.  The server modifies this packet and returns it to your
> > client, again using port 123 on both ends.  Even if you are using a
> > broadcast server, your client must still exchange packets with the
> > server to establish the round trip delay.
> 
> Why does NTP do it this way?  Why isn't everything shifted up to a
> high port, like other protocols?
> 
> TIA

Because you need to run a server on a well-known port. The privileged
ports (0-1023) are reserved for services that are defined and known
about by all other systems. You cannot "shift" to some other random
port. Other protocols don't get "shifted up" to a high port. What makes
you think they do?

Danny

"Richard Hoskins" <scuff@adelphia.net> wrote in message 
news:87oes9xmxs.fsf@adelphia.net...


> Yes but, there is no shortage of high ports, and the UDP packet
> carries the originating port anyway.  The client shifting it to a high
> port would give the user the option of blocking port 123, and having
> NTP still work.


    Huh?! Why would a person want to block port 123 and still have NTP work? 
What possible reason could there be for blocking port 123 other than to stop 
NTP from working? And why would someone block port 123 (which is known to 
belong to NTP and generally considered safe) but allow random high ports 
(which could do anything at all)?

    DS

In article <pan.2004.02.08.20.30.34.490545@btinternet.com>,
Paul <squiz@btinternet.com> wrote:

> ntpd -q.  I thought you had to use -U to make it drop root privileges.

There is no such option in the standard version of ntpd; it only exists
in the Red Hat fork of the code.

This is a multi-part message in MIME format.
--------------020009050109040803010407
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Beg to differ, but many services use the well known port only to 
establish a connection.  Consider, if you will, Host A running an FPT 
server, and host B with three different users trying to download files 
from host A using  FTP.  Each user's FTP client, sends a request to port 
21 and supplies a unique high port for the reply; that high port , 
together with the IP address, uniquely identifies the client..  The inet 
daemon, or whatever the O/S on host A uses, forks/spawns a process 
running the FTP server and passes the details to it.  The FTP server 
allocates a unique high port on which to receive future transmissions 
and plugs that port number into its return packet.  Thereafter, that 
instance of the FTP server is identified to the client by that port.

How else could you maintain multiple, simultaneous, FTP sessions with 
two, or two dozen clients?

NTP is a little different, in that it need not maintain any state 
information concerning its clients; it gets a request, replies to that 
request and forgets the whole transaction.  The next request and reply 
do not depend, in any way, on previous interactions with that client. 

Danny Mayer wrote:

>Richard Hoskins <scuff@adelphia.net> wrote in message news:<87smhlxt2f.fsf@adelphia.net>...
>  
>
>>"Richard B. Gilbert" <rgilbert88@comcast.net> writes:
>>
>>    
>>
>>>Your client must send a packet from port 123 to port 123 on the
>>>server.  The server modifies this packet and returns it to your
>>>client, again using port 123 on both ends.  Even if you are using a
>>>broadcast server, your client must still exchange packets with the
>>>server to establish the round trip delay.
>>>      
>>>
>>Why does NTP do it this way?  Why isn't everything shifted up to a
>>high port, like other protocols?
>>
>>TIA
>>    
>>
>
>Because you need to run a server on a well-known port. The privileged
>ports (0-1023) are reserved for services that are defined and known
>about by all other systems. You cannot "shift" to some other random
>port. Other protocols don't get "shifted up" to a high port. What makes
>you think they do?
>
>Danny
>  
>

--------------020009050109040803010407
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
Beg to differ, but many services use the well known port only to
establish a connection.&nbsp; Consider, if you will, Host A running an FPT
server, and host B with three different users trying to download files
from host A using&nbsp; FTP.&nbsp; Each user's FTP client, sends a request to
port 21 and supplies a unique high port for the reply; that high port ,
together with the IP address, uniquely identifies the client..&nbsp; The
inet daemon, or whatever the O/S on host A uses, forks/spawns a process
running the FTP server and passes the details to it.&nbsp; The FTP server
allocates a unique high port on which to receive future transmissions
and plugs that port number into its return packet.&nbsp; Thereafter, that
instance of the FTP server is identified to the client by that port.<br>
<br>
How else could you maintain multiple, simultaneous, FTP sessions with
two, or two dozen clients?<br>
<br>
NTP is a little different, in that it need not maintain any state
information concerning its clients; it gets a request, replies to that
request and forgets the whole transaction.&nbsp; The next request and reply
do not depend, in any way, on previous interactions with that client.&nbsp; <br>
<br>
Danny Mayer wrote:<br>
<blockquote type="cite"
 cite="mid3a2a0492.0402090957.516af42d@posting.google.com">
  <pre wrap="">Richard Hoskins <a class="moz-txt-link-rfc2396E" href="mailto:scuff@adelphia.net">&lt;scuff@adelphia.net&gt;</a> wrote in message news:<a class="moz-txt-link-rfc2396E" href="mailto:87smhlxt2f.fsf@adelphia.net">&lt;87smhlxt2f.fsf@adelphia.net&gt;</a>...
  </pre>
  <blockquote type="cite">
    <pre wrap="">"Richard B. Gilbert" <a class="moz-txt-link-rfc2396E" href="mailto:rgilbert88@comcast.net">&lt;rgilbert88@comcast.net&gt;</a> writes:

    </pre>
    <blockquote type="cite">
      <pre wrap="">Your client must send a packet from port 123 to port 123 on the
server.  The server modifies this packet and returns it to your
client, again using port 123 on both ends.  Even if you are using a
broadcast server, your client must still exchange packets with the
server to establish the round trip delay.
      </pre>
    </blockquote>
    <pre wrap="">Why does NTP do it this way?  Why isn't everything shifted up to a
high port, like other protocols?

TIA
    </pre>
  </blockquote>
  <pre wrap=""><!---->
Because you need to run a server on a well-known port. The privileged
ports (0-1023) are reserved for services that are defined and known
about by all other systems. You cannot "shift" to some other random
port. Other protocols don't get "shifted up" to a high port. What makes
you think they do?

Danny
  </pre>
</blockquote>
</body>
</html>

--------------020009050109040803010407--

"Richard B. Gilbert" <rgilbert88@comcast.net> wrote in message 
news:db2dncSAkrjWvbXdRVn-ug@comcast.com...


> Beg to differ, but many services use the well known port only to
> establish a connection.

    Umm, no. Very, very few do. SMTP does not. HTTP does not. SSH does not.

> Consider, if you will, Host A running an FPT
> server, and host B with three different users trying to download files
> from host A using  FTP.  Each user's FTP client, sends a request to port
> 21 and supplies a unique high port for the reply; that high port ,
> together with the IP address, uniquely identifies the client..

    Actually, the server IP address, client IP address, well known port, and 
client side port together uniquely identify the connection between the 
server and the client.

> The inet
> daemon, or whatever the O/S on host A uses, forks/spawns a process
> running the FTP server and passes the details to it.  The FTP server
> allocates a unique high port on which to receive future transmissions
> and plugs that port number into its return packet.  Thereafter, that
> instance of the FTP server is identified to the client by that port.

    I think you're a bit confused. You seem to be confusing the FTP data 
connection with the distinct client and server side ports of a single 
connection. If you know what you're talking about, say it over again using 
another protocol (SSH, SMTP, POP, telnet, or something like that) which 
doesn't have the very rare complication of using multiple logical 
connections.


> How else could you maintain multiple, simultaneous, FTP sessions with
> two, or two dozen clients?


    They have different IP addresses. Only one NTP server can run on a 
machine, so you don't need ports to tell them apart.


> NTP is a little different, in that it need not maintain any state
> information concerning its clients; it gets a request, replies to that
> request and forgets the whole transaction.  The next request and reply
> do not depend, in any way, on previous interactions with that client.


    That's not totally true. But in any event, it's not the important 
distinction. NTP doesn't need to talk to more than one process on the same 
IP address. However, when it does, a high port can be used as the source 
port.

    DS

See the -u and -i flags in ntp-dev.

I think -u was implemented in ntp-stable (4.2.0) but was not documented.

H
--
In article <T1076364088@djwhome.demon.co.uk>,
David Woolley <david@djwhome.demon.co.uk> wrote:
>In article <pan.2004.02.08.20.30.34.490545@btinternet.com>,
>Paul <squiz@btinternet.com> wrote:
>
>> ntpd -q.  I thought you had to use -U to make it drop root privileges.
>
>There is no such option in the standard version of ntpd; it only exists
>in the Red Hat fork of the code.

"David Schwartz" <davids@webmaster.com> writes:

>     Huh?! Why would a person want to block port 123 and still have
> NTP work?  What possible reason could there be for blocking port 123
> other than to stop NTP from working? And why would someone block
> port 123 (which is known to belong to NTP and generally considered
> safe) but allow random high ports (which could do anything at all)?

To disallow NTP requests from outside of the subnet while still
allowing an NTP connection to a higher stratum server outside the
subnet.  (I know now that you can do this in other ways.)

Consider how I can block incoming port 80 at the router, and not only
run a web server for my LAN only, but still surf the big bad Internet:

Frame 34 (74 bytes on wire, 74 bytes captured)
Internet Protocol, Src Addr: <my workstation>, Dst Addr: <fsf.org>
Transmission Control Protocol, Src Port: 45023 (45023), Dst Port: www (80)

Frame 35 (74 bytes on wire, 74 bytes captured)
Internet Protocol, Src Addr: <fsf.org>, Dst Addr: <my workstation>
Transmission Control Protocol, Src Port: www (80), Dst Port: 45023 (45023)

-- 
Lift me down, so I can make the Earth tremble.
                                --Bucky Katt

This is a multi-part message in MIME format.
--------------020507040802020607050002
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Ok, I hit the books and discovered that I am slightly confused.  The 
destination port and the protocol number determine which which process 
receives the packet.   The source port and IP address uniquely identify 
the sender.  The source port is usually dynamic and the destination port 
is usually fixed.

Am I correct in thinking that NTP uses 123 as both source and 
destination port?


David Schwartz wrote:

>"Richard B. Gilbert" <rgilbert88@comcast.net> wrote in message 
>news:db2dncSAkrjWvbXdRVn-ug@comcast.com...
>
>
>  
>
>>Beg to differ, but many services use the well known port only to
>>establish a connection.
>>    
>>
>
>    Umm, no. Very, very few do. SMTP does not. HTTP does not. SSH does not.
>
>  
>
>>Consider, if you will, Host A running an FPT
>>server, and host B with three different users trying to download files
>>from host A using  FTP.  Each user's FTP client, sends a request to port
>>21 and supplies a unique high port for the reply; that high port ,
>>together with the IP address, uniquely identifies the client..
>>    
>>
>
>    Actually, the server IP address, client IP address, well known port, and 
>client side port together uniquely identify the connection between the 
>server and the client.
>
>  
>
>>The inet
>>daemon, or whatever the O/S on host A uses, forks/spawns a process
>>running the FTP server and passes the details to it.  The FTP server
>>allocates a unique high port on which to receive future transmissions
>>and plugs that port number into its return packet.  Thereafter, that
>>instance of the FTP server is identified to the client by that port.
>>    
>>
>
>    I think you're a bit confused. You seem to be confusing the FTP data 
>connection with the distinct client and server side ports of a single 
>connection. If you know what you're talking about, say it over again using 
>another protocol (SSH, SMTP, POP, telnet, or something like that) which 
>doesn't have the very rare complication of using multiple logical 
>connections.
>
>
>  
>
>>How else could you maintain multiple, simultaneous, FTP sessions with
>>two, or two dozen clients?
>>    
>>
>
>
>    They have different IP addresses. Only one NTP server can run on a 
>machine, so you don't need ports to tell them apart.
>
>
>  
>
>>NTP is a little different, in that it need not maintain any state
>>information concerning its clients; it gets a request, replies to that
>>request and forgets the whole transaction.  The next request and reply
>>do not depend, in any way, on previous interactions with that client.
>>    
>>
>
>
>    That's not totally true. But in any event, it's not the important 
>distinction. NTP doesn't need to talk to more than one process on the same 
>IP address. However, when it does, a high port can be used as the source 
>port.
>
>    DS
>
>
>
>
>  
>

--------------020507040802020607050002
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
Ok, I hit the books and discovered that I am slightly confused.&nbsp; The
destination port and the protocol number determine which which process
receives the packet.&nbsp;&nbsp; The source port and IP address uniquely identify
the sender.&nbsp; The source port is usually dynamic and the destination
port is usually fixed.<br>
<br>
Am I correct in thinking that NTP uses 123 as both source and
destination port?<br>
<br>
<br>
David Schwartz wrote:<br>
<blockquote type="cite" cite="midc09cfp$28t$1@nntp.webmaster.com">
  <pre wrap="">"Richard B. Gilbert" <a class="moz-txt-link-rfc2396E" href="mailto:rgilbert88@comcast.net">&lt;rgilbert88@comcast.net&gt;</a> wrote in message 
<a class="moz-txt-link-freetext" href="news:db2dncSAkrjWvbXdRVn-ug@comcast.com">news:db2dncSAkrjWvbXdRVn-ug@comcast.com</a>...


  </pre>
  <blockquote type="cite">
    <pre wrap="">Beg to differ, but many services use the well known port only to
establish a connection.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
    Umm, no. Very, very few do. SMTP does not. HTTP does not. SSH does not.

  </pre>
  <blockquote type="cite">
    <pre wrap="">Consider, if you will, Host A running an FPT
server, and host B with three different users trying to download files
from host A using  FTP.  Each user's FTP client, sends a request to port
21 and supplies a unique high port for the reply; that high port ,
together with the IP address, uniquely identifies the client..
    </pre>
  </blockquote>
  <pre wrap=""><!---->
    Actually, the server IP address, client IP address, well known port, and 
client side port together uniquely identify the connection between the 
server and the client.

  </pre>
  <blockquote type="cite">
    <pre wrap="">The inet
daemon, or whatever the O/S on host A uses, forks/spawns a process
running the FTP server and passes the details to it.  The FTP server
allocates a unique high port on which to receive future transmissions
and plugs that port number into its return packet.  Thereafter, that
instance of the FTP server is identified to the client by that port.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
    I think you're a bit confused. You seem to be confusing the FTP data 
connection with the distinct client and server side ports of a single 
connection. If you know what you're talking about, say it over again using 
another protocol (SSH, SMTP, POP, telnet, or something like that) which 
doesn't have the very rare complication of using multiple logical 
connections.


  </pre>
  <blockquote type="cite">
    <pre wrap="">How else could you maintain multiple, simultaneous, FTP sessions with
two, or two dozen clients?
    </pre>
  </blockquote>
  <pre wrap=""><!---->

    They have different IP addresses. Only one NTP server can run on a 
machine, so you don't need ports to tell them apart.


  </pre>
  <blockquote type="cite">
    <pre wrap="">NTP is a little different, in that it need not maintain any state
information concerning its clients; it gets a request, replies to that
request and forgets the whole transaction.  The next request and reply
do not depend, in any way, on previous interactions with that client.
    </pre>
  </blockquote>
  <pre wrap=""><!---->

    That's not totally true. But in any event, it's not the important 
distinction. NTP doesn't need to talk to more than one process on the same 
IP address. However, when it does, a high port can be used as the source 
port.

    DS




  </pre>
</blockquote>
</body>
</html>

--------------020507040802020607050002--

"Richard B. Gilbert" <rgilbert88@comcast.net> wrote in message news:<db2dncSAkrjWvbXdRVn-ug@comcast.com>...
> Beg to differ, but many services use the well known port only to 
> establish a connection.  Consider, if you will, Host A running an FPT 
> server, and host B with three different users trying to download files 
> from host A using  FTP.  Each user's FTP client, sends a request to port 
> 21 and supplies a unique high port for the reply; that high port , 
> together with the IP address, uniquely identifies the client..  The inet 
> daemon, or whatever the O/S on host A uses, forks/spawns a process 
> running the FTP server and passes the details to it.  The FTP server 
> allocates a unique high port on which to receive future transmissions 
> and plugs that port number into its return packet.  Thereafter, that 
> instance of the FTP server is identified to the client by that port.

This is NOT how it works. ftp uses port 21 for control and port 20 for
data. If it wants to fork/spawn a process to handle the request it's up
to the implementer, but that's not the general way it works. You should
check a running ftp server and see if it creates additional processes.
Most servers uses select/poll loops to read requests and write responses
all in the same process and on the same port. It does NOT allocate yet
another port. The port/address on the client side doesn't matter to the
server as long as it has that information to respond to the request.

> How else could you maintain multiple, simultaneous, FTP sessions with 
> two, or two dozen clients?
> 
On Unix select/poll loops. Read the source code. Just about every server
works this way.

> NTP is a little different, in that it need not maintain any state 
> information concerning its clients; it gets a request, replies to that 
> request and forgets the whole transaction.  The next request and reply 
> do not depend, in any way, on previous interactions with that client. 
> 
NTP is no different in any way. NTP does in fact keep information about
requestors, partly because some clients become obnoxious and keep trying
at high frequency to rerequest data even if they've received a KOD packet.


Danny