X-Recipient: archive-cygwin AT delorie DOT com
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 75206394FC01
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com;
	s=default; t=1627637709;
	bh=ZW6D3FRbPippiZ1nrlmtkcPNIJl8YeU9PzXNLGoaIVU=;
	h=Date:To:Subject:References:In-Reply-To:List-Id:List-Unsubscribe:
	 List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc:
	 From;
	b=x+TVn/2+qkuDcUXlYDHpI/YGYu60EP7mIkowE1hhXDq/5Dk99cKT/59TktirKvdZD
	 EUOeKfoaanfekuUBYpqGwU91mmd7fuFHpoGQyt8p8fea3zuH+7f91MeffyQdjY8PZO
	 z8R4BgbVASoGvp/tgbP5VGXDc+lCgD60UTj5T2kU=
X-Original-To: cygwin AT cygwin DOT com
Delivered-To: cygwin AT cygwin DOT com
DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 4126B394FC01
Date: Fri, 30 Jul 2021 11:34:34 +0200
To: John Scott <jscott AT posteo DOT net>
Subject: Re: calls to socket() fail when calling getaddrinfo() with IPPROTO_TCP
Message-ID: <YQPHquBoiwj50IdF@calimero.vinschen.de>
Mail-Followup-To: John Scott <jscott AT posteo DOT net>, cygwin AT cygwin DOT com
References: <1f5c0302c156c9391d294ea9df84d93b8742a500 DOT camel AT posteo DOT net>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1f5c0302c156c9391d294ea9df84d93b8742a500.camel@posteo.net>
X-Provags-ID: V03:K1:zXkwk4fesqPp709m+KXmmeF/EDDrAvjYZnuR0xI9LL20VmrOsNB
 vkeA7tIdykZrP6197HuWdQ7eco1u+jyJpXOkuhWaCU8Yp060pdyznmA/NcnJ70YphZEg0iN
 f07VHFO6V0uVjf2OikJD3fE8z1Zf5RxJlCpMWfuSrr9cGqcqWRw1juJtddIfANz3rngiyOt
 VdKvbjbZck4jd34AXfWyA==
X-UI-Out-Filterresults: notjunk:1;V03:K0:L5fv/56Mte4=:MDPjqOOIEHDXykLUIiHA3r
 oZMqvL02H+XVJIqxfK2HcLe0VWZSnwFTLODsO1e21aIp3nxmvibV/ro9pmLMD/asX0XPpJcth
 CAyrdzaI/DrxbSGdHZxmo1rOavKUcTjF5+UxyBUPFuum94Iw6v6YEMGzDagf+hMAWhxwgZlLp
 oEpHBGalCu15u88+mqY8Gnxww2RXWDu8uJ2sL5ub/ETRxGXtO6Lx07ibta2GXm2M7GX8iPNaj
 wQ89tz3WTxqzot15fyfcNTlNw8W9V+f/ONwdAnVrABhiSADbTICkLd8GJY/v3TB9E5MZ+tZoy
 1qXxQqAkU029gI7ySuFDl/fJutvyO2Fbi0IiTTy+hRzLkfd92AQsapjJEaLZLjO9K+r38VYaX
 +90Xt56alfj1KuQUVofbgfxp8HJNlQN4ZXoukfNcBWc8HFQVct4sTLdLztJmBObSp1YGcE/Hz
 1lkM9cHbl0USpqB6GNvho4DMpjiphavBCCc7vSmRyW9muUQRMB6pfMjj5S9LmxpXKb1MSUg/5
 oYrC5VuBO4S1lAVf3xi1+CQ443jDkxtawDCdFqwh3h+Tmk2Nu0KngzxOFntK6sLPGfoYbgtux
 QdYdgNcvwYFr9anW3bvFICoSmRFqNWXBlKuz2xKwCXtrmqabiIg4c17rgxi1aDIbupQq/bFCK
 PqjoWhbyGceWE0Z2mHyPaZfqkXlZ59S8cfl2OfH8IfKuXGEy9ewnPVLj6zozcqnXecoXNQxrN
 YBLt+BiqXL8H09rXo36J8gSLr+D8hec76Sa9nnCAfNMNl+Pyp1VRBbI5C+TEP34ApwNDY1GVF
 YGLNfRfj1FFYdXntV8IYnXcwU3ooCI88NS3P3BNWJ0Xv06/WacIk9+dOKQxxCIsBULo8dEZSK
 yQfLNrkb6tWqBt8+Uz5g==
