Improved Network Wizard (and rc.network)

[Dougal]

In latest version, today's latest... 4.1 Beta: puppy-4.1retro-beta-408-k2.6.21.7-seamonkey.iso

The wizard does not even see the LAN connection.

I can unload the module, and reload... as the hardware has been detected...by the initial load of Puppy from the CD. The system sees the hard wired PCI lan... but not the wireless. (processes shows zd1211rw running, as well as USB shows the hardware)

Whether the wizard finds your interface depends entirely on the output of "ifconfig -a", so if you could open a terminal and run it and see if the interface is listed or not, it will tell us where the problem lies.

- If the interface is listed: please post here the output, so I can try and see why the wizard doesn't detect it.

- If it is not listed: the problem is at the level of the kernel.
What you can do in this case:
1) In a terminal, run

Code: Select all

dmesg > dmesg-output

then open the file (/root/dmesg-output) in a text editor and look foe any messages related to zd1211rw -- maybe it has some problem with your device.
2) While running 2.17, try to find out the device/vendor IDs for your device.
2.17 should have the lsusb command, which should show your device. I'm interested in the pair of 4 hex chars (0-9a-f) numbers: 1234:5678 (should be the second field in the output, I think)
Another option is to look at the file /proc/bus/usb/devices and look for the block related to your device. You can find it by searching for the module name or by finding the device name (though not all devices give them), then try and find the vendorId and deviceId numbers.

[inoxidabile]

Hi Dougal!
I would send You some note.
It's the first time I try to partecipate to any community, so please be patient - I'm a very newbie!
Barry Kauler suggest to send to You about this topic, so here I am!
I'm very happy with 3.01, because it's incredible easy, quick and stable.
I use two type of wifi adapter,but mainly I use a 3Com usb that matches perfectly with zd1211rw - wpa/tkip and supplicant.
I tried EVERY new version after 3.01, but without success -let me add that I have tried on two notebook and two desktop.
It's strange, it seems that the right module has been loaded but any setup allow the connection - and, more or less, all Puppy version, give the same bad result.
As suggested by barry, I have attached some info trying to send You as many data as I can.
I'm not able to frequently see the blogs, so can You kindly tell me if there is any need of other infos?
Thank You in advance and for all the great work has been done for the great puppy!
Hoping to be useful...
Best Regards

inoxidabile

[Dougal]

I have reported a strange network wizard problem in the 4.1b1 thread. It thinks my Ricoh xD Picture card is an ethernet card. I believe it is actually not a network wizard problem, but something to do with differences in how the lspci command works, but I told Barry I'd report the problem here nonetheless. BTW, is the wizard different between 4.1a7 and 4.1b1? It didn't do this in a7...

SSB stands for Sonics Silicon Backplane.
The kernel documentation says to enable it only if intended for an embedded machine that has such a port, but it is automatically turned on when the b44 module is enabled.
I'm not sure about that b44 module... guess it might be needed, but this mess needs a little more looking into. (I'm quite sure OHCI_HCD_SSB shouldn't be enabled -- not sure if it is in the Puppy kernel)

In any case, with regards to the Ricoh card, since the kernel recognizes it as an ethernet card there's not much I can do... it should probably be reported as a kernel bug.

On a separate issue, wasn't b43legacy supposed to be one of the modules available to load? I think it is in there as (at least in a7) you could load it via the boot manager, but the network wizard still does not show it.

The list of modules to load is generated from /etc/networkmodules... so that's what's responsible for any problems.

[Dougal]

4.1 beta 1 is unchanged from alpha7 (407) in that it forgets the manually entered static IP and gateway addresses after a boot or power cycle. The manually entered DNS address is not forgotten. This problem has been reported by others using post-406 Puppies and may be unique to the use of static addressing. See attached hardware report.

What kind of messages do you get in /tmp/bootsysinit.log? I need to know if there is a problem with the startup code configuring it. (note that even after boot, you can use the "autoconnect to ethernet" option when right-clicking the "Connect" icon, then find the output in a log file in /tmp)

