calls to socket() fail when calling getaddrinfo() with IPPROTO_TCP

[Brian Inglis]

On 2021-07-29 16:41, John Scott via Cygwin wrote:
> I was wondering why my daytime server doesn't work when built for
> Cygwin, and I have been able to narrow it down to this reproducible
> test case:
...
> This code fails with "Failed to create socket: Invalid argument". Does
> anyone have an idea why this happens, given that the arguments to
> socket() come directly from the call to getaddrinfo()? Remarkably,
> changing the service from "daytime" to "http" seems to fix it, which
> seems quite strange.
> 
> I'm not subscribed, so please CC me on replies.

These obsolete legacy time services have always been available built 
into the inetd server in the inetutils package:

$ info inetutils inetd built-in

"daytime
      Send back the current date and time in a human readable form.  Any
      input is discarded.

time
      Send back the current date and time as a 32-bit integer number,
      nrepresenting the number of seconds since midnight, January 1,
      1900."

You could download the source package to study the implementation.

The time protocol client rdate is available from:

	https://github.com/openbsd/src/tree/master/usr.sbin/rdate

As daytime is text in arbitrary display format (likely ctime(3), 
asctime(3)) telnet, netcat, etc. to the service port was probably used.

For currently supported network time services, Meinberg has for many 
years provided native Windows service ports of the latest releases of 
the ntp.org NTP V4 client/server daemon, including a kernel serial 
driver interface supporting GPS devices with PPS signal pins, the latest 
OpenSSL, a Windows installer, and an interactive monitor to control and 
display service daemon NTP info, and view loopstats and peerstats graphs:

	https://www.meinbergglobal.com/english/sw/ntp.htm#ntp_stable

	https://www.meinbergglobal.com/english/sw/ntp-server-monitor.htm

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]