The appropriate module did not load at bootup. However, I did something that I have resorted to in the past with PCMCIA and SD cards -- unplug and replug. This generated a kernel hotplug event and the correct module loaded, in fact a hole heap of them:
arc4, ecb, crypto_blkcipher, rt61pci, rt2x00pci, rt2x00lib, rfkill, input_polldev, crc_itu_t, mac80211, cfg80211
I was then able to run the Network Wizard and get online.
So, the big question, why didn't the module load at bootup? /etc/rc.d/c.modules loads yenta-socket.ko module and this makes the PCMCIA cards available. I did some investigation on my laptop, and as soon as the PCMCIA wifi card becomes available, that is recognised by the kernel, this directory appears:
What is supposed to happen, is when the kernel detects new hardware, it creates the new entry in /sys and also generates a uevent. This does work correctly when I hotplug the card, and the uevent is this:
add@/devices/pci0000:00/0000:00:1e.0/0000:0a:09.0/0000:0b:00.0 ACTION=add DEVPATH=/devices/pci0000:00/0000:00:1e.0/0000:0a:09.0/0000:0b:00.0 SUBSYSTEM=pci PCI_CLASS=28000 PCI_ID=1814:0302 PCI_SUBSYS_ID=1186:3C08 PCI_SLOT_NAME=0000:0b:00.0 MODALIAS=pci:v00001814d00000302sv00001186sd00003C08bc02sc80i00 SEQNUM=2005
At bootup, rc.modules runs 'udevtrigger' which parses /sys and makes the kernel generate all the uevents. This does load yenta-socket. However, what I found is that the above directory does not appear until several seconds later. What is really bad though, is that when it does appear, the kernel ignores it and does not generate a uevent. Nothing on dmesg either.
Well, the kernel itself has created that directory, so it must know the new hardware has become available. So why does it not then generate the uevent? Mighty strange.
I think that this is an old problem. I tested with Puppy 3.01 and it too does not load the module at bootup. It also did not load the module when I did a replug. But I manually loaded rt61 module and the wlan0 interface became available.
I have had trouble previously with pluggable devices where I have had to replug them after bootup. Not just with Puppy4, earlier puppies too. I don't know how else to interprete this, but as a fault in the kernel.
Anyway, the above outlines the problem. I thought that it would be a good idea to document it. I went to bed last night very mystified, woke up this morning and immediately lots of possible solutions came to mind and I rushed to my desk to write them down. Workarounds really, not a solution for the fundamental problem with the kernel. I'm going to see if I can fix it today.
Comments:Posted on 20 Jun 2008, 22:04 by prehistoric2
a class of problems
This is typical of a whole class of problems with PCMCIA. Here's something I've tested carefully on 3.01, but not on 4.00. My Dell Latitude D600 is set up to use a "smart card", but I don't have the password, so I cannot boot from one. This security measure is built into the BIOS. My natural response was to boot from CD, then use a CF module to store my sessions. This fails, even though Puppy has complete control of the machine, because a PCMCIA module is not loaded in time to read pup_save.2fs. It is available after boot up, even if I take no special action, so something causes the necessary modules to load, but not at the right time. I've also had PCMCIA wifi cards which failed the way you describe. I solved that problem by replacing a mini-pci card instead.
Posted on 20 Jun 2008, 23:09 by tempestuous
encryption, & ifconfig
Barry it's great that you have a successful interface and connection with the new rt61pci module ... but encryption has been the sticking point. Can you enable encryption at your router and test an encrypted connection?
Regarding your earlier question about the value of "ifconfig <interface> down" in the Network Wizard, generally network interfaces need to be up while configuring and running dhcpcd.
I think I have seen reference that the DHCP client application, dhclient, requires a "down" interface, but that doesn't affect Puppy.
And I have seen rare references in the past to certain wifi drivers (zd1211?) which needed to be configured with the interface down.
This now has me thinking - if encryption continues to be a problem under the 2.6.25 kernel, maybe we should try taking down the interface prior to running iwconfig or wpa_supplicant?
If a successful connection can be established in this "down" state, it would then probably be necessary to bring the interface up before running dhcpcd.
Posted on 21 Jun 2008, 9:42 by BarryK
Re: interface down
yes, i'll leave it 'up' in rc.network, and leave it to the Network Wizard to do a 'down' as required. I think in dogone's case, his /etc/eth0mode has a ifconfig line in it that first requires the interface to be down. So, we need to identify these cases and get the Wizard to insert 'ifconfig <interface> down' where appropriate.
Note, later today or tomorrow I plan to put urban soul's patch into the Wizard, so I'll upload it then anyone who wants to hack on the Wizard will be using the latest. Otherwise, it can get into a synchronisation mess. I'll post to the blog as soon as I've done that.