1. Despite write-protecting the correctly configured /etc/network-wizard/network/interfaces/[mac address] file, the Set Static IP dialog came up with both IP and gateway addresses reset to zeros.

If I recall correctly, the dialog gets its values from the output of "ifconfig $INTERFACE", rather than the config file.

2. The module for my NIC (8139too) loads at boot but eth0 is not recognized until Net Wizard is run.

Do the messages in /tmp/bootsysint.log not mention it at all?

[Minnesota]

Hope the attachments will help, it looks like part of the issue may be missing module name in ..../usb/devices in the new beta version.

In the file is the output from dmesg beta 408 as well as from 2.17

Also the usb device information... inside that file I added USB and PCI module information.

If I can look elsewhere please tell me. I assume if I performed a load to a stick or hard drive the /usb/devices file can be modified...

Thanks for all your efforts with Puppy... it is very interesting and I am more that willing to assist in any way. Been reading the forums for quite some time... and slowly learning .

THANKS!

PS, could not locate lsusb. Hope what I sent will give you the information.

[BarryK]

I have reported a strange network wizard problem in the 4.1b1 thread. It thinks my Ricoh xD Picture card is an ethernet card. I believe it is actually not a network wizard problem, but something to do with differences in how the lspci command works, but I told Barry I'd report the problem here nonetheless. BTW, is the wizard different between 4.1a7 and 4.1b1? It didn't do this in a7...

SSB stands for Sonics Silicon Backplane.
The kernel documentation says to enable it only if intended for an embedded machine that has such a port, but it is automatically turned on when the b44 module is enabled.
I'm not sure about that b44 module... guess it might be needed, but this mess needs a little more looking into. (I'm quite sure OHCI_HCD_SSB shouldn't be enabled -- not sure if it is in the Puppy kernel)

In any case, with regards to the Ricoh card, since the kernel recognizes it as an ethernet card there's not much I can do... it should probably be reported as a kernel bug.

On a separate issue, wasn't b43legacy supposed to be one of the modules available to load? I think it is in there as (at least in a7) you could load it via the boot manager, but the network wizard still does not show it.

The list of modules to load is generated from /etc/networkmodules... so that's what's responsible for any problems.

Well, not really....
I already posted what is in /etc/networkmodules. It is up to the Wizard to read this, and show b43legacy as one of the choices. Reiterating what I already posted:

The Wizard might have to be upgraded to show these modules properly. /etc/networkmodules in 4.1beta has these entries:

b43legacy "ssb: Broadcom B43legacy wireless driver"
b43 "pcmcia: Broadcom B43 wireless driver"
b44 "ssb: Broadcom 44xx/47xx 10/100 PCI ethernet driver"
bcm43xx "pci: Broadcom BCM43xx wireless driver"

Regarding the the Wizard showing the Ricoh card description, this is not in /etc/networkmodules, so the Wizard script is getting it from somewhere else. Therefore there is a bug in the Wizard.

[PaulBx1]

Uh, before we get into a pissing match (old US computer support terminology ) I wonder if someone could comment about an oddity I found with the lspci command:

I compared the lspci commands in the two revisions. Interestingly, there IS a difference in output.

Here are the 3 relevant lines from alpha7 - oops, I mean beta1 retro:

Code: Select all

02:09:2 Class 0880: 1180:0843 (rev 12)
02:09:3 Class 0880: 1180:0592 (rev 12)
02:09.4 Class ffff: 1180:0852 (rev ff)

Here are the two corresponding lines from beta1 RETRO - that should be alpha7:

Code: Select all

02:09:2 Class 0880: 1180:0592 (rev 12)
02:09:3 Class 0880: 1180:0852 (rev 12)

Notice how the device numbers are shifted. I suspect the problem is related to that. Is this a kernel problem?

Doesn't the network wizard depend on lspci, so if lspci puts out strange stuff, so will the wizard?

