Re: В ответ на: vnc can't connect to socket

> On 21. Jun 2020, at 20:02, Ian Lepore <ian_at_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_at_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_at_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
> 
>