Re: ntp strangeness
Alexander Yurchenko: > > > I ran tcpdump on the server listening for packets from 224.0.1.1 to know > > > when it's transmitting, > > > > OpenBSD's ntpd doesn't use multicast. What the heck are you talking > > about? > > may be PTP. No, 224.0.1.1 is NTP, alright. PTP defaults to 224.0.1.129. -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: ntp strangeness
On Fri, Jan 30, 2009 at 01:24:54PM +, Christian Weisgerber wrote: > Steve Laurie wrote: > > > I have one machine setup as a NTP server and another setup as couple of > > others setup as NTP clients. > > > > I ran tcpdump on the server listening for packets from 224.0.1.1 to know > > when it's transmitting, on the default router machine that's running pf as > > well > > as on the client. > > OpenBSD's ntpd doesn't use multicast. What the heck are you talking > about? may be PTP. > > -- > Christian "naddy" Weisgerber na...@mips.inka.de -- Alexander Yurchenko
Re: ntp strangeness
Steve Laurie wrote: > I have one machine setup as a NTP server and another setup as couple of > others setup as NTP clients. > > I ran tcpdump on the server listening for packets from 224.0.1.1 to know > when it's transmitting, on the default router machine that's running pf as > well > as on the client. OpenBSD's ntpd doesn't use multicast. What the heck are you talking about? -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: ntp strangeness
On 2009-01-30, Steve Laurie wrote: > Hi all, > > I noticed something I can't explain or find any explanation for > anywhere. > > I have one machine setup as a NTP server and another setup as couple of > others setup as NTP clients. A little more information wouldn't hurt. I guess you are talking about ntpd from ports, not base (unless someone sneaked in multicast support without me noticing :) > I ran tcpdump on the server listening for packets from 224.0.1.1 to know > when it's transmitting, on the default router machine that's running pf as > well > as on the client. > > The server of course showed the packets and so did the gateway machine > but tcpdump on the client wouldn't detect the packets unless the ntp > daemon was actually running. > > Shouldn't tcpdump have picked up the packets off the wire regardless of > whether the ntp daemon was running or not? The packets are still being > broadcast and the daemon can't stop that. I'd have thought tcpdump would ^ > have detected the packets lower down the stack before they even got to > the daemon. this is multicast not broadcast. Your switch is probably doing igmp snooping, in which case: no join request -> switch doesn't send mcast frames -> nothing to see on the wire.
Re: ntp strangeness
On Fri, Jan 30, 2009 at 11:07:03PM +1100, Steve Laurie wrote: > Hi all, > > I noticed something I can't explain or find any explanation for > anywhere. > > I have one machine setup as a NTP server and another setup as couple of > others setup as NTP clients. > > I ran tcpdump on the server listening for packets from 224.0.1.1 to know > when it's transmitting, on the default router machine that's running pf as > well > as on the client. > > The server of course showed the packets and so did the gateway machine > but tcpdump on the client wouldn't detect the packets unless the ntp > daemon was actually running. > > Shouldn't tcpdump have picked up the packets off the wire regardless of > whether the ntp daemon was running or not? The packets are still being > broadcast and the daemon can't stop that. I'd have thought tcpdump would > have detected the packets lower down the stack before they even got to > the daemon. Multicast packets get filtered pretty low (in some cases even by the hardware) if no program registered. See ip(4), IP_ADD_MEMBERSHIP part. -Otto
ntp strangeness
Hi all, I noticed something I can't explain or find any explanation for anywhere. I have one machine setup as a NTP server and another setup as couple of others setup as NTP clients. I ran tcpdump on the server listening for packets from 224.0.1.1 to know when it's transmitting, on the default router machine that's running pf as well as on the client. The server of course showed the packets and so did the gateway machine but tcpdump on the client wouldn't detect the packets unless the ntp daemon was actually running. Shouldn't tcpdump have picked up the packets off the wire regardless of whether the ntp daemon was running or not? The packets are still being broadcast and the daemon can't stop that. I'd have thought tcpdump would have detected the packets lower down the stack before they even got to the daemon. TIA, Steve -- Steve Laurie
