I am running Meinberg's Win32 binaries on Windows Server 2003:

ntpd 4.2.4p5@beijing-o Sep 01 9:15:56 (UTC+02:00) 2008  (10)

It appears to me there is no support for IPv6 in these binaries.  I'm
guessing the work simply hasn't been done in the reference
implementation to support IPv6 on Windows.  Can anyone confirm that
even if I build my own binaries from source, IPv6 on Windows is not
supported?

Incidentally, their free Windows "NTP Time Server Monitor by Meinberg
v1.03a" is a nice piece of work.  I use the NTP status tab instead of
scripted "ntpq -c peers" in a loop, and their loopstats graphing makes
it easy to see how well your timeserver is performing.  If you run ntp
on a platform other than Windows but can access the filesystem via a
mapped network drive, you can use the Statistics tab to graph its
performance by clicking the triple-dot "..." button and navigating to
the directory holding the loopstats file.  You may need to enable
stats gathering in ntp.conf first:

statsdir /path/to/store/loopstats/files/
statistics loopstats

Cheers,
Dave Hart

Dave Hart wrote:
> I am running Meinberg's Win32 binaries on Windows Server 2003:
> 
> ntpd 4.2.4p5@beijing-o Sep 01 9:15:56 (UTC+02:00) 2008  (10)
> 
> It appears to me there is no support for IPv6 in these binaries.  I'm
> guessing the work simply hasn't been done in the reference
> implementation to support IPv6 on Windows.  Can anyone confirm that
> even if I build my own binaries from source, IPv6 on Windows is not
> supported?
> 

Not yet. It's on my list of things to complete in the near future. There
are two pieces that need to be changed and one of them may be tricky
though I seem to remember that Martin had put something together to help
with this since we need to support people without IPv6 support and don't
have getaddrinfo() and friends available. getaddinfo() is necessary for
IPv6 support. Now's the time to get that in.

Danny

On Tue, Jan 6, 2009 at 7:19 PM, Danny Mayer <mayer@ntp.isc.org> wrote
to questions@lists.ntp.org and me:

> Not yet. It's on my list of things to complete in the near future. There
> are two pieces that need to be changed and one of them may be tricky
> though I seem to remember that Martin had put something together to help
> with this since we need to support people without IPv6 support and don't
> have getaddrinfo() and friends available. getaddinfo() is necessary for
> IPv6 support. Now's the time to get that in.

It sounds like late-binding the required syscalls/APIs with LoadModule
and GetProcAddress is in order.  One way to minimize the source
disturbance when late-binding is to provide your own wrapper
implementations for each function and use a macro to redirect ntp's
calls to the conditionally-available functions through the
corresponding runtime-binding wrappers.  In this case Microsoft has
already done the legwork, including support for the Windows 2000 IPv6
download (which implements these in a different DLL than WinXP and
later).  Quoting from their getaddrinfo documentation at
http://msdn.microsoft.com/en-us/library/ms738520(VS.85).aspx

---------------- begin quote
The getaddrinfo function was added to the Ws2_32.dll on Windows XP and
later. To execute an application that uses this function on earlier
versions of Windows (Windows 2000, Windows NT, and Windows Me/98/95),
then you need to include the Ws2tcpip.h and Wspiapi.h files. When the
Wspiapi.h include file is added, the getaddrinfo function is defined
to the WspiapiGetAddrInfo inline function in the Wspiapi.h file. At
runtime, the WspiapiGetAddrInfo function is implemented in such a way
that if the Ws2_32.dll or the Wship6.dll (the file containing
getaddrinfo in the IPv6 Technology Preview for Windows 2000) does not
include getaddrinfo, then a version of getaddrinfo is implemented
inline based on code in the Wspiapi.h header file. This inline code
will be used on older Windows platforms that do not natively support
the getaddrinfo function.
The IPv6 protocol is supported on Windows 2000 when the IPv6
Technology Preview for Windows 2000 is installed. Otherwise
getaddrinfo support on versions of Windows earlier than Windows XP is
limited to handling IPv4 name resolution.
---------------- end quote

That sounds pretty darned painless, I hope it is indeed that easy for
you.  Now, ask me why I care about IPv6 when it'll apparently be years
before my IPv6 service isn't tunnelled over IPv4 using one lovely hack
or another guaranteed to add overhead and latency.  I don't have a
good answer.  I just want to break and enter into a few ipmasq and NAT
pioneers' homes and disable every telephone ringer.

Dave Hart

Dave Hart wrote:
> On Tue, Jan 6, 2009 at 7:19 PM, Danny Mayer <mayer@ntp.isc.org> wrote
> to questions@lists.ntp.org and me:
> 
>> Not yet. It's on my list of things to complete in the near future. There
>> are two pieces that need to be changed and one of them may be tricky
>> though I seem to remember that Martin had put something together to help
>> with this since we need to support people without IPv6 support and don't
>> have getaddrinfo() and friends available. getaddinfo() is necessary for
>> IPv6 support. Now's the time to get that in.
> 
> It sounds like late-binding the required syscalls/APIs with LoadModule
> and GetProcAddress is in order.  One way to minimize the source
> disturbance when late-binding is to provide your own wrapper
> implementations for each function and use a macro to redirect ntp's
> calls to the conditionally-available functions through the
> corresponding runtime-binding wrappers.  In this case Microsoft has
> already done the legwork, including support for the Windows 2000 IPv6
> download (which implements these in a different DLL than WinXP and
> later).  Quoting from their getaddrinfo documentation at
> http://msdn.microsoft.com/en-us/library/ms738520(VS.85).aspx
> 
> ---------------- begin quote
> The getaddrinfo function was added to the Ws2_32.dll on Windows XP and
> later. To execute an application that uses this function on earlier
> versions of Windows (Windows 2000, Windows NT, and Windows Me/98/95),
> then you need to include the Ws2tcpip.h and Wspiapi.h files. When the
> Wspiapi.h include file is added, the getaddrinfo function is defined
> to the WspiapiGetAddrInfo inline function in the Wspiapi.h file. At
> runtime, the WspiapiGetAddrInfo function is implemented in such a way
> that if the Ws2_32.dll or the Wship6.dll (the file containing
> getaddrinfo in the IPv6 Technology Preview for Windows 2000) does not
> include getaddrinfo, then a version of getaddrinfo is implemented
> inline based on code in the Wspiapi.h header file. This inline code
> will be used on older Windows platforms that do not natively support
> the getaddrinfo function.
> The IPv6 protocol is supported on Windows 2000 when the IPv6
> Technology Preview for Windows 2000 is installed. Otherwise
> getaddrinfo support on versions of Windows earlier than Windows XP is
> limited to handling IPv4 name resolution.
> ---------------- end quote

