SOLVED: pcmcia service start problem

[maverick]

Here is a pretty good document.
 
http://www.oreillynet.com/pub/a/wireless/2001/03/06/recipe.html
 
maverick

maverick <class51600 at yahoo.com> wrote:
Hey Josh I have not mess with it a lot, I just started last night but it appears that my default installation has recognize the pcmcia card I have. I did a iwconfig and got this;

eth0 IEEE 802.11-DS ESSID:"linksys" Nickname::Prism I"
mode:Managed Frequency:2.437GHz Access Point: 00:0C:41:82:XX:XX
Bit Rate:11Mb/s Tx-Power=15 dBm Sensitivity:1/3
Rety min limit:8 RTX thr:off Fragment thr:off
Encryption key:off 
Power Management:off
Link Quality:20/92 Signal level:-101 dBm Noise level:-144 dBm
Rx invalid nwid:0 Rx invalid crypt:183 Rx Invalid misc:0 Missed 
beacon:0

I have not been able to get an address yet and I think it's because of the line that says
Encryption key:off
but I put the encryption key in.

Any suggestions would be greatly appreciated.

maverick

Joshua Penix wrote:
Tracy R Reed wrote:

> It's a bug in redhat's scripts. I should have suspected that module names
> shouldn't have .o's on the end. Funny this bug was known back in June of
> 2003 and it's still in Fedora Core 1.

Awesome, thank you for finding that.

I just took a look at the script in question, and you've helped me 
answer my other question - "How is it that the script worked perfectly 
before I installed wlan-ng, but as soon as I did a 'make install' it 
broke?" I was looking all over the computer for things that the wlan-ng 
changed on install (even read the output of install line by line), but 
couldn't find anything.

Reading that script gave me my clue - it seems that the pcmcia script 
will look in one of *two* places for its modules:

1) /lib/modules/`uname -r`/pcmcia
2) /lib/modules/`uname-r`/kernel/drivers/pcmcia

There's a bash 'if' structure which interestingly has the bug you refer 
to only if it follows path #1, but not path #2. In a default Fedora 
install, path #2 is where the modules are found, and the #1 directory is 
nonexistant, so the bug is never triggered. Upon installing the wlan-ng 
drivers from source, they create the #1 directory and the script winds 
up switching to look there, at which point it executes the buggy 
modprobe statements and throws the error.

Of further interest to you, I managed to indirectly solve the problem 
another way - by creating RPMs using the .src.rpm for Fedora found here:
http://prism2.unixguru.raleigh.nc.us/

Here's the procedure I used:

1) Prep /usr/src/linux as you did for the manual install by symlinking 
linux-2.4 to linux and running a make dep (although I noticed that the 
RPM build will do the 'make dep' for you if you forget). Also note that 
Fedora kernel sources seem to have their EXTRAVERSION set to 
"-1..nptlcustom" which causes modules to be built for the "wrong" 
kernel and put in the wrong directory in /lib/modules. Just be sure to 
remove 'custom' from the end of that setting in /usr/src/linux/Makefile.

2) Download the .src.rpm from here:
http://prism2.unixguru.raleigh.nc.us/kernel-wlan-ng-0.2.1-pre14.src.rpm

3) The .spec file in that source RPM requires three definitions to be 
done via the command line. So your rpmbuild line will look like this:

rpmbuild --define="pcmvers 3.1.31" --define="linvers `uname -r`" 
--target i686 --rebuild /path/to/kernel-wlan-ng-0.2.1-pre14.src.rpm

Let that puppy run for a few minutes and then you'll have a complete set 
of linux-wlan-ng drivers waiting for you in /usr/src/redhat/RPMS. 
Install those and they'll automatically set up their init scripts and 
restart the PCMCIA services for you.....

...wait a minute - won't PCMCIA break upon install, as was found above 
with the source install? Nope! Turns out that the .spec author told 
the RPM modules to build for install in path #2 from above - the one 
that doesn't trigger the init script bug. :^)

Ok, well I'm at peace again with my machine, since it's no longer doing 
inexplicable things. Thanks for digging up the bug in that script. You 
say that it's been known since June of '03 - are you referring to the 
date of that email, or did you also find a Bugzilla report? If not, 
I'll go ahead and submit one (unless you'd like to) just so we can be 
sure FC2 won't have the same issues.

--Josh



mav
CAD Systems Administrator
Analog Devices
California Traffic the only bad thing in this state.
Our Officials and CAL-TRANS don't care.
San Diego is not like LA it is LA look at I15.

---------------------------------
Do you Yahoo!?
Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes


mav
CAD Systems Administrator
Analog Devices
California Traffic the only bad thing in this state.
Our Officials and CAL-TRANS don't care.
San Diego is not like LA it is LA look at I15.

---------------------------------
Do you Yahoo!?
Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes