On Mon, Jul 23, 2018 at 08:59:37PM +0200, Björn Ketelaars wrote: > 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.
Why not set the MTU in slaacd? We used to do it in the kernel since the beginning of time. (Until I ripped it out because it was getting in the way). It should be perfectly simple to do it in slaacd though. resolv.conf on the other hand is a can of worms and I'm not going to suggest that it can be done in an evening :) > > 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. What I was trying to say is, if we show an option in slaacctl the assumption is that we do something with it. As a user I run slaactl, it shows me mtu 1280, I look at the interface and it still running at 1500, I would find that very confusing. Because of historical reasons nameserver information is different. "But we already show nameservers without doing anything with them, why not do the same with the mtu?" is not a valid argument. "I don't have time" or "I don't know how" are valid reasons ;) So if you can't do it (for whatever reason) tell me and I'll implement it (eventually). > 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. No need to justify the mtu as being useful to you, I'm sold on the general idea. -- I'm not entirely sure you are real.
