Bug 82686
Summary: | NTP wont allow client access | ||
---|---|---|---|
Product: | [Retired] Red Hat Linux | Reporter: | Alex Weeks <aweeks> |
Component: | ntp | Assignee: | Harald Hoyer <harald> |
Status: | CLOSED WORKSFORME | QA Contact: | Brian Brock <bbrock> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 8.0 | CC: | mehdi.farhat |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i386 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2003-01-27 14:45:50 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Alex Weeks
2003-01-24 21:26:46 UTC
is this line correct? restrict 192.168.0.0 mask 255.255.255.0 notrust nomodify notrap means you have 192.168.0.1-254 as your local LAN? That is correct. oh... you have forgotten: broadcast 192.168.0.0 Nope, that didn't fix it. Here is a copy of my log after I started ntpd: 27 Jan 09:20:35 ntpd[2159]: frequency initialized -102.166 from /etc/ntp/drift 27 Jan 09:20:35 ntpd[2159]: running as uid(38)/gid(38) euid(38)/egid(38). 27 Jan 09:20:35 ntpd[2159]: system event 'event_restart' (0x01) status 'sync_alarm, sync_unspec, 1 event, event_unspec' (0xc010) 27 Jan 09:20:35 ntpd[2162]: signal_no_reset: signal 17 had flags 4000000 27 Jan 09:20:44 ntpd[2159]: peer 132.236.56.250 event 'event_reach' (0x84) status 'unreach, conf, 1 event, event_reach' (0x8014) 27 Jan 09:20:51 ntpd[2159]: peer LOCAL(0) event 'event_reach' (0x84) status 'unreach, conf, 1 event, event_reach' (0x8014) I even tried shutting down my firewall and leaving everything open. well... read the documentation in /usr/share/doc/ntp-*/ I have the same "bug?" so i searched a bit and found something interesting.... 1/ my conf (grep -v -e '^[[:blank:]]*#' -e '^$' /etc/ntp.conf) restrict default ignore restrict 127.0.0.1 restrict 192.168.0.0 mask 255.255.255.0 notrust nomodify notrap restrict ntp.obspm.fr mask 255.255.255.255 nomodify notrap noquery server ntp.obspm.fr server 127.127.1.0 # local clock fudge 127.127.1.0 stratum 10 driftfile /etc/ntp/drift broadcastdelay 0.008 authenticate yes keys /etc/ntp/keys 2/ my port is open (Alex Weeks forget to use udp with nmap) [root@mars root]# nmap -sU -p123 127.0.0.1 Port State Service 123/udp open ntp 3/ ntp sync work fine in local [root@mars root]# ntpq -np remote refid st t when poll reach delay offset jitter ============================================================================== *145.238.110.68 145.238.110.49 2 u 33 128 377 54.228 -33.370 29.775 127.127.1.0 LOCAL(0) 10 l 28 64 377 0.000 0.000 0.002 4/ tcpdump [root@mars root]# tcpdump -n -i any port 123 tcpdump: listening on any 01:36:04.447293 192.168.0.200.ntp > 192.168.0.1.ntp: v3 sym_act strat 3 poll 10 prec -6 its very interesting cuz my client a poor window$ XP use NTPv3 and not NTPv4 the server never respond to the query. after an install of YATS32 (a NTPv4 client for XP) i retry to sync time. [root@mars root]# tcpdump -n -i any port 123 tcpdump: listening on any 01:39:24.188188 192.168.0.200.3442 > 192.168.0.1.ntp: v4 client strat 0 poll 0 prec 0 01:39:24.188576 192.168.0.1.ntp > 192.168.0.200.3442: v4 server strat 3 poll 0 prec -19 (DF) [tos 0x10] All work fine !!! The client take a responce from server :) now the query is ... It's a bug? or How activate the NTPv3 compatibility ? NB: Extract from ntp doc >>> "it continues the tradition of retaining backwards compatibility with older versions, including NTPv3" Have a nice day :) The default setting in /etc/sysconfig/ntpd makes ntpd run as user "ntp". I can reproduce this error exactly with this configuration. Removing "-U ntp" from OPTIONS in /etc/sysconfig/ntpd, causing ntpd to run as root, fixes the behavior described above. Mark Cornick wrote:
> On Thu, Feb 06, 2003 at 06:19:41PM +0100, Harald Hoyer wrote:
>
>>hmm, you have to wait at least 3 minutes until ntpd gets synced with the
>> real time server..
>
>
> yeah, that makes sense. ntpdate is now working from 192.168.2.2 to
> 192.168.2.1, after the ntpd has been running for a while. I don't think
> that's mentioned anywhere in the public bug report, maybe you ought to
> suggest that to the other people who reported this.
>
> Thanks for your help,
> --mark
>
|