Re: IFXF_NOINET doesn't make sense any more
On Sun, Jul 13, 2014 at 03:48:47PM +0200, Henning Brauer wrote:
now that we have an uncontaminated, err, inet6-free system by default,
IFXF_NOINET6 just doesn't make sense any more.
fully go for no inet6 by default, get rid of the IFXF_NOINET6 guarded
attachments etc.
introduce IFAFATTACH and IFAFDETACH ioctls. note that they are NOT
inet6 specific; the kernel only has code for inet6 so far and will
properly return EAFNOSUPPORT for all others.
there should be no user visible changes from this.
I like this direction.
It's a lot better than the AF-specific kill switch.
However, since we're heading towards release, I believe we should wait
and do this flag removal + ioctl addition later. We've already got the
no-link-local-by-default change, and the new autoconf6 flag.
I don't see much harm in leaving it at that for this release cycle and
moving further in the next one. I'm looking forward to florian's in-kernel
rtsol as well, in the next cycle (it's not done yet anyway AFAIK).
Perhaps we can also sort out the autoconf vs. ip6forward conundrum then,
and ship working IPv6 for SOHO routers in 5.7.
I'll be testing this regardless and will let you know if I run into issues.
Index: sbin/ifconfig/ifconfig.c
===
RCS file: /cvs/src/sbin/ifconfig/ifconfig.c,v
retrieving revision 1.287
diff -u -p -r1.287 ifconfig.c
--- sbin/ifconfig/ifconfig.c 12 Jul 2014 19:58:17 - 1.287
+++ sbin/ifconfig/ifconfig.c 13 Jul 2014 13:05:15 -
@@ -148,6 +148,7 @@ void setiflladdr(const char *, int);
void setifdstaddr(const char *, int);
void setifflags(const char *, int);
void setifxflags(const char *, int);
+void addaf(const char *, int);
void removeaf(const char *, int);
void setifbroadaddr(const char *, int);
void setifmtu(const char *, int);
@@ -682,7 +683,7 @@ main(int argc, char *argv[])
}
#ifdef INET6
if (argc != 0 af == AF_INET6)
- setifxflags(inet6, -IFXF_NOINET6);
+ addaf(name, AF_INET6);
#endif
while (argc 0) {
const struct cmd *p;
@@ -1258,18 +1259,25 @@ setifxflags(const char *vname, int value
}
void
+addaf(const char *vname, int value)
+{
+ struct if_afreq ifar;
+
+ strlcpy(ifar.ifar_name, name, sizeof(ifar.ifar_name));
+ ifar.ifar_af = value;
+ if (ioctl(s, SIOCIFAFATTACH, (caddr_t)ifar) 0)
+ warn(SIOCIFAFATTACH);
+}
+
+void
removeaf(const char *vname, int value)
{
- switch (value) {
-#ifdef INET6
- case AF_INET6:
- setifxflags(vname, IFXF_NOINET6);
- setifxflags(vname, -IFXF_AUTOCONF6);
- break;
-#endif
- default:
- errx(1, removeaf not implemented for this AF);
- }
+ struct if_afreq ifar;
+
+ strlcpy(ifar.ifar_name, name, sizeof(ifar.ifar_name));
+ ifar.ifar_af = value;
+ if (ioctl(s, SIOCIFAFDETACH, (caddr_t)ifar) 0)
+ warn(SIOCIFAFDETACH);
}
#ifdef INET6
@@ -1331,7 +1339,9 @@ setia6eui64(const char *cmd, int val)
if (afp-af_af != AF_INET6)
errx(1, %s not allowed for the AF, cmd);
- setifxflags(inet6, -IFXF_NOINET6);
+#ifdef INET6
+ addaf(name, AF_INET6);
+#endif
in6 = (struct in6_addr *)in6_addreq.ifra_addr.sin6_addr;
if (memcmp(in6addr_any.s6_addr[8], in6-s6_addr[8], 8) != 0)
errx(1, interface index is already filled);
Index: sys/net/if.c
===
RCS file: /cvs/src/sys/net/if.c,v
retrieving revision 1.297
diff -u -p -r1.297 if.c
--- sys/net/if.c 12 Jul 2014 18:44:22 - 1.297
+++ sys/net/if.c 13 Jul 2014 13:15:09 -
@@ -428,10 +428,6 @@ if_attach(struct ifnet *ifp)
#else
TAILQ_INSERT_TAIL(ifnet, ifp, if_list);
#endif
-#ifdef INET6
- ifp-if_xflags |= IFXF_NOINET6;
-#endif
-
if_attachsetup(ifp);
}
@@ -1133,11 +1129,6 @@ if_up(struct ifnet *ifp)
bstp_ifstate(ifp);
#endif
rt_ifmsg(ifp);
-#ifdef INET6
- if (!(ifp-if_xflags IFXF_NOINET6))
- in6_if_up(ifp);
-#endif
-
#ifndef SMALL_KERNEL
rt_if_track(ifp);
#endif
@@ -1237,6 +1228,7 @@ ifioctl(struct socket *so, u_long cmd, c
struct ifaddr *ifa;
struct sockaddr_dl *sdl;
struct ifgroupreq *ifgr;
+ struct if_afreq *ifar;
char ifdescrbuf[IFDESCRSIZE];
char ifrtlabelbuf[RTLABEL_LEN];
int s, error = 0;
@@ -1271,6 +1263,26 @@ ifioctl(struct socket *so, u_long cmd, c
if ((error = suser(p, 0)) != 0)
return (error);
return (if_setgroupattribs(data));
+ case SIOCIFAFATTACH:
+ case SIOCIFAFDETACH:
+ if ((error = suser(p, 0)) != 0)
+ return (error);
+ ifar = (struct if_afreq *)data;
+ if ((ifp = ifunit(ifar-ifar_name)) == NULL)
+
Re: IFXF_NOINET doesn't make sense any more
* Stefan Sperling s...@openbsd.org [2014-07-15 11:06]: On Sun, Jul 13, 2014 at 03:48:47PM +0200, Henning Brauer wrote: now that we have an uncontaminated, err, inet6-free system by default, IFXF_NOINET6 just doesn't make sense any more. fully go for no inet6 by default, get rid of the IFXF_NOINET6 guarded attachments etc. introduce IFAFATTACH and IFAFDETACH ioctls. note that they are NOT inet6 specific; the kernel only has code for inet6 so far and will properly return EAFNOSUPPORT for all others. there should be no user visible changes from this. I like this direction. It's a lot better than the AF-specific kill switch. oh absolutely. and yes i plan to add ifconfig if -inet as a convenient way to get rid of all v4 addrs at once; inet doesn't really need that since it just doesn't have sth like the dreaded link-locals and the rtadv magic, but symmetry is good. and who knows whether we'll need it for inet7 anyway :) However, since we're heading towards release, I believe we should wait and do this flag removal + ioctl addition later. We've already got the no-link-local-by-default change, and the new autoconf6 flag. I don't see much harm in leaving it at that for this release cycle and moving further in the next one. I'm looking forward to florian's in-kernel rtsol as well, in the next cycle (it's not done yet anyway AFAIK). florian is done with that really, we're at the last tiny nits stage, polishing that could as well happen in-tree. I'm slightly undecided on whether this should make this release or not... it is actually kinda mechanic, i. e. we already know the relevant places since they are the ones that had the NONINET6 flag check before. I do think the risk is not big, so if we get some solid tests we should be golden. I for one haven't been able to make it misbehave no matter how hard I tried. kernel-rtsol should make release imo. Perhaps we can also sort out the autoconf vs. ip6forward conundrum then, and ship working IPv6 for SOHO routers in 5.7. yeah that limitation is bizarre - straight from the spec and not added by us, tho. I'll be testing this regardless and will let you know if I run into issues. coolio, thx -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services GmbH, http://bsws.de, Full-Service ISP Secure Hosting, Mail and DNS. Virtual Dedicated Servers, Root to Fully Managed Henning Brauer Consulting, http://henningbrauer.com/
Re: IFXF_NOINET doesn't make sense any more
On Tue, Jul 15, 2014 at 12:15:12PM +0200, Henning Brauer wrote: I'm slightly undecided on whether this should make this release or not... In that situation, I usually decide that the risk won't outweigh the benefits of just waiting for a while. No change means nobody can get hurt. kernel-rtsol should make release imo. I haven't seen a working diff yet. Last time I talked to florian there were still some open questions. Generally, I think it's non-trivial to move rtsold into the kernel so we should give such a change a soak period of at least a few weeks (I don't know if there is enough time left for that, but perhaps not). The kernel environment has much more potential for hidden side-effects. go ahead * You've entered a dark room with a single address space. * In the far corner there might be a hidden gremlin or two. What do you want to do? 1] I'll commit my diff anyway. 2] Let me go back to get my torch. 3] I'll wait for my companion developers to show up, then we'll take them by surprise in the dark. Please pick an option: _
Re: IFXF_NOINET doesn't make sense any more
* Stefan Sperling s...@openbsd.org [2014-07-15 12:35]: On Tue, Jul 15, 2014 at 12:15:12PM +0200, Henning Brauer wrote: I'm slightly undecided on whether this should make this release or not... In that situation, I usually decide that the risk won't outweigh the benefits of just waiting for a while. No change means nobody can get hurt. let me reformulate that as haven't made my mind up. first step of coirse is some form of risk assessment, and that risk seems to be rather small. i can perfectly live with postponing this to after release as well, not pushing. kernel-rtsol should make release imo. I haven't seen a working diff yet. I don't think he mailed it out yet. Sitting next to each otehr in Ljubljana had some benefits :) Last time I talked to florian there were still some open questions. tiny nits Generally, I think it's non-trivial to move rtsold into the kernel so we should give such a change a soak period of at least a few weeks (I don't know if there is enough time left for that, but perhaps not). The kernel environment has much more potential for hidden side-effects. oh I'm NOT suggesting to remove rtsol/d yet. It's not like they would conflict with the kernel-based rtsol handling, at worst you send a solicitation too much, which really is no big deal. but again, I wouldn't have a problem with postponing this to after release either. -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services GmbH, http://bsws.de, Full-Service ISP Secure Hosting, Mail and DNS. Virtual Dedicated Servers, Root to Fully Managed Henning Brauer Consulting, http://henningbrauer.com/