[Dougal]

Well, not really....
I already posted what is in /etc/networkmodules. It is up to the Wizard to read this, and show b43legacy as one of the choices. Reiterating what I already posted:

The Wizard might have to be upgraded to show these modules properly. /etc/networkmodules in 4.1beta has these entries:

b43legacy "ssb: Broadcom B43legacy wireless driver"
b43 "pcmcia: Broadcom B43 wireless driver"
b44 "ssb: Broadcom 44xx/47xx 10/100 PCI ethernet driver"
bcm43xx "pci: Broadcom BCM43xx wireless driver"

But all the wizard does is read that list and reformat it. It doesn't even check for the pci:/usb:/pcmcia: part.
I updated my networkmodules file to include those modules and the wizard listed them properly.

BTW: in modules.alias, b43 has one pcmcia entry and a bunch of ssb entries, so maybe it should be listed as ssb?
This ssb business is really not clear to me: the base ssb module (ssb.ko) contains inside it some b43legacy module -- pci-to-ssb or something -- so I really don't see how it all works.

Regarding the the Wizard showing the Ricoh card description, this is not in /etc/networkmodules, so the Wizard script is getting it from somewhere else. Therefore there is a bug in the Wizard.

It probably got it from /proc/bus/usb/devices.

[Dougal]

I compared the lspci commands in the two revisions. Interestingly, there IS a difference in output.

The alpha7 lspci has an entry, "02:09.4 Class ffff: 1180:0852 (rev ff)" that is simply missing in the beta1 lspci. Actually, the difference between the two is more complex than that. Here are the 3 relevant lines from alpha7:

Code: Select all

02:09:2 Class 0880: 1180:0843 (rev 12)
02:09:3 Class 0880: 1180:0592 (rev 12)
02:09.4 Class ffff: 1180:0852 (rev ff)

Here are the two corresponding lines from beta1:

Code: Select all

02:09:2 Class 0880: 1180:0592 (rev 12)
02:09:3 Class 0880: 1180:0852 (rev 12)

Notice how the device numbers are shifted. I suspect the problem is related to that. Is this a kernel problem?

Yes, that is strange... you should make sure the version of lspci is the same, so we know it's a kernel issue. You can also try using scanpci and see if there's a difference in the output.

You might want to also look at the output of dmesg and maybe at the relevant directories in /sys: look somewhere such as /sys/bus or something, then look under "pci" for the directories named like the first field in the lspci output (02:09:0[23]). A simple way to look at all that's in such a directory is to open a terminal in it (` in rox) and run

Code: Select all

cat * 2>/dev/null

The most interesting file there will probably be the "kevents" (or something with "events", if I recall correctly...), which contains all the info about how the kernel recognized it (which is what udev uses).

Doesn't the network wizard depend on lspci, so if lspci puts out strange stuff, so will the wizard?

No. Puppy doesn't have a full pci.ids file, so the wizard uses scanpci.

[PaulBx1]

Sorry, it was beta1 retro, not beta1.

I don't see how to get the versions of either scanpci or lspci, since there are no switches for that. Barry must know, though.

Here is the scanpci from a7:

pci bus 0x0000 cardnum 0x00 function 0x00: vendor 0x8086 device 0x2a00
Intel Corporation Mobile Memory Controller Hub

pci bus 0x0000 cardnum 0x02 function 0x00: vendor 0x8086 device 0x2a02
Intel Corporation Mobile Integrated Graphics Controller

pci bus 0x0000 cardnum 0x02 function 0x01: vendor 0x8086 device 0x2a03
Intel Corporation Mobile Integrated Graphics Controller

pci bus 0x0000 cardnum 0x1a function 0x00: vendor 0x8086 device 0x2834
Intel Corporation 82801H (ICH8 Family) USB UHCI #4

pci bus 0x0000 cardnum 0x1a function 0x01: vendor 0x8086 device 0x2835
Intel Corporation 82801H (ICH8 Family) USB UHCI #5

