On Mon 23/07/2018 17:38, Florian Obser wrote: > On Sun, Jul 22, 2018 at 10:32:31AM +0200, Björn Ketelaars wrote: > > On Sun 22/07/2018 07:27, Björn Ketelaars wrote: > > > Now that rad(8) is able to advertise a MTU I think it would be nice to > > > have slaacctl(8) show this advertisement. The patch below touches both > > > sbin/slaacd and usr.sbin/slaacctl. The addition to sbin/slaacd/engine.c > > > makes sure that MTU RA messages are parsed, and that the result is made > > > available. BTW running slaacd in the foreground already enables one to > > > see the advertised MTU, see debug_log_ra(). > > > The addition to usr.sbin/slaacctl/slaacctl.c enables one to view the > > > advertised MTU. > > > > New diff as tb@ found a mistake in the first one affecting > > ND_OPT_REDIRECTED_HEADER, ND_OPT_SOURCE_LINKADDR and > > ND_OPT_TARGET_LINKADDR as well. > > > > Do you intend to set the mtu on the interface? If not I'm a bit > reluctand to parse and show it. I know that we are showing the > nameservers and not do anything with them. When I wrote that code > there was every intention to do something with the nameservers. For > various reasons that didn't happen (yet). Maybe we shoud not parse & > show the nameservers, either (until if and when we do something with > them).
On some hosts I use advertised DNS information to put together resolv.conf (quick-and-dirty hack using slaacctl and grep). Intention is to do the same for setting MTU on an interface. I'm not sure if a problem is solved by not parsing and showing nameservers from slaacctl. It would be helpful to keep this feature around. I'm guessing that parsing/showing MTU would not be missed by anyone (except me). On the other hand, it nicely complements rad(8), and could help with testing.
