On Mon, Jul 18, 2016 at 03:01:48PM +0200, Martin Pieuchot wrote: > I use a vlan(4) on top of a tap(4). Since the rewrite that made vlan(4) > MP-safe I got errors during boot because my tap0 is not UP when I try > to bring my vlan up. > > Now that tap(4) has been separated from tun(4) is there any reason to > still treat it as a special interface? Does it need to be started > *after* pppoe(4)? If not the diff below fixes my issue.
While I agree, I wonder if this is not just a workaround that we may het with other interfaces as well. In general I'm OK with this but I would also very much like tun(4) to be removed from that list. > Index: netstart > =================================================================== > RCS file: /cvs/src/etc/netstart,v > retrieving revision 1.168 > diff -u -p -r1.168 netstart > --- netstart 27 Mar 2016 20:32:42 -0000 1.168 > +++ netstart 18 Jul 2016 12:54:55 -0000 > @@ -245,7 +245,7 @@ fi > > # Configure all the non-loopback interfaces which we know about, but > # do not start interfaces which must be delayed. Refer to hostname.if(5) > -ifmstart "" "trunk svlan vlan carp gif gre pfsync pppoe tun tap bridge pflow" > +ifmstart "" "trunk svlan vlan carp gif gre pfsync pppoe tun bridge pflow" > > # The trunk interfaces need to come up first in this list. > # The (s)vlan interfaces need to come up after trunk. > @@ -277,7 +277,7 @@ fi > # require routes to be set. TUN might depend on PPPoE, and GIF or GRE may > # depend on either of them. PFLOW might bind to ip addresses configured > # on either of them. > -ifmstart "pppoe tun tap gif gre bridge pflow" > +ifmstart "pppoe tun gif gre bridge pflow" > > # Reject 127/8 other than 127.0.0.1. > route -qn add -net 127 127.0.0.1 -reject >/dev/null > -- :wq Claudio
