Re: routed && route6d removal proposal
Sounds good to me. We don't need a RIP daemon in base, and if needed, it is just a pkg install away via one of the myrriad maintained routing daemons. Thanks, Conrad On Sun, Jun 21, 2020 at 4:06 PM Alexander V. Chernikov wrote: > > Hey, > > I would like to propose removal of sbin/routed and usr.sbin/route6d. > > routed(8) is the daemon implementing RIPv2 routing protocol. > route6d(8) is the daemon implementing RIPng routing protocol for IPv6. > > RIP [1] was one of the first protocols used in the networking. The first > version was implemented back in 1982. > > 1. Network landscape has changed since then. BGP, OSPF, IS-ISIS and other > routing protocols have been created and greatly improved over years. People > have created and adopted numerous designs leveraging OSPF/ISIS or BGP. > RIP became obsolete a while ago as there were no competitive advantage it can > offer. > "It is the oldest routing protocol used by the network industry and is > considered by many to be inefficient or border-line obsolete." — [2], 2009 > "Today, the only reason you might run across a network running RIPv2 is > either that the network is very old and in serious need of an upgrade or the > network is running cheaper, consumer-grade routing hardware that can only > support RIP" — [3], 2016. > > 1.1. Nowadays the daemon name is simply misleading. Given situation described > above, one does expect far wider functionality from the program named > "route[6]d" than just RIP implementation. > > 2. Multiple routing stacks supporting all major routing protocol including > RIP exists these days: bird, frr, quagga. Many BGP-only designs in are > gaining popularity, so do bgp speakers such as exabgp or gobgp. Nowadays, if > one needs dynamic routing on the host, OSPF or BGP speaker is the choice. > FreeBSD packages contains well-maintained ports for these. Having RIP[ng] > speakers in base offers no advantage. > > 3. Both routed/route6d are largely unmaintained [4] and presents an > additional attack vector. Here is the list of last non-trivial commits to > routed/route6d: > > sbin/routed: > r327276 - coverity > r317035 - rtsock fix > r299825 - coverity > r299822 - coverity, from netbsd > r299821 - coverity, from netbsd > r299784 - coverity, from netbsd > r299771 - coverify, from netbsd > r286347 - bugfix > r276602 - SA14:21 patch > r271919 - SA14:21 fix > r215702 - logic fix, 2010 > > usr.sbin/route6d: > r337500 - functional fix, 2018 > r317035 - rtsock fix > r311994 - coverity > r311985 - coverity > r299869 - coverity > r299491 - coverity > r270234 - link-local fix > r243233 - functionality improvement, 2012 > > To summarise: RIP protocol is obsolete, implementations for newer protocols > exists in ports, implementation in base is unmaintained. > > With all that in mind I propose to remove routed and route6d from base in > FreeBSD 13. > Timeline: > June 5 - feedback aggregation and decision point > July 19 - removal (proposed) > > > [1] https://en.wikipedia.org/wiki/Routing_Information_Protocol > [2] > https://www.globalknowledge.com/ca-en/resources/resource-library/articles/basics-of-understanding-rip/ > [3] > https://www.networkcomputing.com/data-centers/comparing-dynamic-routing-protocols > [4] > https://bugs.freebsd.org/bugzilla/buglist.cgi?cmdtype=runnamed_id=361897=routed_prs > > /Alexander > ___ > freebsd-hack...@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
routed && route6d removal proposal
Hey, I would like to propose removal of sbin/routed and usr.sbin/route6d. routed(8) is the daemon implementing RIPv2 routing protocol. route6d(8) is the daemon implementing RIPng routing protocol for IPv6. RIP [1] was one of the first protocols used in the networking. The first version was implemented back in 1982. 1. Network landscape has changed since then. BGP, OSPF, IS-ISIS and other routing protocols have been created and greatly improved over years. People have created and adopted numerous designs leveraging OSPF/ISIS or BGP. RIP became obsolete a while ago as there were no competitive advantage it can offer. "It is the oldest routing protocol used by the network industry and is considered by many to be inefficient or border-line obsolete." — [2], 2009 "Today, the only reason you might run across a network running RIPv2 is either that the network is very old and in serious need of an upgrade or the network is running cheaper, consumer-grade routing hardware that can only support RIP" — [3], 2016. 1.1. Nowadays the daemon name is simply misleading. Given situation described above, one does expect far wider functionality from the program named "route[6]d" than just RIP implementation. 2. Multiple routing stacks supporting all major routing protocol including RIP exists these days: bird, frr, quagga. Many BGP-only designs in are gaining popularity, so do bgp speakers such as exabgp or gobgp. Nowadays, if one needs dynamic routing on the host, OSPF or BGP speaker is the choice. FreeBSD packages contains well-maintained ports for these. Having RIP[ng] speakers in base offers no advantage. 3. Both routed/route6d are largely unmaintained [4] and presents an additional attack vector. Here is the list of last non-trivial commits to routed/route6d: sbin/routed: r327276 - coverity r317035 - rtsock fix r299825 - coverity r299822 - coverity, from netbsd r299821 - coverity, from netbsd r299784 - coverity, from netbsd r299771 - coverify, from netbsd r286347 - bugfix r276602 - SA14:21 patch r271919 - SA14:21 fix r215702 - logic fix, 2010 usr.sbin/route6d: r337500 - functional fix, 2018 r317035 - rtsock fix r311994 - coverity r311985 - coverity r299869 - coverity r299491 - coverity r270234 - link-local fix r243233 - functionality improvement, 2012 To summarise: RIP protocol is obsolete, implementations for newer protocols exists in ports, implementation in base is unmaintained. With all that in mind I propose to remove routed and route6d from base in FreeBSD 13. Timeline: June 5 - feedback aggregation and decision point July 19 - removal (proposed) [1] https://en.wikipedia.org/wiki/Routing_Information_Protocol [2] https://www.globalknowledge.com/ca-en/resources/resource-library/articles/basics-of-understanding-rip/ [3] https://www.networkcomputing.com/data-centers/comparing-dynamic-routing-protocols [4] https://bugs.freebsd.org/bugzilla/buglist.cgi?cmdtype=runnamed_id=361897=routed_prs /Alexander ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ? ????? ??: vnc can't connect to socket
> On 21. Jun 2020, at 23:12, Rodney W. Grimes
> 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 do not believe that this is a destination address when your talking
>> about 0.0.0.0:5900 on the VNC server side, that is a wild card accept
>> any address and if this has been broken.. it must be fixed!
>>
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.
>>
>> I am not aware of that, but can not deny it either, and just confirmed
>> it to be true:
>> root {1002}# telnet 0.0.0.0 22
>> Trying 0.0.0.0...
>> Connected to 0.0.0.0.
>> Escape character is '^]'.
>> SSH-2.0-OpenSSH_7.8 FreeBSD-20180909
>
> And to add the netstat data to show what connected:
> tcp4 0 0 127.0.0.1.22 127.0.0.1.43135ESTABLISHED
> tcp4 38 0 127.0.0.1.43135127.0.0.1.22 ESTABLISHED
>
> Can we back this commit out, discuss it in next weeks call,
> and then find a way forward?
The commit changes the behaviour of calling connect(..., addr, ...) on a
TCP/IPv4 socket by
(a) failing it and indicating EAFNOSUPPORT if addr == 255.255.255.255
(b) failing it and indicating EAFNOSUPPORT if addr == 0.0.0.0
I think it is correct in doing (a). There is no doubt about that, since TCP only
supports unicast.
(b) can be changed. As we discussed, for IPv6 connecting to ::0 is changed to
::1 in
https://svnweb.freebsd.org/base/head/sys/netinet6/in6_pcb.c?view=markup#l370.
However, in_pcbladdr() does not do that mapping.
Let me figure out why 0.0.0.0 works as an address you can connect to. Then I can
prepare a patch to allow 0.0.0.0 again. I don't see a reason why we need to
revert
r361752 and introduce it partially again. OK?
Best regards
Michael
>
>>
>> INADDR_ANY is the wildcard listen address, but as a destination what code
>> remapped
>> it to 127.0.0.1?
>>
>> We should very seriously consider restoring this behavior.
>>
>>> -- Ian
>>>
Best regards
Michael
> ?? ?? Yahoo ? ??? Android
>
> ??, 21 ???. 2020 ? 9:40 Kostya Berger
> ???(-?): Hi,upgraded to 362292 via buildworld.Now I cannot
> connect to my bhyve guest as I used to: neither via VNC nor via
> RDP.VNC gets error: unable to connect the socket. Address family
> not supported by protocol family (47).
> Neither can I ping my bhyve IP (it uses a separate NIC and should
> have no problems)
> Internet connectivity is ok and I can ping other hosts on my
> network.
> In 359997 all works fine.
> ?? ?? Yahoo ? ??? Android
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "
> freebsd-current-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "
freebsd-current-unsubscr...@freebsd.org"
>>>
>>> ___
>>> freebsd-current@freebsd.org mailing list
>>> https://lists.freebsd.org/mailman/listinfo/freebsd-current
>>> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>>>
>>>
>>
>> --
>> Rod Grimes
>> rgri...@freebsd.org
>> ___
>> freebsd-current@freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-current
>> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>>
>
> --
> Rod Grimes rgri...@freebsd.org
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ? ????? ??: vnc can't connect to socket
> > 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 do not believe that this is a destination address when your talking
> about 0.0.0.0:5900 on the VNC server side, that is a wild card accept
> any address and if this has been broken.. it must be fixed!
>
> > > 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.
>
> I am not aware of that, but can not deny it either, and just confirmed
> it to be true:
> root {1002}# telnet 0.0.0.0 22
> Trying 0.0.0.0...
> Connected to 0.0.0.0.
> Escape character is '^]'.
> SSH-2.0-OpenSSH_7.8 FreeBSD-20180909
And to add the netstat data to show what connected:
tcp4 0 0 127.0.0.1.22 127.0.0.1.43135ESTABLISHED
tcp4 38 0 127.0.0.1.43135127.0.0.1.22 ESTABLISHED
Can we back this commit out, discuss it in next weeks call,
and then find a way forward?
>
> INADDR_ANY is the wildcard listen address, but as a destination what code
> remapped
> it to 127.0.0.1?
>
> We should very seriously consider restoring this behavior.
>
> > -- Ian
> >
> > > Best regards
> > > Michael
> > > > ?? ?? Yahoo ? ??? Android
> > > >
> > > > ??, 21 ???. 2020 ? 9:40 Kostya Berger
> > > > ???(-?): Hi,upgraded to 362292 via buildworld.Now I cannot
> > > > connect to my bhyve guest as I used to: neither via VNC nor via
> > > > RDP.VNC gets error: unable to connect the socket. Address family
> > > > not supported by protocol family (47).
> > > > Neither can I ping my bhyve IP (it uses a separate NIC and should
> > > > have no problems)
> > > > Internet connectivity is ok and I can ping other hosts on my
> > > > network.
> > > > In 359997 all works fine.
> > > > ?? ?? Yahoo ? ??? Android
> > > > ___
> > > > freebsd-current@freebsd.org mailing list
> > > > https://lists.freebsd.org/mailman/listinfo/freebsd-current
> > > > To unsubscribe, send any mail to "
> > > > freebsd-current-unsubscr...@freebsd.org"
> > >
> > > ___
> > > freebsd-current@freebsd.org mailing list
> > > https://lists.freebsd.org/mailman/listinfo/freebsd-current
> > > To unsubscribe, send any mail to "
> > > freebsd-current-unsubscr...@freebsd.org"
> > >
> >
> > ___
> > freebsd-current@freebsd.org mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-current
> > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
> >
> >
>
> --
> Rod Grimes rgri...@freebsd.org
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>
--
Rod Grimes rgri...@freebsd.org
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: net.inet6.ip6.deembed_scopeid removal
[re-sending email with as non-html] Hey, I would like to deprecate net.inet6.ip6.deembed_scopeid sysctl while leaving the current default behaviour. This sysctl controls whether IPv6 scope is embedded in the IPv6 address or not when reading or writing route/interface/ifaddr data via rtsock/sysctl. Embedding scope in the address is a hack, that overwrites some of the bits that can be used otherwise. It was probably implemented that way to simplify route table interactions, as rtable uses this hack to add link-local addresses to the same radix tree. The change to fix the userland api by filling in sin6_scopeid and avoid touching IPv6 address was added in r243187, 7 years ago. It provided the sysctl in question, allowing to preserve compatibility with older applications, by reverting to the old behavior. 7 years looks like enough timeframe for the applications to be adjusted. Unless any major objections arise, I'm going to remove the code and make de-embedded IPv6 addresses the only option on July 5 2020. /Alexander ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ? ????? ??: vnc can't connect to socket
> 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 do not believe that this is a destination address when your talking
about 0.0.0.0:5900 on the VNC server side, that is a wild card accept
any address and if this has been broken.. it must be fixed!
> > 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.
I am not aware of that, but can not deny it either, and just confirmed
it to be true:
root {1002}# telnet 0.0.0.0 22
Trying 0.0.0.0...
Connected to 0.0.0.0.
Escape character is '^]'.
SSH-2.0-OpenSSH_7.8 FreeBSD-20180909
INADDR_ANY is the wildcard listen address, but as a destination what code
remapped
it to 127.0.0.1?
We should very seriously consider restoring this behavior.
> -- Ian
>
> > Best regards
> > Michael
> > > ?? ?? Yahoo ? ??? Android
> > >
> > > ??, 21 ???. 2020 ? 9:40 Kostya Berger
> > > ???(-?): Hi,upgraded to 362292 via buildworld.Now I cannot
> > > connect to my bhyve guest as I used to: neither via VNC nor via
> > > RDP.VNC gets error: unable to connect the socket. Address family
> > > not supported by protocol family (47).
> > > Neither can I ping my bhyve IP (it uses a separate NIC and should
> > > have no problems)
> > > Internet connectivity is ok and I can ping other hosts on my
> > > network.
> > > In 359997 all works fine.
> > > ?? ?? Yahoo ? ??? Android
> > > ___
> > > freebsd-current@freebsd.org mailing list
> > > https://lists.freebsd.org/mailman/listinfo/freebsd-current
> > > To unsubscribe, send any mail to "
> > > freebsd-current-unsubscr...@freebsd.org"
> >
> > ___
> > freebsd-current@freebsd.org mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-current
> > To unsubscribe, send any mail to "
> > freebsd-current-unsubscr...@freebsd.org"
> >
>
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>
>
--
Rod Grimes rgri...@freebsd.org
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
net.inet6.ip6.deembed_scopeid removal
___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: В ответ на: vnc can't connect to socket
> 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 > > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: В ответ на: vnc can't connect to socket
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 historical mistake amongst the BSDs to accept it as a destination address synonym for 127.0.0.1. 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.) -- Ian ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: В ответ на: vnc can't connect to socket
> 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 > > -- Ian > >> Best regards >> Michael >>> Отправлено из Yahoo Почты для Android >>> >>> вс, 21 июн. 2020 в 9:40 Kostya Berger >>> написал(-а): Hi,upgraded to 362292 via buildworld.Now I cannot >>> connect to my bhyve guest as I used to: neither via VNC nor via >>> RDP.VNC gets error: unable to connect the socket. Address family >>> not supported by protocol family (47). >>> Neither can I ping my bhyve IP (it uses a separate NIC and should >>> have no problems) >>> Internet connectivity is ok and I can ping other hosts on my >>> network. >>> In 359997 all works fine. >>> Отправлено из Yahoo Почты для Android >>> ___ >>> freebsd-current@freebsd.org mailing list >>> https://lists.freebsd.org/mailman/listinfo/freebsd-current >>> To unsubscribe, send any mail to " >>> freebsd-current-unsubscr...@freebsd.org" >> >> ___ >> freebsd-current@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to " >> freebsd-current-unsubscr...@freebsd.org" >> > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
В ответ на: Re: В ответ на: vnc can't connect to socket
Oh, I see, thank you. Отправлено из Yahoo Почты для Android вс, 21 июн. 2020 в 15:54 Michael Tuexen написал(-а): > 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. Best regards Michael > Отправлено из Yahoo Почты для Android > > вс, 21 июн. 2020 в 9:40 Kostya Berger написал(-а): > Hi,upgraded to 362292 via buildworld.Now I cannot connect to my bhyve guest > as I used to: neither via VNC nor via RDP.VNC gets error: unable to connect > the socket. Address family not supported by protocol family (47). > Neither can I ping my bhyve IP (it uses a separate NIC and should have no > problems) > Internet connectivity is ok and I can ping other hosts on my network. > In 359997 all works fine. > Отправлено из Yahoo Почты для Android > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: В ответ на: vnc can't connect to socket
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. -- Ian > Best regards > Michael > > Отправлено из Yahoo Почты для Android > > > > вс, 21 июн. 2020 в 9:40 Kostya Berger > > написал(-а): Hi,upgraded to 362292 via buildworld.Now I cannot > > connect to my bhyve guest as I used to: neither via VNC nor via > > RDP.VNC gets error: unable to connect the socket. Address family > > not supported by protocol family (47). > > Neither can I ping my bhyve IP (it uses a separate NIC and should > > have no problems) > > Internet connectivity is ok and I can ping other hosts on my > > network. > > In 359997 all works fine. > > Отправлено из Yahoo Почты для Android > > ___ > > freebsd-current@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to " > > freebsd-current-unsubscr...@freebsd.org" > > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to " > freebsd-current-unsubscr...@freebsd.org" > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
В ответ на: vnc can't connect to socket
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. Отправлено из Yahoo Почты для Android вс, 21 июн. 2020 в 9:40 Kostya Berger написал(-а): Hi,upgraded to 362292 via buildworld.Now I cannot connect to my bhyve guest as I used to: neither via VNC nor via RDP.VNC gets error: unable to connect the socket. Address family not supported by protocol family (47). Neither can I ping my bhyve IP (it uses a separate NIC and should have no problems) Internet connectivity is ok and I can ping other hosts on my network. In 359997 all works fine. Отправлено из Yahoo Почты для Android ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: В ответ на: vnc can't connect to socket
> 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. Best regards Michael > Отправлено из Yahoo Почты для Android > > вс, 21 июн. 2020 в 9:40 Kostya Berger написал(-а): > Hi,upgraded to 362292 via buildworld.Now I cannot connect to my bhyve guest > as I used to: neither via VNC nor via RDP.VNC gets error: unable to connect > the socket. Address family not supported by protocol family (47). > Neither can I ping my bhyve IP (it uses a separate NIC and should have no > problems) > Internet connectivity is ok and I can ping other hosts on my network. > In 359997 all works fine. > Отправлено из Yahoo Почты для Android > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
vnc can't connect to socket
Hi,upgraded to 362292 via buildworld.Now I cannot connect to my bhyve guest as I used to: neither via VNC nor via RDP.VNC gets error: unable to connect the socket. Address family not supported by protocol family (47). Neither can I ping my bhyve IP (it uses a separate NIC and should have no problems) Internet connectivity is ok and I can ping other hosts on my network. In 359997 all works fine. Отправлено из Yahoo Почты для Android ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: `shutdown -p now` fails to power off with VirtualBox UEFI boot
Olivier Cochard-Labbé wrote: On Thu, Jun 18, 2020 at 10:26 PM Yasuhiro KIMURA wrote: I have VirtualBox VM running 13-CURRENT. In order to switch from legacy BIOS to UEFI I reinstalled OS by using FreeBSD-13.0-CURRENT-amd64-20200611-r362037-disc1.iso. After that `shutdow -p now` (or select 'ACPI shutdown' in VM menu) fails to power off. Shutdown itself completes successfully. But power off never happens and CPU usage keeps high until either closing or resetting VM. I reinstalled OS by using FreeBSD-13.0-CURRENT-amd64-20200618-r362292-disc1.iso but the problem still happens. If I switch back to legacy BIOS then the problem disappears. And it doesn't happen with either 11.4-RELEASE and 12.1-RELEASE. Hi, Same problem using FreeBSD current UEFI guests with bhyve, so it should happen in any kind of hypervisor. It is an old regression (in the sense of -current, so older than 6 months). My idea was to generate very light UEFI VM images (because the snapshot VM images are BIOS based) and scripting a bisector tool, but I never took the time to do it. FWIW, shutdown works for me in VMware Workstation (Windows) and ESXi VMs, UEFI boot. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: `shutdown -p now` fails to power off with VirtualBox UEFI boot
On 6/21/20 12:37 AM, Olivier Cochard-Labbé wrote: Same problem using FreeBSD current UEFI guests with bhyve, so it should happen in any kind of hypervisor. It is an old regression (in the sense of -current, so older than 6 months). My idea was to generate very light UEFI VM images (because the snapshot VM images are BIOS based) and scripting a bisector tool, but I never took the time to do it. The problem on FreeBSD CURRENT at least is caused by the bhyve UEFI firmware that's running: I've committed a fix upstream to fix it (https://github.com/tianocore/edk2/commit/f159102a130fac9b416418eb9b6fa35b63426ca5), but still need to get CSM support working again before we can switch everyone over from the UDK2014.SP1 build to the newer code. -- Rebecca Cran ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: `shutdown -p now` fails to power off with VirtualBox UEFI boot
On Thu, Jun 18, 2020 at 10:26 PM Yasuhiro KIMURA wrote: > I have VirtualBox VM running 13-CURRENT. In order to switch from > legacy BIOS to UEFI I reinstalled OS by using > FreeBSD-13.0-CURRENT-amd64-20200611-r362037-disc1.iso. After that > `shutdow -p now` (or select 'ACPI shutdown' in VM menu) fails to power > off. Shutdown itself completes successfully. But power off never > happens and CPU usage keeps high until either closing or resetting VM. > > I reinstalled OS by using > FreeBSD-13.0-CURRENT-amd64-20200618-r362292-disc1.iso but the problem > still happens. If I switch back to legacy BIOS then the problem > disappears. And it doesn't happen with either 11.4-RELEASE and > 12.1-RELEASE. > > > Hi, Same problem using FreeBSD current UEFI guests with bhyve, so it should happen in any kind of hypervisor. It is an old regression (in the sense of -current, so older than 6 months). My idea was to generate very light UEFI VM images (because the snapshot VM images are BIOS based) and scripting a bisector tool, but I never took the time to do it. Regards, Olivier ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
