Re: ntp and 0.0.0.0 address

[Brian May <bam@snoopy.apana.org.au>]

>>>>> "Henrique" == Henrique M Holschuh <hmh+debianbug@rcm.org.br> writes:

    Henrique> Please send all the relevant configuration files
    Henrique> attached when you report bugs like this one...

You mean this?

# /etc/ntp.conf, configuration for xntpd

# ntpd will use syslog() if logfile is not defined
#logfile /var/log/ntpd

driftfile /var/lib/ntp/ntp.drift
statsdir /var/log/ntpstats/

statistics loopstats peerstats clockstats
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
filegen clockstats file clockstats type day enable

server ntp.melb.apana.org.au

#server 127.127.1.1              # LCL, local clock
#fudge  127.127.1.1 stratum 12   # increase stratum

I am not sure how this would help, but since you asked..
That is the only config file I know about.

    Henrique> ntpd binds to 0.0.0.0 to receive packets from any
    Henrique> interface, and this is not a problem. Now, it should not
    Henrique> try to TALK to 0.0.0.0, but you didn't show ntpd talking
    Henrique> to 0.0.0.0, rather *ntptrace* was trying to talk to
    Henrique> 0.0.0.0...

You might have missed this bit of my original message then. Yes, I did
post the debug output of ntptrace. Or, at least that what the BTS
says...

    Henrique> A small test shows that the bug is likely to be in
    Henrique> ntptrace, and it is harmless. It should be fixed or
    Henrique> documented (if it isn't documented already, I didn't
    Henrique> check), but it isn't a release-critical (important) bug
    Henrique> IMO.

In which case, it has nothing to do with my main problem. :-(

    Henrique> If you often cannot connect to the *remote* server, that
    Henrique> network path/server is not suitable for NTP (at least
    Henrique> not as a sole server). Try pinging the servers when you
    Henrique> notice you cannot connect to them, to access if the
    Henrique> problem is the network path.

I can ping the remote host. You may have missed my tcpdump...
According to it, the response is correctly reaching my computer, but
my computer is responding with and ICMP error (port unreachable).

Later: Hang on, I see the problem. It should have been obvious, my
firewall setup!!! ARggghhh! The packets were being filtered!

Sorry about any confusion this may have caused.

However, ntptrace still doesn't work correctly...

    Henrique> Anyway, if you reply to the above questions, you should
    Henrique> probably take the BTS out of the reply headers...

Will do.

-- 
Brian May <bam@snoopy.apana.org.au>