From owner-freebsd-current@freebsd.org Sun Jun 21 18:31:26 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id BC5F63576D0 for ; Sun, 21 Jun 2020 18:31:26 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from drew.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.franken.de", Issuer "Sectigo RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49qh2Q3Kvrz4PmR; Sun, 21 Jun 2020 18:31:26 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from mb.fritz.box (ip4d15f5fc.dynamic.kabel-deutschland.de [77.21.245.252]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id ABEA77220B829; Sun, 21 Jun 2020 20:31:23 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: =?utf-8?B?UmU6INCSINC+0YLQstC10YIg0L3QsDogdm5jIGNhbid0IGNvbm5l?= =?utf-8?B?Y3QgdG8gc29ja2V0?= From: Michael Tuexen In-Reply-To: <8899ab009f5a2d6fca0cebd53913ca03a48f4861.camel@freebsd.org> Date: Sun, 21 Jun 2020 20:31:22 +0200 Cc: "bergerkos@yahoo.co.uk" , "freebsd-current@freebsd.org" Content-Transfer-Encoding: 7bit Message-Id: References: <1559644055.2429905.1592721641280.ref@mail.yahoo.com> <1559644055.2429905.1592721641280@mail.yahoo.com> <1749874720.2583691.1592742539717@mail.yahoo.com> <5035A0D1-BF25-4483-BD52-75944EBBEF8E@freebsd.org> <8899ab009f5a2d6fca0cebd53913ca03a48f4861.camel@freebsd.org> To: Ian Lepore X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=disabled version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mail-n.franken.de X-Rspamd-Queue-Id: 49qh2Q3Kvrz4PmR X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [0.00 / 15.00]; ASN(0.00)[asn:680, ipnet:2001:638::/32, country:DE]; local_wl_from(0.00)[freebsd.org] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jun 2020 18:31:26 -0000 > On 21. Jun 2020, at 20:02, Ian Lepore wrote: > > On Sun, 2020-06-21 at 19:54 +0200, Michael Tuexen wrote: >>> On 21. Jun 2020, at 19:40, Ian Lepore wrote: >>> >>> On Sun, 2020-06-21 at 14:54 +0200, Michael Tuexen wrote: >>>>> On 21. Jun 2020, at 14:28, Kostya Berger >>>>> >>>>> wrote: >>>>> >>>>> Ok, it turns out, it gives the previously mentioned error only >>>>> if I >>>>> use VNC server string 0.0.0.0:5900 (as I always did). in my VNC >>>>> client.But when replaced with127.0.0.1:5900it connects all >>>>> right. >>>> >>>> I don't hink 0.0.0.0 is a valid destination address you can use >>>> in >>>> connect(). Using 127.0.0.1 should >>>> be fine. >>>> >>>> I guess, https://svnweb.freebsd.org/changeset/base/361752 is the >>>> relevant commit here. >>>> >>> >>> *BSD has always accepted 0 as a synonym for localhost (and iirc, linux >>> does not). If this no longer works, it's a regression which is going >>> to cause existing applications and scripts to fail. At the very least >>> it deserves an entry in UPDATING. >> >> Hmm. 0.0.0.0 is a wildcard address, meaning any of my local addresses. >> I do understand how that works for binding a TCP socket you will be >> listening on. It just means accept TCP connections on all addresses. >> The destination address of the incoming SYN segment will determine which >> one to use. However, which of the local addresses should be used >> when calling connect() with 0.0.0.0? How should this choice be made? >> >> Best regards >> Michael >> > > I don't know. I had thought the idea was sanctioned by a couple RFCs, > but I just had a fresh look at them (1122, 5735) and it now appears to > me that in both cases it sanctions using 0.0.0.0 as a source address, > but not as a destination. So now I'm thinking maybe it has been a You can use 0.0.0.0 as a source address in specific packets (mainly ones where you don't know your local address like during address configuration), but you can't use it as a destination address. In the TCP case (which is we are looking at), you can't use it as a source or destination address. However, this issue is not about addresses in packets, but address usage in the API, the connect() call for TCP in particular. > historical mistake amongst the BSDs to accept it as a destination > address synonym for 127.0.0.1. That might be possible. But it would be much better to use 127.0.0.1 if you mean it. > > I was mostly just pointing out this change to no longer accept it is > going to be a big surprise to many people when it hits the streets in a > release. I know it's going to break things at $work, we'll have to > start combing around for uses of it and make changes. (Fixing my 20+ > years of finger-memory for "nc 0 " will be harder.) OK. I'll bring that up in the bi-weekly transport telco. It was clear to disallow multicast, but the patch also wanted to deal with 0.0.0.0. For IPv6, there is such a mapping from connect(::0) to connect(::1). So for consistency it might make sense to do/keep the same for IPv4. I need to look at the code why this is working at all for IPv4 as you say it is. Best regards Michael > > -- Ian > >