Improved Network Wizard (and rc.network)

[Dougal]

configuring network interface wlan0
cups: started scheduler.
Starting PCMCIA services:

These three lines seem to imply that configuring wlan0 started before CPMCIA was properly working... is it a PCMCIA NIC you're using?

35eb1eeac6692d1e1ee6dee76dceb44d307f122f317a64c10aaf6100b5150eb"'.
Line 16: WPA-PSK accepted for key management, but no PSK configured.
Line 16: failed to parse network block.
Failed to read or parse configuration '/etc/network-wizard/wireless/wpa_profiles/00:15:05:22:D0:65.WPA.conf'.

This means there might be a problem with that config file -- try looking at it and make sure it's ok. I don't know how that psk (the long hex number) got in the log, but it has a double-quote (") at the end, that might suggest the problem fixed in the 16th version of the wizard (was that configuration file created by an earlier version?).

[sullysat]

So it must be a problem of the HW not being initialized properly when rc.network is run.
This can be solved by increasing the sleep time waiting for it, but I can't just increase it for everybody, since people with HW that initializes fast will want to be connected already when X starts!

I'll be happy to increase the the sleep time and test it. What file is that in?

So I need info on the different setups that have this problem, so that I can detect them and know to wait a little longer:
- which kernel module is used
- which kernel version (i.e. the one from 4.1 or 4.1retro)
- maybe some info about the device: pci ids (from the output of "elspci -l", for example), any possible errors seen in dmesg output etc.

I don't know about the kernel module, but I'm running the retro kernel version of 4.1 with a generic wireless pcmcia card that THIS version of puppy sees as 'hostap_cs' (has always been 'orinoco_cs' in previous versions). The output of elspci -l is as follows:


Hope this helps.
Sully

[Dougal]

I'll be happy to increase the the sleep time and test it. What file is that in?

/etc/rc.d/rc.network
You'll have to add a sleep after the MAXWAIT loop, since that loop quits the moment the interface is found (which in your case is not enough).

I don't know about the kernel module, but I'm running the retro kernel version of 4.1 with a generic wireless pcmcia card that THIS version of puppy sees as 'hostap_cs' (has always been 'orinoco_cs' in previous versions).

The reason it changed is that I found out that hostap and orinoco overlap, but apparently hostap is preferable (it's newer), so Barry added an override.

I have a feeling this might actually be a problem with PCMCIA, where Barry actually needs to make sure it's initialized before starting rc.network...

What I can do, is add an extra sleep if a pcmcia networking module is loaded...

[prit1]

Dougal,

I am having problems with the Network Wizard in Puppy 4.1. I then tried downloading the latest from this thread. Still not working. Atleast now I can get to the Ndiswrapper page where it lets me select an .inf file. But bcmwl5.inf which is for Broadcom that works in Ubuntu and Puppy 4.00 is not working using this Network Wizard.

When I load the .inf file, it says, driver present. But then comes back with the message - no new interfaces found and asks me to unload.

Please help.

[Dougal]

When I load the .inf file, it says, driver present. But then comes back with the message - no new interfaces found and asks me to unload.

Did you remove first the native module that might have been loaded?
The "bcm" part makes me think of Broadcom... if the native driver is b43, you'll need to blacklist the "ssb" module (in the Boot Manager), since that's the one that actually takes hold of the device.
If that's not the case, you might want to have a look at the output of dmesg and see if loading that driver with ndiswrapper produced any error messages.

[Dougal]

I've made an attempt at solving the problem with PCMCIA NICs not being configured at boot.
I've added a check to see if any of the interfaces (in /sys/class/net) is pcmcia and, if so, sleep for an extra 10 seconds.

This file should be gunzipped and go in /etc/rc.d. It might need to be made executable to work (chmod +x rc.network).

[prit1]

Dougal,

The default linux driver could not have loaded as it does not show an interface. Anyway, I checked the blacklist.

Here is the output from the dmesg:

Code: Select all

ndiswrapper version 1.53 loaded (smp=no, preempt=no)
ndiswrapper: driver bcmwl5 (Broadcom,09/20/2007, 4.170.25.12) loaded
ACPI: PCI Interrupt 0000:05:00.0[A] -> Link [LNKB] -> GSI 10 (level, low) -> IRQ 10
PCI: Setting latency timer of device 0000:05:00.0 to 64
ndiswrapper: using IRQ 10
wlan0: ethernet device 00:1f:e2:b4:58:3e using NDIS driver: bcmwl5, version: 0x4aa190c, NDIS version: 0x501, vendor: 'NDIS Network Adapter', 14E4:4315.5.conf
wlan0: encryption modes supported: WEP; TKIP with WPA, WPA2, WPA2PSK; AES/CCMP with WPA, WPA2, WPA2PSK
usbcore: registered new interface driver ndiswrapper
ndiswrapper: device wlan0 removed
ACPI: PCI interrupt for device 0000:05:00.0 disabled
usbcore: deregistering interface driver ndiswrapper

The last few lines come after I am told by the wizard that no interfaces are found and that I need to unload it.

[Sit Heel Speak]

Hi Dougal,

I'm using Puppy 4.1 (MU's k2.6.27 smp version, 2nd build), and the October 16th network-wizard build, on the rig described in my signature. No wireless lan here, just two onboard e1000 Intel gigabit ethernet ports. eth0 connects to my adsl "modem" and eth1 connects through a switching hub to other local computers.

Auto-dhcp does not work, even though it reports success; my adsl modem is 10.0.0.2 but eth0 ends up with a 169.xxx.xx.xx address which varies in the last three numbers. So I must set eth0 to a static IP.

I would guess that what I need, is for the network-wizard to have the ability to set the default route (i.e. gateway machine's IP) for each of my two NIC's to its own gateway IP. For example: if eth1 is set to IP=192.168.1.13, netmask=255.255.255.0 default gateway=192.168.1.5, DNS1=192.168.1.5 DNS2 not set,

then it is possible to ping local machine 192.168.1.5, I can open its shares using PNetHood or gFTP.

But if I then try to set eth0 (Network Wizard test shows an available live network, OK) to static IP=10.0.0.13, netmask=255.0.0.0, default gateway=10.0.0.2, DNS1=10.0.0.2, DNS2 not set,

and then try to ping 10.0.0.2, I get an error dialog box:

***
Error!
Could not set default route through10.0.0.2.
Note that Puppy has tried to do this:
route add -net default gw 10.0.0.2 dev eth0
route: SIOCADDRT: Network is unreachable
***

If I disconnect the cable from eth1 and reboot, I have no trouble assigning the static IP 10.0.0.13 to eth0.

Also, I would suggest, for the sake of logical consistency, change the subdir name from
/etc/network/network-wizard/network
to
/etc/network/network-wizard/wired

Thanks for your help,
Philip

PS I have a Microsoft MN-500 wireless base station, no software, if anyone wants it PM me, you can have it for postage. Weight is about 1 pound (453g) including the 120VAC 60Hz AC adapter.

[MU]

Dougal, do you plan to localize the wizard?
Mark

[sullysat]

I've made an attempt at solving the problem with PCMCIA NICs not being configured at boot.
I've added a check to see if any of the interfaces (in /sys/class/net) is pcmcia and, if so, sleep for an extra 10 seconds.

Hey Dougal, sorry for the delayed response but life got in the way for a couple days.

I tried increasing the MAXWAIT to 20, then tried swapping the existing network file for the one you built. Neither of these corrected the issue.

Sully

[Dougal]

Here is the output from the dmesg:

Code: Select all

wlan0: ethernet device 00:1f:e2:b4:58:3e using NDIS driver: bcmwl5, version: 0x4aa190c, NDIS version: 0x501, vendor: 'NDIS Network Adapter', 14E4:4315.5.conf
wlan0: encryption modes supported: WEP; TKIP with WPA, WPA2, WPA2PSK; AES/CCMP with WPA, WPA2, WPA2PSK
usbcore: registered new interface driver ndiswrapper
ndiswrapper: device wlan0 removed

Well, the interface does seem to appear, so the question is why the wizard doesn't find it.

You should try running the wizard and having a terminal open at the same time. Then, when you load the ndiswrapper module, run in the terminal

Code: Select all

ifconfig -a

and see if wlan0 is appears.
If not, wait a few seconds and try again: maybe that what the wizard has to do -- it might be checking before the interface finished initializing.

[Dougal]

I tried increasing the MAXWAIT to 20, then tried swapping the existing network file for the one you built. Neither of these corrected the issue.

Changing MAXWAIT would not have any effect, since we've already established that
the interface is seen in the output of ifconfig (which will stop the loop before
MAXWAIT time has passed).

You should look if booting with the modified rc.network gave any different messages
than before.

You could also try increasing the sleep in line 291 and see if that helps.
It would also be good if you try adding before line 291 the follwing:

Code: Select all

cat /sys/class/net/*/device/modalias

...just to make sure my attempt fix actually does something.

Also, try looking at the output of dmesg and see if you can find anything about
pcmcia initializing and if it's done before/after the code in rc.network is
run.
(The rc.network code should start with lines like "eth0: link down", then do the
sleeping, then generate more lines like that.)

[Béèm]

Dougal, do you plan to localize the wizard?
Mark

Good question.

[BarryK]

I have hacked the 'net-setup.sh' script from Oct. 16 Wizard.

This "fixes" the handling of blacklisting.

I also put in further information in the ndiswrapper dialog box, clarifying which interface, if any, needs to be brought down, and warning of the risk of the system becoming unstable if a wireless module is unloaded -- and explanation how to use the BootManager to get around this.

I've only done some basic testing. Haven't created a diff file. Done quickly, and Dougal might like to tidy it up a bit.

My edits have "v411" in the comments.

[dogone]

My appologies to Dogual and all, but I've finally caved with regard to wireless problems under Puppy post 4.0. I have disabled rc.network (chmod -x) and am employing my "bringup_wireless" script in rc.local (or /root/Startup) to bring up the pcmcia wireless cards (bcm43xx and ath_pci) on my two laptops. The script works flawlessly in both cases.

Desperate times call for desparate measures. Neither laptop leaves the house so all settings are fixed. My script will get me through until a fix is found...and yes, I have followed the forum threads, tested the latest updates and contributed feedback here and there. Nothing has worked and entering wireless settings again after each boot finally got the best of me.

Perhaps the following will help some of you. Many thanks to those who contributed and apologies for my own the crude coding. There's probably a better way, but this works.

#start dogone's wireless startup script

#!/bin/sh
# inspired by forum posts in an effort to autostart wireless
#shouldn't need xorg input driver as this is cli
#modprobe evdev
#reload card driver to be sure
rmmod bcm43xx
modprobe bcm43xx
#we don't appear to need sleep
#sleep 5s
#net interface must be up
ifconfig wlan0 up
#make sure nothing's left from prior attempt
rm -fr /var/run/*.pid
rm -f /var/run/wpa_supplicant/wlan0
#establish a wpa encrypted connection
wpa_supplicant -B -D wext -i wlan0 -c /etc/wpa_supplicant.conf
#this is done automagically
#route add 192.168.0.5 wlan0
#we don't appear to need sleep here either
#sleep 3s
#clear old dhcpcd info
rm -f /var/lib/dhcpcd/*.info
#get ip address and were done
dhcpcd -t 30 -h puppypc -d wlan0

#end dogone's bringup wireless script


#start dogone's wpa_supplicant.conf

ctrl_interface=/var/run/wpa_supplicant
ap_scan=1
update_config=0
network={
ssid="61599243"
scan_ssid=1
psk="????????????"
proto=WPA
key_mgmt=WPA-PSK
pairwise=TKIP
group=TKIP
}

#end dogone's wpa_supplicant.conf

[prit1]

You should try running the wizard and having a terminal open at the same time. Then, when you load the ndiswrapper module, run in the terminal

Code: Select all

ifconfig -a

and see if wlan0 is appears.
If not, wait a few seconds and try again: maybe that what the wizard has to do -- it might be checking before the interface finished initializing.

You were right. I could see wlan0 in the terminal after the ndiswrapper loaded the driver. But then the wizard did not see it and asked me to unload the driver. After this ifconfig -a did not show the interface.

How can this be solved?

[Barburo]

@dogone
I too have a purpose-built script of simple commands that will always get my bcm43xx connected (it's for WEP). Sometimes I need to try multiple times. I use it because it works. B.
http://murga-linux.com/puppy/viewtopic. ... 8&start=45

[mawebb88]

Similar to dogone I have not had any success with the Network wizard in Puppy 4.1. (my apologies to Dogual and all).

Its the second time I have had to resort to make my own script (for 4.1) and putting a link to this in the Startup folder (see http://www.murga-linux.com/puppy/viewtopic.php?t=34184 re my solution for a USB stick install for a Acer Aspire 5100).

I just bought a Eee PC901. I took the stick I had previously made for my Acer Aspire 5100 laptop. It booted fine (press Esc during booting to get the boot device menu). But although I did not have the same problems as with the Acer laptop (never could get WiFi scanning in the wizard to work) I could not get it connected to my home WiFi no matter what I tried, be it DHCP or fixed. I monitored what what was happening with both ifconfig and iwconfig and it would not get a IP address from my routers DHCP server. In the end I cleared all profiles in the the Network wizard and decided to script the connection (like I resorted to on the Acer).

So make a file as below. Made is executable and put links(2) to it in the Startup folder:

Code: Select all

# For Mike's AP using USB stick or SD card on Asus Eee PC901
# For some reason this seems to take running twice to get it to work. Hence 2 links in the Startup folder
iwconfig ra0 essid AAA
iwconfig ra0 mode managed
iwconfig ra0 key xxx
iwconfig ra0 ap yyy
iwconfig ra0 channel 12
ifconfig ra0 192.168.1.239 netmask 255.255.255.0 broadcast 192.168.1.255
route add default gw 192.168.1.1
sleep 1
iwconfig ra0 key open

For some reason even using his I could not get the ESSID and Key to stick without running this twice. So I just make 2 links to the same script in the Startup folder. I know also there is some odd things in the script but I don't care as it works. For example putting the "open" in the same line as where I specify my key does not work hence a separate line.

Now it works perfectly. Installed it also on a SD card (SDHC 4G) copied my save file from the USB stick to the SD card and its working great without anything sticking out of the sides.

Mike

[Dougal]

Auto-dhcp does not work, even though it reports success; my adsl
modem is 10.0.0.2 but eth0 ends up with a 169.xxx.xx.xx address which
varies in the last three numbers. So I must set eth0 to a static IP.

The problem with dhcpcd is that even if you run it on an interface that's not plugged
in to anything it will return success and daemonize (probably expecting you to plug in at some later stage)... it seems to return an error only when there's a problem
with the actual HW/module.
You could try running dhcpcd on that interface manually (with the "-d" option) and see what
kind of messages it gives you.

if I then try to set eth0 (Network Wizard test shows an
available live network, OK) to static IP=10.0.0.13, netmask=255.0.0.0,
default gateway=10.0.0.2, DNS1=10.0.0.2, DNS2 not set,
and then try to ping 10.0.0.2, I get an error dialog box:
Could not set default route through10.0.0.2.
Note that Puppy has tried to do this:
route add -net default gw 10.0.0.2 dev eth0
route: SIOCADDRT: Network is unreachable

As I mentioned when I first added the support for multiple interfaces, I don't really
know anything about all these route commands and they might very need updating.

The original code (from Rarsa, I think) had the commands without the "dev" part,
so you just added items, regardless of which interface you were configuring.
Then I saw some script tempestuous posted where the "-net" was added before the "default"
and where the "dev" was used (or did I see that one in the man page?) and I figured
it might be the right thing to use if we're doing multiple interfaces. Which might
be wrong.
I just configured my eth0 with the wizard to the same settings as yours and it worked ok.
Then I configured wlan0 as static with similar info (10.0.0.2->10.0.03 etc.) and
it also configured ok -- and just overwrote the routing table:
iproute output changed from

Code: Select all

10.0.0.0/8 dev eth0  src 10.0.0.13 
default via 10.0.0.2 dev eth0 

to

Code: Select all

10.0.0.0/8 dev wlan0  src 10.0.0.12 
default via 10.0.0.3 dev wlan0

After that, "route add default gw 10.0.0.2 dev eth0" gave me an error, but
"route add default gw 10.0.0.2" didn't -- it just added it for wlan0:

Code: Select all

sh-3.00# iproute 
10.0.0.0/8 dev wlan0  src 10.0.0.12 
default via 10.0.0.2 dev wlan0 
default via 10.0.0.3 dev wlan0

Maybe I need to remove the "dev" part from the end? I just tried that and
configured eth0 with 4 at the end of all addresses and it worked:

Code: Select all

iproute 
10.0.0.0/8 dev wlan0  src 10.0.0.12 
10.0.0.0/8 dev eth0  src 10.0.0.14 
default via 10.0.0.4 dev eth0 
default via 10.0.0.2 dev wlan0 
default via 10.0.0.3 dev wlan0 

So I guess that will stay that way... but I still don't really understand why it
is that way -- I really have no idea about all this routing busyness.

Also, I would suggest, for the sake of logical consistency, change the subdir name from
/etc/network/network-wizard/network
to
/etc/network/network-wizard/wired

The reason for those names is that those directories were originally just in /etc,
but it turned out /etc/network is a file in other distros...
Anyway, the "network" directory does not contain wired networks only -- it contains
all of them (the "wireless" directory contains extra info for wireless).

[Dougal]

Dougal, do you plan to localize the wizard?

Good question... I thought about it a while ago, but things were changing very
quickly, so I delayed it.

The problem is that it might not be very easy: not only are there lots of messages
that are used, but there are messages that include in them variable expansion,
so it might be a little complicated (maybe the messages should be replaced with
subshells where the message is echoed??).