pci bus 0x0000 cardnum 0x1a function 0x07: vendor 0x8086 device 0x283a
Intel Corporation 82801H (ICH8 Family) USB2 EHCI #2

pci bus 0x0000 cardnum 0x1b function 0x00: vendor 0x8086 device 0x284b
Intel Corporation 82801H (ICH8 Family) HD Audio Controller

pci bus 0x0000 cardnum 0x1c function 0x00: vendor 0x8086 device 0x283f
Intel Corporation 82801H (ICH8 Family) PCI Express Port 1

pci bus 0x0000 cardnum 0x1c function 0x01: vendor 0x8086 device 0x2841
Intel Corporation 82801H (ICH8 Family) PCI Express Port 2

pci bus 0x0000 cardnum 0x1c function 0x04: vendor 0x8086 device 0x2847
Intel Corporation 82801H (ICH8 Family) PCI Express Port 5

pci bus 0x0000 cardnum 0x1d function 0x00: vendor 0x8086 device 0x2830
Intel Corporation 82801H (ICH8 Family) USB UHCI #1

pci bus 0x0000 cardnum 0x1d function 0x01: vendor 0x8086 device 0x2831
Intel Corporation 82801H (ICH8 Family) USB UHCI #2

pci bus 0x0000 cardnum 0x1d function 0x02: vendor 0x8086 device 0x2832
Intel Corporation 82801H (ICH8 Family) USB UHCI #3

pci bus 0x0000 cardnum 0x1d function 0x07: vendor 0x8086 device 0x2836
Intel Corporation 82801H (ICH8 Family) USB2 EHCI #1

pci bus 0x0000 cardnum 0x1e function 0x00: vendor 0x8086 device 0x2448
Intel Corporation 82801 Mobile PCI Bridge

pci bus 0x0000 cardnum 0x1f function 0x00: vendor 0x8086 device 0x2815
Intel Corporation Mobile LPC Interface Controller

pci bus 0x0000 cardnum 0x1f function 0x01: vendor 0x8086 device 0x2850
Intel Corporation Mobile IDE Controller

pci bus 0x0000 cardnum 0x1f function 0x02: vendor 0x8086 device 0x2829
Intel Corporation Mobile SATA AHCI Controller

pci bus 0x0000 cardnum 0x1f function 0x03: vendor 0x8086 device 0x283e
Intel Corporation 82801H (ICH8 Family) SMBus Controller

pci bus 0x0002 cardnum 0x09 function 0x00: vendor 0x1180 device 0x0832
Ricoh Co Ltd Device unknown

pci bus 0x0002 cardnum 0x09 function 0x01: vendor 0x1180 device 0x0822
Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter

pci bus 0x0002 cardnum 0x09 function 0x02: vendor 0x1180 device 0x0592
Ricoh Co Ltd R5C592 Memory Stick Bus Host Adapter

pci bus 0x0002 cardnum 0x09 function 0x03: vendor 0x1180 device 0x0852
Ricoh Co Ltd xD-Picture Card Controller

pci bus 0x0009 cardnum 0x00 function 0x00: vendor 0x11ab device 0x4354
Marvell Technology Group Ltd. Device unknown

pci bus 0x000b cardnum 0x00 function 0x00: vendor 0x14e4 device 0x4315
Broadcom Corporation BCM4310 USB Controller

Here is that from beta1 retro:

pci bus 0x0000 cardnum 0x00 function 0x00: vendor 0x8086 device 0x2a00
Intel Corporation Mobile Memory Controller Hub

pci bus 0x0000 cardnum 0x02 function 0x00: vendor 0x8086 device 0x2a02
Intel Corporation Mobile Integrated Graphics Controller

pci bus 0x0000 cardnum 0x02 function 0x01: vendor 0x8086 device 0x2a03
Intel Corporation Mobile Integrated Graphics Controller

pci bus 0x0000 cardnum 0x1a function 0x00: vendor 0x8086 device 0x2834
Intel Corporation 82801H (ICH8 Family) USB UHCI #4

