[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ntp-bugs
Subject:    [ntp:bugs] [Bug 450]  New: ntpd port does not work under NT4 SP6
From:       bugzilla () ntp ! isc ! org
Date:       2005-06-10 6:22:58
Message-ID: 20050610062258.C715D398BF () ntp2 ! ntp ! isc ! org
[Download RAW message or body]

http://bugs.ntp.isc.org/show_bug.cgi?id=450

           Summary: ntpd port does not work under NT4 SP6
           Product: ntp
           Version: dev
          Platform: PC
        OS/Version: Windows NT
            Status: NEW
          Severity: normal
          Priority: P3
         Component: ntpd
        AssignedTo: stenn@ntp.org
        ReportedBy: heiko.gerstung@meinberg.de
                CC: bugs@ntp.isc.org


Yesterday I built 1.1393-o and tried to use it on two different Windows NT4
Workstation systems, both with SP6. 

What I did:
a simple ntp.conf like this:
server 127.127.1.1
server 172.16.3.2
server 172.61.3.2

works fine under Windows 2000. Under NT only the local clock entry survived the
initial sanity check, the other two servers (one is a valid stratum 1, the other
is a bogus entry) did not, so only one association has been mobilized leading to
this ntpq -p output:

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 LOCAL(0)        LOCAL(0)        12 l   11   64    1    0.000    0.000   0.002

In the debug output I see that for both dropped servers no suitable interface
could be found by findlocalinterface() in ntp_io.c ... 

I have no idea why we should try to find out which physical network interface
the OS will choose when communicating with a specific IP address, this should be
the duty of the IP router functions of the kernel. 

But, as long as we need to do so, I'd like to get this fixed. 
A first look into the routine with the debugger and I found out that the routine
works this way:

- it tries to send a packet to the IP address of the association
- it then looks into a saddr structure in order to find out which source address
the OS selected for that packet
- then this source IP is compared to all IP adresses of the network interfaces

The second step seems to be broken on NT, the SOCKCMP macro always gets a
0.0.0.0 address and therefore never finds any interface. 

Kind regards,
Heiko



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
_______________________________________________
bugs mailing list
bugs@lists.ntp.isc.org
https://lists.ntp.isc.org/mailman/listinfo/bugs
[prev in list] [next in list] [prev in thread] [next in thread]