Back in 2005 I had already made the changes which import getaddrinfo() and
friends from the DLL if available, or use NTP's built-in functions
otherwise. That code is in the xmas version for Windows but has never made
it into the official code base.

Unfortunately there have been many changes to the official code base in the
mean time so that much of the former work will have to be done once more.

Martin
-- 
Martin Burnicki

Meinberg Funkuhren
Bad Pyrmont
Germany

We do have code for this. I won't use Microsoft's code though except the
standard API code. It's a matter of getting it back in. There is one
item that may yet cause me grief but that's a matter of figuring
everything out.

Danny
Dave Hart wrote:
> 
> 
> On Tue, Jan 6, 2009 at 7:19 PM, Danny Mayer <mayer@ntp.isc.org> wrote
> to questions@lists.ntp.org and me:
> 
>> Not yet. It's on my list of things to complete in the near future. There
>> are two pieces that need to be changed and one of them may be tricky
>> though I seem to remember that Martin had put something together to help
>> with this since we need to support people without IPv6 support and don't
>> have getaddrinfo() and friends available. getaddinfo() is necessary for
>> IPv6 support. Now's the time to get that in.
> 
> It sounds like late-binding the required syscalls/APIs with LoadModule
> and GetProcAddress is in order.  One way to minimize the source
> disturbance when late-binding is to provide your own wrapper
> implementations for each function and use a macro to redirect ntp's
> calls to the conditionally-available functions through the
> corresponding runtime-binding wrappers.  In this case Microsoft has
> already done the legwork, including support for the Windows 2000 IPv6
> download (which implements these in a different DLL than WinXP and
> later).  Quoting from their getaddrinfo documentation at
> http://msdn.microsoft.com/en-us/library/ms738520(VS.85).aspx
> 
> ---------------- begin quote
> The getaddrinfo function was added to the Ws2_32.dll on Windows XP and
> later. To execute an application that uses this function on earlier
> versions of Windows (Windows 2000, Windows NT, and Windows Me/98/95),
> then you need to include the Ws2tcpip.h and Wspiapi.h files. When the
> Wspiapi.h include file is added, the getaddrinfo function is defined
> to the WspiapiGetAddrInfo inline function in the Wspiapi.h file. At
> runtime, the WspiapiGetAddrInfo function is implemented in such a way
> that if the Ws2_32.dll or the Wship6.dll (the file containing
> getaddrinfo in the IPv6 Technology Preview for Windows 2000) does not
> include getaddrinfo, then a version of getaddrinfo is implemented
> inline based on code in the Wspiapi.h header file. This inline code
> will be used on older Windows platforms that do not natively support
> the getaddrinfo function.
> The IPv6 protocol is supported on Windows 2000 when the IPv6
> Technology Preview for Windows 2000 is installed. Otherwise
> getaddrinfo support on versions of Windows earlier than Windows XP is
> limited to handling IPv4 name resolution.
> ---------------- end quote
> 
> That sounds pretty darned painless, I hope it is indeed that easy for
> you.  Now, ask me why I care about IPv6 when it'll apparently be years
> before my IPv6 service isn't tunnelled over IPv4 using one lovely hack
> or another guaranteed to add overhead and latency.  I don't have a
> good answer.  I just want to break and enter into a few ipmasq and NAT
> pioneers' homes and disable every telephone ringer.
> 
> Dave Hart
> 
> _______________________________________________
> questions mailing list
> questions@lists.ntp.org
> https://lists.ntp.org/mailman/listinfo/questions
> 
> 

On Thu, Jan 8, 2009 at 2:30 PM, Danny Mayer <mayer@ntp.isc.org> wrote:

> We do have code for this. I won't use Microsoft's code though except the
> standard API code. It's a matter of getting it back in. There is one
> item that may yet cause me grief but that's a matter of figuring
> everything out.
>
I do not understand why using Microsoft's Windows header files as documented
to enable the broadest IPv6 support on Windows is reaching beyond "standard
API code."  If you do roll-your-own, please do also support the different
DLL used on Windows 2000 for IPv6 APIs.

Cheers,
Dave Hart

Dave Hart wrote:
> On Thu, Jan 8, 2009 at 2:30 PM, Danny Mayer <mayer@ntp.isc.org
> <mailto:mayer@ntp.isc.org>> wrote:
> 
>     We do have code for this. I won't use Microsoft's code though except the
>     standard API code. It's a matter of getting it back in. There is one
>     item that may yet cause me grief but that's a matter of figuring
>     everything out.
> 
> I do not understand why using Microsoft's Windows header files as
> documented to enable the broadest IPv6 support on Windows is reaching
> beyond "standard API code."  If you do roll-your-own, please do also
> support the different DLL used on Windows 2000 for IPv6 APIs.
>  

We want to use the API's where they are available but use the emulations
where they are not. You can't do that with Microsoft's source code, you
would only get that emulation. We build once and deploy many and you
want to take advantage of the API in the MS DLL's where available.

Danny

> Cheers,
> Dave Hart