pci bus 0x0000 cardnum 0x1a function 0x01: vendor 0x8086 device 0x2835
Intel Corporation 82801H (ICH8 Family) USB UHCI #5

pci bus 0x0000 cardnum 0x1a function 0x07: vendor 0x8086 device 0x283a
Intel Corporation 82801H (ICH8 Family) USB2 EHCI #2

pci bus 0x0000 cardnum 0x1b function 0x00: vendor 0x8086 device 0x284b
Intel Corporation 82801H (ICH8 Family) HD Audio Controller

pci bus 0x0000 cardnum 0x1c function 0x00: vendor 0x8086 device 0x283f
Intel Corporation 82801H (ICH8 Family) PCI Express Port 1

pci bus 0x0000 cardnum 0x1c function 0x01: vendor 0x8086 device 0x2841
Intel Corporation 82801H (ICH8 Family) PCI Express Port 2

pci bus 0x0000 cardnum 0x1c function 0x04: vendor 0x8086 device 0x2847
Intel Corporation 82801H (ICH8 Family) PCI Express Port 5

pci bus 0x0000 cardnum 0x1d function 0x00: vendor 0x8086 device 0x2830
Intel Corporation 82801H (ICH8 Family) USB UHCI #1

pci bus 0x0000 cardnum 0x1d function 0x01: vendor 0x8086 device 0x2831
Intel Corporation 82801H (ICH8 Family) USB UHCI #2

pci bus 0x0000 cardnum 0x1d function 0x02: vendor 0x8086 device 0x2832
Intel Corporation 82801H (ICH8 Family) USB UHCI #3

pci bus 0x0000 cardnum 0x1d function 0x07: vendor 0x8086 device 0x2836
Intel Corporation 82801H (ICH8 Family) USB2 EHCI #1

pci bus 0x0000 cardnum 0x1e function 0x00: vendor 0x8086 device 0x2448
Intel Corporation 82801 Mobile PCI Bridge

pci bus 0x0000 cardnum 0x1f function 0x00: vendor 0x8086 device 0x2815
Intel Corporation Mobile LPC Interface Controller

pci bus 0x0000 cardnum 0x1f function 0x01: vendor 0x8086 device 0x2850
Intel Corporation Mobile IDE Controller

pci bus 0x0000 cardnum 0x1f function 0x02: vendor 0x8086 device 0x2829
Intel Corporation Mobile SATA AHCI Controller

pci bus 0x0000 cardnum 0x1f function 0x03: vendor 0x8086 device 0x283e
Intel Corporation 82801H (ICH8 Family) SMBus Controller

pci bus 0x0002 cardnum 0x09 function 0x00: vendor 0x1180 device 0x0832
Ricoh Co Ltd Device unknown

pci bus 0x0002 cardnum 0x09 function 0x01: vendor 0x1180 device 0x0822
Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter

pci bus 0x0002 cardnum 0x09 function 0x02: vendor 0x1180 device 0x0843
Ricoh Co Ltd Device unknown

pci bus 0x0002 cardnum 0x09 function 0x03: vendor 0x1180 device 0x0592
Ricoh Co Ltd R5C592 Memory Stick Bus Host Adapter

pci bus 0x0002 cardnum 0x09 function 0x04: vendor 0x1180 device 0x0852
Ricoh Co Ltd xD-Picture Card Controller

pci bus 0x0009 cardnum 0x00 function 0x00: vendor 0x11ab device 0x4354
Marvell Technology Group Ltd. Device unknown

pci bus 0x000b cardnum 0x00 function 0x00: vendor 0x14e4 device 0x4315
Broadcom Corporation BCM4310 USB Controller

I used the xfdiff and found the only difference was starting with pci bus 0x0002 cardnum 0x09 function 0x02 (strangely, xfdiff did not display the last 4 lines of these files). Same result as lspci, I'd say. I've bolded those lines.

