From owner-freebsd-net@freebsd.org Sun Feb 25 21:13:41 2018 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6E0E2F29D9C for ; Sun, 25 Feb 2018 21:13:41 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DF571716EB for ; Sun, 25 Feb 2018 21:13:40 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id w1PLDTaF029288 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 25 Feb 2018 23:13:33 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua w1PLDTaF029288 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id w1PLDTHq029287; Sun, 25 Feb 2018 23:13:29 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 25 Feb 2018 23:13:29 +0200 From: Konstantin Belousov To: jschauma@netmeister.org Cc: freebsd-net@freebsd.org Subject: Re: tcpmux port opened for dual-stack results Message-ID: <20180225211329.GP94212@kib.kiev.ua> References: <20180225203306.GL8306@netmeister.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180225203306.GL8306@netmeister.org> User-Agent: Mutt/1.9.3 (2018-01-21) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Feb 2018 21:13:41 -0000 On Sun, Feb 25, 2018 at 03:33:06PM -0500, Jan Schaumann wrote: > Hi, > > I just encountered something that befuddles me: > > On an AWS EC2 instance (ami-d0b520b8, FreeBSD 10.1-RELEASE), I noticed > that 'telnet www.google.com 80' first opens a UDP socket to google's > addresses on port 1, then closes it without sending any data before > opening the TCP socket. > > Sample (trimmed) ktrace output: > > 1098 telnet RET socket 3 > 1098 telnet CALL connect(0x3,0xbfbfe8c8,0x1c) > 1098 telnet STRU struct sockaddr { AF_INET6, [2607:f8b0:4004:807::2004]:1 } > 1098 telnet RET connect -1 errno 65 No route to host > 1098 telnet CALL close(0x3) > 1098 telnet RET close 0 > 1098 telnet CALL socket(PF_INET,SOCK_CLOEXEC|SOCK_DGRAM,IPPROTO_UDP) > 1098 telnet RET socket 3 > 1098 telnet CALL connect(0x3,0xbfbfe8c8,0x10) > 1098 telnet STRU struct sockaddr { AF_INET, 172.217.12.228:1 } > 1098 telnet RET connect 0 > 1098 telnet CALL getsockname(0x3,0x28c311dc,0xbfbfe8c4) > 1098 telnet STRU struct sockaddr { AF_INET, 10.234.105.225:22661 } > 1098 telnet RET getsockname 0 > 1098 telnet CALL close(0x3) > [...] > 1098 telnet GIO fd 1 wrote 25 bytes > "Trying 172.217.12.228... > " > 1098 telnet RET write 25/0x19 > 1098 telnet CALL socket(PF_INET,SOCK_STREAM,IPPROTO_TCP) > 1098 telnet RET socket 3 > [...] > 1098 telnet CALL connect(0x3,0x28c0f0f0,0x10) > 1098 telnet STRU struct sockaddr { AF_INET, 172.217.12.228:80 } > 1098 telnet RET connect 0 > > > I don't see this happening when the destination host in question has > either only an IPv6 record or only an IPv4 record. In those cases, > telnet will try to open the TCP socket to port 80. In the case of > dual-stack addresses, however, I see the above behaviour. > > (I also see the same behavior in e.g. nc(1), so this is not a telnet(1) > specific thing.) > > Anybody have any idea why this is done? This is getaddrinfo(3) using fake connect(2) to get appropriate source address for the requested destination. They are used to order the result set when there is more that one element, which somewhat explains why do you need inet and inet6 addresses to see this. Note that created socket is not only to port 1 but also UDP.