Hi all,
I upgraded to FreeBSD 6.3-STABLE, I have 3 problems.
I think this is the right place to ask. Please someone point me out.
(1)
Previously, I ran ntpd on FreeBSD 6.2-RELEASE with dial-up, I had no problems.
Late last year I switched to ADSL and stayed behind NAT.
I found that ntpd couldn't synchronize with IPv4 NTP servers.
It got synchronized with ONLY IPv6 NTP servers.
(Note that I got IPv6 from freenet6, even machine behind NAT can still get
real IPv6 address using UDP encapsulation.)
Last week I upgraded from source to FreeBSD 6.3-STABLE (buildworld).
I found that I can not get sync with any NTP servers both IPv4 and IPv6.
The followings are my information.
# cat /etc/ntp.conf
server time.navy.mi.th prefer
server asia.pool.ntp.org
server ntp.nict.jp
driftfile /etc/ntp.drift
# ntpdc -c peers
remote local st poll reach delay offset disp
=======================================================================122.154.11.67
192.168.1.10 16 1024 0 0.00000 0.000000 0.00000
=starlite.ispwor 192.168.1.10 16 1024 0 0.00000 0.000000 0.00000
=ntp-b2.nict.go. 192.168.1.10 16 1024 0 0.00000 0.000000 0.00000
messages from syslog
Feb 25 20:00:36 bsdhost ntpd[711]: ntpd 4.2.0-a Mon Feb 18 21:23:47 ICT 2008 (1)
Feb 25 20:00:36 bsdhost ntpd[711]: bind() fd 10, family 28, port 123, addr
2001:5c0:8fff:fffe::42ad, in6_is_addr_multicast=0 flags=0 fails: Can't
assign requested address
# uname -a
FreeBSD bsdhost.localdomain 6.3-STABLE FreeBSD 6.3-STABLE #0: Mon Feb 18
23:20:40 ICT 2008 root@bsdhost.localdomain:/usr/obj/usr/src/sys/SMP i386
(2)
My next problem after buildworld is ``man pages are not updated''.
They are still FreeBSD 6.2. What happen? How to fix it?
(3)
My last problem may be irrelevant to freebsd-stable.
The problem is ``handbook is not updated''.
I ran cvsup -g -L 2 /usr/share/example/cvsup/doc-supfile.
I got many files/dirs in /usr/doc.
I simply cd into /usr/doc then ``make install'' and ``make all
install''
I guess that but it just doesn't work.
Actually I can read the new handbook from www.freebsd.org.
But I'm very curious to know how to update handbook in my computer.
Please someone point me out.
Thanks in advance.
Pongthep
Pongthep Kulkrisada wrote:> (2) > My next problem after buildworld is ``man pages are not updated''. > They are still FreeBSD 6.2. What happen? How to fix it? >You need to delete your old catman pages. find /usr/share/man/cat* -type f -exec rm -f {} \;> > Please someone point me out. > > Thanks in advance. > Pongthep-Proto
On Mon, Feb 25, 2008 at 10:07:56PM +0700, Pongthep Kulkrisada wrote:> Last week I upgraded from source to FreeBSD 6.3-STABLE (buildworld). > I found that I can not get sync with any NTP servers both IPv4 and IPv6. > The followings are my information. > > # cat /etc/ntp.conf > server time.navy.mi.th prefer > server asia.pool.ntp.org > server ntp.nict.jp > driftfile /etc/ntp.drift > > # ntpdc -c peers > remote local st poll reach delay offset disp > ======================================================================> =122.154.11.67 192.168.1.10 16 1024 0 0.00000 0.000000 0.00000 > =starlite.ispwor 192.168.1.10 16 1024 0 0.00000 0.000000 0.00000 > =ntp-b2.nict.go. 192.168.1.10 16 1024 0 0.00000 0.000000 0.00000 > > messages from syslog > Feb 25 20:00:36 bsdhost ntpd[711]: ntpd 4.2.0-a Mon Feb 18 21:23:47 ICT 2008 (1) > Feb 25 20:00:36 bsdhost ntpd[711]: bind() fd 10, family 28, port 123, addr 2001:5c0:8fff:fffe::42ad, in6_is_addr_multicast=0 flags=0 fails: Can't assign requested addressI can't help you with the IPv6 stuff; I don't use IPv6. Please do not define driftfile in /etc/ntp.conf. The /etc/rc.d/ntpd framework will take care of that for you by using -f /var/db/ntpd.drift. If I were you, I'd try sniffing traffic on your LAN segment to see if you're even getting responses from the remote NTP servers. Using tcpdump, you should be able to achieve this by doing: # tcpdump -l -n -s 8192 -p "port 123" I'm willing to bet you're not even getting responses from the remote servers, which would imply firewall rules on your gateway, or the machine itself.> (2) > My next problem after buildworld is ``man pages are not updated''. > They are still FreeBSD 6.2. What happen? How to fix it?These won't be taken care of until you do an installworld. And if you did do an installworld and your manpages are still outdated, it's being caused by the fact that there's two sets of pages: manpages located in /usr/share/man/man*, and catpages (which are manpages which have been pre-formatted, thus saving CPU time, but taking up extra disk, stored in /usr/share/man/cat*). The catpages can sometimes become outdated because of this. # find /usr/share/man/cat* -type f -delete And then enable weekly creation of the catman pages via the weekly periodic script, by placing this in /etc/periodic.conf: weekly_catman_enable="yes" You can also create those catman pages right now by setting the above variable in periodic.conf and doing the following: /etc/periodic/weekly/330.catman Keep something in mind, however: by enabling this, you're also prone to get a lot of nasty messages from groff/troff/nroff every week. A lot of manpages are not 100% syntactically correct or compatible with the version of troff FreeBSD uses, so they emit warnings. Finally, when you upgraded from 6.2 to 6.3, did you follow all of the instructions in /usr/src/Makefile perfectly? See the 10-11 steps listed under "For individuals wanting to upgrade their sources...". I'm left wondering if you didn't do the mergemaster step. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB |
Thanks Proto and Chadwick> I can't help you with the IPv6 stuff; I don't use IPv6.Actually I don't force ntpd to use IPv6. Hostnames could be resolved to any IPv4 addresses. I have no problem with that. The only thing I want is ``synchronization''.> Please do not define driftfile in /etc/ntp.conf. The /etc/rc.d/ntpd > framework will take care of that for you by using -f /var/db/ntpd.drift.I have tried it, still not work.> If I were you, I'd try sniffing traffic on your LAN segment to see if > you're even getting responses from the remote NTP servers. Using > tcpdump, you should be able to achieve this by doing: > > # tcpdump -l -n -s 8192 -p "port 123" > > I'm willing to bet you're not even getting responses from the remote > servers, which would imply firewall rules on your gateway, or the > machine itself.# tcpdump -l -n -s 8192 -p "port 123" tcpdump: listening on fxp0, link-type EN10MB (Ethernet), capture size 8182 bytes 0 packets captured 12 packets received by filter 0 packets dropped by kernel ^C (after awaiting around 20secs then hits interrupt) You are right, I didn't get any responses. I have doubly checked. Firewall on my router/gateway is disabled, not active. I have also tried disabling firewall on my machine. It still doesn't work. Actually I am not suspecting my /etc/ipfw.rules, which has been being used for long since FreeBSD 5.4. ntpd has never encountered any problems for such ipfw configuration with dial-up (both 5.4-RELEASE and 6.2-RELEASE). (I also didn't forget to change interface name from dial-up to ethernet.)> # find /usr/share/man/cat* -type f -exec rm -f {} \;or> # find /usr/share/man/cat* -type f -deleteI have tested it, I still get outdated man pages. I even dive into /usr/src/share/man. Man pages over there are all FreeBSD 6.2. But some timestamps dated Feb 13, 2008; but footer is still FreeBSD 6.2> And then enable weekly creation of the catman pages via the weekly > periodic script, by placing this in /etc/periodic.conf: > > weekly_catman_enable="yes" > > You can also create those catman pages right now by setting the above > variable in periodic.conf and doing the following: > > /etc/periodic/weekly/330.catman > > Keep something in mind, however: by enabling this, you're also prone to > get a lot of nasty messages from groff/troff/nroff every week. A lot of > manpages are not 100% syntactically correct or compatible with the > version of troff FreeBSD uses, so they emit warnings.I want them to be compatible with the current version of FreeBSD. So I will not use it, thanks.> Finally, when you upgraded from 6.2 to 6.3, did you follow all of the > instructions in /usr/src/Makefile perfectly? See the 10-11 steps > listed under "For individuals wanting to upgrade their sources...". > I'm left wondering if you didn't do the mergemaster step.No, but I perfectly followed instruction in handbook. # cvsup -g -L 2 /usr/share/examples/cvsup/stable-supfile backup data and /etc read /usr/src/UPDATING # mergemaster -p # shutdown now (drop to single user) # fsck -p # mount -u / # mount -a -t ufs # swapon -a # adjkerntz -i # cd /usr/obj # chflags -R noschg * # rm -rf * # cd /usr/src # make [-j4] buildworld # make buildkernel KERNCONF=SMP # make installkernel KERNCONF=SMP # shutdown -r now (reboot the new kernel in single user mode) # make installworld # mergemaster # shutdown -r now (reboot the new system) # uname -a (show the new kernel) And I also look in some forums. I think that the procedure above is correct. I also got many new man pages in /usr/src/share/man, but as said all are 6.2 (with some new timestamps). If so, archives in cvs repository (cvsup.th.freebsd.org) are probably outdated. If I did anything wrong, please tell me. Please note that I have been using FreeBSD since 5.0. But I ALWAYS install new system from iso image. This is my first time updating from source. And what about updating handbook? # cvsup -g -L 2 /usr/share/examples/cvsup/doc-supfile # cd /usr/doc (many dirs/files in here, like sgml files) # make all install (or) make install It just doesn't work. I don't want to waste your time; it is also irrelevant to freebsd-stable. Please just give me a brief hint. Thanks, Pongthep
> This isn't enough time. Please try this instead. > > # /etc/rc.d/ntpd stop > # /etc/rc.d/ntpdate start > > This should set your clock, even if only by a few milliseconds. > Assuming the ntpdate part is successful, continue on: > > # tcpdump -l -n -s 8192 -p "port 123" > > Now, in another window, execute: > > # /etc/rc.d/ntpd start > > Then let the tcpdump go for about 15 minutes. You aren't using the > "iburst" feature on any of the servers, so it will take some time before > they try to sync up.Alright, here is the output. Script started on Wed Feb 27 20:46:19 2008 root@bsdhost:~# /etc/rc.c/ntpd stop Stopping ntpd. root@bsdhost:~# /etc/rc.d/ntpdate start Setting date via ntp. 27 Feb 20:46:53 ntpdate[2000]: no server suitable for synchronization found root@bsdhost:~# tcpdump -l -n -s 8192 -p "port 123" tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on fxp0, link-type EN10MB (Ethernet), capture size 8192 bytes 20:51:46.149541 IP 192.168.1.10.123 > 122.154.11.67.123: NTPv4, Client, length 48 20:51:47.149369 IP 192.168.1.10.123 > 202.73.37.27.123: NTPv4, Client, length 48 20:51:48.149192 IP 192.168.1.10.123 > 133.243.238.163.123: NTPv4, Client, length 48 20:52:50.148777 IP 192.168.1.10.123 > 122.154.11.67.123: NTPv4, Client, length 48 20:52:50.148818 IP 192.168.1.10.123 > 202.73.37.27.123: NTPv4, Client, length 48 20:52:54.149147 IP 192.168.1.10.123 > 133.243.238.163.123: NTPv4, Client, length 48 20:53:53.149127 IP 192.168.1.10.123 > 202.73.37.27.123: NTPv4, Client, length 48 20:53:56.148700 IP 192.168.1.10.123 > 122.154.11.67.123: NTPv4, Client, length 48 20:53:57.149545 IP 192.168.1.10.123 > 133.243.238.163.123: NTPv4, Client, length 48 20:54:56.149586 IP 192.168.1.10.123 > 202.73.37.27.123: NTPv4, Client, length 48 20:55:02.149701 IP 192.168.1.10.123 > 122.154.11.67.123: NTPv4, Client, length 48 20:55:02.149749 IP 192.168.1.10.123 > 133.243.238.163.123: NTPv4, Client, length 48 20:56:00.148838 IP 192.168.1.10.123 > 202.73.37.27.123: NTPv4, Client, length 48 20:56:05.149070 IP 192.168.1.10.123 > 133.243.238.163.123: NTPv4, Client, length 48 20:56:07.148751 IP 192.168.1.10.123 > 122.154.11.67.123: NTPv4, Client, length 48 20:57:06.148789 IP 192.168.1.10.123 > 202.73.37.27.123: NTPv4, Client, length 48 20:57:11.148992 IP 192.168.1.10.123 > 133.243.238.163.123: NTPv4, Client, length 48 20:57:13.148718 IP 192.168.1.10.123 > 122.154.11.67.123: NTPv4, Client, length 48 20:58:10.149016 IP 192.168.1.10.123 > 202.73.37.27.123: NTPv4, Client, length 48 20:58:17.148954 IP 192.168.1.10.123 > 122.154.11.67.123: NTPv4, Client, length 48 20:58:17.148997 IP 192.168.1.10.123 > 133.243.238.163.123: NTPv4, Client, length 48 20:59:14.149296 IP 192.168.1.10.123 > 202.73.37.27.123: NTPv4, Client, length 48 20:59:22.149048 IP 192.168.1.10.123 > 122.154.11.67.123: NTPv4, Client, length 48 20:59:23.148886 IP 192.168.1.10.123 > 133.243.238.163.123: NTPv4, Client, length 48 21:00:19.149376 IP 192.168.1.10.123 > 202.73.37.27.123: NTPv4, Client, length 48 21:00:26.149309 IP 192.168.1.10.123 > 122.154.11.67.123: NTPv4, Client, length 48 21:00:29.148856 IP 192.168.1.10.123 > 133.243.238.163.123: NTPv4, Client, length 48 21:01:23.149634 IP 192.168.1.10.123 > 202.73.37.27.123: NTPv4, Client, length 48 21:01:30.149579 IP 192.168.1.10.123 > 122.154.11.67.123: NTPv4, Client, length 48 21:01:33.149117 IP 192.168.1.10.123 > 133.243.238.163.123: NTPv4, Client, length 48 21:02:29.149586 IP 192.168.1.10.123 > 202.73.37.27.123: NTPv4, Client, length 48 21:02:35.148637 IP 192.168.1.10.123 > 122.154.11.67.123: NTPv4, Client, length 48 21:02:37.149400 IP 192.168.1.10.123 > 133.243.238.163.123: NTPv4, Client, length 48 21:03:32.149004 IP 192.168.1.10.123 > 202.73.37.27.123: NTPv4, Client, length 48 21:03:40.148796 IP 192.168.1.10.123 > 133.243.238.163.123: NTPv4, Client, length 48 21:03:41.149618 IP 192.168.1.10.123 > 122.154.11.67.123: NTPv4, Client, length 48 21:04:35.149397 IP 192.168.1.10.123 > 202.73.37.27.123: NTPv4, Client, length 48 21:04:45.148898 IP 192.168.1.10.123 > 122.154.11.67.123: NTPv4, Client, length 48 21:04:46.148714 IP 192.168.1.10.123 > 133.243.238.163.123: NTPv4, Client, length 48 21:05:39.149665 IP 192.168.1.10.123 > 202.73.37.27.123: NTPv4, Client, length 48 21:05:50.148985 IP 192.168.1.10.123 > 122.154.11.67.123: NTPv4, Client, length 48 21:05:50.149032 IP 192.168.1.10.123 > 133.243.238.163.123: NTPv4, Client, length 48 21:06:44.148776 IP 192.168.1.10.123 > 202.73.37.27.123: NTPv4, Client, length 48 21:06:54.149246 IP 192.168.1.10.123 > 133.243.238.163.123: NTPv4, Client, length 48 21:06:56.148916 IP 192.168.1.10.123 > 122.154.11.67.123: NTPv4, Client, length 48 21:07:49.148879 IP 192.168.1.10.123 > 202.73.37.27.123: NTPv4, Client, length 48 21:07:58.149478 IP 192.168.1.10.123 > 133.243.238.163.123: NTPv4, Client, length 48 21:08:00.149183 IP 192.168.1.10.123 > 122.154.11.67.123: NTPv4, Client, length 48 21:09:56.149530 IP 192.168.1.10.123 > 202.73.37.27.123: NTPv4, Client, length 48 ^C 49 packets captured 230 packets received by filter 0 packets dropped by kernel root@bsdhost:~# ^D Script done on Wed Feb 27 21:10:30 2008 I also run ``/etc/rc.d/ntpd start'' on another root console right after tcpdump. Note that I appended the following lines in /etc/rc.conf and reboot prior to running ``/etc/rc.d/ntpdate start''. # grep ntpdate /etc/rc.conf ntpdate_enable="YES" ntpdate_flags="-b time.navy.mi.th asia.pool.ntp.org ntp.nict.jp" These 3 NTP servers are the same as ones in /etc/ntp.conf. And same as ones in my other machine running MS Windows. On my Windows machine behind NAT, I can always get sync with these servers. And on my FreeBSD dial-up connection, I can also get sync with these servers. But ntpdate and ntpd just don't work for the ``machine behind NAT''. Even firewall on machine and router are disabled. There must be something wrong, I don't know. Please also noted that my clock is drifted but less than 1000secs, for sure. It should not be a problem for ntpd. ...referred to ntpd(8)> > Man pages over there are all FreeBSD 6.2. > > But some timestamps dated Feb 13, 2008; but footer is still FreeBSD 6.2 > > I can confirm this on my RELENG_6 box (using 6.3). I wouldn't worry > about the footer saying 6.2.OK, thanks. I will not worry it either.> The procedure is documented in /usr/src/Makefile, and you should really > follow that. I haven't read the Handbook's documentation on what to do, > but the above seems awfully extensive for something that is described in > the Makefile (which I have used since the days of 4.x without issue).Noted, thanks.> I can't help you with anything relating to updating doc-all or your > /usr/doc tree. I'm not familiar with that, sorry.No problems, actually it is not necessary. Thanks, Pongthep
> You're not getting responses back from __any__ of those NTP servers. If > you have a firewall *in front* of your BSD box (meaning a separate box, > not ipfw/ipfilter/pf on the same BSD box!), then this is likely the > cause of the problem.The question is that two weeks ago, with same machine, same gateway, same NAT and same firewall config, when I was on FreeBSD 6.2-RELEASE and behind NAT, I could sync with ALL IPv6 servers (IPv4 is not functioning there) I said that in my first post. I'm pretty sure that if I went back to 6.2 even behind NAT, I could get sync with IPv6. Long writing since my first post I shall summarize my events here for better understanding, and sorry for redundancy. 1. FreeBSD 5.4-RELEASE(dial up) - can sync all servers 2. FreeBSD 6.2-RELEASE(dial up) - can sync all servers 3. FreeBSD 6.2-RELEASE(NAT) - can sync IPv6 servers 4. FreeBSD 6.3-STABLE (NAT) - not sync at all The issue is the different result between 3. and 4. It seems something different between 6.2-RELEASE and 6.3-STABLE. But today I hear good news for issuance of 7.0-RELEASE. I shall go on with the new RELEASE. My bad news is I've just updated to 6.3 for 2 weeks. :-(> If not, there's two explanations: > > * Your uplink provider is filtering incoming packets destined to your > network on port 123.It works with IPv6 on 6.2 behind NAT. So this reason might not be the case. IPv4 or IPv6 bind() the same port (123). In addition, I look in ntpdate/ntpd source code. They both use datagram socket (UDP). But only ntpd support AF_INET6 address family. So in my case ntpdate, which supports only IPv4, will never work on my system even on 6.2 behind NAT.> * If you're using NAT on this BSD box, somehow your NAT rules are > broken, or you're doing something bizarre with network interfaces.I'm not using BSD box as a router.> You also confirm this by stating that you're able to talk to NTP servers > if you use a dial-up connection on the same box, so it really sounds > like you have a NAT problem and not an NTP problem.Probably, but I'm not quite sure as my reason above. Thanks, Pongthep
Firstly, thank all of you for supporting me! But please note that I shall install FreeBSD 7.0-RELEASE this weekend. So I can no longer give you more information regarding 6.3-STABLE. Secondly I'm sorry for confusing you (NAT: I mean the machine ``behind NAT.'')> > 1. FreeBSD 5.4-RELEASE(dial up) - can sync all servers > > 2. FreeBSD 6.2-RELEASE(dial up) - can sync all servers > > 3. FreeBSD 6.2-RELEASE(behind NAT) - can sync IPv6 servers > > 4. FreeBSD 6.3-STABLE (behind NAT) - not sync at allThe followings are my answers to all your questions. Answers to Jeremy Chadwick...> Okay, so this really sounds like something that changed between 6.2 and > 6.3. I don't know what kind of NAT you're using; I believe FreeBSD > offers a couple different methods. > More information is required... > 1) What NAT method are you using (ipfw, ipnat, etc.)As said earlier I'm not running FreeBSD 6.3 as a router or gateway. My NAT is very simple. It is stationed at home. A ``Conexant'' router and 2 computers running Windows XP and FreeBSD 6.3-STABLE. Connection is made with CAT5e cables.> 2) What does your network topology look like (draw a diagram, referring > to each NIC/ethernet device, IPs, and so on)I'm sorry, I'm not familiar with any kinds of GUI. ISP | | dynamic IP Conexant router (firewall diabled) | 192.168.1.1 / \ / \ / \ static IP 192.168.1.10/ \ static IP 192.168.1.11 FreeBSD-6.3 Windows XP running gw6 client for IPv6 running ipfw> 3) Please post your NAT rulesNo NAT rules as per my configuration above. Or I misunderstood something!> 4) Have you checked /usr/src/UPDATING for relevant changes?Yes of course as said in my previous post. But nothing is relevant to ntpd from 6.2 to 6.3.> Then I'm not sure why you're using NAT on the box at all?I'm not using NAT on the box. I mean machine behind NAT, sorry. Answers to Peter Jeremy> If you are expecting to connect via IPv6 then the first issue you need > to address is why your ntpd is failing to generate any IPv6 packets. > Have you changed your rc.conf, ntpd.conf, hosts, nsswitch.conf or > resolv.conf since you upgraded?Since last mergemaster I only added ntpdate_enable and ntpdate_flags to /etc.rc.conf and removing driftfile from /etc/ntp.conf following suggestion from Jeremy Chadwick. Nothing else. % grep ntpdate /etc/rc.conf ntpdate_enable="YES" ntpdate_flags="-b time.navy.mi.th asia.pool.ntp.org ntp.nict.jp"> Do you have IP addresses or hostnames in your ntp.conf?% cat /etc/ntp.conf server time.navy.mi.th prefer server asia.pool.ntp.org server ntp.nict.jp> If you have hostnames, can you do an AAAA lookup on them and get back > the correct addresses?I don't know which option for nslookup to resolve AAAA record. I tried it, only IPv4 address is presented. So I use ping6 instead. Note that only the last one, ntp.nict.jp, has AAAA record. % ping6 -c 5 ntp.nict.jp PING6(56=40+8+8 bytes) 2001:5c0:8fff:fffe::42ad --> 2001:2f8:29:100::fff3 16 bytes from 2001:2f8:29:100::fff3, icmp_seq=0 hlim=30 time=552.329 ms 16 bytes from 2001:2f8:29:100::fff3, icmp_seq=1 hlim=31 time=549.556 ms 16 bytes from 2001:2f8:29:100::fff3, icmp_seq=2 hlim=31 time=593.890 ms 16 bytes from 2001:2f8:29:100::fff3, icmp_seq=3 hlim=30 time=616.043 ms 16 bytes from 2001:2f8:29:100::fff3, icmp_seq=4 hlim=31 time=610.353 ms --- ntp.nict.jp ping6 statistics --- 5 packets transmitted, 5 packets received, 0.0% packet loss round-trip min/avg/max/std-dev = 549.556/584.434/616.043/28.311 ms> If you built your own world, are you sure a NOINET6 hasn't snuck in > somewhere?I'm not quite sure, I just simply follow the procedure in handbook as per my previous post. But I CAN ping6 any IPv6 hosts. Therefore I don't think so. Answers to Clifton Royston> What the first 3 items in your list suggest, totally independent of > any questions involving 6.3 vs. 6.2, is that you don't have a NAT/LAN > configuration which works correctly with NTP on IPv4.Yes you are right.> Do any other UDP services work with NAT on IPv4, under either 6.2, > 6.3, or 5.4?Yes I ran many UDP clients/servers. Mostly I coded C on my own. All work without any problems.> If you want to confirm this is the problem, try running 6.3-STABLE on > the same dialup connection that worked for 5.4 and 6.2. My prediction > is that NTP will work via your dialup connection.Yes ntp works with both IPv4 and IPv6 on dial up. root@bsdhost:~# ntpdc -c peers remote local st poll reach delay offset disp ======================================================================*122.154.11.67 118.174.95.234 1 128 7 0.17996 -14.62198 1.93799 =www.hypercore.c 118.174.95.234 3 128 7 0.31084 -14.61814 1.93852 =ntp-b2.nict.go. :: 1 128 7 0.37003 -14.67507 1.93871> If that is case, your problem is that your NAT implementation is > broken or incomplete, or your NAT configuration also incorporates a > firewall blocking NTP. (Note also that if you connect through dial-up, > naturally you're not going through any firewall present on the LAN, so > a firewall could well be the problem.)Probably, but there is still divergence between 6.2-RELEASE and 6.3-STABLE. Thanks, Pongthep
> Clifton Royston wrote: > > You're not getting responses back from __any__ of those NTP servers. If > > you have a firewall *in front* of your BSD box (meaning a separate box, > > not ipfw/ipfilter/pf on the same BSD box!), then this is likely the > > cause of the problem.I really agree with you. I have upgraded to FreeBSD 7.0-RELEASE last weekend. The problem still persists. There must be some firewall in front of my BSD box. I will check my router/gateway. I'm sure that it's not an ntpd or BSD issue. Thanks, Pongthep