Note, the actual eth0 is the Marvel card following the Ricoh things.

Those files you mention, the uevent file has permissions "200". If I chmod it to 600, and try to cat it, it gives "Input/output error". In beta1 retro if I cat everything I see the "843" string in there, not the "592" string, in the 02:09:2 device, the first device to disagree.

[Dougal]

Note, the actual eth0 is the Marvel card following the Ricoh things.

Which module does the network wizard list? Maybe it's just getting something wrong when it gets the description from the scanpci output... the fact that the Marvel card entry is just below it seems to hint towards that. (that would happen if /sys/class/net/eth0/device does not point to 0000:09:00.0...)

In any case, regarding the funny listing:
Is the machine you're using a Compaq Presario?
I looked for the pci numbers you got from lspci and all three of them
have subsystem numbers matching one:

Code: Select all

	0843  R5C843 MMC Host Controller
		103c 30b7  Presario V6133CL
	0592  R5C592 Memory Stick Bus Host Adapter
		103c 30b7  Presario V6133CL
		1043 1967  V6800V
		144d c018  X20 IV
	0852  xD-Picture Card Controller
		103c 30b7  Presario V6133CL
		1043 1967  V6800V

(You can see the subsystem numbers by running "lspci -nvv")

There is something that may be related to this, which is worth looking
up: look at the kernel config file and see if MMC_RICOH_MMC is enabled
or not. I was wondering if it might be related.
Here's what the kernel documentation says about it:

This selects the disabler for the Ricoh MMC Controller. This
proprietary controller is unnecessary because the SDHCI driver
supports MMC cards on the SD controller, but if it is not
disabled, it will steal the MMC cards away - rendering them
useless. It is safe to select this driver even if you don't
have a Ricoh based card reader.

So maybe that's why the 843 disappears with the new kernel.

Oh, and the version of lspci/scanpci can probably be got with "--version", or "-V".

[Dougal]

Hope the attachments will help, it looks like part of the issue may be missing module name in ..../usb/devices in the new beta version.

That means the module isn't using that device.

Anyway, that seems simple enough... I hope.
The error you got in dmesg:

Code: Select all

usb 2-6.3: Could not load firmware file zd1211/zd1211_ub. Error number -2
zd1211rw 2-6.3:1.0: couldn't load firmware. Error number -2

means it couldn't find the firmware file: /lib/firmware/zd1211/zd1211_ub
(Error -2 = -ENOENT = No such file or directory)
So you should first check and see if that file exists.
If it does, maybe something is wrong with it, so you should try and download
the latest firmware package from here.
If it still gives an error, it might be a kernel bug (there was some
work on firmware loading in recent kernels), but it's also worth raising
with Barry, as udev is supposed to do the firmware loading, so maybe that
is responsible.
(The usev rules in /etc/udev should have an entry such as

Code: Select all

SUBSYSTEM=="firmware", ACTION=="add", RUN+="firmware.sh"

where firmware.sh is located in /lib/udev/ -- but there might be a different
script assigned to handle it.)

[PaulBx1]

So maybe that's why the 843 disappears with the new kernel.

Sorry, another goof on my part. I got the two lspci reports swapped. The 843 appears with the beta1 retro kernel, compared to alpha7 where it is absent. I corrected my above post.

The computer is a Dell Inspiron 1525.

--version worked (even though not documented in the --help) and for the beta1 retro the lspci is version 2.1.11, same as for alpha7. No luck on scanpci version.

The network wizard in beta1 retro lists the Ricoh xD Picture card controller as eth0.

I don't know where to look up kernel config parameters.

[JustGreg]

I did some testing of the Puppy 4.1 Beta #1 network manager with my WPA2 (Linksys router) wireless network and my desk computer using the RT73usb driver.

With a broadcast SSIB WPA2 wireless network, network manager using dhcpcd client connected with out a problem.

