I go to the arfcom well of knowlege once again.
A product we are developing is supposed to allow you to sync time with a NTP 3 time server. So I get to build one. All the stuff on the web is now geared towards ntp4, but we are going to use 3.

So I have built a red hat 9.0 box and loaded a ntp3 version on it. Took all the defaults for the red hat install, actually installed everything off the cd's.
Someone else got the ntp service to run, so it is up and running as a daemon now.
The problem is, none of the Windows boxes on the network see it. If I try to \\ to it, it shows network path not found. If I try net time \\ it errors out as well. XP time server settings can't find it either.
I am kindergarden level at Linux, so use small words please. Is there some service I didn't start so the linux box shows up on the network? Is there something wrong with how the NTP service is set up?
Hopefully the well isn't dry yet.

You need to point your XP boxes to the NTP server.  If they are on a 2000/2003 domain, they use the PDC Emulator by default.  If you want to point them to the Linux box, you will need to use the command line utility to point them to the NTP server.

Sorry.

Just reread your situation.  It looks more like you might have a problem with name resolution.

Have you verified that you have the correct A records in DNS for your NTP server?  If you use WINS, you checked that as well.  Can you ping the server by name, and by IP?

Sorry, should clarify, there is not a DNS. This is in a testing lab. Basically it is isolated from the rest of the network programatically. So the swtiches don't let traffic in or out except specific IP's, and the DNS servers for the building are not allowed. So I have my own dhcp server set up and mail server for the lab, but that is it. Some machines are dhcp, but I used fixed ip's for these machines.
I supposed I could turn a 2000 server into a DNS server as well. Do I need one to use a NTP server?
I can ping it by IP, I would have to set up something in the host file for name resolution to ping it by name. (Again, no DNS.)
Thanks.
BTW I apparently red hat loads with a firewall of some sort. I believe I removed it, but it still doesn't work. iptables or somethingl like that.

You could edit the hosts file, rather than set up DNS.

I don't think the host file entry is required. I can use NET Time against a windows time server using ip address, and it works fine. Just can't get anything from the Linux box. I will add it just incase though.

Well, if you can ping the Linux server by IP, but not by name, then it would be a name res issue.

If you can at least get a ping through, then you know the Linux box is at least accepting ICMP traffic.  What ports would you need to open for NTP traffic?  I can't recall off the top of my head.

I'm assuming all hosts are on the same phyiscal subnet/VLAN so that routing isn't an issue.  NTP is a open service, so you shouldn't need any type of gateway service between the two disparate systems.

I added a host file entry for it, still no good.
I looked at a NTP4 machine and found it mostly acted the same except, I could set it to look at itself for a time server which doesn't work on mine.
I looked at a network traffic sniffer built in, and I see the request and it shows some ports blocked or inacessable. I verified the firewall was down both through the gui and the command line, so it isn't that machine.
I sent off an email to IT and am checking to see if they block ports internal to the lab for some reason.
Still no idea, need a linux/unix guy I think. Could still be the network.

post your ntp.conf file. its most likely in etc or etc/inet.

ok, here it is. Not sure what it all means. Looks much cleaner in linux. note pad kind of screws it up.
cool guess it fixed it here.
# Prohibit general access to this service.
restrict default ignore
restrict 149.98.66.114 mask 255.255.255.255 nomodify notrap noquery

# Permit all access over the loopback interface.  This could
# be tightened as well, but to do so would effect some of
# the administrative functions.
restrict 127.0.0.1


# -- CLIENT NETWORK -------
# Permit systems on this network to synchronize with this
# time service.  Do not permit those systems to modify the
# configuration of this service.  Also, do not use those
# systems as peers for synchronization.
# restrict 192.168.1.0 mask 255.255.255.0 notrust nomodify notrap


# --- OUR TIMESERVERS -----
# or remove the default restrict line
# Permit time synchronization with our time source, but do not
# permit the source to query or modify the service on this system.

# restrict mytrustedtimeserverip mask 255.255.255.255 nomodify notrap noquery
# server mytrustedtimeserverip



# --- NTP MULTICASTCLIENT ---
#multicastclient # listen on default 224.0.1.1
# restrict 224.0.1.1 mask 255.255.255.255 notrust nomodify notrap
# restrict 192.168.1.0 mask 255.255.255.0 notrust nomodify notrap



# --- GENERAL CONFIGURATION ---
#
# Undisciplined Local Clock. This is a fake driver intended for backup
# and when no outside source of synchronized time is available. The
# default stratum is usually 3, but in this case we elect to use stratum
# 0. Since the server line does not have the prefer keyword, this driver
# is never used for synchronization, unless no other other
# synchronization source is available. In case the local host is
# controlled by some external source, such as an external oscillator or
# another protocol, the prefer keyword would cause the local host to
# disregard all other synchronization sources, unless the kernel
# modifications are in use and declare an unsynchronized condition.
#
server 149.98.66.114
fudge 127.127.1.0 stratum 10

#
# Drift file.  Put this in a directory which the daemon can write to.
# No symbolic links allowed, either, since the daemon updates the file
# by creating a temporary in the same directory and then rename()'ing
# it to the file.
#
driftfile /etc/ntp/drift
broadcastdelay 0.008

#
# Authentication delay.  If you use, or plan to use someday, the
# authentication facility you should make the programs in the auth_stuff
# directory and figure out what this number should be on your machine.
#
authenticate yes

