Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 21 Jun 2020 20:31:22 +0200
From:      Michael Tuexen <tuexen@freebsd.org>
To:        Ian Lepore <ian@freebsd.org>
Cc:        "bergerkos@yahoo.co.uk" <bergerkos@yahoo.co.uk>, "freebsd-current@freebsd.org" <freebsd-current@freebsd.org>
Subject:   =?utf-8?B?UmU6INCSINC+0YLQstC10YIg0L3QsDogdm5jIGNhbid0IGNvbm5l?= =?utf-8?B?Y3QgdG8gc29ja2V0?=
Message-ID:  <A004D004-2DC2-493D-9BBD-EEFD50359B60@freebsd.org>
In-Reply-To: <8899ab009f5a2d6fca0cebd53913ca03a48f4861.camel@freebsd.org>
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> <ae6c2e2856e1e7193026c01821571d7f17e3d0f5.camel@freebsd.org> <E9CA2FDE-0F7E-47C8-BB3B-F00F2E471DF3@freebsd.org> <8899ab009f5a2d6fca0cebd53913ca03a48f4861.camel@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
> On 21. Jun 2020, at 20:02, Ian Lepore <ian@freebsd.org> wrote:
> 
> On Sun, 2020-06-21 at 19:54 +0200, Michael Tuexen wrote:
>>> On 21. Jun 2020, at 19:40, Ian Lepore <ian@freebsd.org> wrote:
>>> 
>>> On Sun, 2020-06-21 at 14:54 +0200, Michael Tuexen wrote:
>>>>> On 21. Jun 2020, at 14:28, Kostya Berger <bergerkos@yahoo.co.uk
>>>>>> 
>>>>> 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 <someport>" 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
> 
> 




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?A004D004-2DC2-493D-9BBD-EEFD50359B60>