On Jan 10, 7:03=A0am, ma...@ntp.isc.org (Danny Mayer) wrote:

> We want to use the API's where they are available but use the emulations
> where they are not. You can't do that with Microsoft's source code, you
> would only get that emulation. We build once and deploy many and you
> want to take advantage of the API in the MS DLL's where available.

I am pretty sure you misunderstand.  The whole point of the header
file machinations I quoted earlier is to solve exactly the problem ntp
has, which is to use the system getaddrinfo and friends when available
while allowing the binaries to load and run successfully on older
versions of Windows lacking those new-for-IPv6 system APIs.  I can
find no information to indicate Microsoft's getaddrinfo inline code
emulation would be used when there is an OS getaddrinfo available.

Please read this quote carefully:

----------- begin MSDN quote
When the
Wspiapi.h include file is added, the getaddrinfo function is defined
to the WspiapiGetAddrInfo inline function in the Wspiapi.h file. At
runtime, the WspiapiGetAddrInfo function is implemented in such a way
that if the Ws2_32.dll or the Wship6.dll (the file containing
getaddrinfo in the IPv6 Technology Preview for Windows 2000) does not
include getaddrinfo, then a version of getaddrinfo is implemented
inline based on code in the Wspiapi.h header file. This inline code
will be used on older Windows platforms that do not natively support
the getaddrinfo function.
----------- end MSDN quote

http://msdn.microsoft.com/en-us/library/ms738520(VS.85).aspx

Cheers,
Dave Hart

Dave Hart wrote:
> On Jan 10, 7:03 am, ma...@ntp.isc.org (Danny Mayer) wrote:
> 
>> We want to use the API's where they are available but use the emulations
>> where they are not. You can't do that with Microsoft's source code, you
>> would only get that emulation. We build once and deploy many and you
>> want to take advantage of the API in the MS DLL's where available.
> 
> I am pretty sure you misunderstand.  The whole point of the header
> file machinations I quoted earlier is to solve exactly the problem ntp
> has, which is to use the system getaddrinfo and friends when available
> while allowing the binaries to load and run successfully on older
> versions of Windows lacking those new-for-IPv6 system APIs.  I can
> find no information to indicate Microsoft's getaddrinfo inline code
> emulation would be used when there is an OS getaddrinfo available.
> 
> Please read this quote carefully:
> 
> ----------- begin MSDN quote
> When the
> Wspiapi.h include file is added, the getaddrinfo function is defined
> to the WspiapiGetAddrInfo inline function in the Wspiapi.h file. At
> runtime, the WspiapiGetAddrInfo function is implemented in such a way
> that if the Ws2_32.dll or the Wship6.dll (the file containing
> getaddrinfo in the IPv6 Technology Preview for Windows 2000) does not
> include getaddrinfo, then a version of getaddrinfo is implemented
> inline based on code in the Wspiapi.h header file. This inline code
> will be used on older Windows platforms that do not natively support
> the getaddrinfo function.
> ----------- end MSDN quote
> 
> http://msdn.microsoft.com/en-us/library/ms738520(VS.85).aspx

I'm very careful to avoid the WSP* functions. I don't think many people
know about the WSP* functions but I am very careful to avoid them as far
as possible especially as there are potential security implications.
Otherwise I would be using WSP* functions everywhere and avoid the extra
overhead of the WSA* functions.

Let's not go there.

Danny

On Jan 10, 7:02=A0pm, ma...@ntp.isc.org (Danny Mayer) wrote:
> Dave Hart wrote:
> > On Jan 10, 7:03 am, ma...@ntp.isc.org (Danny Mayer) wrote:
>
> >> We want to use the API's where they are available but use the emulatio=
ns
> >> where they are not. You can't do that with Microsoft's source code, yo=
u
> >> would only get that emulation. We build once and deploy many and you
> >> want to take advantage of the API in the MS DLL's where available.
>
> > I am pretty sure you misunderstand. =A0The whole point of the header
> > file machinations I quoted earlier is to solve exactly the problem ntp
> > has, which is to use the system getaddrinfo and friends when available
> > while allowing the binaries to load and run successfully on older
> > versions of Windows lacking those new-for-IPv6 system APIs. =A0I can
> > find no information to indicate Microsoft's getaddrinfo inline code
> > emulation would be used when there is an OS getaddrinfo available.
>
> > Please read this quote carefully:
>
> > ----------- begin MSDN quote
> > When the
> > Wspiapi.h include file is added, the getaddrinfo function is defined
> > to the WspiapiGetAddrInfo inline function in the Wspiapi.h file. At
> > runtime, the WspiapiGetAddrInfo function is implemented in such a way
> > that if the Ws2_32.dll or the Wship6.dll (the file containing
> > getaddrinfo in the IPv6 Technology Preview for Windows 2000) does not
> > include getaddrinfo, then a version of getaddrinfo is implemented
> > inline based on code in the Wspiapi.h header file. This inline code
> > will be used on older Windows platforms that do not natively support
> > the getaddrinfo function.
> > ----------- end MSDN quote
>
> >http://msdn.microsoft.com/en-us/library/ms738520(VS.85).aspx
>
> I'm very careful to avoid the WSP* functions. I don't think many people
> know about the WSP* functions but I am very careful to avoid them as far
> as possible especially as there are potential security implications.
> Otherwise I would be using WSP* functions everywhere and avoid the extra
> overhead of the WSA* functions.
>
> Let's not go there.

I am not suggesting you to go referencing Wsp* functions willy-nilly
to avoid some perceived (and insignificant) overhead of using
published APIs.  I'm suggesting you use the published API names like
getaddrinfo and let Microsoft's runtime binding implementation do what
it is designed to do.  That it involves macros to inline functions
with names like WspiapiGetAddrInfo is an implementation detail
invisible to everyone not using a symbolic debugger against ntp
binaries on Windows.

