rtsol

Hi Robert

Post by Robert Swindells
What is the recommended way to replace rtsol(8) ?
I have read the man page.
dhcpcd=YES
dhcpcd_flags="-B6 --nodhcp6 rtk0"
At boot, dhcpcd prints that it has received the RA but then blocks,
prints an error that it has timed out and overwrites the
/etc/resolv.conf file with an empty one.
It doesn't set the IPv6 address of the interface.

Remove the B flag, that stops it forking to the background.
You may need the ipv6ra_fork option if your RA doesn't provide the RDNSS
option and you're not doing an IPv4 setup to avoid the timeout error.

As you're setting one interface via the flags and not dhcpcd.conf I
would recommend adding the M flag as well in-case you want to use any
dhcpcd tools further down the road.

The resolv.conf part is tricky - because dhcpcd supports DNSSL and RDNSS
options that need to expire it needs to be able to manage resolv.conf
somehow. The solution is to either disable dhcpcd from writing to it at
all (--nohook resolv.conf), setup your static config using
resolvconf.conf or make the file immutable. Is this something we should
document in resolv.conf(5)?

Roy

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

Robert Swindells

2014-10-21 12:02:55 UTC

The RA comes from rtadvd(8) on another NetBSD system, I needed the
ipv6ra_fork option.

It doesn't block or generate an error now.

It still doesn't set the IPv6 address though, which was the whole
point of running rtsol previously.

Post by Roy Marples
As you're setting one interface via the flags and not dhcpcd.conf I
would recommend adding the M flag as well in-case you want to use any
dhcpcd tools further down the road.

I just followed the suggestion in the new rtsol man page.

I think users are going to get bitten by this when upgrading to
NetBSD-7.

Post by Roy Marples
The resolv.conf part is tricky - because dhcpcd supports DNSSL and RDNSS
options that need to expire it needs to be able to manage resolv.conf
somehow. The solution is to either disable dhcpcd from writing to it at
all (--nohook resolv.conf), setup your static config using
resolvconf.conf or make the file immutable. Is this something we should
document in resolv.conf(5)?

I would expect the default behaviour to be to not overwrite
resolv.conf on an error.

Robert Swindells

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

Roy Marples

2014-10-21 12:30:15 UTC

The RA comes from rtadvd(8) on another NetBSD system, I needed the
ipv6ra_fork option.
It doesn't block or generate an error now.
It still doesn't set the IPv6 address though, which was the whole
point of running rtsol previously.

rtadvd(8) supports setting RDNSS servers to populate resolv.conf with.
So if you set that, you don't need the ipv6ra_fork.
I think we could possibly set this by default if *only* running IPv6RS,
ie disable IPv4 entirely and DHCPv6 as you have done.

I don't know why it doesn't set an address though.
Can you post the output of dhcpcd -dT6 --nodhcp rtk0 please?

Post by Roy Marples
As you're setting one interface via the flags and not dhcpcd.conf I
would recommend adding the M flag as well in-case you want to use any
dhcpcd tools further down the road.

I just followed the suggestion in the new rtsol man page.
I think users are going to get bitten by this when upgrading to
NetBSD-7.

The example in the man page is just for testing purposes, it even states
that. For example, the --nodhcp6 flag is only intended for testing as
the RA message will say if DHCPv6 should be started or not.

I would expect the default behaviour to be to not overwrite
resolv.conf on an error.

This behaves like DHCP, DHCPv6 or a vpn link - expect resolv.conf to be
modified. The entry for the interface is cleared on start, just like the
addresses are cleared on a reboot. Hence the above comment I made.

Roy

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

Alan Barrett

2014-10-21 13:06:31 UTC

Post by Robert Swindells
I just followed the suggestion in the new rtsol man page.
I think users are going to get bitten by this when upgrading to
NetBSD-7.

The example in the man page is just for testing purposes

Please could we have documentation for what people need to change
in all the common cases of migrating from a system with rtsol and
rtsold, to a system without them.

--apb (Alan Barrett)

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

Roy Marples

2014-10-21 13:23:39 UTC

Post by Robert Swindells
I just followed the suggestion in the new rtsol man page.
I think users are going to get bitten by this when upgrading to
NetBSD-7.

