I recently moved from a wired ethernet interface to wireless via ndiswrapper.
I now have wlan0 interface, and configuring it by hand works fine.
But, on boot, it's not coming up. The initscript gets as far as setting up the
essid, but then says that it cannot configure it. That's the only feedback.
msoulier@anton:~$ cat /etc/conf.d/net
essid_wlan0="digitaltorque"
config_wlan0=( "192.168.0.5/24" )
routes_wlan0=( "default via 192.168.0.1" )
msoulier@anton:~$ ls -l /etc/init.d/net.wlan0
lrwxrwxrwx 1 root root 6 Nov 8 2008 /etc/init.d/net.wlan0 -> net.lo
Do I need more here? I'm not yet running encryption, just a MAC filter, so no
other wireless params are needed.
Mike
--
Michael P. Soulier <msou...@digitaltorque.ca>
"Any intelligent fool can make things bigger and more complex... It takes a
touch of genius - and a lot of courage to move in the opposite direction."
--Albert Einstein
Forget all about conf.d/net, and disable the init scripts for it.
Install and run wicd instead.
--
alan dot mckinnon at gmail dot com
> Forget all about conf.d/net, and disable the init scripts for it.
>
> Install and run wicd instead.
I'll look into it, but the Gentoo Handbook still points at conf.d/net, so
should there not be an update if it has fallen out of favour? Should the bugs
in conf.d/net not be fixed?
I don't think that there bugs in conf.d/net just a matter of preference. Alan
suggested that wicd is a simpler way to have your wireless configured and it
does not need /etc/init.d/*net scripts to function.
I am running wpa_supplicant:
modules=( "wpa_supplicant" )
wpa_supplicant_ath0="-Dwext"
and it just works™ for my wireless card.
You may want to try something like this in your /etc/conf.d/net:
sleep_scan_wlan0="1"
config_wlan0=( "dhcp" )
fallback_wlan0=( "192.168.0.5 netmask 255.255.255.0" )
fallback_route_wlan0=( "default via 192.168.0.1" )
in case there is a dhcp problem with how the router releases IP address
leases.
--
Regards,
Mick
Laszlo
> I don't think that there bugs in conf.d/net just a matter of preference. Alan
> suggested that wicd is a simpler way to have your wireless configured and it
> does not need /etc/init.d/*net scripts to function.
>
> I am running wpa_supplicant:
>
> modules=( "wpa_supplicant" )
>
> wpa_supplicant_ath0="-Dwext"
>
> and it just works??? for my wireless card.
>
> You may want to try something like this in your /etc/conf.d/net:
>
> sleep_scan_wlan0="1"
>
> config_wlan0=( "dhcp" )
> fallback_wlan0=( "192.168.0.5 netmask 255.255.255.0" )
> fallback_route_wlan0=( "default via 192.168.0.1" )
>
> in case there is a dhcp problem with how the router releases IP address
> leases.
I'm not using dhcp, just a static address. All I want the damn scripts to do
is this
modprobe ndiswrapper
iwconfig wlan0 essid digitaltorque
ifconfig wlan0 192.168.0.5 netmask 255.255.255.0
route add default gw 192.168.0.1
After looking at the net.example again maybe I need this
modules=( "ifconfig" "iwconfig" "!wpa_supplicant" )
Or maybe I should just run an rc.local script.
> for me the best solution is to use networkmanager, delete net scripts
> and everything plus install nm-applet, so I have a real user friendly
> look and feel :) my only issue now is vpnc (see my other mail)
I'm not a fan of networkmanager.
On my ubuntu laptop I use whereami.
On this gentoo desktop, it doesn't roam. I want one network config to set a
static IP on my wireless card, always to the same essid.
conf.d/net is not buggy - it is suitable for static networking where the
interfaces never change and neither does the address.
It is simply inadequate for desktop use, *especially* roaming laptops. A side
note in the docs to this effect would not be amiss.
That's easy enough, here's what I used to use:
xxxxx means the essid
yyyyy means the wep passphrase
modules=( "dhclient" )
modules=( "iwconfig" )
config_eth0=( "dhcp" )
essid_wlan0="xxxxx"
key_xxxxx="s:'yyyyyyyyy' enc open"
preferred_aps_wlan0=( "xxxxx" )
channel_wlan0="11"
config_xxxxx=( "dhcp" )
config_wlan0=("dhcp")
> conf.d/net is not buggy - it is suitable for static networking where the
> interfaces never change and neither does the address.
>
> It is simply inadequate for desktop use, *especially* roaming laptops. A side
> note in the docs to this effect would not be amiss.
In my case the interface won't change and neither will the address.
It worked fine when it was a wired eth0 interface.
Does your router know this? I'm not being funny, but I had run into a problem
sometime in the past where a change in the dhcpcd version caused the router to
not read the NIC MAC address correctly. That created a clash with the IP
address lease.
> All I want the damn scripts to
> do is this
>
> modprobe ndiswrapper
OK, have you looked in your logs/dmesg? I think that the ndiswrapper has to
load first and probe your NIC, before /etc/init.d/net.wlan0 launches. It may
pay to keep an eye on the router logs while your machine boots.
My line above with sleep_scan_wlan0="1" or say "3" seconds delay may help, if
this is the problem.
> iwconfig wlan0 essid digitaltorque
> ifconfig wlan0 192.168.0.5 netmask 255.255.255.0
> route add default gw 192.168.0.1
>
> After looking at the net.example again maybe I need this
>
> modules=( "ifconfig" "iwconfig" "!wpa_supplicant" )
If you have not installed wpa_supplicant you don't need this. Just make sure
#modules=( "wpa_supplicant" ) is commented out. iwconfig is the default
anyway. ifconfig or iproute2 will work so I don't think that you need to
define that either. Your entries:
essid_wlan0="digitaltorque"
config_wlan0=( "192.168.0.5/24" )
routes_wlan0=( "default via 192.168.0.1" )
are correct - so the error is not because of these.
> Or maybe I should just run an rc.local script.
You could use the preup scripts in /etc/conf.d/net, if for some reason the
ndiswrapper takes for ever to kick into action.
HTH.
--
Regards,
Mick
I just noticed that the latest dhcpcd-4.0.15 is playing up when it
comes up. It seems that on 3 out of 5 it will time out when my
machine boots up. It works fine if I bring it up manually thereafter,
or run /etc/init.d/net.eth0 restart. The previous version worked
without timing out. This may be related to how dhcpcd interacts with
my router - or it could also be related to your problem? I haven't
had time to troublshoot it yet.
--
Regards,
Mick
> Does your router know this? I'm not being funny, but I had run into a problem
> sometime in the past where a change in the dhcpcd version caused the router to
> not read the NIC MAC address correctly. That created a clash with the IP
> address lease.
If I configure it statically then it dhcpcd shouldn't run at all. It works
fine when I configure it by hand.
> OK, have you looked in your logs/dmesg? I think that the ndiswrapper has to
> load first and probe your NIC, before /etc/init.d/net.wlan0 launches. It may
> pay to keep an eye on the router logs while your machine boots.
>
> My line above with sleep_scan_wlan0="1" or say "3" seconds delay may help, if
> this is the problem.
I'll play with it a bit.
> If you have not installed wpa_supplicant you don't need this. Just make sure
> #modules=( "wpa_supplicant" ) is commented out. iwconfig is the default
> anyway. ifconfig or iproute2 will work so I don't think that you need to
> define that either. Your entries:
>
> essid_wlan0="digitaltorque"
> config_wlan0=( "192.168.0.5/24" )
> routes_wlan0=( "default via 192.168.0.1" )
>
> are correct - so the error is not because of these.
>
> > Or maybe I should just run an rc.local script.
>
> You could use the preup scripts in /etc/conf.d/net, if for some reason the
> ndiswrapper takes for ever to kick into action.
Hmm. I did put ndiswrapper in my /etc/modules.autoload.d/kernel-2.6, so it
should be loaded at boot, but maybe it takes too long, causing a race
condition at boot.
> I just noticed that the latest dhcpcd-4.0.15 is playing up when it
> comes up. It seems that on 3 out of 5 it will time out when my
> machine boots up. It works fine if I bring it up manually thereafter,
> or run /etc/init.d/net.eth0 restart. The previous version worked
> without timing out. This may be related to how dhcpcd interacts with
> my router - or it could also be related to your problem? I haven't
> had time to troublshoot it yet.
I'd be surprised, as it shouldn't be run at all.