# OpenRC and network scripts

## VanDan

After updating to OpenRC stuff, my system doesn't boot properly. To start with, it doesn't wait for an IP address before continuing on to other things which really should depend on one, like netmount, ntp-client, etc. So sometimes, netmount works and other times it doesn't, as I don't have a network connection yet.

The next problem is that I now keep dropping my IP address and getting some 169.x.x.x address. This never used to happen.

And finally, when I go to restart net.eth0, I get:

```
metabox ~ # /etc/init.d/net.eth0 restart

 * Bringing down interface eth0

 *   Stopping dhcpcd on eth0 ...                                                                                             [ ok ]

 *   Stopping wpa_cli on eth0 ...                                                                                            [ ok ]

 *   Stopping wpa_supplicant on eth0 ...                                                                                     [ ok ]

 * Bringing up interface eth0

 *   Starting wpa_supplicant on eth0 ...                                                                                     [ ok ]

 *   Starting wpa_cli on eth0 ...                                                                                            [ ok ]

 *   Backgrounding ... ...

 * WARNING: net.eth0 not under our control, aborting
```

Why isn't net.eth0 under 'our' control, and who's control is it under?

----------

## UberLord

It's under wpa_supplicants control.

169.254 addresses are IPV4LL, aka ZeroConf aka APIPA.

If you get that it normally means dhcpcd could not contact a DHCP server.

----------

## Gef

You can use dhcpcd with the "-L" flag not to get this ZeroConf ip adress. But this won't help if you machine cannot contact the dhcp server.

----------

## Maliron

To fix the issue where the rest of the scripts are running before net is up try this:

/etc/conf.d/rc

```

# Set to "yes" if you want the rc system to try and start services

# in parallel for a slight speed improvement. NOTE: When RC_PARALLEL_STARTUP

# is enabled, init script output is replaced with simple "service foo

# starting/stopping" messages so that output is not mixed up.

# You can stop this from happening on the command line by passing --verbose

# to the init script or by setting RC_VERBOSE="yes" below.

RC_PARALLEL_STARTUP="no"

```

As for the "not under our control thing" I have to agree this is pretty bad verbiage. I am having an issue where the wireless comes up and wpa_sup will connect to the ap, pull an IP, but this brings the interface down. I am assuming this is because its "not under our control."

```

Jun  4 09:36:21 rreese-lt wpa_cli: interface ath1 CONNECTED

Jun  4 09:36:21 rreese-lt /etc/init.d/net.ath1[17149]: WARNING: net.ath1 not under our control, aborting

Jun  4 09:36:21 rreese-lt dhclient: ath-mon1: unknown hardware address type 801

Jun  4 09:36:21 rreese-lt dhclient: eth1: unknown hardware address type 801

Jun  4 09:36:22 rreese-lt dhclient: ath-mon1: unknown hardware address type 801

Jun  4 09:36:22 rreese-lt dhclient: eth1: unknown hardware address type 801

Jun  4 09:36:24 rreese-lt dhclient: option_space_encapsulate: option space agent does not exist, but is configured.

Jun  4 09:36:24 rreese-lt dhclient: DHCPREQUEST on ath1 to 255.255.255.255 port 67

Jun  4 09:36:24 rreese-lt dhclient: DHCPACK from 10.10.220.254

Jun  4 09:36:24 rreese-lt dhclient: bound to 10.10.220.241 -- renewal in 259 seconds.

Jun  4 09:36:24 rreese-lt wpa_cli: interface ath1 DISCONNECTED

```

Thanks!

----------

## musv

Same problem here:

```
 *   Backgrounding ... ... 

 * WARNING: net.ath0 not under our control, aborting
```

I'm still using 2.6.24 with madwifi-drivers. And in opposite to the posting above, I try to specify a static IP. So my config looks like:

```
config_ath0="192.168.100.100/24"

routes_ath0="default via 192.168.100.1"

modules="wpa_supplicant"

wpa_supplicant_ath0="-Dmadwifi"

```

While booting ath0 starts, it doesn't set the IP. When WPA-supplicant starts everything else is ignored.

How can I get it working with static IP?

Reason for not using dhcp: I have to connect via Vodafone Easybox A600. The piece of technical shit allows to specify port-mapping from the external IP to the computers inside the local red. But unfortunately with every connection I get a different internal IP. And I didn't find an entry in that box to assign a mac-address to an internal fixed ip.

----------

## UberLord

You'll get the static IP once wpa_supplicant thinks the connection is up.

"wpa_cli status" can tell you the status of wpa_supplicant

----------