The example in the man page is just for testing purposes

Please could we have documentation for what people need to change in all
the common cases of migrating from a system with rtsol and rtsold, to a
system without them.

In rc.conf
dhcpcd=YES

This is the intent stated in the 1st paragraph of the man page.
You are also advised to enable dhcpcd if you have rtsol configured when
running rc.d/network.

Roy

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

Robert Swindells

2014-10-21 14:09:50 UTC

The RA comes from rtadvd(8) on another NetBSD system, I needed the
ipv6ra_fork option.
It doesn't block or generate an error now.
It still doesn't set the IPv6 address though, which was the whole
point of running rtsol previously.

rtadvd(8) supports setting RDNSS servers to populate resolv.conf with.
So if you set that, you don't need the ipv6ra_fork.
I think we could possibly set this by default if *only* running IPv6RS,
ie disable IPv4 entirely and DHCPv6 as you have done.
I don't know why it doesn't set an address though.
Can you post the output of dhcpcd -dT6 --nodhcp rtk0 please?

dhcpcd[244]: version 6.5.1 starting
dhcpcd[244]: DUID 00:01:00:01:1b:ca:5e:a8:00:13:d4:bb:35:ed
dhcpcd[244]: rtk0: IAID f2:75:b2:f0
dhcpcd[244]: rtk0: delaying IPv6 router solictation for 0.4 seconds
dhcpcd[244]: rtk0: soliciting an IPv6 router
dhcpcd[244]: rtk0: sending Router Solicitation
dhcpcd[244]: rtk0: Router Advertisement from fe80::3e4a:92ff:fe77:c13c
dhcpcd[244]: rtk0: executing `/libexec/dhcpcd-run-hooks' TEST
interface=rtk0
pid=244
reason=TEST
skip_hooks='lookup-hostname resolv.conf'
ifcarrier=up
ifflags=4294936643
ifmtu=1500
ifwireless=0
ra1_addr=2001:8b0:beb9:11c7:215:f2ff:fe75:b2f0/64
ra1_from=fe80::3e4a:92ff:fe77:c13c
ra1_prefix=2001:8b0:beb9:11c7::/64
ra_count=1
dhcpcd[244]: rtk0: No DHCPv6 instruction in RA
dhcpcd[244]: exited

There was also a kernel message printed when dhcpcd ran at boot:

nd6_dad_timer: called with non-tentative address 2001:8b0:beb9:11c7:215:f2ff:fe75:b2f0(rtk0)

Post by Roy Marples
As you're setting one interface via the flags and not dhcpcd.conf I
would recommend adding the M flag as well in-case you want to use any
dhcpcd tools further down the road.

I just followed the suggestion in the new rtsol man page.
I think users are going to get bitten by this when upgrading to
NetBSD-7.

I don't want to run DHCPv6. I didn't need it before, why would I need it
now ?

I would expect the default behaviour to be to not overwrite
resolv.conf on an error.

It still fails POLA for me.

Robert Swindells

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

Roy Marples

2014-10-21 14:43:38 UTC

Post by Roy Marples
I don't know why it doesn't set an address though.
Can you post the output of dhcpcd -dT6 --nodhcp rtk0 please?

dhcpcd[244]: version 6.5.1 starting
dhcpcd[244]: DUID 00:01:00:01:1b:ca:5e:a8:00:13:d4:bb:35:ed
dhcpcd[244]: rtk0: IAID f2:75:b2:f0
dhcpcd[244]: rtk0: delaying IPv6 router solictation for 0.4 seconds
dhcpcd[244]: rtk0: soliciting an IPv6 router
dhcpcd[244]: rtk0: sending Router Solicitation
dhcpcd[244]: rtk0: Router Advertisement from fe80::3e4a:92ff:fe77:c13c
dhcpcd[244]: rtk0: executing `/libexec/dhcpcd-run-hooks' TEST
interface=rtk0
pid=244
reason=TEST
skip_hooks='lookup-hostname resolv.conf'
ifcarrier=up
ifflags=4294936643
ifmtu=1500
ifwireless=0
ra1_addr=2001:8b0:beb9:11c7:215:f2ff:fe75:b2f0/64
ra1_from=fe80::3e4a:92ff:fe77:c13c
ra1_prefix=2001:8b0:beb9:11c7::/64
ra_count=1
dhcpcd[244]: rtk0: No DHCPv6 instruction in RA
dhcpcd[244]: exited
nd6_dad_timer: called with non-tentative address 2001:8b0:beb9:11c7:215:f2ff:fe75:b2f0(rtk0)