#
# Keys file.  If you want to diddle your server at run time, make a
# keys file (mode 600 for sure) and define the key number to be
# used for making requests.
#
# PLEASE DO NOT USE THE DEFAULT VALUES HERE. Pick your own, or remote
# systems might be able to reset your clock at will. Note also that
# ntpd is started with a -A flag, disabling authentication, that
# will have to be removed as well.
#
keys /etc/ntp/keys

know this is the file that controls it helps. I see now there is a restrict entry at the top. I will try changing that to see if it works.

ntp uses UDP port 123 i believe.

-foxxz

Quoted: know this is the file that controls it helps. I see now there is a restrict entry at the top. I will try changing that to see if it works.

yes there are a few odditites in the .conf file. biggest issue is that the machine is looks to be set up to deny all ntp requests from outside clients. perhaps related to your lab set-up, but i doubt it. and with that .conf file, it would be expected that ntp server has been assigned a fixed IP address of 149.98.66.114. is this what you have planned? also, how does that fit into your lab set-up with the dhcp machines? are they being assigned address on the same subnet?

uncomment (remove the #) this line as well in teh client network section:

# restrict 192.168.1.0 mask 255.255.255.0 notrust nomodify notrap

the numbers may need to change based on your lab set-up.

I saw that in a file. I checked, and nothing is blocked internal to the lab I am setting this up in. I tried changing the top line so it wasn't restricted at all, but it still tells me it can't find the network path to the machine.
I am still thinking it is a set up problem on the linux side. I can no longer ftp into the machine, but I can telnet in at least. I can use the linux box to browse out to the network, but nothing can see it.

btw, changes to the ntp.conf file are only reflected if you stop then restart the service after the change. also, are you sure iptables is off? use status to check if you arent sure.

/etc/init.d/iptables status

that's my guess as to the path...

Yes, the iptables are off, I removed them from the init.d thing, and verified with a command.
Also after I changed the ntp.conf file, I rebooted. I prefer rebooting to stopping and starting a service just from past bad windows experiences. Thanks though.
I even checked if ipchains were doing something, but when I tried to stop them, it said it wasn't compatible with the kernal so I figure they weren't running either.

here are the logs from tcpdump.

[root@NTP3server root]# tcpdump |grep 149.98.66.70
tcpdump: listening on eth0
13:46:05.675208 149.98.66.70.netbios-ns > 149.98.66.255.netbios-ns: NBT UDP PACKET(137): QUERY;
REQUEST; BROADCAST
13:46:06.424198 149.98.66.70.netbios-ns > 149.98.66.255.netbios-ns: NBT UDP PACKET(137): QUERY;
REQUEST; BROADCAST
13:46:07.175275 149.98.66.70.netbios-ns > 149.98.66.255.netbios-ns: NBT UDP PACKET(137): QUERY;
REQUEST; BROADCAST
13:47:03.437093 149.98.66.70.4030 > 149.98.66.114.netbios-ssn: S 3539193:3539193(0) win 8192 <mss 1460> (DF)
13:47:03.437146 149.98.66.114.netbios-ssn > 149.98.66.70.4030: R 0:0(0) ack 3539194 win 0 (DF)
13:47:03.925861 149.98.66.70.4030 > 149.98.66.114.netbios-ssn: S 3539193:3539193(0) win 8192 <mss 1460> (DF)
13:47:03.925917 149.98.66.114.netbios-ssn > 149.98.66.70.4030: R 0:0(0) ack 1 win 0 (DF)
13:47:04.426564 149.98.66.70.4030 > 149.98.66.114.netbios-ssn: S 3539193:3539193(0) win 8192 <mss 1460> (DF)
13:47:04.426615 149.98.66.114.netbios-ssn > 149.98.66.70.4030: R 0:0(0) ack 1 win 0 (DF)
13:47:04.927276 149.98.66.70.4030 > 149.98.66.114.netbios-ssn: S 3539193:3539193(0) win 8192 <mss 1460> (DF)
13:47:04.927326 149.98.66.114.netbios-ssn > 149.98.66.70.4030: R 0:0(0) ack 1 win 0 (DF)
13:47:04.927667 149.98.66.70.netbios-ns > 149.98.66.114.netbios-ns: NBT UDP PACKET(137): QUERY;
REQUEST; BROADCAST
13:47:04.927701 149.98.66.114 > 149.98.66.70: icmp: 149.98.66.114 udp port netbios-ns unreachable [tos 0xc0]
13:47:06.429442 149.98.66.70.netbios-ns > 149.98.66.114.netbios-ns: NBT UDP PACKET(137): QUERY;
REQUEST; BROADCAST
13:47:06.429497 149.98.66.114 > 149.98.66.70: icmp: 149.98.66.114 udp port netbios-ns unreachable [tos 0xc0]
13:47:07.931571 149.98.66.70.netbios-ns > 149.98.66.114.netbios-ns: NBT UDP PACKET(137): QUERY;
REQUEST; BROADCAST
13:47:07.931625 149.98.66.114 > 149.98.66.70: icmp: 149.98.66.114 udp port netbios-ns unreachable [tos 0xc0]
13:47:08.427965 arp who-has 149.98.66.70 tell 149.98.66.114
13:47:08.428134 arp reply 149.98.66.70 is-at 0:6:29:8f:13:34

343 packets received by filter
0 packets dropped by kernel

btt

one last time