X-Spam-Status: No, score=-100.2 required=5.0 tests=BAYES_00,
 GOOD_FROM_CORINNA_CYGWIN, KAM_DMARC_NONE, KAM_DMARC_STATUS, RCVD_IN_DNSWL_NONE,
 RCVD_IN_MSPIKE_H2, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE,
 SPF_NEUTRAL, TXREP autolearn=ham autolearn_force=no version=3.4.4
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on
 server2.sourceware.org
X-BeenThere: cygwin AT cygwin DOT com
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: General Cygwin discussions and problem reports <cygwin.cygwin.com>
List-Unsubscribe: <https://cygwin.com/mailman/options/cygwin>,
 <mailto:cygwin-request AT cygwin DOT com?subject=unsubscribe>
List-Archive: <https://cygwin.com/pipermail/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-request AT cygwin DOT com?subject=help>
List-Subscribe: <https://cygwin.com/mailman/listinfo/cygwin>,
 <mailto:cygwin-request AT cygwin DOT com?subject=subscribe>
From: Corinna Vinschen via Cygwin <cygwin AT cygwin DOT com>
Reply-To: cygwin AT cygwin DOT com
Cc: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>, cygwin AT cygwin DOT com
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: cygwin-bounces+archive-cygwin=delorie DOT com AT cygwin DOT com
Sender: "Cygwin" <cygwin-bounces+archive-cygwin=delorie DOT com AT cygwin DOT com>

Hi John,

On Jul 29 22:41, John Scott via Cygwin wrote:
> Hi,
> 
> 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()?

Welcome to the Windows implementation of getaddrinfo.

Assuming you call getaddrinfo (NULL, "daytime", NULL, &result), you get
the following return from Linux:

  family: 2 socktype 1 protocol 6	AF_INET,  STREAM, TCP
  family: 2 socktype 2 protocol 17	AF_INET,  DGRAM,  UCP
  family: 10 socktype 1 protocol 6	AF_INET6, STREAM, TCP
  family: 10 socktype 2 protocol 17	AF_INET6, DGRAM,  UCP

The same call on Windows returns:

  family: 23 socktype 0 protocol 0	AF_INET6, any, any
  family: 2 socktype 0 protocol 0	AF_INET,  any, any

If the service supports both, TCP and UDP, then socktype and protocol
are always 0 on Windows.  The restriction from the hints parameter
*only* restricts the output for that very field!

I.e., your hints with .ai_protocol = IPPROTO_TCP only restricts the
output of the ai_protocol field, not the output of the ai_socktype
field:

  family: 23 socktype 0 protocol 6	AF_INET6, any, TCP
  family: 2 socktype 0 protocol 6	AF_INET,  any, TCP

On Linux you get the less surprising result

  family: 2 socktype 1 protocol 6	AF_INET,  STREAM, TCP
  family: 10 socktype 1 protocol 6	AF_INET6, STREAM, TCP

> Remarkably,
> changing the service from "daytime" to "http" seems to fix it, which
> seems quite strange.

Yeah, that's a bad joke as well.  The reason is that the http service is
defined for TCP only.  Not for UDP.  As a result, Windows' getaddrinfo
suddenly returns a valid ai_socktype field:

  family: 23 socktype 1 protocol 6	AF_INET6, STREAM, TCP
  family: 2 socktype 1 protocol 6	AF_INET,  STREAM, TCP

Cygwin implements a shallow (~300 lines) wrapper over the WinSock
GetAddrInfoW function and otherwise relies on the values returned by the
OS.  However, it already duplicates the returned list to self-allocated
memory, which is required for fork(2) semantics.  It should be possible
to improve the wrapper to duplicate entries with socktype and protocol
0-entries, but that would be in the next Cygwin version earliest.

Back to your problem.  For the time being, you can easily "fix" your
code by changing the hints:

- 	int s = getaddrinfo(NULL, "daytime", &(const struct addrinfo){.ai_flags = AI_PASSIVE, .ai_protocol = IPPROTO_TCP}, &res);
+ 	int s = getaddrinfo(NULL, "daytime", &(const struct addrinfo){.ai_flags = AI_PASSIVE, .ai_socktype = SOCK_STREAM}, &res);

This returns

  family: 23 socktype 1 protocol 0      AF_INET6, STREAM, any
  family: 2 socktype 1 protocol 0       AF_INET,  STREAM, any

The content of the protocol parameter doesn't really matter to socket(2),
so it will work on Cygwin as well as on Linux and others.
  

HTH,
Corinna

-- 
Problem reports:      https://cygwin.com/problems.html
FAQ:                  https://cygwin.com/faq/
Documentation:        https://cygwin.com/docs.html
Unsubscribe info:     https://cygwin.com/ml/#unsubscribe-simple