Re: call for testing: rad(8) - a rtadvd(8) replacement

2018-07-20 Thread Florian Obser
On Fri, Jul 20, 2018 at 03:40:07PM +0200, Björn Ketelaars wrote:
> New diff, which addresses all your comments except the "no mtu" bit in
> the parser as I do not understand what you mean.

Never mind then :)

I was thinking about something like this:

8<
mtu 1480
interface ix0 # gets mtu 1480 option from global default
interface em0 {
no mtu # do not send mtu option
}
8<

but that seems rather obscure. And can be achieved like this:

interface em0 { mtu 0 }

one tweak inline:

> 
> 
> diff --git frontend.c frontend.c
> index b06fa43038c..0509d2b3efe 100644
> --- frontend.c
> +++ frontend.c
> @@ -887,6 +887,7 @@ void
>  build_packet(struct ra_iface *ra_iface)
>  {
>   struct nd_router_advert *ra;
> + struct nd_opt_mtu   *ndopt_mtu;
>   struct nd_opt_prefix_info   *ndopt_pi;
>   struct ra_iface_conf*ra_iface_conf;
>   struct ra_options_conf  *ra_options_conf;
> @@ -904,6 +905,8 @@ build_packet(struct ra_iface *ra_iface)
>   ra_options_conf = &ra_iface_conf->ra_options;
>  
>   len = sizeof(*ra);
> + if (ra_options_conf->mtu > 0)
> + len += sizeof(*ndopt_mtu);
>   len += sizeof(*ndopt_pi) * ra_iface->prefix_count;
>   if (ra_iface_conf->rdnss_count > 0)
>   len += sizeof(*ndopt_rdnss) + ra_iface_conf->rdnss_count *
> @@ -940,6 +943,15 @@ build_packet(struct ra_iface *ra_iface)
>   ra->nd_ra_retransmit = htonl(ra_options_conf->retrans_timer);
>   p += sizeof(*ra);
>  
> + if (ra_options_conf->mtu > 0) {
> + ndopt_mtu = (struct nd_opt_mtu *)p;
> + ndopt_mtu->nd_opt_mtu_type = ND_OPT_MTU;
> + ndopt_mtu->nd_opt_mtu_len = 1;
> + ndopt_mtu->nd_opt_mtu_reserved = 0;
> + ndopt_mtu->nd_opt_mtu_mtu = htonl(ra_options_conf->mtu);
> + p += sizeof(*ndopt_mtu);
> + }
> +
>   SIMPLEQ_FOREACH(ra_prefix_conf, &ra_iface->prefixes, entry) {
>   ndopt_pi = (struct nd_opt_prefix_info *)p;
>   memset(ndopt_pi, 0, sizeof(*ndopt_pi));
> diff --git parse.y parse.y
> index 582d165c7d6..6eb6990f97b 100644
> --- parse.y
> +++ parse.y
> @@ -115,7 +115,7 @@ typedef struct {
>  %token   DEFAULT ROUTER HOP LIMIT MANAGED ADDRESS
>  %token   CONFIGURATION OTHER LIFETIME REACHABLE TIME RETRANS TIMER
>  %token   AUTO PREFIX VALID PREFERRED LIFETIME ONLINK AUTONOMOUS
> -%token   ADDRESS_CONFIGURATION DNS RESOLVER SEARCH
> +%token   ADDRESS_CONFIGURATION DNS RESOLVER SEARCH MTU
>  
>  %token STRING
>  %token NUMBER
> @@ -209,6 +209,9 @@ ra_opt_block  : DEFAULT ROUTER yesno {
>   | RETRANS TIMER NUMBER {
>   ra_options->retrans_timer = $3;
>   }
> + | MTU NUMBER {
> + ra_options->mtu = $2;
> + }
>   ;
>  
>  optnl: '\n' optnl/* zero or more newlines */
> @@ -423,6 +426,7 @@ lookup(char *s)
>   {"lifetime",LIFETIME},
>   {"limit",   LIMIT},
>   {"managed", MANAGED},
> + {"mtu", MTU},
>   {"no",  NO},
>   {"on-link", ONLINK},
>   {"other",   OTHER},
> diff --git printconf.c printconf.c
> index 1fc8cd4ca3f..b7864dbae6b 100644
> --- printconf.c
> +++ printconf.c
> @@ -54,6 +54,7 @@ print_ra_options(const char *indent, const struct 
> ra_options_conf *ra_options)
>   printf("%srouter lifetime %d\n", indent, ra_options->router_lifetime);
>   printf("%sreachable time %u\n", indent, ra_options->reachable_time);
>   printf("%sretrans timer %u\n", indent, ra_options->retrans_timer);

please add
if (ra_options->mtu)
to print mtu only when it's set. Since mtu 0 means to not send the option at 
all.

With that OK florian@
(note that I just caused a conflict for you in parse.y, sorry about that)

> + printf("%smtu %u\n", indent, ra_options->mtu);
>  }
>  
>  void
> diff --git rad.c rad.c
> index 4652e1e0fb7..9f4be1b2190 100644
> --- rad.c
> +++ rad.c
> @@ -716,6 +716,7 @@ config_new_empty(void)
>   xconf->ra_options.router_lifetime = 1800;
>   xconf->ra_options.reachable_time = 0;
>   xconf->ra_options.retrans_timer = 0;
> + xconf->ra_options.mtu = 0;
>  
>   return (xconf);
>  }
> diff --git rad.conf.5 rad.conf.5
> index 6ca6b3ef956..486bec24769 100644
> --- rad.conf.5
> +++ rad.conf.5
> @@ -87,6 +87,11 @@ The default is 1800 seconds.
>  .\" XXX
>  .\" .It Ic retrans timer Ar number
>  .\" XXX
> +.It Ic mtu Ar bytes
> +The MTU option is used in Router Advertisement messages to ensure that all
> +nodes on a link use the same MTU value in those cases where the link MTU
> +is not well known.
> +The default is 0, meaning unspecified by this router.
>  .El
>  .Sh INTERFACES
>  A list of interfaces to send advertisments on:
> diff --

Re: call for testing: rad(8) - a rtadvd(8) replacement

2018-07-20 Thread Björn Ketelaars
On Fri 20/07/2018 07:57, Florian Obser wrote:
> On Thu, Jul 19, 2018 at 09:47:06PM +0200, Björn Ketelaars wrote:
> > On Wed 18/07/2018 08:54, Florian Obser wrote:
> > > During g2k18 I commited rad(8).
> > > 
> > > The latest amd64 and i386 snapshots should contain it with enough
> > > features to replace rtadvd(8). If you are using rtadvd(8) I'd
> > > appreciate if you could switch to rad(8) and report back if any
> > > features are missing.
> > 
> > Florian,
> > 
> > Thank you for rad(8). I like the configuration format, and it seems to
> > work for me as replacement for rtadvd(8). For reference purposes:
> > 
> > $ cat /etc/rtadvd.conf
> > vlan1003:\
> > :mtu#1480:\
> > :rdnss="2001:470:7ce4:1::1":\
> > :dnssl="guest":
> > 
> > $ cat /etc/rad.conf
> > interface vlan1003 {
> > dns {
> > resolver 2001:470:7ce4:1::1
> > search guest
> > }
> > }
> > 
> > There is one thing that I'm missing, and that is the MTU option in RA
> > messages (RFC 4861 Section 4.6.4). I've baked up a diff which works for
> > me. My current rad.conf looks like:
> > 
> > interface vlan1003 {
> > dns {
> > resolver 2001:470:7ce4:1::1
> > search guest
> > }
> > 
> > mtu 1480
> > }
> > 
> > Output "tcpdump - -ttt -i vlan1003 icmp6 and 'ip6[40] = 134'":
> > 
> > Jul 19 21:26:10.009348 fe80::a562:1f47:a75c:a5fc > ff02::1: icmp6: router 
> > advertisement(chlim=0, pref=medium, router_ltime=1800, reachable_time=0, 
> > retrans_time=0)(prefix info: LA valid_ltime=2592000, 
> > preferred_ltime=604800, prefix=2001:470:7ce4:1::/64)(mtu: mtu=1480)[ndp 
> > opt] (len 88, hlim 255)
> > 
> > I'm not sure this is an option for rad(8) that is useful for anyone else
> > but me. What do you think? Also, what do you think of the diff below?
> 
> I like it, I think we should have it. Out of curiosity, which clients
> pay attention to the MTU option? I know that slaacd does not. If you
> are sufficiently bored you might want to implement it there, too! ;)
> (hint: you will need to add to the wroute pledge in the kernel)
> 
> Diff reads mostly ok but needs a few tweaks, see inline:
> 
> > 
> > 
> > diff --git engine.c engine.c
> > index 5d186439dd8..4ade634a689 100644
> > --- engine.c
> > +++ engine.c
> > @@ -355,6 +355,9 @@ engine_dispatch_main(int fd, short event, void *bula)
> > SIMPLEQ_INSERT_TAIL(&ra_iface_conf->ra_prefix_list,
> > ra_prefix_conf, entry);
> > break;
> > +   case IMSG_RECONF_RA_MTU:
> > +   ra_iface_conf->ra_mtu = *((uint32_t *)imsg.data);
> > +   break;
> 
> no need for the extra IMSG, ra_mtu is not a substructure in
> ra_iface_conf, it will be copied with the rest of the ra_iface_conf in
> IMSG_RECONF_RA_IFACE
> 
> > case IMSG_RECONF_RA_RDNS_LIFETIME:
> > ra_iface_conf->rdns_lifetime = *((uint32_t *)imsg.data);
> > break;
> > diff --git frontend.c frontend.c
> > index b06fa43038c..06c4cc5cb2b 100644
> > --- frontend.c
> > +++ frontend.c
> > @@ -397,6 +397,9 @@ frontend_dispatch_main(int fd, short event, void *bula)
> > SIMPLEQ_INSERT_TAIL(&ra_iface_conf->ra_prefix_list,
> > ra_prefix_conf, entry);
> > break;
> > +   case IMSG_RECONF_RA_MTU:
> > +   ra_iface_conf->ra_mtu = *((uint32_t *)imsg.data);
> > +   break;
> 
> same here
> 
> > case IMSG_RECONF_RA_RDNS_LIFETIME:
> > ra_iface_conf->rdns_lifetime = *((uint32_t *)imsg.data);
> > break;
> > @@ -888,6 +891,7 @@ build_packet(struct ra_iface *ra_iface)
> >  {
> > struct nd_router_advert *ra;
> > struct nd_opt_prefix_info   *ndopt_pi;
> > +   struct nd_opt_mtu   *ndopt_mtu;
> > struct ra_iface_conf*ra_iface_conf;
> > struct ra_options_conf  *ra_options_conf;
> > struct ra_prefix_conf   *ra_prefix_conf;
> > @@ -960,6 +964,15 @@ build_packet(struct ra_iface *ra_iface)
> > p += sizeof(*ndopt_pi);
> > }
> >  
> > +   if (ra_iface_conf->ra_mtu > 0) {
> > +   ndopt_mtu = (struct nd_opt_mtu *)p;
> > +   ndopt_mtu->nd_opt_mtu_type = ND_OPT_MTU;
> > +   ndopt_mtu->nd_opt_mtu_len = 1;
> > +   ndopt_mtu->nd_opt_mtu_reserved = 0;
> > +   ndopt_mtu->nd_opt_mtu_mtu = htonl(ra_iface_conf->ra_mtu);
> > +   p += sizeof(*ndopt_mtu);
> > +   }
> > +
> 
> you need to account for the length of the mtu option, see the beginning
> of build_packet(), something like
> 
>   if (ra_iface_conf->ra_mtu > 0)
>   len += sizeof(*ndopt_mtu);
> 
> > if (ra_iface_conf->rdnss_count > 0) {
> > ndopt_rdnss = (struct nd_opt_rdnss *)p;
> > ndopt_rdnss->nd_opt_rdnss_type = ND_OPT_RDNSS;
> > diff --git parse.y pars

Re: call for testing: rad(8) - a rtadvd(8) replacement

2018-07-19 Thread Florian Obser
On Thu, Jul 19, 2018 at 09:47:06PM +0200, Björn Ketelaars wrote:
> On Wed 18/07/2018 08:54, Florian Obser wrote:
> > During g2k18 I commited rad(8).
> > 
> > The latest amd64 and i386 snapshots should contain it with enough
> > features to replace rtadvd(8). If you are using rtadvd(8) I'd
> > appreciate if you could switch to rad(8) and report back if any
> > features are missing.
> 
> Florian,
> 
> Thank you for rad(8). I like the configuration format, and it seems to
> work for me as replacement for rtadvd(8). For reference purposes:
> 
> $ cat /etc/rtadvd.conf
> vlan1003:\
> :mtu#1480:\
> :rdnss="2001:470:7ce4:1::1":\
> :dnssl="guest":
> 
> $ cat /etc/rad.conf
> interface vlan1003 {
> dns {
> resolver 2001:470:7ce4:1::1
> search guest
> }
> }
> 
> There is one thing that I'm missing, and that is the MTU option in RA
> messages (RFC 4861 Section 4.6.4). I've baked up a diff which works for
> me. My current rad.conf looks like:
> 
> interface vlan1003 {
> dns {
> resolver 2001:470:7ce4:1::1
> search guest
> }
> 
> mtu 1480
> }
> 
> Output "tcpdump - -ttt -i vlan1003 icmp6 and 'ip6[40] = 134'":
> 
> Jul 19 21:26:10.009348 fe80::a562:1f47:a75c:a5fc > ff02::1: icmp6: router 
> advertisement(chlim=0, pref=medium, router_ltime=1800, reachable_time=0, 
> retrans_time=0)(prefix info: LA valid_ltime=2592000, preferred_ltime=604800, 
> prefix=2001:470:7ce4:1::/64)(mtu: mtu=1480)[ndp opt] (len 88, hlim 255)
> 
> I'm not sure this is an option for rad(8) that is useful for anyone else
> but me. What do you think? Also, what do you think of the diff below?

I like it, I think we should have it. Out of curiosity, which clients
pay attention to the MTU option? I know that slaacd does not. If you
are sufficiently bored you might want to implement it there, too! ;)
(hint: you will need to add to the wroute pledge in the kernel)

Diff reads mostly ok but needs a few tweaks, see inline:

> 
> 
> diff --git engine.c engine.c
> index 5d186439dd8..4ade634a689 100644
> --- engine.c
> +++ engine.c
> @@ -355,6 +355,9 @@ engine_dispatch_main(int fd, short event, void *bula)
>   SIMPLEQ_INSERT_TAIL(&ra_iface_conf->ra_prefix_list,
>   ra_prefix_conf, entry);
>   break;
> + case IMSG_RECONF_RA_MTU:
> + ra_iface_conf->ra_mtu = *((uint32_t *)imsg.data);
> + break;

no need for the extra IMSG, ra_mtu is not a substructure in
ra_iface_conf, it will be copied with the rest of the ra_iface_conf in
IMSG_RECONF_RA_IFACE

>   case IMSG_RECONF_RA_RDNS_LIFETIME:
>   ra_iface_conf->rdns_lifetime = *((uint32_t *)imsg.data);
>   break;
> diff --git frontend.c frontend.c
> index b06fa43038c..06c4cc5cb2b 100644
> --- frontend.c
> +++ frontend.c
> @@ -397,6 +397,9 @@ frontend_dispatch_main(int fd, short event, void *bula)
>   SIMPLEQ_INSERT_TAIL(&ra_iface_conf->ra_prefix_list,
>   ra_prefix_conf, entry);
>   break;
> + case IMSG_RECONF_RA_MTU:
> + ra_iface_conf->ra_mtu = *((uint32_t *)imsg.data);
> + break;

same here

>   case IMSG_RECONF_RA_RDNS_LIFETIME:
>   ra_iface_conf->rdns_lifetime = *((uint32_t *)imsg.data);
>   break;
> @@ -888,6 +891,7 @@ build_packet(struct ra_iface *ra_iface)
>  {
>   struct nd_router_advert *ra;
>   struct nd_opt_prefix_info   *ndopt_pi;
> + struct nd_opt_mtu   *ndopt_mtu;
>   struct ra_iface_conf*ra_iface_conf;
>   struct ra_options_conf  *ra_options_conf;
>   struct ra_prefix_conf   *ra_prefix_conf;
> @@ -960,6 +964,15 @@ build_packet(struct ra_iface *ra_iface)
>   p += sizeof(*ndopt_pi);
>   }
>  
> + if (ra_iface_conf->ra_mtu > 0) {
> + ndopt_mtu = (struct nd_opt_mtu *)p;
> + ndopt_mtu->nd_opt_mtu_type = ND_OPT_MTU;
> + ndopt_mtu->nd_opt_mtu_len = 1;
> + ndopt_mtu->nd_opt_mtu_reserved = 0;
> + ndopt_mtu->nd_opt_mtu_mtu = htonl(ra_iface_conf->ra_mtu);
> + p += sizeof(*ndopt_mtu);
> + }
> +

you need to account for the length of the mtu option, see the beginning
of build_packet(), something like

if (ra_iface_conf->ra_mtu > 0)
len += sizeof(*ndopt_mtu);

>   if (ra_iface_conf->rdnss_count > 0) {
>   ndopt_rdnss = (struct nd_opt_rdnss *)p;
>   ndopt_rdnss->nd_opt_rdnss_type = ND_OPT_RDNSS;
> diff --git parse.y parse.y
> index 582d165c7d6..9696ac58213 100644
> --- parse.y
> +++ parse.y
> @@ -115,7 +115,7 @@ typedef struct {
>  %token   DEFAULT ROUTER HOP LIMIT MANAGED ADDRESS
>  %token   CONFIGURATION OTHER LIFETIME REACHABLE TIME R

Re: call for testing: rad(8) - a rtadvd(8) replacement

2018-07-19 Thread Björn Ketelaars
On Wed 18/07/2018 08:54, Florian Obser wrote:
> During g2k18 I commited rad(8).
> 
> The latest amd64 and i386 snapshots should contain it with enough
> features to replace rtadvd(8). If you are using rtadvd(8) I'd
> appreciate if you could switch to rad(8) and report back if any
> features are missing.

Florian,

Thank you for rad(8). I like the configuration format, and it seems to
work for me as replacement for rtadvd(8). For reference purposes:

$ cat /etc/rtadvd.conf
vlan1003:\
:mtu#1480:\
:rdnss="2001:470:7ce4:1::1":\
:dnssl="guest":

$ cat /etc/rad.conf
interface vlan1003 {
dns {
resolver 2001:470:7ce4:1::1
search guest
}
}

There is one thing that I'm missing, and that is the MTU option in RA
messages (RFC 4861 Section 4.6.4). I've baked up a diff which works for
me. My current rad.conf looks like:

interface vlan1003 {
dns {
resolver 2001:470:7ce4:1::1
search guest
}

mtu 1480
}

Output "tcpdump - -ttt -i vlan1003 icmp6 and 'ip6[40] = 134'":

Jul 19 21:26:10.009348 fe80::a562:1f47:a75c:a5fc > ff02::1: icmp6: router 
advertisement(chlim=0, pref=medium, router_ltime=1800, reachable_time=0, 
retrans_time=0)(prefix info: LA valid_ltime=2592000, preferred_ltime=604800, 
prefix=2001:470:7ce4:1::/64)(mtu: mtu=1480)[ndp opt] (len 88, hlim 255)

I'm not sure this is an option for rad(8) that is useful for anyone else
but me. What do you think? Also, what do you think of the diff below?


diff --git engine.c engine.c
index 5d186439dd8..4ade634a689 100644
--- engine.c
+++ engine.c
@@ -355,6 +355,9 @@ engine_dispatch_main(int fd, short event, void *bula)
SIMPLEQ_INSERT_TAIL(&ra_iface_conf->ra_prefix_list,
ra_prefix_conf, entry);
break;
+   case IMSG_RECONF_RA_MTU:
+   ra_iface_conf->ra_mtu = *((uint32_t *)imsg.data);
+   break;
case IMSG_RECONF_RA_RDNS_LIFETIME:
ra_iface_conf->rdns_lifetime = *((uint32_t *)imsg.data);
break;
diff --git frontend.c frontend.c
index b06fa43038c..06c4cc5cb2b 100644
--- frontend.c
+++ frontend.c
@@ -397,6 +397,9 @@ frontend_dispatch_main(int fd, short event, void *bula)
SIMPLEQ_INSERT_TAIL(&ra_iface_conf->ra_prefix_list,
ra_prefix_conf, entry);
break;
+   case IMSG_RECONF_RA_MTU:
+   ra_iface_conf->ra_mtu = *((uint32_t *)imsg.data);
+   break;
case IMSG_RECONF_RA_RDNS_LIFETIME:
ra_iface_conf->rdns_lifetime = *((uint32_t *)imsg.data);
break;
@@ -888,6 +891,7 @@ build_packet(struct ra_iface *ra_iface)
 {
struct nd_router_advert *ra;
struct nd_opt_prefix_info   *ndopt_pi;
+   struct nd_opt_mtu   *ndopt_mtu;
struct ra_iface_conf*ra_iface_conf;
struct ra_options_conf  *ra_options_conf;
struct ra_prefix_conf   *ra_prefix_conf;
@@ -960,6 +964,15 @@ build_packet(struct ra_iface *ra_iface)
p += sizeof(*ndopt_pi);
}
 
+   if (ra_iface_conf->ra_mtu > 0) {
+   ndopt_mtu = (struct nd_opt_mtu *)p;
+   ndopt_mtu->nd_opt_mtu_type = ND_OPT_MTU;
+   ndopt_mtu->nd_opt_mtu_len = 1;
+   ndopt_mtu->nd_opt_mtu_reserved = 0;
+   ndopt_mtu->nd_opt_mtu_mtu = htonl(ra_iface_conf->ra_mtu);
+   p += sizeof(*ndopt_mtu);
+   }
+
if (ra_iface_conf->rdnss_count > 0) {
ndopt_rdnss = (struct nd_opt_rdnss *)p;
ndopt_rdnss->nd_opt_rdnss_type = ND_OPT_RDNSS;
diff --git parse.y parse.y
index 582d165c7d6..9696ac58213 100644
--- parse.y
+++ parse.y
@@ -115,7 +115,7 @@ typedef struct {
 %token DEFAULT ROUTER HOP LIMIT MANAGED ADDRESS
 %token CONFIGURATION OTHER LIFETIME REACHABLE TIME RETRANS TIMER
 %token AUTO PREFIX VALID PREFERRED LIFETIME ONLINK AUTONOMOUS
-%token ADDRESS_CONFIGURATION DNS RESOLVER SEARCH
+%token ADDRESS_CONFIGURATION DNS RESOLVER SEARCH MTU
 
 %token   STRING
 %token   NUMBER
@@ -265,6 +265,9 @@ ra_ifaceoptsl   : NO AUTO PREFIX {
} ra_prefix_block {
ra_prefix_conf = NULL;
}
+   | MTU NUMBER {
+   ra_iface_conf->ra_mtu = $2;
+   }
| DNS dns_block
| ra_opt_block
;
@@ -423,6 +426,7 @@ lookup(char *s)
{"lifetime",LIFETIME},
{"limit",   LIMIT},
{"managed", MANAGED},
+   {"mtu", MTU},
{"no",  NO},
{"on-link", ONLINK},
{"oth

Re: call for testing: rad(8) - a rtadvd(8) replacement

2018-07-18 Thread Mike
On 7/18/2018 2:54 AM, Florian Obser wrote:
> During g2k18 I commited rad(8).
> 
> [snip]

I had a chance to do a couple simple tests with rad(8) in my test
environment.

# cat rad.conf

interface em0 {
prefix fdcf:b715:2f4d:100::/64
prefix 2001:DB8:2f4d:100::/64
dns {
resolver fdcf:b715:2f4d:1::3
}
}



I used a FreeBSD client on em0.

I verified that each prefix in the rad.conf was assigned to the client,
and the DNS resolver made it into /etc/resolv.conf on the client.

So far, it looks good.  And I do like the new syntax!  :)

Thanks.



Re: call for testing: rad(8) - a rtadvd(8) replacement

2018-07-18 Thread Paul de Weerd
On Wed, Jul 18, 2018 at 08:54:51AM +0200, Florian Obser wrote:
| During g2k18 I commited rad(8).
| 
| The latest amd64 and i386 snapshots should contain it with enough
| features to replace rtadvd(8). If you are using rtadvd(8) I'd
| appreciate if you could switch to rad(8) and report back if any
| features are missing.
| 
| The plan is to unhook rtadvd(8) from the build sooner rather than
| later and to ship 6.4 with rad(8) only.
| 
| If you are running rtadvd(8) with out any configuration and only have
| rtadvd_flags=em1 the /etc/rad.conf file will be
| 
| ---8<---
| interface em0
| ---8<---
| 
| Once that is inplace disable rtadvd and enable rad:
| 
| # rcctl stop rtadvd
| # rcctl disable rtadvd
| # rcctl enable rad
| # rcctl start rad
| 
| see man rad.conf for documentation on the config file format. Good
| news: it's no longer termcap based!

Works well.  Love the configuration format, although I never did have
any special or interesting config for rtadvd:

[root@tuna] # grep -e rad -e rtadvd /etc/rc.conf.local 
/var/backups/etc_rc.conf.local.current 
/etc/rc.conf.local:rad_flags=
/var/backups/etc_rc.conf.local.current:rtadvd_flags="em1 em2 em3"
[root@tuna] # cat /etc/rad.conf
interface em1
interface em2
interface em3

Seems to work as advertised just fine.  I do see the logging bits
Sebastien already mentioned, but that will disappear with the next
snapshot upgrade as I see you've already committed some fixes.

Thanks for working on this Florian .. it's pretty rad!

Cheers,

Paul

-- 
>[<++>-]<+++.>+++[<-->-]<.>+++[<+
+++>-]<.>++[<>-]<+.--.[-]
 http://www.weirdnet.nl/ 



Re: call for testing: rad(8) - a rtadvd(8) replacement

2018-07-18 Thread Florian Obser
On Wed, Jul 18, 2018 at 11:03:46AM +0200, Sebastien Marie wrote:
> On Wed, Jul 18, 2018 at 08:54:51AM +0200, Florian Obser wrote:
> > During g2k18 I commited rad(8).
> > 
> > The latest amd64 and i386 snapshots should contain it with enough
> > features to replace rtadvd(8). If you are using rtadvd(8) I'd
> > appreciate if you could switch to rad(8) and report back if any
> > features are missing.
> > 
> > The plan is to unhook rtadvd(8) from the build sooner rather than
> > later and to ship 6.4 with rad(8) only.
> > 
> 
> Hi,
> 
> I switched my gateway to use rad instead of rtadvd.

thank you for testing!

> 
> So, some questions :-)
> 
> First the topology:
> - internet connection on pppoe0
> - 2 lan interfaces with ipv6: vlan92 and vlan110
> 
> I obtain ipv6 on pppoe0 with DHCPv6-PD.
> 
> My upstream send me also router-advertisement on this interface.
> 
> tcpdump output:
>   fe80::2a6f:7fff:fe0e:ae80 > ff02::1: icmp6: router 
> advertisement(chlim=64, O, pref=medium, router_ltime=1800, reachable_time=0, 
> retrans_time=0)(mtu: mtu=1492)(rdnss: lifetime=400s, 
> addr=:::::1, addr=:::::1) [icmp6 cksum ok] 
> [class 0xe0] (len 64, hlim 255) 
> 
> 
> On the gateway, I use the following rad.conf file:
> 
> interface vlan92 {
> dns {
> resolver ":::XX5c:cabe:19ff:fee2:2ced"
> }
> }
> 
> interface vlan110 {
> dns {
> resolver ":::XX6e:cabe:19ff:fee2:2ced"
> }
> }
> 
> 
> $ ifconfig vlan92
> vlan92: flags=8943 mtu 1500
> lladdr c8:be:19:e2:2c:ed
> index 16 priority 0 llprio 3
> encap: vnetid 92 parent re0
> groups: vlan
> media: Ethernet autoselect (1000baseT full-duplex)
> status: active
> inet 192.168.92.2 netmask 0xff00 broadcast 192.168.92.255
> inet6 fe80::7f08:c8d1:d9fd:1581%vlan92 prefixlen 64 scopeid 0x10
> inet6 :::XX5c:cabe:19ff:fee2:2ced prefixlen 64
> inet6 :::XX5c::1 prefixlen 64 pltime 599160 vltime 2586360
> 
> For now, it works well. But I see the following in syslog:
> 
> Jul 18 10:28:05 alf rad[86733]: RA or RS with hop limit of 255 from 
> fe80::7f08:c8d1:d9fd:1581 on vlan92   # from itself
> Jul 18 10:28:06 alf rad[86733]: RA or RS with hop limit of 255 from 
> fe80::7f08:c8d1:d9fd:1581 on vlan110  # from itself
> Jul 18 10:29:24 alf rad[86733]: RA or RS with hop limit of 255 from 
> fe80::2a6f:7fff:fe0e:ae80 on pppoe0   # not managed interface
> Jul 18 10:31:12 alf rad[86733]: RA or RS with hop limit of 255 from 
> fe80::f280:16b4:9c3b:5f8f on vlan92   
> Jul 18 10:32:19 alf rad[86733]: RA or RS with hop limit of 255 from 
> fe80::2a6f:7fff:fe0e:ae80 on pppoe0   # not managed interface
> Jul 18 10:33:33 alf rad[86733]: RA or RS with hop limit of 255 from 
> fe80::7f08:c8d1:d9fd:1581 on vlan92   # from itself
> Jul 18 10:35:28 alf rad[86733]: RA or RS with hop limit of 255 from 
> fe80::2a6f:7fff:fe0e:ae80 on pppoe0   # not managed interface
> Jul 18 10:36:49 alf rad[86733]: RA or RS with hop limit of 255 from 
> fe80::7f08:c8d1:d9fd:1581 on vlan110  # from itself
> Jul 18 10:38:04 alf rad[86733]: RA or RS with hop limit of 255 from 
> fe80::2a6f:7fff:fe0e:ae80 on pppoe0   # not managed interface
> Jul 18 10:40:08 alf rad[86733]: RA or RS with hop limit of 255 from 
> fe80::7f08:c8d1:d9fd:1581 on vlan92   # from itself
> Jul 18 10:40:47 alf rad[86733]: RA or RS with hop limit of 255 from 
> fe80::2a6f:7fff:fe0e:ae80 on pppoe0   # not managed interface
> Jul 18 10:41:58 alf rad[86733]: RA or RS with hop limit of 255 from 
> fe80::61fd:ac94:2a15:bd0b on vlan92

I just switched the log_warnx to log_debug, that was an oversight on
my part, this is mostly normal operation

> 
> rad(8) seems to log RA/RS from all interfaces:
> - from interface not configured for being managed by itself, like pppoe0
> - from interface managed by itself and RA sent by itself (shouldn't it
>   know it sent it ?)

Yes, and it should not receive them. I believe this is the
IPV6_MULTICAST_LOOP socketopt missing on the icmp6 socket.
I'll probably fix it this evening.

> - from interface managed by itself and RA/RS sent by someone else
> 
> I am unsure about the purpose of this log: it seems to be an
> unconditional log on RA/RS reception.
> 
> It could have value for RA/RS where it isn't sent by rad(8) itself, and
> if it is on some configured interface for rad(8). For others cases, I am
> unsure.

rad(8) receiving RAs on all interfaces is for future work. As said
above, it doesn't need to see it's own RAs, but all the others.

Router advertisement messages are supposed to contain all prefixes
this router knows about. Hosts can form addresses from some of these
prefixes (iff the A flag is set) or add more specific routes for
others.

Let's assume a slightly different topology. Assume 

Re: call for testing: rad(8) - a rtadvd(8) replacement

2018-07-18 Thread Sebastien Marie
On Wed, Jul 18, 2018 at 08:54:51AM +0200, Florian Obser wrote:
> During g2k18 I commited rad(8).
> 
> The latest amd64 and i386 snapshots should contain it with enough
> features to replace rtadvd(8). If you are using rtadvd(8) I'd
> appreciate if you could switch to rad(8) and report back if any
> features are missing.
> 
> The plan is to unhook rtadvd(8) from the build sooner rather than
> later and to ship 6.4 with rad(8) only.
> 

Hi,

I switched my gateway to use rad instead of rtadvd.

So, some questions :-)

First the topology:
- internet connection on pppoe0
- 2 lan interfaces with ipv6: vlan92 and vlan110

I obtain ipv6 on pppoe0 with DHCPv6-PD.

My upstream send me also router-advertisement on this interface.

tcpdump output:
fe80::2a6f:7fff:fe0e:ae80 > ff02::1: icmp6: router 
advertisement(chlim=64, O, pref=medium, router_ltime=1800, reachable_time=0, 
retrans_time=0)(mtu: mtu=1492)(rdnss: lifetime=400s, 
addr=:::::1, addr=:::::1) [icmp6 cksum ok] 
[class 0xe0] (len 64, hlim 255) 


On the gateway, I use the following rad.conf file:

interface vlan92 {
dns {
resolver ":::XX5c:cabe:19ff:fee2:2ced"
}
}

interface vlan110 {
dns {
resolver ":::XX6e:cabe:19ff:fee2:2ced"
}
}


$ ifconfig vlan92
vlan92: flags=8943 mtu 1500
lladdr c8:be:19:e2:2c:ed
index 16 priority 0 llprio 3
encap: vnetid 92 parent re0
groups: vlan
media: Ethernet autoselect (1000baseT full-duplex)
status: active
inet 192.168.92.2 netmask 0xff00 broadcast 192.168.92.255
inet6 fe80::7f08:c8d1:d9fd:1581%vlan92 prefixlen 64 scopeid 0x10
inet6 :::XX5c:cabe:19ff:fee2:2ced prefixlen 64
inet6 :::XX5c::1 prefixlen 64 pltime 599160 vltime 2586360

For now, it works well. But I see the following in syslog:

Jul 18 10:28:05 alf rad[86733]: RA or RS with hop limit of 255 from 
fe80::7f08:c8d1:d9fd:1581 on vlan92 # from itself
Jul 18 10:28:06 alf rad[86733]: RA or RS with hop limit of 255 from 
fe80::7f08:c8d1:d9fd:1581 on vlan110# from itself
Jul 18 10:29:24 alf rad[86733]: RA or RS with hop limit of 255 from 
fe80::2a6f:7fff:fe0e:ae80 on pppoe0 # not managed interface
Jul 18 10:31:12 alf rad[86733]: RA or RS with hop limit of 255 from 
fe80::f280:16b4:9c3b:5f8f on vlan92 
Jul 18 10:32:19 alf rad[86733]: RA or RS with hop limit of 255 from 
fe80::2a6f:7fff:fe0e:ae80 on pppoe0 # not managed interface
Jul 18 10:33:33 alf rad[86733]: RA or RS with hop limit of 255 from 
fe80::7f08:c8d1:d9fd:1581 on vlan92 # from itself
Jul 18 10:35:28 alf rad[86733]: RA or RS with hop limit of 255 from 
fe80::2a6f:7fff:fe0e:ae80 on pppoe0 # not managed interface
Jul 18 10:36:49 alf rad[86733]: RA or RS with hop limit of 255 from 
fe80::7f08:c8d1:d9fd:1581 on vlan110# from itself
Jul 18 10:38:04 alf rad[86733]: RA or RS with hop limit of 255 from 
fe80::2a6f:7fff:fe0e:ae80 on pppoe0 # not managed interface
Jul 18 10:40:08 alf rad[86733]: RA or RS with hop limit of 255 from 
fe80::7f08:c8d1:d9fd:1581 on vlan92 # from itself
Jul 18 10:40:47 alf rad[86733]: RA or RS with hop limit of 255 from 
fe80::2a6f:7fff:fe0e:ae80 on pppoe0 # not managed interface
Jul 18 10:41:58 alf rad[86733]: RA or RS with hop limit of 255 from 
fe80::61fd:ac94:2a15:bd0b on vlan92

rad(8) seems to log RA/RS from all interfaces:
- from interface not configured for being managed by itself, like pppoe0
- from interface managed by itself and RA sent by itself (shouldn't it
  know it sent it ?)
- from interface managed by itself and RA/RS sent by someone else

I am unsure about the purpose of this log: it seems to be an
unconditional log on RA/RS reception.

It could have value for RA/RS where it isn't sent by rad(8) itself, and
if it is on some configured interface for rad(8). For others cases, I am
unsure.

Thanks for the clarification.
-- 
Sebastien Marie



call for testing: rad(8) - a rtadvd(8) replacement

2018-07-17 Thread Florian Obser
During g2k18 I commited rad(8).

The latest amd64 and i386 snapshots should contain it with enough
features to replace rtadvd(8). If you are using rtadvd(8) I'd
appreciate if you could switch to rad(8) and report back if any
features are missing.

The plan is to unhook rtadvd(8) from the build sooner rather than
later and to ship 6.4 with rad(8) only.

If you are running rtadvd(8) with out any configuration and only have
rtadvd_flags=em1 the /etc/rad.conf file will be

---8<---
interface em0
---8<---

Once that is inplace disable rtadvd and enable rad:

# rcctl stop rtadvd
# rcctl disable rtadvd
# rcctl enable rad
# rcctl start rad

see man rad.conf for documentation on the config file format. Good
news: it's no longer termcap based!

Thanks!

-- 
I'm not entirely sure you are real.