Please elaborate on the potential security implications of using
Microsoft's recommended late-binding of getaddrinfo and friends.

Please accept my apologies for going there, no offense intended.  I am
just failing to see why bloating ntp source code with Win32-specific
code that accomplishes exactly what Microsoft's header's already do
for you is beneficial given the counterarguments I'm hearing so far.

Cheers,
Dave Hart

Dave Hart wrote:
>>> http://msdn.microsoft.com/en-us/library/ms738520(VS.85).aspx
>> I'm very careful to avoid the WSP* functions. I don't think many people
>> know about the WSP* functions but I am very careful to avoid them as far
>> as possible especially as there are potential security implications.
>> Otherwise I would be using WSP* functions everywhere and avoid the extra
>> overhead of the WSA* functions.
>>
>> Let's not go there.
> 
> I am not suggesting you to go referencing Wsp* functions willy-nilly
> to avoid some perceived (and insignificant) overhead of using
> published APIs.  I'm suggesting you use the published API names like
> getaddrinfo and let Microsoft's runtime binding implementation do what
> it is designed to do.  That it involves macros to inline functions
> with names like WspiapiGetAddrInfo is an implementation detail
> invisible to everyone not using a symbolic debugger against ntp
> binaries on Windows.
> 

That is not correct. These are not macros. The SPI layer is a layer
between Winsock2 and the base layer and there can be multiple SPI layers
and in fact you can specify the order. All of this gets very tricky and
it's one of the reasons why I don't want to go there. Just because
Microsoft provides something doesn't mean that we should use it.

> Please elaborate on the potential security implications of using
> Microsoft's recommended late-binding of getaddrinfo and friends.
> 

The SPI layer is a whole other set of layers that I don't have time to
go into.

> Please accept my apologies for going there, no offense intended.  I am
> just failing to see why bloating ntp source code with Win32-specific
> code that accomplishes exactly what Microsoft's header's already do
> for you is beneficial given the counterarguments I'm hearing so far.
> 

Actually, there's no bloat since there's already code in ntp to support
 non-IPv6 operating systems. The only thing we will be doing is figuring
out whether or not the support is there for IPv6 and calling one or the
other. The only reason to consider Microsoft's code is to support IPv6
on Windows 2000 and I don't see a need to support something that is long
since obsolete.

Danny

On Jan 11, 6:04=A0pm, ma...@ntp.isc.org (Danny Mayer) wrote:
> Dave Hart wrote:
> > I am not suggesting you to go referencing Wsp* functions willy-nilly
> > to avoid some perceived (and insignificant) overhead of using
> > published APIs. =A0I'm suggesting you use the published API names like
> > getaddrinfo and let Microsoft's runtime binding implementation do what
> > it is designed to do. =A0That it involves macros to inline functions
> > with names like WspiapiGetAddrInfo is an implementation detail
> > invisible to everyone not using a symbolic debugger against ntp
> > binaries on Windows.
>
> That is not correct. These are not macros. The SPI layer is a layer
> between Winsock2 and the base layer and there can be multiple SPI layers
> and in fact you can specify the order. All of this gets very tricky and
> it's one of the reasons why I don't want to go there. Just because
> Microsoft provides something doesn't mean that we should use it.

You are mistaken.  I'm getting sick of you speaking without checking
on the accuracy of your claims.  Wspiapi.h and the Wspiapi-prefixed
inline functions and macros have nothing to do with Winsock's Service
Provider Interface (SPI).  Rather, they are part of the pedestrian
client application socket API.  Please take a few minutes and read the
header file, since you are so stubbornly unwilling to believe the
documentation I've referred you to repeatedly.

http://pf.itd.nrl.navy.mil/mdp/dox/html/wspiapi_8h-source.html

You don't even need to have a set of Windows header files handy, the
US Navy has kindly published the entire header file at the URL above.
You said "these are not macros."  The source code disagrees:

00027 #define getaddrinfo             WspiapiGetAddrInfo

If you scroll down to line 941 you can find the inline function
implementation WspiapiGetAddrInfo, which is terribly boring because
all it does is call through a function pointer, which is either
initialized to the system API address for getaddrinfo in ws2_32.dll/
wship6.dll or if running on a system lacking IPv6, left pointing to
the IPv4-only WspiapiLegacyGetAddrInfo implemented in that header file
on line 439.

I've read through the entire Wspiapi.h file and assert it is obvious
to anyone skilled in the art that all it does is provide getaddrinfo,
getnameinfo, and freeaddrinfo implementations for IPv4-only Windows
systems and the plumbing to runtime-bind those three functions and use
the OS versions where available and the inline WspiapiLegacyXxx
versions where not.  It has nothing to do with Winsock SPI.  Not every
Windows sockets function that begins with Wsp is related to SPI, as it
turns out.  If you do not believe me, please read Wspiapi.h for
yourself.

I realize ntp already has its own code related to deciding whether to
use getaddrinfo and friends or v4-only DNS APIs.  I see no reason that
code should be brought to bear on the issue of IPv6 support on
Windows.  Microsoft has already invented the wheel, so to speak.  I
bet Win32 NTP could simply always use getaddrinfo, getnameinfo, and
freeaddrinfo via the Wspiapi.h magic and avail itself of IPv6 on
systems which support it without preventing compatibility with older
versions of NT lacking IPv6.  Even if there is good reason for NTP on
Windows to decide at runtime whether to use old name resoloution
services or new, I would suggest Wspiapi.h is still the best way to
runtime-bind the new routines.  It would be easy to peek under the
covers to decide if the routines are mapped to the system or to the
WspiapiLegacyXxx inline emulation.

>
> > Please elaborate on the potential security implications of using
> > Microsoft's recommended late-binding of getaddrinfo and friends.
>
> The SPI layer is a whole other set of layers that I don't have time to
> go into.

