| View previous topic :: View next topic |
| Author |
Message |
VanDan
Guru
Joined: 30 Sep 2002
Posts: 586
Location: Australia
|
 Posted: Sun May 25, 2008 10:42 am Post subject: OpenRC and network scripts |
 |
|
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:
| Code: | 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?
_________________
David Hicks' plea. Was it:
a) I plead guilty, or
b) Please let me out of here and end the torture |
|
| Back to top |
|
 |
UberLord
Retired Dev
Joined: 18 Sep 2003
Posts: 6835
Location: Blighty
|
|
| Back to top |
|
|
Gef
Apprentice
Joined: 17 May 2008
Posts: 180
Location: France
|
| Posted: Sun May 25, 2008 7:40 pm Post subject: |
|
|
| 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. |
|
| Back to top |
|
|
Maliron
n00b
Joined: 01 Apr 2004
Posts: 11
|
| Posted: Wed Jun 04, 2008 4:52 pm Post subject: Any updates |
|
|
To fix the issue where the rest of the scripts are running before net is up try this:
/etc/conf.d/rc
| Code: |
# 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."
| Code: |
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!
_________________
If ignorance truly were bliss the world would be a much happier place... |
|
| Back to top |
|
|
musv
Advocate
Joined: 01 Dec 2002
Posts: 3367
Location: de
|
| Posted: Fri Jun 06, 2008 10:21 am Post subject: |
|
|
Same problem here:
| Code: | * 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:
| Code: | 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. |
|
| Back to top |
|
|
UberLord
Retired Dev
Joined: 18 Sep 2003
Posts: 6835
Location: Blighty
|
|
| Back to top |
|
|
Maliron
n00b
Joined: 01 Apr 2004
Posts: 11
|
| Posted: Fri Jun 06, 2008 7:38 pm Post subject: So what next? |
|
|
So what should we do with this "not under our control" thing? Of note I also get this:
| Code: |
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?
_________________
If ignorance truly were bliss the world would be a much happier place... |
|
| Back to top |
|
|
UberLord
Retired Dev
Joined: 18 Sep 2003
Posts: 6835
Location: Blighty
|
| Posted: Sat Jun 07, 2008 12:44 am Post subject: Re: So what next? |
|
|
| Maliron wrote: | | So what should we do with this "not under our control" thing? |
Maybe I should change that messge 
"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:
| Code: | | 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? |
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.
_________________
Use dhcpcd for all your automated network configuration needs
Use dhcpcd-ui (GTK+/Qt) as your System Tray Network tool |
|
| Back to top |
|
|
Maliron
n00b
Joined: 01 Apr 2004
Posts: 11
|
| Posted: Mon Jun 09, 2008 7:37 am Post subject: Re: So what next? |
|
|
| 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"
instead of
"service has started, but is inactive"
|
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.
You are free to open a bug, but the onus is on you to try and show where the bug lies. |
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?
_________________
If ignorance truly were bliss the world would be a much happier place... |
|
| Back to top |
|
|
UberLord
Retired Dev
Joined: 18 Sep 2003
Posts: 6835
Location: Blighty
|
| Posted: Mon Jun 09, 2008 9:09 am Post subject: |
|
|
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
| Code: | | 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.
| Code: | | 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
_________________
Use dhcpcd for all your automated network configuration needs
Use dhcpcd-ui (GTK+/Qt) as your System Tray Network tool |
|
| Back to top |
|
|
Ion Silverbolt
Apprentice
Joined: 04 Nov 2004
Posts: 203
|
| Posted: Mon Jun 09, 2008 5:39 pm Post subject: |
|
|
| 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. |
|
| Back to top |
|
|
UberLord
Retired Dev
Joined: 18 Sep 2003
Posts: 6835
Location: Blighty
|
|
| Back to top |
|
|
musv
Advocate
Joined: 01 Dec 2002
Posts: 3367
Location: de
|
| Posted: Tue Jun 10, 2008 7:20 am Post subject: |
|
|
| 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. |
|
| Back to top |
|
|
UberLord
Retired Dev
Joined: 18 Sep 2003
Posts: 6835
Location: Blighty
|
| Posted: Wed Jun 11, 2008 10:56 am Post subject: |
|
|
| 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
_________________
Use dhcpcd for all your automated network configuration needs
Use dhcpcd-ui (GTK+/Qt) as your System Tray Network tool |
|
| Back to top |
|
|
|
Networking & Security
