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 us
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 im
> 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:
> > 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.B
[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/sys
> 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 replac
___
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"
> 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:
>
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 previ
> 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
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 d
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
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
> 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 destina
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
prob
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 'ACP
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 s
17 matches
Mail list logo