I also checked static IP addressing the broadcast SSID wireless network. It did not work for me. I used the same ip address information that I use with my normal script, which works for a static IP address. Wpa_cli status reported that wpa_supplicant had connected. Ifconfig for the network reported the correct ip address and broadcast address. For the kernel routing tables, I have the same information as the script. Resolv.conf had the same DNS information. I rebooted after trying the script and then trying Network Manager. The only difference from the dhcpc version was "search myISP.com" entry was missing. With the same resolv.conf file, my normal script worked. Here is how I do it in my script:

Code: Select all

echo "Setting Static IP addresses"
 ifconfig wlan0 192.168.1.XXX broadcast 192.168.0.255 netmask 255.255.255.0
 route add default gw 192.168.1.1 wlan0

I do not know what else to try.

Using a network with non-broadcast (hidden) SSID was fustrating. I first tried my
normal script (static ip) with this wpa2.conf file:

Code: Select all

ctrl_interface=/var/run/wpa_supplicant
update_config=0

network={
	ssid="wireless1"
	scan_ssid=1
	psk="mypassphrase"
	proto=RSN
	key_mgmt=WPA-PSK
	pairwise=CCMP
	group=CCMP

}

This worked fine with no problems. Both ping (google and the router) and a browser worked. I also tried the wpa2.conf with ap_scan=0 and removed scan_ssid=1. I was able to connect to the non-broadcast (hidden) wireless network one time. This is where the fustration occurred for me. The second time for ap_scan=0 after a reboot of both the router and desktop computer, no connection was made. Wpa_cli status reported wlan0 as disconnected. With ap_scan=1, no connection was made. A check with wpa_cli status showed the wpa_supplicant was scanning. Using ap_scan=2 failed with the wpa_supplicant in the associating stage. This is the fustration with a hidden network. Sometimes ap_scan value will work and other times it will not. The only reliable way with my normal script was using only scan_ssid=1 (ap_scan was commented out) in the network section of the wpa2.conf file.

Using network manager, I could not make a network connection with any of the possible ssid configurations (driver, hidden or broadcast). With hidden, wpa_cli status as associating. With broadcast, wpa_cli status as scanning. With driver, wpa_cli status as disconnected.

I commented out the lines 998-1008 in wag-profiles.sh as you suggested. I still could not connect to the non-broadcast (hidden) wireless network.

Bottom line, if you use a broadcast SSID wireless network with auto dhcp, you should have no problems. However, a non-broadcast network seems to be problematic.

[Dougal]

I don't know where to look up kernel config parameters.

The config file should be in /lib/modules/ and named DOTconfig something.
Otherwise it will be in /usr/src/`uname -r` and named .config (hidden file), but only when you have the devx module.
You could also try and look in /sys/modules and see if there's a ricoh_mmc directory.

I've just added a line to my previous post, regarding /sys/class/net/eth0/device...

[PaulBx1]

I found it - in /etc/modules.

CONFIG_MMC_RICOH_MMC = "m" in alpha7, "y" in beta1 retro. It seems you've found the problem.

[Minnesota]

You can find modules zd1211_ub in /lib/firmware/zd1211/zd1211_ub

no references in /etc/udev....as near as I can tell.

Since I do not understand when and how SUBSYSTEM== command runs... I tried the code in a terminal window.. nothing happened or appeared to be nothing. Tried the wizard after... same results.

Is there a way to run the "Firmware.sh" commands manually? Just to see if loading will solve the problem?

File search does not find zd1211.sh command any place.


/initrd/pup_rw/lib/firmware/zd1211/zd1211_ub
/initrd/pup_rw/tmp/zd1211_firmware/lib/firmware/zd1211/zd1211_ub
/lib/firmware/zd1211/zd1211_ub
/tmp/zd1211_firmware/lib/firmware/zd1211/zd1211_ub


Out of curiosity why would a copy reside in /tmp ?

Guess I am learning some of the guts .... THANK your for your help and Teaching.

I do not find a specific entry in /etc/udev....but do not understand all the substitutions that take place.