Since I'm not talking about SPI layer interfaces, it sounds like the
potential security implications are moot.  Once again, the Wspiapi
prefix is used by the windows sockets platform independent API, which
is solely at the Winsock API level and has nothing to do with Winsock
SPI or the WspXxx interfaces used by SPI.

Dave Hart

Dave Hart wrote:
> On Jan 11, 6:04 pm, ma...@ntp.isc.org (Danny Mayer) wrote:
>> Dave Hart wrote:
>>> I am not suggesting you to go referencing Wsp* functions willy-nilly
>>> to avoid some perceived (and insignificant) overhead of using
>>> published APIs.  I'm suggesting you use the published API names like
>>> getaddrinfo and let Microsoft's runtime binding implementation do what
>>> it is designed to do.  That it involves macros to inline functions
>>> with names like WspiapiGetAddrInfo is an implementation detail
>>> invisible to everyone not using a symbolic debugger against ntp
>>> binaries on Windows.
>> That is not correct. These are not macros. The SPI layer is a layer
>> between Winsock2 and the base layer and there can be multiple SPI layers
>> and in fact you can specify the order. All of this gets very tricky and
>> it's one of the reasons why I don't want to go there. Just because
>> Microsoft provides something doesn't mean that we should use it.
> 
> You are mistaken.  I'm getting sick of you speaking without checking
> on the accuracy of your claims.  Wspiapi.h and the Wspiapi-prefixed
> inline functions and macros have nothing to do with Winsock's Service
> Provider Interface (SPI).  Rather, they are part of the pedestrian
> client application socket API.  Please take a few minutes and read the
> header file, since you are so stubbornly unwilling to believe the
> documentation I've referred you to repeatedly.
> 
> http://pf.itd.nrl.navy.mil/mdp/dox/html/wspiapi_8h-source.html
> 
> You don't even need to have a set of Windows header files handy, the
> US Navy has kindly published the entire header file at the URL above.
> You said "these are not macros."  The source code disagrees:
> 
> 00027 #define getaddrinfo             WspiapiGetAddrInfo
>

Dave, I was inclined to agree with you that these headers do look like 
what we need, functionality-wise they look spot on, but when I started 
to read the code I found some ugly stuff, i.e.:

00272 __inline
00273 int
00274 WINAPI
00275 WspiapiLookupNode(
00276     IN  const char                      *pszNodeName,
00277     IN  int                             iSocketType,
00278     IN  int                             iProtocol,
00279     IN  WORD                            wPort,
00280     IN  BOOL                            bAI_CANONNAME,
00281     OUT struct addrinfo                 **pptResult)
00282 /*++
[snip]

00308     char    szFQDN1[NI_MAXHOST] = "";
00309     char    szFQDN2[NI_MAXHOST] = "";
00310     char    *pszName            = szFQDN1;
00311     char    *pszAlias           = szFQDN2;
00312     char    *pszScratch         = NULL;
00313     strcpy(pszName, pszNodeName);

I.e. the _very_ first operation of this function is to enable a stack 
overflow bug/security hole!

If you send in a too-long szNodeName, then the strcpy() will overwrite 
lots of stack values. :-(

Terje
-- 
- <Terje.Mathisen@hda.hydro.com>
"almost all programming can be viewed as an exercise in caching"

On Jan 11, 10:41=A0pm, Terje Mathisen <terje.mathi...@hda.hydro.com>
wrote:
> Dave, I was inclined to agree with you that these headers do look like
> what we need, functionality-wise they look spot on, but when I started
> to read the code I found some ugly stuff, i.e.:
[...]
> I.e. the _very_ first operation of this function is to enable a stack
> overflow bug/security hole!
>
> If you send in a too-long szNodeName, then the strcpy() will overwrite
> lots of stack values. :-(

I also note ports/winnt/include/config.h has this bit:

/*
 * VS.NET's version of wspiapi.h has a bug in it
 * where it assigns a value to a variable inside
 * an if statement. It should be comparing them.
 * We prevent inclusion since we are not using this
 * code so we don't have to see the warning messages
 */
#ifndef _WSPIAPI_H_
#define _WSPIAPI_H_
#endif

Given that ISC already has its own preferred implementation of
getaddrinfo and friends and the issues with the wspiapi.h
implementation, using the ISC stuff makes sense.  It would be nice to
look for the functions in whsip6.dll after checking ws2_32.dll for
them, so that any lingering Windows 2000 IPv6 users are equally
served.

Cheers,
Dave Hart

Guys,

Dave Hart wrote:
> I also note ports/winnt/include/config.h has this bit:
> 
> /*
>  * VS.NET's version of wspiapi.h has a bug in it
>  * where it assigns a value to a variable inside
>  * an if statement. It should be comparing them.
>  * We prevent inclusion since we are not using this
>  * code so we don't have to see the warning messages
>  */
> #ifndef _WSPIAPI_H_
> #define _WSPIAPI_H_
> #endif
> 
> Given that ISC already has its own preferred implementation of
> getaddrinfo and friends and the issues with the wspiapi.h
> implementation, using the ISC stuff makes sense.  It would be nice to
> look for the functions in whsip6.dll after checking ws2_32.dll for
> them, so that any lingering Windows 2000 IPv6 users are equally
> served.
> 
> Cheers,
> Dave Hart

Here are a few thoughts:

1.) The NTP code tries to use getaddrinfo() and friends if possible, and
provides basic versions of those functions for target environments which
don't provide those functions.

2.) For Unix versions NTP is normally distributed as source code and
compiled for a specific target OS and target OS version, so the ./configure
script determines whether getaddrinfo() etc. are available on that target
platform and uses either the target functions or the built-in functions as
appropriate.

