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. > > http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/netinet6/in6.c?annotate=1.166&only_with_tag=MAIN > > 1.2 itojun 374: switch (cmd) { > 1.104 christos 375: /* > 1.105 christos 376: * XXX: Fix me, once we fix SIOCSIFADDR, > SIOCIFDSTADDR, etc. > 1.104 christos 377: */ > 378: case SIOCSIFADDR: > 1.105 christos 379: case SIOCSIFDSTADDR: > 1.129 cube 380: #ifdef SIOCSIFCONF_X25 > 1.106 christos 381: case SIOCSIFCONF_X25: > 1.110 matt 382: #endif > 1.104 christos 383: return EOPNOTSUPP; > > If it's indeed the case in OpenBSD, here's a diff: > > 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.
-- :wq Claudio
