I have downloaded the following file from the D-Link site:
dwa140_BETAdriver_1201.zip
I’ve copied it to a dvd, and have placed the dvd in my openSUSE machine. I’ve made several attempts at installing this myself, but Linux has me a bit stumped. Could someone help?
I am pretty sure there was more output if you actually used the script as explained on its HP, especially the txt-file which is automatically generated.
It most likely does, but before having the USB-ID of your device posted here, I would not touch it.
Still, I am not keen on guessing, if you don’t want to post the data of the script, fine, then unpack the zip-file (i.e. unzip on command line) read the instructions provided in the zip file and good luck.
And for people reading this thread: If the “model” is really DWA-140 and D-Link does not change chipsets on the same “model” (as they did with other devices) it’s a rt2870-chip and supported by recent linux kernels (but the OP didn’t even tell us which version of openSUSE he uses).
The link Akoellh gave you starts with the most basic. You’re assuming you need a driver from the d-link site when in fact it’s most probable you don’t. The driver you’re downloading is source code. If you don’t know how/where to unzip the file, you would definitely have issues compiling it.
Please post the output of the command
And even with that information only, there is not much to do before the most basic stuff is posted, i.e. kernel version, version of distribution etc.
The script takes care of all that, there are detailed instructions and I do ask users to use that script for a good reason.
It will not only give a lot information, it does also give detailed hints on how to fix very common problems and even if it fails (nobody’s perfect) it will give me enough input to contact the author in order to fix little bugs or improve its workflow.
There are quite a few threads -recent ones- here and in Network/Internet, where I know the script would catch what’s wrong as it is even obvious from the minimal output helpers asked (instead of linking the script), fun thing though, they asked for output, got the output and then don’t get the clue.
So it would make things easier for both sides, and things like this
I mean, if you actually ask for the output of ifconfig or ip, get it in the next posting and then don’t see that there is already a connection via cable which makes all other testing rather useless until you take that interface down (and depending on the setup, will “automagically” get the wireless interface going, but that’s just a guess, the output of the script would tell the helpers if/where the OP used “ifplugd” as start mode), then I ask myself, why people like framp do all this work and why I advertise it so diagnostic is easier for both sides and still gives you more information than you would ever be able to ask in one single posting.
There are quite a few threads -recent ones- here and in Network/Internet, where I know the script would catch what’s wrong as it is even obvious from the minimal output helpers asked (instead of linking the script), fun thing though, they asked for output, got the output and then don’t get the clue.
I think a lot of users are looking for answers, not clues. If they’re new to Linux they have no idea what all that output means. Looking at that script, I can see how a new user would find it a little overwhelming.
So, if you need the kernel version, why not just tell them to use uname -r?
I see why you want all that information, but most of the time it’s probably overkill. This user’s problem could be as simple as installing the kernel-firmware package. The output of dmesg would tell us that.
I was not talking about the users asking for help here, it was about users trying to help and THEY asked for something without getting the clue from the answer to their own question.
In that particular case, even the most unexperienced user would get a clue which is completely clear.
!!! CND0360E: Wireless connection tested with an existing wired connection on interface eth0. Unplug the cable and execute the script again
Just to show you, that I thought about the same thing but perhaps took this a little further.
a) Is there really a rt2870-chip on that device?
No, one can not be 100% sure from the model, some “vendors” (and D-link is one of them) tend to sell the same “model” with different revisions and very often different chipsets.
b) If there is a rt2870-chip inside the device, which driver(s!) are loaded?
There are two modules for those family of chips, rt2800usb and rt2870sta, both need the same firmware file (rt2870.bin) but if both are loaded, this is a good way to get into trouble.
And by default, most likely both modules will be loaded.
Now this is all just “guessing” from a minimal amount of information, and even with lsusb and dmesg, you will be none the wiser about a lot of other potential problems.
I realize that, but lsusb will tell us the USB identifier which will tell us which chipset it uses.
b) If there is a rt2870-chip inside the device, which driver(s!) are loaded?
There are two modules for those family of chips, rt2800usb and rt2870sta, both need the same firmware file (rt2870.bin) but if both are loaded, this is a good way to get into trouble.
Couldn’t that be considered a bug if a USB identifier is listed in two driver files, causing it to load both? The USB identifier SHOULD always be unique, although I know there are probably some rare exceptions.
And by default, most likely both modules will be loaded.
Now this is all just “guessing” from a minimal amount of information, and even with lsusb and dmesg, you will be none the wiser about a lot of other potential problems.
No, why should this be a bug?
The USB-identifier IS unique, there are just two drivers suitable for the respective device(s), rt2800usb is the one to hopefully become the standard driver in the near future and rt2870sta is the other solution until rt2800usb matures.
And those exceptions where there are two drivers for one device are not that rare.
Because something that causes the system to break should be considered a problem. In the scenario we were talking about, if only the rt2870sta driver loaded, all you would have to do to make your NIC work is install the kernel-firmware package (In my opinion, this should be detected automatically as well and ask if you want to install the firmware, if available. I don’t have to install any firmware on Ubuntu for my NIC to work). If both drivers are loading you have to go through additional steps to blacklist one of the drivers.
Personally, I don’t think it’s terribly difficult to get most wireless NICS working with Linux. The average end user probably has a completely different opinion. Anything we can do to simplify these tasks that (I hate to say it) on windows are simple would help.
It is detected automatically, at least if you run the install with the device present, the last time I had to deal with a wireless USB adapter needing firmware (zd1211rw) the respective firmware package was even selected by the package manager after plugging the device into the machine, I just had to run YOU.
The only workaround would be to blacklist one of the drivers by default, as rt2870sta is a staging driver, blacklisting rt2800usb is not really what you want to do and both would need the same firmware.
I am pretty sure both drivers will be loaded but this does not break the system necessarily, in most cases rt2800usb “won” and if rt2800usb works for a certain device, this is the better option.
Choosing a certain driver for a network device (if there is more than one) can be done via YaST (Tab “Hardware”), so blacklisting is not even needed.
Just tested this with a wireless USB adapter (rtl8187.ko comes with the kernel and r8187l.ko is from the vendor driver I installed additionally), works as expected without any blacklist-entry for neither of them.
This is done via udev and /etc/udev/rules.d/79-yast2-drivers.rules
Even worse, if one would really blacklist one of those drivers by default, you could choose that driver via YaST but it will not be loaded and therefor really break things.