I looked at the dates from http://sourceforge.net/project/showfile ... _id=187875 time is slightly different but date is the same. So assume latest versions. as they are from 2007.

Thanks again.

[BarryK]

BTW: in modules.alias, b43 has one pcmcia entry and a bunch of ssb entries, so maybe it should be listed as ssb?
This ssb business is really not clear to me: the base ssb module (ssb.ko) contains inside it some b43legacy module -- pci-to-ssb or something -- so I really don't see how it all works.

I don't know anything about ssb so I'm probably more confused. In the case of b43, running 'modinfo b43' all the alias lines have 'ssb:' so I would be inclined to take that as the authoritative information.

[BarryK]

Sorry, it was beta1 retro, not beta1.

I don't see how to get the versions of either scanpci or lspci, since there are no switches for that. Barry must know, though.

The version of lspci used in Puppy is very old, hasn't changed for ages. That was due to a change in the output format of lspci, and I never upgraded it to avoid breaking scripts. The package is pciutils and it is version 2.1.11.

As for scanpci, that comes with Xorg. Um, 3.01 has Xorg 7.2, 4.x has Xorg 7.3.

[BarryK]

Hope the attachments will help, it looks like part of the issue may be missing module name in ..../usb/devices in the new beta version.

That means the module isn't using that device.

Anyway, that seems simple enough... I hope.
The error you got in dmesg:

Code: Select all

usb 2-6.3: Could not load firmware file zd1211/zd1211_ub. Error number -2
zd1211rw 2-6.3:1.0: couldn't load firmware. Error number -2

means it couldn't find the firmware file: /lib/firmware/zd1211/zd1211_ub
(Error -2 = -ENOENT = No such file or directory)
So you should first check and see if that file exists.
If it does, maybe something is wrong with it, so you should try and download
the latest firmware package from here.
If it still gives an error, it might be a kernel bug (there was some
work on firmware loading in recent kernels), but it's also worth raising
with Barry, as udev is supposed to do the firmware loading, so maybe that
is responsible.
(The usev rules in /etc/udev should have an entry such as

Code: Select all

SUBSYSTEM=="firmware", ACTION=="add", RUN+="firmware.sh"

where firmware.sh is located in /lib/udev/ -- but there might be a different
script assigned to handle it.)

That firmware file is in the "firmware tarball", so do check that you have it at /lib/firmware/zd1211/zd1211_ub.
If you do, and it isn't loading... then I don't know.

In pup 4.1, the udev rule is:

Code: Select all

SUBSYSTEM=="firmware", ACTION=="add", RUN+="/sbin/pup_event_backend_firmware"

Hmmm, I wonder. This is the content of pup_event_backend_firmware:

Code: Select all

      fndFIRMWARE="`find /lib/firmware -type f -name ${FIRMWARE}`"
      if [ "$fndFIRMWARE" != "" ];then
       echo 1 > /sys$DEVPATH/loading
       cat "$fndFIRMWARE" > /sys$DEVPATH/data
       echo 0 > /sys$DEVPATH/loading
      else
       echo -1 > /sys$DEVPATH/loading
      fi

If that $FIRMWARE is 'zd1211/zd1211_ub' and not just the name of the firmware file, that's going to stuff up the 'find' operation, isn't it?

Maybe I should change the code to:

baseFIRMWARE="`basename $FIRMWARE`"
fndFIRMWARE="`find /lib/firmware -type f -name ${baseFIRMWARE}`"

the original idea of the 'find' operation was in case the firmware was located in some other place inside /lib/firmware than the driver expected.

...Minnesota, could you give this a go?

EDIT:
That is, open up /sbin/pup_event_backend_firmware in a text editor and insert the 'baseFIRMWARE' line and replace the 'fndFIRMWARE' line, save, then reload the module -- I think all you would need to do is unload it if it's currently loaded, then load it:
# rmmod zd1211rw
# modprobe zd1211rw
...then see if the firmware is found and loaded.