The setup: eth0: physical network interface LAN eth1: physical network interface ADSL-Modem eth2: physical network interface WLAN tun1000: virtual interface for openvpn (server) Services (apache, postfix etc.) are explicitly bound to eth0 and tun1000, so in my understanding those interfaces have to be up for is_net_up() to return true. If a daemon would be started before eg. tun1000 is up, it would fail in bind(2). First I had to set RC_COLDPLUG="!net.*" since otherwise eth1 would get started because of hotplug events, but thanks, I want to take my internet connection up and down manually. Since people are told to "rc-update -a" new network scripts/links I guess this should be made the default. If I add a service to init, I expect it to be started for that reason, and not beforehand by some coldplug event magic. Next thing I stumbled upon is the implementation for is_net_up. I don't get the comment close to the bottom, and also not the "polarity" of the return value. From places where is_net_up is called, I'd expect it to return 1 if the net is up, so the "none" case should "return 1" instead of zero. The "${netcount} -lt 1" comparison also seems odd, shouldn't netcount be compared to the number of configured net.* interfaces in /etc/runlevels/default? Last problem is that the tun interface does not get created (should be by tuntap_pre_start in net.modules.d/tuntap.sh). Looking through a dump of "strace -f /etc/init.d/net.tun1000 start" I found some calls to "/sbin/ip", but no "--mktun" is to be found anywhere. I tried modules_tun1000 = ( "tuntap" )in conf.d/net, but no change. I can hack on this myself, but please someone share some insights if I'm on the right track, thanks.
(In reply to comment #0) > The setup: > eth0: physical network interface LAN > eth1: physical network interface ADSL-Modem > eth2: physical network interface WLAN > tun1000: virtual interface for openvpn (server) > > Services (apache, postfix etc.) are explicitly bound to eth0 and tun1000, so in > my understanding those interfaces have to be up for is_net_up() to return true. > If a daemon would be started before eg. tun1000 is up, it would fail in > bind(2). If they explicitly bind to that interface then yes. > > First I had to set RC_COLDPLUG="!net.*" since otherwise eth1 would get started > because of hotplug events, but thanks, I want to take my internet connection up > and down manually. Since people are told to "rc-update -a" new network > scripts/links I guess this should be made the default. If I add a service to > init, I expect it to be started for that reason, and not beforehand by some > coldplug event magic. Documentation can be changed. The fact that they have added a network script to a runlevel does not affect coldplug events. Most people seem to like the coldplug default of yes - it's mainly people with servers with virtual network connection like yourself which appear to have issue with the default. > > Next thing I stumbled upon is the implementation for is_net_up. I don't get the > comment close to the bottom, and also not the "polarity" of the return value. > From places where is_net_up is called, I'd expect it to return 1 if the net is > up, so the "none" case should "return 1" instead of zero. The "${netcount} -lt > 1" comparison also seems odd, shouldn't netcount be compared to the number of > configured net.* interfaces in /etc/runlevels/default? Well, your first assumption is wrong. is_net_up returns 0 if net is classified as UP as bash (and userspace programs) like to return 0 on success. > > Last problem is that the tun interface does not get created (should be by > tuntap_pre_start in net.modules.d/tuntap.sh). Looking through a dump of "strace > -f /etc/init.d/net.tun1000 start" I found some calls to "/sbin/ip", but no > "--mktun" is to be found anywhere. I tried modules_tun1000 = ( "tuntap" )in > conf.d/net, but no change. Have you set tuntap_tun1000="tun"? It's a new setting that triggers the use of tuntap (openvpn/tunctl) to create the interface. We use this so the interface can now have any name you wish. I use "vpn" myself.
(In reply to comment #1) > > If a daemon would be started before eg. tun1000 is up, it would fail in > > bind(2). > > If they explicitly bind to that interface then yes. I just like that second line of defense in addition to the firewall. > > First I had to set RC_COLDPLUG="!net.*" since otherwise eth1 would get started > > because of hotplug events, but thanks, I want to take my internet connection up > > Documentation can be changed. The fact that they have added a network script to > a runlevel does not affect coldplug events. Most people seem to like the > coldplug default of yes - it's mainly people with servers with virtual network > connection like yourself which appear to have issue with the default. When documented properly, it's ok. I was just a bit surprised to see my box connect to the "big bad internet" when I didn't yet expected it to. > > Next thing I stumbled upon is the implementation for is_net_up. I don't get the > > comment close to the bottom, and also not the "polarity" of the return value. > Well, your first assumption is wrong. is_net_up returns 0 if net is classified > as UP as bash (and userspace programs) like to return 0 on success. Ah, sorry. I'll never get this inverted logic to stick in my brain. > > Last problem is that the tun interface does not get created (should be by > > Have you set tuntap_tun1000="tun"? It's a new setting that triggers the use of > tuntap (openvpn/tunctl) to create the interface. We use this so the interface > can now have any name you wish. I use "vpn" myself. > Strangely enough, it seems to be a matter of running the init script at boot time vs. later when the machine is up. I know that's probably too little info as to be useful. I'll try to look into this again next weekend. But what would be the point of the new setting you mentioned, shouldn't a "config_tun1000 = (blah)" have the same effect already?
(In reply to comment #2) > Strangely enough, it seems to be a matter of running the init script at boot > time vs. later when the machine is up. I know that's probably too little info > as to be useful. Yes it is. You could try doing this in conf.d/net depend_tun1000() { need net.eth0 } To depend on the interface used for the tunnel to be up. > But what would > be the point of the new setting you mentioned, shouldn't a "config_tun1000 = > (blah)" have the same effect already? > Well it used to as we could rely on the name tun or tap being used. But take my example of just config_vpn=( "foo" ). I know it's a vpn, but how do our init scripts know? The answer is they don't. You could even rename a physical interface to read "tun0" which would cause serious issue. This way is better I think. Resolving as NEED-INFO regarding it not working at boot.
Everything is working now as I want to, thanks for your time. Here's what I did: - set RC_COLDPLUG="!net.*" - update to baselayout-1.12.0_pre18 - add tuntap_tun1000="tun" As there were no changes to tuntap.sh between pre17 and pre18, most likely I did a typo when trying out the tuntap_...="tun" setting first time (before the update).