On Tue, Aug 27, 2013 at 10:37:30AM +0200, Martin Pieuchot wrote: > On 22/08/13(Thu) 23:31, Claudio Jeker wrote: > > On Wed, Aug 21, 2013 at 09:59:56AM -0700, Loganaden Velvindron wrote: > > > I'm not sure if applies to OpenBSD as well, but NetBSD > > > also disallowed SIOCSIFDSTADDR for ioctl. > > > [...] > > > > > > Index: sys/netinet6/in6.c > > > =================================================================== > > > RCS file: /cvs/src/sys/netinet6/in6.c,v > > > retrieving revision 1.117 > > > diff -u -p -r1.117 in6.c > > > --- sys/netinet6/in6.c 13 Aug 2013 05:52:25 -0000 1.117 > > > +++ sys/netinet6/in6.c 21 Aug 2013 15:50:00 -0000 > > > @@ -429,8 +429,9 @@ in6_control(struct socket *so, u_long cm > > > sa6 = &ifr->ifr_addr; > > > break; > > > case SIOCSIFADDR: > > > + case SIOCSIFDSTADDR: > > > /* > > > - * Do not pass this ioctl to driver handler since it is not > > > + * Do not pass those ioctl to driver handler since they are not > > > * properly setup. Instead just error out. > > > */ > > > return (EOPNOTSUPP); > > > > Are any of our driver ioctl handlers handling SIOCSIFDSTADDR? I don't > > think so but I think this could be just extra safety and should therefor > > be commited. > > Only tun(4) seems to have some code for it, but I don't think it is > correct. And if it is, we should probably use SIOCGIFDSTADDR_IN6 > anyway. > > Maybe a small cleanup can be done? I haven't looked at tun(4) code yet, but I can give it a try :-)
> > So I'm also in favor of this supplementary safety check, and I > would even add SIOCSIFBRDADDR to this list. I'm updating the diff. > > M. >