## Maliron

So what should we do with this "not under our control" thing? Of note I also get this:

```

Jun  5 20:20:49 rreese-lt /etc/init.d/net.ath1[4512]: WARNING: net.ath1 has started, but is inactive

```

The card also does not work in this case.

Should there be a bug opened?

----------

## UberLord

 *Maliron wrote:*   

> So what should we do with this "not under our control" thing?

 

Maybe I should change that messge  :Smile: 

"Not under our control" means this -

1) We mark ourselves inactive as we are about to start a daemon&&

2) We start a daemon to continue configuration of the interface

3) exit

Woah there! That daemon we launched is fast!

Before we exited we noticed that we had been started again (probably by the daemon wanting to continue) so we aborted with the message

"Not under our control"

instead of

"service has started, but is inactive"

 *Quote:*   

>  Of note I also get this:
> 
> ```
> Jun  5 20:20:49 rreese-lt /etc/init.d/net.ath1[4512]: WARNING: net.ath1 has started, but is inactive
> ```
> ...

 

This means that the daemon we started to continue configuration of the interface (in this case wpa_supplicant) did not associate with an AP.

Whllst it maybe a bug with OpenRC/baselayout, it's more likely a simple case of wireless not being that reliable ora wpa_supplicant mis-configuration.

You are free to open a bug, but the onus is on you to try and show where the bug lies.

----------

## Maliron

 *UberLord wrote:*   

> 
> 
> Before we exited we noticed that we had been started again (probably by the daemon wanting to continue) so we aborted with the message
> 
> "Not under our control"
> ...

 

So essentially the "not under our control" message is from a second spawning of the init script caused by wpa_sup? I guess if I need a clearer explanation of this message I should look at the init script myself.

 *UberLord wrote:*   

> 
> 
> This means that the daemon we started to continue configuration of the interface (in this case wpa_supplicant) did not associate with an AP.
> 
> Whllst it maybe a bug with OpenRC/baselayout, it's more likely a simple case of wireless not being that reliable ora wpa_supplicant mis-configuration.
> ...

 

This is very frustrating because everything was fine before a recent update to this system. Madwifi-ng was NOT updated, nor was there an update to wpa_supplicant. The biggest change to the system was a move to the new OpenRC init process. Since then my wireless may actually comes up and work (i.e. attaches to my AP and gives me an IP and STAYS attached) about 50% of the time now. The few times when the wireless card does come up it is very prone to "losing" auth and kicking my VPN offline. It's gotten to point were I have ran a wired connection just so I can get my work done. 

I consider myself a very linux savvy individual and have exhausted every possibility I can think of. I am willing to believe this is a wpa_supplicant issue though, as I have never liked that package much and would not be opposed to trying another package out.

That being said does anyone have any other recommendations for a different supplicant for handling WPA authentication and potentially 802.1x?

----------

## UberLord

If it's saying "not under our control" then something else has indeed restarted it - probably wpa_cli.

If "wpa_cli status" says it's connected, but you don't have a DHCP address you can do this

```
IN_BACKGROUND=true /etc/init.d/net.ath0 start
```

If that fails, then we can start debugging as it then looks like an openrc bug.

```
IN_BACKGROUND=true /etc/init.d/net.ath0 --debug start &>/tmp/debug
```

And email roy@marples.name me that debug file -don't post it here as it will be far too big. Or link to it if you like  :Smile: 

----------

## Ion Silverbolt

I also have this problem with madwifi since upgrading openrc. Oddly my main system works fine while my usb backup hard drives gives out the "not under our control" error. I don't think it is a wpa supplicant problem. Both systems have identical kernels and config files.  The only difference I know of is a SATA raptor boots a lot faster than a USB HD.

----------

## UberLord

I'll need some debug output please, as right now it Works For Me

----------

## musv

 *UberLord wrote:*   

> You'll get the static IP once wpa_supplicant thinks the connection is up.
> 
> "wpa_cli status" can tell you the status of wpa_supplicant

 

Thx, that's it.

----------

## UberLord

 *Ion Silverbolt wrote:*   

> I also have this problem with madwifi since upgrading openrc. Oddly my main system works fine while my usb backup hard drives gives out the "not under our control" error. I don't think it is a wpa supplicant problem. Both systems have identical kernels and config files.  The only difference I know of is a SATA raptor boots a lot faster than a USB HD.

 

I got your email, but when I reply to it, a server upstream bounces back with an invalid HELO message. Please fix this:)

Anyway, it seems that you've not installed a dhcp client. Try emerging dhcpcd  :Smile: 

----------

