[ntp:questions] Trouble with XP IPv6 ntp client (still unable to connect to link local ntp server)

Cindy Huyser chuyser at io.com
Fri Aug 6 16:29:21 UTC 2010


Using a packet sniffer, I verified that no traffic addressed to the
server (or coming from it) is going across the ethernet interface when
my configuration file specifies the IPv6 server. I also verified that
I saw ICMPv6 packets going across when I pinged the server, along with
the neighbor solicitation and advertisement. The server is in the XP
host's destination cache, and also is listed in the "neighbors" list.
I'm puzzled as to why there's not even an attempt at neighbor
discovery.

Maybe the trouble shows up in the line "findlocalinterface: kernel
maps fe80::290:fbff:fe80:6aff to ::", and the subsequent use of the
wildcard (or maybe not -- the address for the server is not local to
the host, but the host should be able to figure out that it needs to
send a neighbor discovery solicitation from it single ethernet
interface!). Can anyone out there shed any light on this?

Thanks again,
Cindy

<snip>

Now my server is fe80::290:fbff:fe80:6aff. My
> output is substantially the same. The crux of the problem seems to be:
>
> <snipping ntpd output>
> Finding interface for addr fe80::290:fbff:fe80:6aff in list of
> addresses
> findlocalinterface: kernel maps fe80::290:fbff:fe80:6aff to ::
> Searching for addr :: in list of addresses - FOUND
> Searching for addr with same subnet as :: in list of addresses - NOT
> FOUND
> Found no interface for address fe80::290:fbff:fe80:6aff - returning
> wildcard
> peer_refresh_interface: <null>->fe80::290:fbff:fe80:6aff mode 3 vers 4
> poll 4 5
> flags 0x121 0x1 ttl 0 key 00000000: new interface: <NONE>
> poll_update: at 17 fe80::290:fbff:fe80:6aff poll 4 burst 0 retry 1
> head 0 early
> 2 next 16
> poll_update: at 33 fe80::290:fbff:fe80:6aff poll 4 burst 0 retry 0
> head 0 early
> 2 next 16
> poll_update: at 49 fe80::290:fbff:fe80:6aff poll 4 burst 0 retry 2
> head 0 early
> 2 next 16
> <snip>
>
> The client never gets a response from the server. After a few minutes,
> the ntpq output verifies that the client's been unable to reach the
> server:
>
> C:\Program Files\NTP\bin>ntpq -p
>      remote           refid      st t when poll reach   delay
> offset  jitter
> ==============================================================================
>  fe80::290:fbff: .INIT.          16 -    -   32    0    0.000
> 0.000   0.000
>
> C:\Program Files\NTP\bin>ntpq
> ntpq> associations
>
> ind assid status  conf reach auth condition  last_event cnt
> ===========================================================
>   1 39761  8011   yes    no  none    reject    mobilize  1
> ntpq> rv
> associd=0 status=c011 leap_alarm, sync_unspec, 1 event, freq_not_set,
> version="ntpd 4.2.6p2-o Jul 09 4:44:44.34 (UTC-00:00) 2010  (1)",
> processor="x86", system="Windows", leap=11, stratum=16, precision=-18,
> rootdelay=0.000, rootdisp=3.750, refid=INIT,
> reftime=00000000.00000000  Thu, Feb  7 2036  6:28:16.000,
> clock=d006929c.0a0c7707  Fri, Aug  6 2010 13:54:36.039, peer=0, tc=3,
> mintc=3, offset=0.000, frequency=0.000, sys_jitter=0.000,
> clk_jitter=0.004, clk_wander=0.000
>




More information about the questions mailing list