Hello, struttthatstuff, gd2shoe (*poke*), and all.
In case this link hasn't already been posted, here's a great ndiswrapper guide:
http://www.linuxquestions.org/linux/...Ultimate_Guide
What version of Linux are you using? Ubuntu? Debian? Slackware? Fedora? Suse? There are a LOT of them, so if you're not sure, please post the output of this command (in a terminal window):
Code:
cat /etc/lsb-release
Most likely (depending on your distribution), this will tell you the full name and version of the Linux distribution you are using. We will need this information in order to help you with the more specific details of how to get your wireless stick to work. If that command gives you an error, post that error here, and also give us the output of this command:
That will help us to figure out which distro you're using if the first command doesn't help.
The link I gave you is specific to Ubuntu, so there are probably some commands/steps in it that won't work unless you are using Ubuntu (preferably a very recent version of it). There are, however some very generic tips that I can give you about how ndiswrapper works, that you may find helpful.
1) Ndiswrapper is a sort of "container" for Windows drivers (.inf, .sys, and sometimes .bin files) that will tell the Linux kernel how to understand what the driver is trying to do, and how it's supposed to do it.
2) Instead of loading the Windows driver directly with something like 'modprobe myhardwaredriver.inf', you will need to "encase" the Windows driver in Ndiswrapper and load Ndiswrapper (using something like 'modprobe ndiswrapper') with the Windows driver inside it. This is what most instructions and HOW-TOs on the subject focus on.
3) WINE will most likely be of NO HELP WHATSOEVER. WINE is just a compatability layer that allows the Linux kernel, libraries (such as all the .so files in /usr/lib), and executables (like what is in /usr/bin) to communicate with Windows libraries and executables, such as files ending in ".dll" or ".exe". The Windows program, such as a game or office application, will ask the operating system (which it thinks is Windows) for somelibrary.dll, and expect that library to do certain things, a certain way. WINE basically acts as a translater for those programs, fetching equivilent functionality from the Linux system, and translating that functionality into "Windows language." The problem with using this for a driver, is that the driver needs to work directly with the Linux kernel (possibly through a wrapper, such as Ndiswrapper), whereas anything you run with WINE is NOT ALLOWED to work directly with the Linux kernel. WINE will, in that case, just get in the way.
4) All that being said about WINE, there is one possible use for it when installing Windows drivers, only if you can't do this using native Linux tools: if the driver files come packed in a .msi, .exe, or some other Windows-specific package, then, in some cases, you can use WINE to decompress that package so that you can get to the files inside of it. This is usually a hassle, involving finding the temporary directory where Windows/WINE stores the decompressed files during installation, somehow making sure they aren't deleted when the program/package file stops running, and then sifting through all the mess to find what you want. Sometimes, WINE can't even run the package files properly, as you seem to be experiencing. ONLY ATTEMPT THIS METHOD AS A LAST RESORT! It really is a pain, and there are much less painful methods of getting to most Windows-packaged files, such as cabextract, unshield, unzip, unrar, etc., all of which work natively (properly) in Linux on almost all Windows driver packages. In fact, WINE usually uses these tools to extract stuff anyway.
5) Once you are able to get Ndiswrapper to load the driver into the Linux kernel, you will need to somehow make it load at startup, when you boot up your machine. There are several methods for doing this, which we can talk about when we know what distro you're using.
Here is another thread that deals specifically with your device (again, on Ubuntu). You should pay special note to the chip(s) that your device uses, as they are much more important to getting Ndiswrapper and the device to work than the product's brand or model number. In this case, a Ralink 2870 chip is being used in the USB device, which required a native Linux driver (specifically, rt2800usb) to be "blacklisted" (disabled), so that it wouldn't keep trying to load its broken driver code and prevent Ndiswrapper from doing its job. In order to make sure we are looking at the right chip, here, please type the output of this terminal command, while you have the USB device plugged in (after having it plugged in for at least 10 seconds):
Code:
sudo lsusb
[type your user's password]
Or, if that doesn't work, try this:
Code:
su
[type your root password]
lsusb
This should tell you about all the USB devices currently attached to your computer. We will need this information to make sure we're trying the right steps for your device.
Hope that helps, and get back to us soon.
--Dane