3.) The Windows version of NTP is mostly distributed as precompiled
binaries, so the program (e.g. ntpd) has to determine at runtime whether
the specific version it is currently running on provides that functions, or
not. This can be handled using late binding of DLL functions, i.e. call
getaddrinfo() and friends via function pointers. If a binary starts on a
specific Windows version it can test whether the target OS supports those
functions. If it does it can let the function pointers point to the
exported functions. If it does not then the pointers can be set to the
built-in function. As already mentione earlier I had implemented this
already for the xmas version back in 2005, but this was never accepted for
the public source code base.

4.) One more thing is the build environment. Depending on the compiler
version and installed header files (SDK available or not) the definitions
required to use getaddrinfo() etc. may be available or not at compile time.
If they are not then the NTP source code also provides the required
definitions. For example, if we build with VC6 without SDK then we have to
use the definitions coming with NTP.

5.) Finally, in order to be able to distribute a single binary which can be
run on Windows with or without support for IPv6 the program fully needs to
check at runtime whether IPv6 support is available, or not. I.e. it first
has to try to import getaddrinfo() and friends from the OS, then call those
functions in order to check whether IPv6 is supported. The current code
already does the check but makes many assumptions just depending on the
compiler version instead of checking whether some declarations are
available after the header files have been imported.


Martin
-- 
Martin Burnicki

Meinberg Funkuhren
Bad Pyrmont
Germany

Martin Burnicki wrote:
[]
> Here are a few thoughts:
[]
> 5.) Finally, in order to be able to distribute a single binary which
> can be run on Windows with or without support for IPv6 the program
> fully needs to check at runtime whether IPv6 support is available, or
> not. I.e. it first has to try to import getaddrinfo() and friends
> from the OS, then call those functions in order to check whether IPv6
> is supported. The current code already does the check but makes many
> assumptions just depending on the compiler version instead of
> checking whether some declarations are available after the header
> files have been imported.
>
> Martin

Martin,

(5) is the standard way of doing things - a single binary for all - and 
the way I would expect NTP to be made available.

Cheers,
David 