Please update sys/netinet6/in6.c to version 1.177 which should hopefully
fix this.

Post by Roy Marples
As you're setting one interface via the flags and not dhcpcd.conf I
would recommend adding the M flag as well in-case you want to use any
dhcpcd tools further down the road.

I just followed the suggestion in the new rtsol man page.
I think users are going to get bitten by this when upgrading to
NetBSD-7.

I don't want to run DHCPv6. I didn't need it before, why would I need it
now ?

The difference is that you're explicitly saying you don't need it. If
you do this for say 100 nodes and later decide you do want DHCPv6 you
can change this in the router rather than 100 nodes.

Roy

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

Robert Swindells

2014-10-21 16:47:17 UTC

I would expect the default behaviour to be to not overwrite
resolv.conf on an error.

It still fails POLA for me.

But dhcpcd has not learned the information that is being deleted.

I am suggesting that in the case where nothing is returned then no
change should be made to resolv.conf.

Robert Swindells

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

Robert Swindells

2014-10-21 18:39:01 UTC

Post by Roy Marples
I don't know why it doesn't set an address though.
Can you post the output of dhcpcd -dT6 --nodhcp rtk0 please?

dhcpcd[244]: version 6.5.1 starting
dhcpcd[244]: DUID 00:01:00:01:1b:ca:5e:a8:00:13:d4:bb:35:ed
dhcpcd[244]: rtk0: IAID f2:75:b2:f0
dhcpcd[244]: rtk0: delaying IPv6 router solictation for 0.4 seconds
dhcpcd[244]: rtk0: soliciting an IPv6 router
dhcpcd[244]: rtk0: sending Router Solicitation
dhcpcd[244]: rtk0: Router Advertisement from fe80::3e4a:92ff:fe77:c13c
dhcpcd[244]: rtk0: executing `/libexec/dhcpcd-run-hooks' TEST
interface=rtk0
pid=244
reason=TEST
skip_hooks='lookup-hostname resolv.conf'
ifcarrier=up
ifflags=4294936643
ifmtu=1500
ifwireless=0
ra1_addr=2001:8b0:beb9:11c7:215:f2ff:fe75:b2f0/64
ra1_from=fe80::3e4a:92ff:fe77:c13c
ra1_prefix=2001:8b0:beb9:11c7::/64
ra_count=1
dhcpcd[244]: rtk0: No DHCPv6 instruction in RA
dhcpcd[244]: exited
nd6_dad_timer: called with non-tentative address 2001:8b0:beb9:11c7:215:f2ff:fe75:b2f0(rtk0)

Please update sys/netinet6/in6.c to version 1.177 which should hopefully
fix this.

The address only became set after about 5 minutes with a new kernel.

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

Roy Marples

2014-10-21 18:21:01 UTC

Post by Robert Swindells
But dhcpcd has not learned the information that is being deleted.
I am suggesting that in the case where nothing is returned then no
change should be made to resolv.conf.

These are indeed fair points, but I feel the conversion has now moved
from dhcpcd(8) to resolvconf(8).

resolvconf(8) simply takes all available inputs and then outputs
something sensible. Without any configuration or input you get a blank
resolv.conf(5).

Of course, we could do things a little differently. Here's some ideas,
from worst to best in my mind:

* resolvconf should be opt-in rather than opt-out in resolvconf.conf

* refuse to update resolv.conf if it doesn't contain the resolvconf
signature when adding or removing interfaces via resolvconf

* if resolv.conf has no valid signature, save it and only restore it
when resolvconf has no valid inputs left

Any of these changes could affect the long standing behaviour of
resolvconf placing a blank resolv.conf file to make 127.0.0.1 the
resolver to use.

Commentary on this is welcome.

Roy

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

Christos Zoulas

2014-10-22 13:09:34 UTC

Post by Robert Swindells
But dhcpcd has not learned the information that is being deleted.
I am suggesting that in the case where nothing is returned then no
change should be made to resolv.conf.

These are indeed fair points, but I feel the conversion has now moved
from dhcpcd(8) to resolvconf(8).
resolvconf(8) simply takes all available inputs and then outputs
something sensible. Without any configuration or input you get a blank
resolv.conf(5).
Of course, we could do things a little differently. Here's some ideas,
* resolvconf should be opt-in rather than opt-out in resolvconf.conf
* refuse to update resolv.conf if it doesn't contain the resolvconf
signature when adding or removing interfaces via resolvconf
* if resolv.conf has no valid signature, save it and only restore it
when resolvconf has no valid inputs left
Any of these changes could affect the long standing behaviour of
resolvconf placing a blank resolv.conf file to make 127.0.0.1 the
resolver to use.

I just want to be able to precisely control its behaviour which in the
current configuration language I cannot. I.e. I should be able by setting
variables to affect the output resolv.conf file to be exactly how I
like it. For example, if I want 127.0.0.1 not to be the first resolving
nameserver, I should be able to do it. If I want to change the domain,
I should be able to do it. If I want to delete the ISP's nameservers
and the ISP suffix from the search path, I should be able to do it.
Right now resolvconf does what it thinks is better, and gets it wrong.

It is simple to fix this: For each variable provide a prepend, append,
and replace variable override, like dhclient does.

christos

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

Roy Marples

2014-10-24 08:03:19 UTC

Post by Christos Zoulas

Post by Robert Swindells
But dhcpcd has not learned the information that is being deleted.
I am suggesting that in the case where nothing is returned then no
change should be made to resolv.conf.

These are indeed fair points, but I feel the conversion has now moved
from dhcpcd(8) to resolvconf(8).
resolvconf(8) simply takes all available inputs and then outputs
something sensible. Without any configuration or input you get a blank
resolv.conf(5).
Of course, we could do things a little differently. Here's some ideas,
* resolvconf should be opt-in rather than opt-out in resolvconf.conf
* refuse to update resolv.conf if it doesn't contain the resolvconf
signature when adding or removing interfaces via resolvconf
* if resolv.conf has no valid signature, save it and only restore it
when resolvconf has no valid inputs left
Any of these changes could affect the long standing behaviour of
resolvconf placing a blank resolv.conf file to make 127.0.0.1 the
resolver to use.

I just want to be able to precisely control its behaviour which in the
current configuration language I cannot. I.e. I should be able by setting
variables to affect the output resolv.conf file to be exactly how I
like it. For example, if I want 127.0.0.1 not to be the first resolving
nameserver, I should be able to do it. If I want to change the domain,
I should be able to do it. If I want to delete the ISP's nameservers
and the ISP suffix from the search path, I should be able to do it.
Right now resolvconf does what it thinks is better, and gets it wrong.
It is simple to fix this: For each variable provide a prepend, append,
and replace variable override, like dhclient does.

That's a different topic to the above and I'm slightly disappointed that
no-one has voiced an opinion on it.

Roy

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

Roy Marples

2014-10-29 01:19:10 UTC

Post by Christos Zoulas
I just want to be able to precisely control its behaviour which in the
current configuration language I cannot. I.e. I should be able by setting
variables to affect the output resolv.conf file to be exactly how I
like it. For example, if I want 127.0.0.1 not to be the first resolving
nameserver, I should be able to do it. If I want to change the domain,
I should be able to do it. If I want to delete the ISP's nameservers
and the ISP suffix from the search path, I should be able to do it.
Right now resolvconf does what it thinks is better, and gets it wrong.
It is simple to fix this: For each variable provide a prepend, append,
and replace variable override, like dhclient does.

Imported openresolv-3.6.1 with these changes as discussed.

Roy

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

Christos Zoulas

2014-10-29 02:17:14 UTC

On Oct 29, 1:19am, ***@marples.name (Roy Marples) wrote:
-- Subject: Re: DNS Expectations (was rtsol)

| On Wednesday 22 Oct 2014 13:09:34 Christos Zoulas wrote:
| > I just want to be able to precisely control its behaviour which in the
| > current configuration language I cannot. I.e. I should be able by setting
| > variables to affect the output resolv.conf file to be exactly how I
| > like it. For example, if I want 127.0.0.1 not to be the first resolving
| > nameserver, I should be able to do it. If I want to change the domain,
| > I should be able to do it. If I want to delete the ISP's nameservers
| > and the ISP suffix from the search path, I should be able to do it.
| > Right now resolvconf does what it thinks is better, and gets it wrong.
| >
| > It is simple to fix this: For each variable provide a prepend, append,
| > and replace variable override, like dhclient does.
|
| Imported openresolv-3.6.1 with these changes as discussed.

Thanks, I will give it a try.

christos

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

Roy Marples

2014-10-21 16:27:50 UTC

I would expect the default behaviour to be to not overwrite
resolv.conf on an error.

It still fails POLA for me.

Every protocol that supplies an IP address also supplies DNS servers.
DHCP, DHCPv6, IPv6RS/RA, PPP (+ pppoe), various VPN's.
I would argue that any of these not supplying DNS fails POLA.

In all cases, when any of these is used there exists the possibility
that any one of them could impose their idea of DNS on resolv.conf.
Because of this, we have resolvconf(8) which every daemon who learns DNS
dynamically should write to rather than directly to resolv.conf.

For the case where a lack of dynamically learned information does not
exist, or it expires, dhcpcd will remove what it previously learned.
In the case of DNS, it will call resolvconf -d $interface:$protocol

You can opt-out of resolvconf(8) ever touching resolv.conf by setting
resolvconf=NO in resolvconf.conf(5) (you'll need -current of a few days ago)
or change the file it writes to
resolv_conf=/var/run/resolv.conf (or /dev/null)

Or you can take the OS level approach and make the file immutable.

Thanks

Roy

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

Roy Marples

2014-10-24 21:00:07 UTC

Post by Robert Swindells
But dhcpcd has not learned the information that is being deleted.
I am suggesting that in the case where nothing is returned then no
change should be made to resolv.conf.

I believe I have fixed this here.
http://roy.marples.name/projects/openresolv/ci/4ff15739b724779f209fb0f19d0cd193a1e4423a?sbs=0

Sorry for being dense about the problem.
I'll try and roll a new release into -current later tonight or sometime over
the weekend with that fix.

Still appreciate some commentary on this though, even to say it's probably not
needed.
http://mail-index.netbsd.org/tech-net/2014/10/22/msg004785.html

Thanks

Roy

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

Robert Swindells

2014-10-24 21:21:37 UTC

Post by Robert Swindells
But dhcpcd has not learned the information that is being deleted.
I am suggesting that in the case where nothing is returned then no
change should be made to resolv.conf.

Thanks.

Post by Roy Marples
Still appreciate some commentary on this though, even to say it's probably not
needed.
http://mail-index.netbsd.org/tech-net/2014/10/22/msg004785.html
* if resolv.conf has no valid signature, save it and only restore it
when resolvconf has no valid inputs left

I would like to be able to run dhcpcd on a laptop when it is connected
to a "foreign" network then revert to a default resolv.conf when it
returns "home".

Robert Swindells

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

Roy Marples

2014-10-25 00:31:26 UTC

Post by Roy Marples
Still appreciate some commentary on this though, even to say it's probably
not needed.
http://mail-index.netbsd.org/tech-net/2014/10/22/msg004785.html
* if resolv.conf has no valid signature, save it and only restore it
when resolvconf has no valid inputs left

I would like to be able to run dhcpcd on a laptop when it is connected
to a "foreign" network then revert to a default resolv.conf when it
returns "home".

Done!

http://roy.marples.name/projects/openresolv/ci/466ed1522189bc5a68ff8f480ca09a1063efc85e?sbs=0

Roy

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

Roy Marples

2014-10-29 01:18:01 UTC

Post by Roy Marples
Still appreciate some commentary on this though, even to say it's probably
not needed.
http://mail-index.netbsd.org/tech-net/2014/10/22/msg004785.html
* if resolv.conf has no valid signature, save it and only restore it
when resolvconf has no valid inputs left

I would like to be able to run dhcpcd on a laptop when it is connected
to a "foreign" network then revert to a default resolv.conf when it
returns "home".

Done!
http://roy.marples.name/projects/openresolv/ci/466ed1522189bc5a68ff8f480ca09
a1063efc85e?sbs=0

openresolv-3.6.1 has been imported with this fix.

Roy

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

Robert Swindells

2014-10-21 14:15:34 UTC

Post by Robert Swindells
I just followed the suggestion in the new rtsol man page.
I think users are going to get bitten by this when upgrading to
NetBSD-7.

The example in the man page is just for testing purposes

Please could we have documentation for what people need to change in all
the common cases of migrating from a system with rtsol and rtsold, to a
system without them.

In rc.conf
dhcpcd=YES
This is the intent stated in the 1st paragraph of the man page.
You are also advised to enable dhcpcd if you have rtsol configured when
running rc.d/network.

Somebody already using DHCP on their network wouldn't need to add
dhcpcd=YES to rc.conf.

I think we need better documentation for how to migrate from just
using rtsol.

Robert Swindells

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

Alan Barrett

2014-10-21 14:25:56 UTC

Please could we have documentation for what people need to change in all
the common cases of migrating from a system with rtsol and rtsold, to a
system without them.

In rc.conf
dhcpcd=YES

I don't think that covers all scenarios. What if I want rtsol for
IPv6 but I do not want dhcp for IPv4? What if I want to run rtsol
manually? For every possible flag (or combination of flags) that
could have been passed to the old rtsol or rtsold, what is the new
way to acheieve the same result? Where is this documented?

--apb (Alan Barrett)

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

Roy Marples

2014-10-21 16:47:29 UTC

Post by Robert Swindells
I just followed the suggestion in the new rtsol man page.
I think users are going to get bitten by this when upgrading to
NetBSD-7.

The example in the man page is just for testing purposes

Please could we have documentation for what people need to change in all
the common cases of migrating from a system with rtsol and rtsold, to a
system without them.

In rc.conf
dhcpcd=YES
This is the intent stated in the 1st paragraph of the man page.
You are also advised to enable dhcpcd if you have rtsol configured when
running rc.d/network.

Somebody already using DHCP on their network wouldn't need to add
dhcpcd=YES to rc.conf.

That's right, and using the default config with dhcpcd enabled they
wouldn't need to change a thing.

Post by Robert Swindells
I think we need better documentation for how to migrate from just
using rtsol.

Care to provide some?
I've done my best and I think it's good enough. You don't so instead of
us going around in circles I feel that you're better placed than me.

Roy

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

Christos Zoulas

2014-10-22 00:11:25 UTC

Post by Wolfgang Solfrank
Yes, I'm sure that I can come up with a solution for this (if I find
enough round tuits), however, apart from this being some unwarranted
effort on my part, I don't think that we should impose this burden to any
and all of our users.

Although I don't have any issues, I think that removing rtsol and rtsold
was a bit too quick... Perhaps making an rtsol shell script that uses
dhcpcd would have been a better ide.

christos

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

Robert Swindells

2014-10-21 18:48:52 UTC

Post by Robert Swindells
I think we need better documentation for how to migrate from just
using rtsol.

Care to provide some?

Not really.

Post by Roy Marples
I've done my best and I think it's good enough. You don't so instead of
us going around in circles I feel that you're better placed than me.

I don't have a working system, what am I supposed to document ?

I have put back rtsol in my local tree for now.

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

Wolfgang Solfrank

2014-10-21 22:26:56 UTC

Hi,

Post by Roy Marples
Care to provide some?
I've done my best and I think it's good enough. You don't so instead of
us going around in circles I feel that you're better placed than me.

Sorry, but I have to disagree here. The current documentation
isn't even close to good enough.

E.g. in my situation I've got a NetBSD instance running on a virtual
host (Linux KVM),which I can't control and where the host does
send router advertisements only upon request. With the previous
default configuration as well as with the current one, the kernel will
drop the default route after some timeout. With the previous
situation I used a cron job to regularly send router solicitations
with rtsol and so keep the default route. What is the replacement
for rtsol in this case?

Yes, I'm sure that I can come up with a solution for this (if I find
enough round tuits), however, apart from this being some unwarranted
effort on my part, I don't think that we should impose this burden to any
and all of our users.

Ciao,
Wolfgang

--
***@Solfrank.net Wolfgang Solfrank

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

Roy Marples

2014-10-22 08:27:06 UTC