I got to install the ipw3945 properly, but I do not know how to start it on boot. To activate my wireless now, I would need use this script that came with the driver, each time i reboot the machine.

I was wondering if there is a way to use that script when my machine is booting up automatically.

Using Slackware 12 on a Dell E1505 with the ipw3945 wireless card I did the following:

I built the driver using the source supplied with Slackware 12.

I created a text file in /etc/rc.d called rc.netdevice and added the following line to it:

/sbin/modprobe ipw3945

Then I moved the load and unload scripts to /etc/rc.d directory and renamed them rc.ipw3945d-start and rc.ipw3945-stop (not required, but more descriptive than load and unload). Make sure these are executable:

chmod +x /etc/rc.d/rc.ipw3945-start
chmod +x /etc/rc.d/rc.ipw3945-stop

Then I edited the /etc/rc.local script to contain the following:
Then I created a script in /etc/rc.d called rc.local_shutdown and added the following:
make sure it's executable:

chmod +x /etc/rc.d/rc.local_shutdown

That takes care of the daemon and the module at boot.

HTH

I'm gunna try that out today, also another note the ' modprobe ipw3945 ' does not work for me it says " FATAL: Module ipw3945 not found. "

But the scripts work for me for activating the wireless. I'm able to use the internet without the modprobe.

When you built the driver, did you run "make" and then "make install" or just "make"?

I think "make install" is required to put the new module where modprobe can find it. Otherwise, the scripts will work to load the module, but only if you run them from within the directory where you built it.

Look in /lib/modules/2.6.21.5-smp/kernel/drivers/net/wireless. [0]

If the ipw3945.ko module is not there, then you will need to run "make install" as root from within the directory where you ran the make command to build the module.

[0] Replace the <2.6.21.5-smp> with whatever kernel you are running if not that one.

HTH

well I found out something interesting apparently I did not install the driver to the folder, the reason I was able to activate it was because it was in the same source folder where it had the driver.

I used checkinstall to install the driver. Was using checkinstall a bad idea to use?

Are you using slackware 11 or 12?

I'm guessing 11 because 12 does not come with a functional checkinstall - unless you installed it on your own from source - and I'm not even certain that's possible yet. I don't use checkinstall any longer so I may be out of the loop on that.

Regardless, checkinstall is not how I would do this. You're building a kernel module - not a program. That does nor mean it can't be done that way. I just would not go that route.

That being said, there are build scripts available at slackbuilds.org which I used for this driver with slackware 11. If you are using 12 and a recent kernel, then the method I outlined is, in my opinion, easier. You will find the source in /extra/source/intel-wlan-ipw3945.

Read the README's - good info. You can use the kernel's ieee80211 with the newer kernels.

HTH

I did make install and the modprobe worked, so checkinstall should be use to install programs?

Checkinstall is a nice tool that creates a slackware package from source. Building from source is usually done by:

./configure
make
make install

This works fine, but you loose the ability to (easily) manage installs, uninstalls, and upgrades.

If you install checkinstall and do:

./configure
make
checkinstall

Then a slackware package is created, foo.tgz, which can be installed using the slackware package management tools.

So to answer your question, checkinstall makes a slackware package from a program's source that can then be installed using the slackware package management tools. Checkinstall is only one means by which a slackware package can be created. Many people use "slackbuild scripts". www.slackbuilds.org is a growing repository of these scripts. Browse the site and do some reading to learn about that method of building packages.

The reason that checkinstall did not work for this module is that there was no configure routine used. This is where the install location, among other options, would be specified. So, this is not a situation that would lend itself to checkinstall, but a package could be created using a slackbuild script that defined how the module should be installed.

This explanation may not be entirely accurate, but hopefully it is close enough for the purposes of this thread.
If not, I'm sure I will hear about it from someone.

HTH