Re: [vox-tech] I'm also having ntp problems :-(
On Thursday 25 April 2002 10:52 pm, [EMAIL PROTECTED] wrote: > On Thu, Apr 25, 2002 at 06:36:47PM -0700, Ryan wrote: > > in playing with things some more, I can't get nat to connect to ANY > > services on bob... > > Cool, based on that last trace one or two things is happening: > - You have no process listing to UDP port 123 on nat > - Your firewall rules on nat are rejecting UDP traffic to port 123. > > The strace of ntpd would finalize the problem, but it looks like > you have a firewall rule filtering out the traffic. ;) No, really, I run 'nc -lp 1234' on bob, then 'nc bob 1234' on nat and it times out. I also can't ssh from nat to bob (or fnord, my other box) ___ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] I'm also having ntp problems :-(
On Thu, Apr 25, 2002 at 06:36:47PM -0700, Ryan wrote: > in playing with things some more, I can't get nat to connect to ANY > services on bob... Cool, based on that last trace one or two things is happening: - You have no process listing to UDP port 123 on nat - Your firewall rules on nat are rejecting UDP traffic to port 123. The strace of ntpd would finalize the problem, but it looks like you have a firewall rule filtering out the traffic. ;) ___ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] I'm also having ntp problems :-(
On Wednesday 24 April 2002 11:31 pm, [EMAIL PROTECTED] wrote: > my bad, I kinda expect a verbose tcpdump... > tcpdump -tteni eth0 > -tt switches to a better time format, > -e shows ethernet mac address info > -n doesn't do name/server lookups so it's harder to hide errors. > -i eth0 : you know this > > I would like a trace of the same even from both hosts bob and nat... > since tcpdump's view of events is sometimes faked out by firewall > rules on the machine running the dump (things it sees don't really > happen on the wire). [root@bob root]# tcpdump -ttne tcpdump: listening on eth0 1019784403.866888 0:c0:f0:70:5:3d 0:40:5:74:4e:46 0800 90: 192.168.0.10.123 > 192.168.0.1.123: v4 client strat 0 poll 4 prec -6 (DF) 1019784403.867759 0:40:5:74:4e:46 0:c0:f0:70:5:3d 0800 118: 192.168.0.1 > 192.168.0.10: icmp: 192.168.0.1 udp port 123 unreachable [tos 0xc0] 1019784404.866821 0:c0:f0:70:5:3d 0:40:5:74:4e:46 0800 90: 192.168.0.10.123 > 192.168.0.1.123: v4 client strat 0 poll 4 prec -6 (DF) 1019784404.867643 0:40:5:74:4e:46 0:c0:f0:70:5:3d 0800 118: 192.168.0.1 > 192.168.0.10: icmp: 192.168.0.1 udp port 123 unreachable [tos 0xc0] 1019784405.866835 0:c0:f0:70:5:3d 0:40:5:74:4e:46 0800 90: 192.168.0.10.123 > 192.168.0.1.123: v4 client strat 0 poll 4 prec -6 (DF) 1019784405.867660 0:40:5:74:4e:46 0:c0:f0:70:5:3d 0800 118: 192.168.0.1 > 192.168.0.10: icmp: 192.168.0.1 udp port 123 unreachable [tos 0xc0] 1019784406.866822 0:c0:f0:70:5:3d 0:40:5:74:4e:46 0800 90: 192.168.0.10.123 > 192.168.0.1.123: v4 client strat 0 poll 4 prec -6 (DF) 1019784406.867643 0:40:5:74:4e:46 0:c0:f0:70:5:3d 0800 118: 192.168.0.1 > 192.168.0.10: icmp: 192.168.0.1 udp port 123 unreachable [tos 0xc0] [root@nat root]# tcpdump -ttne tcpdump: listening on eth0 1019784406.612164 0:c0:f0:70:5:3d 0:40:5:74:4e:46 0800 90: 192.168.0.10.123 > 192.168.0.1.123: v4 client strat 0 poll 4 prec -6 (DF) 1019784406.612481 0:40:5:74:4e:46 0:c0:f0:70:5:3d 0800 118: 192.168.0.1 > 192.168.0.10: icmp: 192.168.0.1 udp port 123 unreachable [tos 0xc0] 1019784407.611976 0:c0:f0:70:5:3d 0:40:5:74:4e:46 0800 90: 192.168.0.10.123 > 192.168.0.1.123: v4 client strat 0 poll 4 prec -6 (DF) 1019784407.612251 0:40:5:74:4e:46 0:c0:f0:70:5:3d 0800 118: 192.168.0.1 > 192.168.0.10: icmp: 192.168.0.1 udp port 123 unreachable [tos 0xc0] 1019784408.611880 0:c0:f0:70:5:3d 0:40:5:74:4e:46 0800 90: 192.168.0.10.123 > 192.168.0.1.123: v4 client strat 0 poll 4 prec -6 (DF) 1019784408.612151 0:40:5:74:4e:46 0:c0:f0:70:5:3d 0800 118: 192.168.0.1 > 192.168.0.10: icmp: 192.168.0.1 udp port 123 unreachable [tos 0xc0] 1019784409.611749 0:c0:f0:70:5:3d 0:40:5:74:4e:46 0800 90: 192.168.0.10.123 > 192.168.0.1.123: v4 client strat 0 poll 4 prec -6 (DF) 1019784409.612021 0:40:5:74:4e:46 0:c0:f0:70:5:3d 0800 118: 192.168.0.1 > 192.168.0.10: icmp: 192.168.0.1 udp port 123 unreachable [tos 0xc0] in playing with things some more, I can't get nat to connect to ANY services on bob... ___ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] I'm also having ntp problems :-(
Well, after something like 16 months at the same IP, the ISP has decided to issue a new address to moria so DNS information is broken, and I'm not going to receive any email until it is fixed... worse yet if someone acquires the previous address email to me may begin to bounce. If anyone wondered why I started participating in vox-tech email it was because just a few days ago the DNS records were fixed, they had been broken for about 16 months which delayed mail to moria by over 24 hours most of the time. Sigh, Mike ...back to playing with debmirror. On Thu, Apr 25, 2002 at 02:31:49AM -0400, [EMAIL PROTECTED] wrote: > On Wed, Apr 24, 2002 at 11:21:56PM -0700, Ryan wrote: > > On Wednesday 24 April 2002 11:11 pm, [EMAIL PROTECTED] wrote: > > > On Wed, Apr 24, 2002 at 11:04:01PM -0700, Ryan wrote: ___ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] I'm also having ntp problems :-(
On Wed, Apr 24, 2002 at 11:21:56PM -0700, Ryan wrote: > On Wednesday 24 April 2002 11:11 pm, [EMAIL PROTECTED] wrote: > > On Wed, Apr 24, 2002 at 11:04:01PM -0700, Ryan wrote: > > > The following seems to be happening... > > > > > > connections to a udp server on nat work fine both ways. > > > > > > connections to a udp server on bob only work for sending data to bob. > > > > > > in tcpdump, I see nat telling bob that the udp port is unreachable, yet > > > bob has no firewall. > > > > > > Very odd. > > > > Can you paste a 10 line tcpdump log showing this event? my bad, I kinda expect a verbose tcpdump... tcpdump -tteni eth0 -tt switches to a better time format, -e shows ethernet mac address info -n doesn't do name/server lookups so it's harder to hide errors. -i eth0 : you know this I would like a trace of the same even from both hosts bob and nat... since tcpdump's view of events is sometimes faked out by firewall rules on the machine running the dump (things it sees don't really happen on the wire). > 23:18:56.151057 bob.ntp > nat.ntp: [udp sum ok] v4 client strat 0 poll 4 prec -6 >dist 1.00 disp 1.00 ref (unspec)@0.0 orig 0.0 rec >-0.0 xmt -1066262965.417984008 (DF) (ttl 64, id 0, len 76) > 23:18:56.151341 nat > bob: icmp: nat udp port ntp unreachable for bob.ntp > nat.ntp: > v4 client strat 0 poll 4 prec -6 dist 1.00 disp 1.00 ref >(unspec)@0.0 [|ntp] (DF) (ttl 64, id 0, len 76) [tos 0xc0] (ttl 255, id >20476, len 104) ___ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] I'm also having ntp problems :-(
On Wednesday 24 April 2002 11:11 pm, [EMAIL PROTECTED] wrote: > On Wed, Apr 24, 2002 at 11:04:01PM -0700, Ryan wrote: > > The following seems to be happening... > > > > connections to a udp server on nat work fine both ways. > > > > connections to a udp server on bob only work for sending data to bob. > > > > in tcpdump, I see nat telling bob that the udp port is unreachable, yet > > bob has no firewall. > > > > Very odd. > > Can you paste a 10 line tcpdump log showing this event? 23:18:56.151057 bob.ntp > nat.ntp: [udp sum ok] v4 client strat 0 poll 4 prec -6 dist 1.00 disp 1.00 ref (unspec)@0.0 orig 0.0 rec -0.0 xmt -1066262965.417984008 (DF) (ttl 64, id 0, len 76) 23:18:56.151341 nat > bob: icmp: nat udp port ntp unreachable for bob.ntp > nat.ntp: v4 client strat 0 poll 4 prec -6 dist 1.00 disp 1.00 ref (unspec)@0.0 [|ntp] (DF) (ttl 64, id 0, len 76) [tos 0xc0] (ttl 255, id 20476, len 104) [repeated 3 times] > A little background, > nat is (the nat/firewall/ntp machine) > bob is (the client) > if not correct please explain. Yes, correct. nat's main job is to do NAT and firewall stuff. > > On Wednesday 24 April 2002 10:51 pm, [EMAIL PROTECTED] wrote: > > > On Wed, Apr 24, 2002 at 10:26:13PM -0700, Ryan wrote: > > > > On Wednesday 24 April 2002 10:04 pm, [EMAIL PROTECTED] wrote: > > > > > Something is preventing port 123 UDP packets from going between > > > > > bob and nat, you can see packets be transmitted and no reply. It > > > > > could also be that your ntpd is configured to not accept > > > > > connections from bob. > > > > > > > > This can now be blamed on firewall rules. > > > > > > Something doesn't look right about this... > > > > > > Both ntdq and ntpdate create the same type of UDP based socket, > > > running from the same machine one of them gets replies the other > > > does not (the packets are different sizes). It is true that some > > > length based firewall checks could be blocking the replies... but > > > it's important to figure out what is broken before changing things > > > and I still don't have enough information. It could be either ntpd > > > or the firewall, since it could as likely be server configuration > > > (like only accepting certain client revisions). > > > > > > If it still doesn't work after you have fun looking through your > > > firewall rules install strace on the firewall and run the trace > > > requested below. If you can't use "apt-get install strace" then > > > remember it is simply one big executable, scp it to the firewall > > > from a similar machine and just run the binary from /tmp then > > > nuke it. > > > > ___ > > vox-tech mailing list > > [EMAIL PROTECTED] > > http://lists.lugod.org/mailman/listinfo/vox-tech > > ___ > vox-tech mailing list > [EMAIL PROTECTED] > http://lists.lugod.org/mailman/listinfo/vox-tech ___ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] I'm also having ntp problems :-(
On Wed, Apr 24, 2002 at 11:04:01PM -0700, Ryan wrote: > The following seems to be happening... > > connections to a udp server on nat work fine both ways. > > connections to a udp server on bob only work for sending data to bob. > > in tcpdump, I see nat telling bob that the udp port is unreachable, yet bob > has no firewall. > > Very odd. Can you paste a 10 line tcpdump log showing this event? A little background, nat is (the nat/firewall/ntp machine) bob is (the client) if not correct please explain. > On Wednesday 24 April 2002 10:51 pm, [EMAIL PROTECTED] wrote: > > On Wed, Apr 24, 2002 at 10:26:13PM -0700, Ryan wrote: > > > On Wednesday 24 April 2002 10:04 pm, [EMAIL PROTECTED] wrote: > > > > Something is preventing port 123 UDP packets from going between > > > > bob and nat, you can see packets be transmitted and no reply. It > > > > could also be that your ntpd is configured to not accept connections > > > > from bob. > > > > > > This can now be blamed on firewall rules. > > > > Something doesn't look right about this... > > > > Both ntdq and ntpdate create the same type of UDP based socket, > > running from the same machine one of them gets replies the other > > does not (the packets are different sizes). It is true that some > > length based firewall checks could be blocking the replies... but > > it's important to figure out what is broken before changing things > > and I still don't have enough information. It could be either ntpd > > or the firewall, since it could as likely be server configuration > > (like only accepting certain client revisions). > > > > If it still doesn't work after you have fun looking through your > > firewall rules install strace on the firewall and run the trace > > requested below. If you can't use "apt-get install strace" then > > remember it is simply one big executable, scp it to the firewall > > from a similar machine and just run the binary from /tmp then > > nuke it. > ___ > vox-tech mailing list > [EMAIL PROTECTED] > http://lists.lugod.org/mailman/listinfo/vox-tech ___ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] I'm also having ntp problems :-(
The following seems to be happening... connections to a udp server on nat work fine both ways. connections to a udp server on bob only work for sending data to bob. in tcpdump, I see nat telling bob that the udp port is unreachable, yet bob has no firewall. Very odd. On Wednesday 24 April 2002 10:51 pm, [EMAIL PROTECTED] wrote: > On Wed, Apr 24, 2002 at 10:26:13PM -0700, Ryan wrote: > > On Wednesday 24 April 2002 10:04 pm, [EMAIL PROTECTED] wrote: > > > Something is preventing port 123 UDP packets from going between > > > bob and nat, you can see packets be transmitted and no reply. It > > > could also be that your ntpd is configured to not accept connections > > > from bob. > > > > This can now be blamed on firewall rules. > > Something doesn't look right about this... > > Both ntdq and ntpdate create the same type of UDP based socket, > running from the same machine one of them gets replies the other > does not (the packets are different sizes). It is true that some > length based firewall checks could be blocking the replies... but > it's important to figure out what is broken before changing things > and I still don't have enough information. It could be either ntpd > or the firewall, since it could as likely be server configuration > (like only accepting certain client revisions). > > If it still doesn't work after you have fun looking through your > firewall rules install strace on the firewall and run the trace > requested below. If you can't use "apt-get install strace" then > remember it is simply one big executable, scp it to the firewall > from a similar machine and just run the binary from /tmp then > nuke it. ___ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] I'm also having ntp problems :-(
On Wed, Apr 24, 2002 at 10:26:13PM -0700, Ryan wrote:
> On Wednesday 24 April 2002 10:04 pm, [EMAIL PROTECTED] wrote:
> > Something is preventing port 123 UDP packets from going between
> > bob and nat, you can see packets be transmitted and no reply. It
> > could also be that your ntpd is configured to not accept connections
> > from bob.
>
> This can now be blamed on firewall rules.
Something doesn't look right about this...
Both ntdq and ntpdate create the same type of UDP based socket,
running from the same machine one of them gets replies the other
does not (the packets are different sizes). It is true that some
length based firewall checks could be blocking the replies... but
it's important to figure out what is broken before changing things
and I still don't have enough information. It could be either ntpd
or the firewall, since it could as likely be server configuration
(like only accepting certain client revisions).
If it still doesn't work after you have fun looking through your
firewall rules install strace on the firewall and run the trace
requested below. If you can't use "apt-get install strace" then
remember it is simply one big executable, scp it to the firewall
from a similar machine and just run the binary from /tmp then
nuke it.
> [root@bob root]# strace -e connect,socket,sendto ntpq -ddn -c peers
> 192.168.0.1 2>&1 | grep -Ev '(htons\(53\)|AF_UNIX|PF_UNIX)'
>
> socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 3
> connect(3, {sin_family=AF_INET, sin_port=htons(123),
> sin_addr=inet_addr("192.168.0.1")}}, 16) = 0
> Got packet, size = 20
>
> [root@bob root]# strace -e connect,socket,sendto ntpdate -qd 192.168.0.1 2>&1
> | grep -Ev '(htons\(53\)|AF_UNIX|PF_UNIX)'
>
> 24 Apr 22:17:59 ntpdate[7455]: ntpdate [EMAIL PROTECTED] Wed Feb 27 16:42:53 CET
> 2002 (1)
> socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 3
> --- SIGALRM (Alarm clock) ---
> transmit(192.168.0.1)
> sendto(3, "\343\0\4\372\0\1\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 48, 0,
> {sin_family=AF_INET, sin_port=htons(123),
> sin_addr=inet_addr("192.168.0.1")}}, 16) = 48
> --- SIGALRM (Alarm clock) ---
> --- SIGALRM (Alarm clock) ---
___
vox-tech mailing list
[EMAIL PROTECTED]
http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] I'm also having ntp problems :-(
On Wednesday 24 April 2002 10:04 pm, [EMAIL PROTECTED] wrote:
> Something is preventing port 123 UDP packets from going between
> bob and nat, you can see packets be transmitted and no reply. It
> could also be that your ntpd is configured to not accept connections
> from bob.
Debugging things with netcat in udp mode reveals that if bob runs
`nc -ulp 123` bob recives packets, but can't get them back to nat.
With nc listening on nat, however, it works both ways.
This can now be blamed on firewall rules.
Ugh.
> Below are two commands as they show up on my local network,
> if you could verify that the UDP packets are not being dropped,
> then send the output from the following commands it would help.
>
> root@star:/tmp#
> strace -e connect,socket,sendto ntpq -ddn -c peers 10.1.1.1 2>&1 |
> grep -Ev '(htons\(53\)|AF_UNIX|PF_UNIX)'
>
>
> # socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 3
> # connect(3, {sin_family=AF_INET, sin_port=htons(123),
> sin_addr=inet_addr("10.1.1.1")}}, 16) = 0 # Got packet, size = 24
> # Packet okay
> # remote refid st t when poll reach delay offset
> jitter #
> ===
>=== # Got packet, size = 428
> # Packet okay
> # Got packet, size = 192
> # Packet okay
> # +169.237.105.80 192.5.41.41 2 u 28 256 377 32.159 -11.673
> 4.231
[root@bob root]# strace -e connect,socket,sendto ntpq -ddn -c peers
192.168.0.1 2>&1 | grep -Ev '(htons\(53\)|AF_UNIX|PF_UNIX)'
socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 3
connect(3, {sin_family=AF_INET, sin_port=htons(123),
sin_addr=inet_addr("192.168.0.1")}}, 16) = 0
Got packet, size = 20
Packet okay
remote refid st t when poll reach delay offset jitter
==
Got packet, size = 420
Packet okay
Got packet, size = 204
Packet okay
*192.43.244.18 .ACTS. 1 u 135 512 377 133.955 -2.932 12.280
Got packet, size = 428
Packet okay
Got packet, size = 192
Packet okay
+207.215.64.108 192.5.41.41 2 u 98 512 377 25.751 23.138 1.170
> root@star:/tmp#
> strace -e connect,socket,sendto ntpdate -qd 10.1.1.1 |
> grep -Ev '(htons\(53\)|AF_UNIX|PF_UNIX)'
>
> # socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 3
> # 24 Apr 21:59:09 ntpdate[12079]: ntpdate 4.1.0 Mon Mar 25 23:39:50 UTC
> 2002 (2) # --- SIGALRM (Alarm clock) ---
> # transmit(10.1.1.1)
> # sendto(3, "\343\0\4\372\0\1\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"...,
> 48, 0, {sin_family=AF_INET, sin_port=htons(123),
> sin_addr=inet_addr("10.1.1.1")}}, 16) = # 48
> # receive(10.1.1.1)
> # transmit(10.1.1.1)
> # sendto(3, "\343\0\4\372\0\1\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"...,
> 48, 0, {sin_family=AF_INET, sin_port=htons(123),
> sin_addr=inet_addr("10.1.1.1")}}, 16) = # 48
>
[root@bob root]# strace -e connect,socket,sendto ntpdate -qd 192.168.0.1 2>&1
| grep -Ev '(htons\(53\)|AF_UNIX|PF_UNIX)'
24 Apr 22:17:59 ntpdate[7455]: ntpdate [EMAIL PROTECTED] Wed Feb 27 16:42:53 CET
2002 (1)
socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 3
--- SIGALRM (Alarm clock) ---
transmit(192.168.0.1)
sendto(3, "\343\0\4\372\0\1\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 48, 0,
{sin_family=AF_INET, sin_port=htons(123),
sin_addr=inet_addr("192.168.0.1")}}, 16) = 48
--- SIGALRM (Alarm clock) ---
--- SIGALRM (Alarm clock) ---
--- SIGALRM (Alarm clock) ---
--- SIGALRM (Alarm clock) ---
--- SIGALRM (Alarm clock) ---
transmit(192.168.0.1)
sendto(3, "\343\0\4\372\0\1\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 48, 0,
{sin_family=AF_INET, sin_port=htons(123),
sin_addr=inet_addr("192.168.0.1")}}, 16) = 48
--- SIGALRM (Alarm clock) ---
--- SIGALRM (Alarm clock) ---
--- SIGALRM (Alarm clock) ---
--- SIGALRM (Alarm clock) ---
--- SIGALRM (Alarm clock) ---
transmit(192.168.0.1)
sendto(3, "\343\0\4\372\0\1\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 48, 0,
{sin_family=AF_INET, sin_port=htons(123),
sin_addr=inet_addr("192.168.0.1")}}, 16) = 48
--- SIGALRM (Alarm clock) ---
--- SIGALRM (Alarm clock) ---
--- SIGALRM (Alarm clock) ---
--- SIGALRM (Alarm clock) ---
--- SIGALRM (Alarm clock) ---
transmit(192.168.0.1)
sendto(3, "\343\0\4\372\0\1\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 48, 0,
{sin_family=AF_INET, sin_port=htons(123),
sin_addr=inet_addr("192.168.0.1")}}, 16) = 48
--- SIGALRM (Alarm clock) ---
--- SIGALRM (Alarm clock) ---
--- SIGALRM (Alarm clock) ---
--- SIGALRM (Alarm clock) ---
--- SIGALRM (Alarm clock) ---
transmit(192.168.0.1)
192.168.0.1: Server dropped: no data
server 192.168.0.1, port 123
stratum 0, precision 0, leap 00, trust 000
refid [0.0.0.0], delay 0.0, dispersion 64.0
transmitted 4, in filter 4
reference time:. Wed, Feb 6 2036 22:28:16.000
originate timestamp: . Wed, Feb 6 2036 22:28:16.000
transmit timestamp: c072100a.953f39d1 Wed, Apr 24 2002 22:18:02.582
filter delay: 0.0 0.0 0.0 0.0
0.0
Re: [vox-tech] I'm also having ntp problems :-(
On Wed, Apr 24, 2002 at 09:37:08PM -0700, Ryan wrote:
> On Wednesday 24 April 2002 08:16 pm, [EMAIL PROTECTED] wrote:
> > I would recommend you drop localhost from your configuration then pick
> > a series of time servers which are the same stratum.
>
> Ok, didn't help...
>
> > > [root@bob root]# ntpdate nat
> > > 24 Apr 18:02:18 ntpdate[3482]: no server suitable for synchronization
> > > found
> >
> > If you add -q it will show you the results from each machines it tried,
> > and which one it would pick. A -d to see what it's doing, in the
> > output look for a line like this:
> > # stratum 16, precision -17, leap 11, trust 000
> > When a machine reports itself at stratum 16, it is basically saying
> > don't trust me, I don't think I'm synchronized against anything.
>
> [root@bob root]# ntpdate -q nat
> transmit(192.168.0.1)
> transmit(192.168.0.1)
> transmit(192.168.0.1)
> transmit(192.168.0.1)
> transmit(192.168.0.1)
> 192.168.0.1: Server dropped: no data
Something is preventing port 123 UDP packets from going between
bob and nat, you can see packets be transmitted and no reply. It
could also be that your ntpd is configured to not accept connections
from bob.
Below are two commands as they show up on my local network,
if you could verify that the UDP packets are not being dropped,
then send the output from the following commands it would help.
root@star:/tmp#
strace -e connect,socket,sendto ntpq -ddn -c peers 10.1.1.1 2>&1 |
grep -Ev '(htons\(53\)|AF_UNIX|PF_UNIX)'
# socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 3
# connect(3, {sin_family=AF_INET, sin_port=htons(123),
sin_addr=inet_addr("10.1.1.1")}}, 16) = 0
# Got packet, size = 24
# Packet okay
# remote refid st t when poll reach delay offset jitter
# ==
# Got packet, size = 428
# Packet okay
# Got packet, size = 192
# Packet okay
# +169.237.105.80 192.5.41.41 2 u 28 256 377 32.159 -11.673 4.231
root@star:/tmp#
strace -e connect,socket,sendto ntpdate -qd 10.1.1.1 |
grep -Ev '(htons\(53\)|AF_UNIX|PF_UNIX)'
# socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 3
# 24 Apr 21:59:09 ntpdate[12079]: ntpdate 4.1.0 Mon Mar 25 23:39:50 UTC 2002 (2)
# --- SIGALRM (Alarm clock) ---
# transmit(10.1.1.1)
# sendto(3, "\343\0\4\372\0\1\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 48, 0,
{sin_family=AF_INET, sin_port=htons(123), sin_addr=inet_addr("10.1.1.1")}}, 16) =
# 48
# receive(10.1.1.1)
# transmit(10.1.1.1)
# sendto(3, "\343\0\4\372\0\1\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 48, 0,
{sin_family=AF_INET, sin_port=htons(123), sin_addr=inet_addr("10.1.1.1")}}, 16) =
# 48
Now on the firewall...
root@seawolf:~# strace -p `pidof ntpd` -e recvfrom
# --- SIGALRM (Alarm clock) ---
# recvfrom(6, "\343\0\4\372\0\1\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 500, 0,
{sin_family=AF_INET, sin_port=htons(1458), sin_addr=inet_addr("10.1.1.27")}}, [16]) =
48
# recvfrom(6, "\343\0\4\372\0\1\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 500, 0,
{sin_family=AF_INET, sin_port=htons(1458), sin_addr=inet_addr("10.1.1.27")}}, [16]) =
48
# recvfrom(6, "\343\0\4\372\0\1\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 500, 0,
{sin_family=AF_INET, sin_port=htons(1458), sin_addr=inet_addr("10.1.1.27")}}, [16]) =
48
# recvfrom(6, "\343\0\4\372\0\1\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 500, 0,
{sin_family=AF_INET, sin_port=htons(1458), sin_addr=inet_addr("10.1.1.27")}}, [16]) =
48
# --- SIGALRM (Alarm clock) ---
___
vox-tech mailing list
[EMAIL PROTECTED]
http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] I'm also having ntp problems :-(
On Wednesday 24 April 2002 08:16 pm, [EMAIL PROTECTED] wrote: > On Wed, Apr 24, 2002 at 06:03:56PM -0700, Ryan wrote: > > I just set up ntpd on my firewall, and am trying to use it as a ntp relay > > to sync my local lan to. > > [...] > > > The port's open and it will tell me about it's peers when i connect to it > > with ntpq... > > For a few minutes after restarting the ntpd it will tell clients not > to synchronize off of itself. You may have to wait (about 5 mins) for > the server to get itself happy. Nope, that's not it :-( > > [root@bob root]# ntpq -c peers nat > > remote refid st t when poll reach delay offset > > jitter > > = > >= LOCAL(0)LOCAL(0)10 l- 64 3770.000 > > 0.000 0.000 *time.nist.gov .ACTS. 1 u- 64 377 > > 66.324 11.718 1.090 +step.mother.com ntp1.usno.navy. 2 u 14 64 > > 377 26.117 -0.109 0.941 > >^^ stratum column > > From what I understand you have the "nat" machine synchronizing off of > three sources, itself and two remote time servers, it has picked > time.nist.gov to use as it's reference (probably because it has a lower > stratum level). When I last played around with ntp clients I found that > regardless of how close different sources are from localtime, the clients > would first sort by stratum, then all the machines with the lowest stratum > would be selected for "closest to me". > > You don't have a reliable local time source so you shouldn't sync against > the local machine, I've seen ntp servers that have themselves in their > peers list rule out the other servers (because of network connections), > then go around reporting themselves as stratum 0 machines, which can > totally other clients using that machine's clock (because of the block > above). > > I would recommend you drop localhost from your configuration then pick > a series of time servers which are the same stratum. Ok, didn't help... > > [root@bob root]# ntpdate nat > > 24 Apr 18:02:18 ntpdate[3482]: no server suitable for synchronization > > found > > If you add -q it will show you the results from each machines it tried, > and which one it would pick. A -d to see what it's doing, in the > output look for a line like this: > # stratum 16, precision -17, leap 11, trust 000 > When a machine reports itself at stratum 16, it is basically saying > don't trust me, I don't think I'm synchronized against anything. [root@bob root]# ntpdate -q nat24 Apr 21:30:47 ntpdate[7067]: ntpdate [EMAIL PROTECTED] Wed Feb 27 16:42:53 CET 2002 (1) transmit(192.168.0.1) transmit(192.168.0.1) transmit(192.168.0.1) transmit(192.168.0.1) transmit(192.168.0.1) 192.168.0.1: Server dropped: no data server 192.168.0.1, port 123 stratum 0, precision 0, leap 00, trust 000 refid [0.0.0.0], delay 0.0, dispersion 64.0 transmitted 4, in filter 4 reference time:. Wed, Feb 6 2036 22:28:16.000 originate timestamp: . Wed, Feb 6 2036 22:28:16.000 transmit timestamp: c07204fa.dcaf9229 Wed, Apr 24 2002 21:30:50.862 filter delay: 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 filter offset: 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 delay 0.0, dispersion 64.0 offset 0.00 24 Apr 21:30:51 ntpdate[7067]: no server suitable for synchronization found > If you try this stuff and are still having problems post some more > details. > > Later, > Mike > ___ > vox-tech mailing list > [EMAIL PROTECTED] > http://lists.lugod.org/mailman/listinfo/vox-tech ___ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] I'm also having ntp problems :-(
On Wed, Apr 24, 2002 at 06:03:56PM -0700, Ryan wrote: > I just set up ntpd on my firewall, and am trying to use it as a ntp relay to > sync my local lan to. [...] > The port's open and it will tell me about it's peers when i connect to it > with ntpq... For a few minutes after restarting the ntpd it will tell clients not to synchronize off of itself. You may have to wait (about 5 mins) for the server to get itself happy. > [root@bob root]# ntpq -c peers nat > remote refid st t when poll reach delay offset jitter > == > LOCAL(0)LOCAL(0)10 l- 64 3770.0000.000 0.000 > *time.nist.gov .ACTS. 1 u- 64 377 66.324 11.718 1.090 > +step.mother.com ntp1.usno.navy. 2 u 14 64 377 26.117 -0.109 0.941 ^^ stratum column From what I understand you have the "nat" machine synchronizing off of three sources, itself and two remote time servers, it has picked time.nist.gov to use as it's reference (probably because it has a lower stratum level). When I last played around with ntp clients I found that regardless of how close different sources are from localtime, the clients would first sort by stratum, then all the machines with the lowest stratum would be selected for "closest to me". You don't have a reliable local time source so you shouldn't sync against the local machine, I've seen ntp servers that have themselves in their peers list rule out the other servers (because of network connections), then go around reporting themselves as stratum 0 machines, which can totally other clients using that machine's clock (because of the block above). I would recommend you drop localhost from your configuration then pick a series of time servers which are the same stratum. > [root@bob root]# ntpdate nat > 24 Apr 18:02:18 ntpdate[3482]: no server suitable for synchronization found If you add -q it will show you the results from each machines it tried, and which one it would pick. A -d to see what it's doing, in the output look for a line like this: # stratum 16, precision -17, leap 11, trust 000 When a machine reports itself at stratum 16, it is basically saying don't trust me, I don't think I'm synchronized against anything. If you try this stuff and are still having problems post some more details. Later, Mike ___ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech
[vox-tech] I'm also having ntp problems :-(
I just set up ntpd on my firewall, and am trying to use it as a ntp relay to sync my local lan to. It no work. The port's open and it will tell me about it's peers when i connect to it with ntpq... [root@bob root]# ntpq -c peers nat remote refid st t when poll reach delay offset jitter == LOCAL(0)LOCAL(0)10 l- 64 3770.0000.000 0.000 *time.nist.gov .ACTS. 1 u- 64 377 66.324 11.718 1.090 +step.mother.com ntp1.usno.navy. 2 u 14 64 377 26.117 -0.109 0.941 But trying to get the time from it is a problem. [root@bob root]# ntpdate nat 24 Apr 18:02:18 ntpdate[3482]: no server suitable for synchronization found ___ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech
