Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 130171 - various issues with complicated network setup on baselayout-1.12.0_pre17-r2
Summary: various issues with complicated network setup on baselayout-1.12.0_pre17-r2
Status: VERIFIED NEEDINFO
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] baselayout (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Roy Marples (RETIRED)
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-04-16 09:10 UTC by Stefan Nickl
Modified: 2006-05-04 12:50 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Stefan Nickl 2006-04-16 09:10:49 UTC
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.
Comment 1 Roy Marples (RETIRED) gentoo-dev 2006-04-18 00:10:57 UTC
(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.
Comment 2 Stefan Nickl 2006-04-18 14:23:52 UTC
(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?
Comment 3 Roy Marples (RETIRED) gentoo-dev 2006-04-19 00:31:29 UTC
(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.
Comment 4 Stefan Nickl 2006-05-04 12:50:20 UTC
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).