Terje Mathisen wrote:
> Dave Hart wrote:
>> On Jan 11, 6:04 pm, ma...@ntp.isc.org (Danny Mayer) wrote:
>>> Dave Hart wrote:
>>>> I am not suggesting you to go referencing Wsp* functions willy-nilly
>>>> to avoid some perceived (and insignificant) overhead of using
>>>> published APIs.  I'm suggesting you use the published API names like
>>>> getaddrinfo and let Microsoft's runtime binding implementation do what
>>>> it is designed to do.  That it involves macros to inline functions
>>>> with names like WspiapiGetAddrInfo is an implementation detail
>>>> invisible to everyone not using a symbolic debugger against ntp
>>>> binaries on Windows.
>>> That is not correct. These are not macros. The SPI layer is a layer
>>> between Winsock2 and the base layer and there can be multiple SPI layers
>>> and in fact you can specify the order. All of this gets very tricky and
>>> it's one of the reasons why I don't want to go there. Just because
>>> Microsoft provides something doesn't mean that we should use it.
>> You are mistaken.  I'm getting sick of you speaking without checking
>> on the accuracy of your claims.  Wspiapi.h and the Wspiapi-prefixed
>> inline functions and macros have nothing to do with Winsock's Service
>> Provider Interface (SPI).  Rather, they are part of the pedestrian
>> client application socket API.  Please take a few minutes and read the
>> header file, since you are so stubbornly unwilling to believe the
>> documentation I've referred you to repeatedly.
>>
>> http://pf.itd.nrl.navy.mil/mdp/dox/html/wspiapi_8h-source.html
>>
>> You don't even need to have a set of Windows header files handy, the
>> US Navy has kindly published the entire header file at the URL above.
>> You said "these are not macros."  The source code disagrees:
>>
>> 00027 #define getaddrinfo             WspiapiGetAddrInfo
>>
> 
> Dave, I was inclined to agree with you that these headers do look like 
> what we need, functionality-wise they look spot on, but when I started 
> to read the code I found some ugly stuff, i.e.:
> 
> 00272 __inline
> 00273 int
> 00274 WINAPI
> 00275 WspiapiLookupNode(
> 00276     IN  const char                      *pszNodeName,
> 00277     IN  int                             iSocketType,
> 00278     IN  int                             iProtocol,
> 00279     IN  WORD                            wPort,
> 00280     IN  BOOL                            bAI_CANONNAME,
> 00281     OUT struct addrinfo                 **pptResult)
> 00282 /*++
> [snip]
> 
> 00308     char    szFQDN1[NI_MAXHOST] = "";
> 00309     char    szFQDN2[NI_MAXHOST] = "";
> 00310     char    *pszName            = szFQDN1;
> 00311     char    *pszAlias           = szFQDN2;
> 00312     char    *pszScratch         = NULL;
> 00313     strcpy(pszName, pszNodeName);
> 
> I.e. the _very_ first operation of this function is to enable a stack 
> overflow bug/security hole!
> 
> If you send in a too-long szNodeName, then the strcpy() will overwrite 
> lots of stack values. :-(
> 
> Terje

And line 340-341 makes it clear that it's doing it's own lookups:
// there was a new CNAME, look again.
WspiapiSwap(pszName, pszAlias, pszScratch);

That also means that it is not using the resolvers since CNAME restart
is the job of a resolver and that means that this code cannot make use
of DNSSEC and other security changes being added to DNS.

In addition as Martin mentioned this is compile-time code. We need it to
do the right thing at runtime. We won't be supporting IPv6 on Windows
2000, it's just too difficult to deal with from a support point of view.

Danny

On Jan 12, 6:52=A0pm, ma...@ntp.isc.org (Danny Mayer) wrote:
> We won't be supporting IPv6 on Windows
> 2000, it's just too difficult to deal with from a support point of view.

OK, Windows 2000 is too difficult to deal with from a support point of
view.  Why on earth have we been talking about late-binding IPv6 APIs,
then?  Just build a binary that requires WinXP/Windows Server 2003 or
later by using getaddrinfo as usual, thereby requiring ws2_32.dll
export it for ntp binaries to load at all.  Boom, you've solved your
Windows NT and Windows 2000 support problems for good.

Dave Hart

On Jan 12, 6:52=A0pm, ma...@ntp.isc.org (Danny Mayer) wrote:
> And line 340-341 makes it clear that it's doing it's own lookups:
> // there was a new CNAME, look again.
> WspiapiSwap(pszName, pszAlias, pszScratch);
>
> That also means that it is not using the resolvers since CNAME restart
> is the job of a resolver and that means that this code cannot make use
> of DNSSEC and other security changes being added to DNS.

Take a step back and read the code some more.  On line 232 is the call
to gethostbyname(), the IPv4-only resolver entrypoint.  CNAME records
can be followed by that function, resulting in a return of both the
canonical text name via hostent.h_name as well as one or more IPv4
addresses in hostent.s_addr.  Only in the case that the resolver
returns a different h_name with zero addresses in the hostent will
this code loop around for another call to gethostbyname.

I'm not an expert on why gethostbyname would or would not include any
addresses when resolving through a CNAME.  I do know gethostbyname is
the old-style resolver, though.  I'm not sure that helps with DNSSEC
and other security changes being added to DNS, I've seen no hint of
support for such in Windows DNS clients or servers.

Cheers,
Dave Hart

Dave Hart wrote:
> On Jan 12, 6:52 pm, ma...@ntp.isc.org (Danny Mayer) wrote:
>> We won't be supporting IPv6 on Windows
>> 2000, it's just too difficult to deal with from a support point of
>> view.
>
> OK, Windows 2000 is too difficult to deal with from a support point of
> view.  Why on earth have we been talking about late-binding IPv6 APIs,
> then?  Just build a binary that requires WinXP/Windows Server 2003 or
> later by using getaddrinfo as usual, thereby requiring ws2_32.dll
> export it for ntp binaries to load at all.  Boom, you've solved your
> Windows NT and Windows 2000 support problems for good.
>
> Dave Hart

Folks,

I would prefer that Windows 2000 support not be dropped just yet, although 
for me it only need to be IPv4.

I retired the last NT4 system when its power supply failed, but it would 
be nice to have a legacy version of NTP which still and installed and 
worked there.  Nothing more than making sure the last working version, 
warts and all, isn't thrown away by mistake.

Cheers,
David 

Dave Hart wrote:
> On Jan 12, 6:52 pm, ma...@ntp.isc.org (Danny Mayer) wrote:
>> We won't be supporting IPv6 on Windows
>> 2000, it's just too difficult to deal with from a support point of view.
> 
> OK, Windows 2000 is too difficult to deal with from a support point of
> view.  Why on earth have we been talking about late-binding IPv6 APIs,
> then?  Just build a binary that requires WinXP/Windows Server 2003 or
> later by using getaddrinfo as usual, thereby requiring ws2_32.dll
> export it for ntp binaries to load at all.  Boom, you've solved your
> Windows NT and Windows 2000 support problems for good.
> 

I was very specific here: I won't support Windows 2000 and IPv6. I did
not say anything about not supporting Windows 2000 with IPv4.

Danny
> Dave Hart
> 
> _______________________________________________
> questions mailing list
> questions@lists.ntp.org
> https://lists.ntp.org/mailman/listinfo/questions
> 
> 

Dave Hart wrote:
> On Jan 12, 6:52 pm, ma...@ntp.isc.org (Danny Mayer) wrote:
>> And line 340-341 makes it clear that it's doing it's own lookups:
>> // there was a new CNAME, look again.
>> WspiapiSwap(pszName, pszAlias, pszScratch);
>>
>> That also means that it is not using the resolvers since CNAME restart
>> is the job of a resolver and that means that this code cannot make use
>> of DNSSEC and other security changes being added to DNS.
> 
> Take a step back and read the code some more.  On line 232 is the call
> to gethostbyname(), the IPv4-only resolver entrypoint.  CNAME records
> can be followed by that function, resulting in a return of both the
> canonical text name via hostent.h_name as well as one or more IPv4
> addresses in hostent.s_addr.  Only in the case that the resolver
> returns a different h_name with zero addresses in the hostent will
> this code loop around for another call to gethostbyname.
> 
> I'm not an expert on why gethostbyname would or would not include any
> addresses when resolving through a CNAME.  I do know gethostbyname is
> the old-style resolver, though.  I'm not sure that helps with DNSSEC
> and other security changes being added to DNS, I've seen no hint of
> support for such in Windows DNS clients or servers.
> 

But I am an expert in this area. This code has a layering violation and
I won't agree to support that.

Danny

> Cheers,
> Dave Hart

Danny Mayer wrote:
> Dave Hart wrote:
>> On Jan 12, 6:52 pm, ma...@ntp.isc.org (Danny Mayer) wrote:
>>> We won't be supporting IPv6 on Windows
>>> 2000, it's just too difficult to deal with from a support point of view.
>> 
>> OK, Windows 2000 is too difficult to deal with from a support point of
>> view.  Why on earth have we been talking about late-binding IPv6 APIs,
>> then?  Just build a binary that requires WinXP/Windows Server 2003 or
>> later by using getaddrinfo as usual, thereby requiring ws2_32.dll
>> export it for ntp binaries to load at all.  Boom, you've solved your
>> Windows NT and Windows 2000 support problems for good.
>> 
> 
> I was very specific here: I won't support Windows 2000 and IPv6. I did
> not say anything about not supporting Windows 2000 with IPv4.

I also agree to that. If we can use late binding at runtime it should be
possible to have a single binary which runs on Windows 2000 without support
for IPv6 and on newer Windows versions with support for IPv6.

I guess the runtime thing is similar to building e.g. on a Linux system
which basically supports IPv6 but where IPv6 is just disabled in the OS.

Then no IPv6 interfaces are found, so no IPv6 interfaces are used.

Martin
-- 
Martin Burnicki

Meinberg Funkuhren
Bad Pyrmont
Germany

Danny,

I think I still have the dynamic DLL function import code lying around.
Should I try to add it to the current ntp-dev so you just had to care about
calling the functions and evaluating the results to see if IPv6 is
supported? That should save you quite a bunch of work.

Martin
-- 
Martin Burnicki

Meinberg Funkuhren
Bad Pyrmont
Germany

On Jan 13, 4:38=A0am, ma...@ntp.isc.org (Danny Mayer) wrote:
> I was very specific here: I won't support Windows 2000 and IPv6. I did
> not say anything about not supporting Windows 2000 with IPv4.

There is nothing more difficult about supporting IPv6 on Windows 2000
from a code perspective, since checking two places for a set of
resolver routines is little more difficult from checking one.  It is
true the IPv6 download for Windows 2000 isn't supported by Microsoft
and never was, from a product support perspective.  But then that's
true for IPv6 on Windows XP as well.  The management of IPv6 settings
is different (and without GUI) on Windows 2000, but that is a problem
for those using it, not those supporting NTP's reference
implementation, right?  I don't understand what it is about Windows
2000 IPv6 that bothers you.

Cheers,
Dave Hart

On Jan 13, 4:42=A0am, ma...@ntp.isc.org (Danny Mayer) wrote:
> Dave Hart wrote:
> > On Jan 12, 6:52 pm, ma...@ntp.isc.org (Danny Mayer) wrote:
> >> And line 340-341 makes it clear that it's doing it's own lookups:
> >> // there was a new CNAME, look again.
> >> WspiapiSwap(pszName, pszAlias, pszScratch);
>
> >> That also means that it is not using the resolvers since CNAME restart
> >> is the job of a resolver and that means that this code cannot make use
> >> of DNSSEC and other security changes being added to DNS.
>
> > Take a step back and read the code some more. =A0On line 232 is the cal=
l
> > to gethostbyname(), the IPv4-only resolver entrypoint. =A0CNAME records
> > can be followed by that function, resulting in a return of both the
> > canonical text name via hostent.h_name as well as one or more IPv4
> > addresses in hostent.s_addr. =A0Only in the case that the resolver
> > returns a different h_name with zero addresses in the hostent will
> > this code loop around for another call to gethostbyname.
>
> > I'm not an expert on why gethostbyname would or would not include any
> > addresses when resolving through a CNAME. =A0I do know gethostbyname is
> > the old-style resolver, though. =A0I'm not sure that helps with DNSSEC
> > and other security changes being added to DNS, I've seen no hint of
> > support for such in Windows DNS clients or servers.
>
> But I am an expert in this area. This code has a layering violation and
> I won't agree to support that.

You have lost track.  This branch of the thread is a pissing contest
about your ability to read code before you make claims about wspiapi.h
not involving macros, for one, or about wspiapi.h not using the system
resolver, for another.  As I said previously, I appreciate the
education I've been given and I understand NTP has its own emulation
for the new resolver interface should it choose to use such a beast on
Windows, and I understand wspiapi.h in at least one release had a bug
involving intending to test but instead assigning, so am not
advocating its use by NTP.

Cheers,
Dave Hart

Martin Burnicki wrote:
> Danny,
> 
> I think I still have the dynamic DLL function import code lying around.
> Should I try to add it to the current ntp-dev so you just had to care about
> calling the functions and evaluating the results to see if IPv6 is
> supported? That should save you quite a bunch of work.
> 
> Martin

I have your code from the last time so you don't need to look for it.

Thanks,
Danny

Danny Mayer wrote:

> Martin Burnicki wrote:
>> Danny,
>> 
>> I think I still have the dynamic DLL function import code lying around.
>> Should I try to add it to the current ntp-dev so you just had to care
>> about calling the functions and evaluating the results to see if IPv6 is
>> supported? That should save you quite a bunch of work.
>> 
>> Martin
> 
> I have your code from the last time so you don't need to look for it.
> 
> Thanks,
> Danny

Sorry,
as already mentioned I hust wanted to save you some work since you've still
got so many other things on your todo list ...

Martin
-- 
Martin Burnicki

Meinberg Funkuhren
Bad Pyrmont
Germany

Martin Burnicki wrote:
> Danny Mayer wrote:
> 
>> Martin Burnicki wrote:
>>> Danny,
>>>
>>> I think I still have the dynamic DLL function import code lying around.
>>> Should I try to add it to the current ntp-dev so you just had to care
>>> about calling the functions and evaluating the results to see if IPv6 is
>>> supported? That should save you quite a bunch of work.
>>>
>>> Martin
>> I have your code from the last time so you don't need to look for it.
>>
>> Thanks,
>> Danny
> 
> Sorry,
> as already mentioned I hust wanted to save you some work since you've still
> got so many other things on your todo list ...
> 
> Martin

If you want to do this part, sure, go ahead. The other part I will do,
which is to enumerate the IPv4 and IPv6 interfaces and then enable IPv6.
I have the code for that and then we will have to enable the IPv6 for
Windows. Testing is a bit harder.

Thanks,
Danny

Danny Mayer wrote:
> Martin Burnicki wrote:
>> as already mentioned I hust wanted to save you some work since you've
>> still got so many other things on your todo list ...
>> 
>> Martin
> 
> If you want to do this part, sure, go ahead. The other part I will do,
> which is to enumerate the IPv4 and IPv6 interfaces and then enable IPv6.
> I have the code for that and then we will have to enable the IPv6 for
> Windows. Testing is a bit harder.

That's exactly what I meant. 

I'm not too familiar with interface enumeration, network programming, etc.,
so I'd really prefer that you care about that.

However, I can help implementing the basic functionality required to make it
work, so you don't have to spend your time for that.

Martin
-- 
Martin Burnicki

Meinberg Funkuhren
Bad Pyrmont
Germany