Just a follow up from my last message. I have done a bit of searching and found that I can use something called NDISWrapper (as mentioned in an earlier reply), I'm not too sure how to use it though.
Anyway, it seems that this comes pre loaded in Linspire 5.
I have looked on the CD, in the drivers folder, for the Belkin F5D7050, for the .inf file. It seems to be listed as rt73???.inf. There is also a .sys file.
Before I attempt to use this can someone tell me HOW to do it please? Also, there are two folders, one for Win9x and one for 2kxp. Does it matter which one I use? They seem to have the same .inf / .sys files in them.
Regards and thanks
Peter
Peter Hunter wrote:
Just a follow up from my last message. I have done a bit of searching and found that I can use something called NDISWrapper (as mentioned in an earlier reply), I'm not too sure how to use it though.
Anyway, it seems that this comes pre loaded in Linspire 5.
I have looked on the CD, in the drivers folder, for the Belkin F5D7050, for the .inf file. It seems to be listed as rt73???.inf. There is also a .sys file.
Before I attempt to use this can someone tell me HOW to do it please?
From a console as root do:
ndiswrapper -l
should give a list of installed drivers - should be none at this point.
Then do ndiswrapper -i rt73whatever.inf
should install the driver. Repeat ndiswrapper -l to check it is there and the hardware is seen. Next do:
ndiswrapper -?? can't remember the letter but it is the one that creates an alias for modprobe - if you just do ndiswrapper on its own it will list all the switch letters. The alias is usually wlan0
The rest is distro dependent - I can tell ypu what to do in Slackware but you'll need to check your local distro expert for your own version of this. Basicaly you need to modify some start up scripts in /etc/rc.d. In Slackware I do the following:
Add a line to rc.modules -
/sbin/modprobe wlan0
This loads the driver. Add a line to rc.inet1
/sbin/iwconfig wlan0 essid "any" mode managed
That configures the card to connect to any wireless network it can find, Lastly, add a line to rc.local
/sbin/dhcpcd wlan0
which actually connects the card to the network and gets ip addresses sorted.
HTH
Ian
On Fri, Apr 28, 2006 at 05:11:13PM +0100, Ian bell wrote:
Peter Hunter wrote:
I have looked on the CD, in the drivers folder, for the Belkin F5D7050, for the .inf file. It seems to be listed as rt73???.inf. There is also a .sys file.
Then do ndiswrapper -i rt73whatever.inf
should install the driver. Repeat ndiswrapper -l to check it is there and the hardware is seen. Next do:
I'd really suggest not using ndiswrapper if you can at all help it, especially in this case as there is a native Linux driver available for the Belkin F5D7050 from http://rt2x00.serialmonkey.com/wiki/index.php/Main_Page
I'm sure the right search will throw up a way of getting it running with Linspire.
Thanks Adam
On Fri, 2006-04-28 at 17:29 +0100, Adam Bower wrote:
I'd really suggest not using ndiswrapper if you can at all help it, especially in this case as there is a native Linux driver available for the Belkin F5D7050 from http://rt2x00.serialmonkey.com/wiki/index.php/Main_Page
I'm sure the right search will throw up a way of getting it running with Linspire.
Thanks Adam
Adam Bower wrote:
I'd really suggest not using ndiswrapper if you can at all help it,
Because??
especially in this case as there is a native Linux driver available for the Belkin F5D7050 from http://rt2x00.serialmonkey.com/wiki/index.php/Main_Page
Except it is buggy. I have never yet got it to compile - well I did once but then it segfaulted when run. ndiswrapper does at least work.
Ian
On Fri, Apr 28, 2006 at 07:14:02PM +0100, Ian bell wrote:
Adam Bower wrote:
I'd really suggest not using ndiswrapper if you can at all help it,
Because??
Because it's a buggy hack to use drivers from another OS, i'd only want to use it as a real last resort (actually, I'd get rid of the buggy hardware and replace it with something that had proper support)
In fact, given the amount of time I've spent trying to get badly supported hardware working in the past I now just get something that is well supported in the first place or If I already have the hardware I get rid of it and replace it with something that works.
especially in this case as there is a native Linux driver available for the Belkin F5D7050 from http://rt2x00.serialmonkey.com/wiki/index.php/Main_Page
Except it is buggy. I have never yet got it to compile - well I did once but then it segfaulted when run. ndiswrapper does at least work.
Except ndiswrapper doesn't work for all people, I do hope you reported the bugs that you found in the rt2500 driver. The main reason I suggested the native driver was that I've heard of people having good success with it and problems with ndiswrapper.
Thanks Adam
Adam Bower wrote:
On Fri, Apr 28, 2006 at 07:14:02PM +0100, Ian bell wrote:
Adam Bower wrote:
I'd really suggest not using ndiswrapper if you can at all help it,
Because??
Because it's a buggy hack to use drivers from another OS, i'd only want to use it as a real last resort (actually, I'd get rid of the buggy hardware and replace it with something that had proper support)
In fact, given the amount of time I've spent trying to get badly supported hardware working in the past I now just get something that is well supported in the first place or If I already have the hardware I get rid of it and replace it with something that works.
especially in this case as there is a native Linux driver available for the Belkin F5D7050 from http://rt2x00.serialmonkey.com/wiki/index.php/Main_Page
Except it is buggy. I have never yet got it to compile - well I did once but then it segfaulted when run. ndiswrapper does at least work.
Except ndiswrapper doesn't work for all people, I do hope you reported the bugs that you found in the rt2500 driver. The main reason I suggested the native driver was that I've heard of people having good success with it and problems with ndiswrapper.
So to summarise, ndiswrapper is buggy and doesn't work for some people and the rt2x00 driver is buggy and doesn't work for some people
Ian
On Fri, Apr 28, 2006 at 08:20:41PM +0100, Ian bell wrote:
So to summarise, ndiswrapper is buggy and doesn't work for some people and the rt2x00 driver is buggy and doesn't work for some people
That's hardly suprising, all drivers are buggy to a certain degree, how much or often it actually causes a problem is the factor that varies ;)
Thanks Adam
On Fri, 2006-04-28 at 20:20 +0100, Ian bell wrote:
So to summarise, ndiswrapper is buggy and doesn't work for some people and the rt2x00 driver is buggy and doesn't work for some people
Well yes and no.
I think what Adam is saying is that one is a buggy driver that is in development and will improve with bug reports and further development.
The other is a (admittedly quite clever) hack that approximates the Windows network driver API just well enough to load Wireless network device drivers.
There are several reasons why the second one can only ever be a hack.
The driver API is a moving target, so with this method we have two moving targets (the API and the driver) Both of which are proprietary and some of which may be patent encumbered, therefore this solution can never be 'perfect'
The driver itself is closed source..This is even worse than using things like the closed Nvidia drivers because at least there is a degree of support from Nvidia as they are running on the intended target platform.
It is restricted to only architectures that both Windows and the hardware manufacturer support.
Also there is the classic anti-wine argument.
If wine was perfect then it would probably result in less native linux software being developed or ported because there would be less itches to scratch, therefore Wine solves short term goals at the expense of long term ones.*
So really (and perhaps in this case seeing as the native driver didn't work for you this was the only viable option) you should only use ndiswapper when there is no other alternative, it's a last resort. In the same way that running stuff under wine is really a last resort because you can't find the native software to achieve the same functionality.
So basically you should put as much effort as you can afford into getting the first option working first, before resorting to the second one.
* regarding the anti-wine argument, I don't completely subscribe to this view but it's a view that many hold so it's worth mentioning.
Wayne Stallwood wrote:
On Fri, 2006-04-28 at 20:20 +0100, Ian bell wrote:
So to summarise, ndiswrapper is buggy and doesn't work for some people and the rt2x00 driver is buggy and doesn't work for some people
Well yes and no.
I think what Adam is saying is that one is a buggy driver that is in development and will improve with bug reports and further development.
The other is a (admittedly quite clever) hack that approximates the Windows network driver API just well enough to load Wireless network device drivers.
Whilst I agree with your sentiments, I applaud any method that allows me to use the hardware I have/want with Linux. For as long as Windows is supported first by suppliers there will be times when a native Linux driver is not available and hacks like ndiswrapper are perfectly viable until a native driver becomes available.
As for the wine argument, there are many specialist areas where Linux alternatives simply are not available. I do a lot of microcontroller programming and the IDEs and particularly the device programming tools are windows only. Most are provided free (as in cash) by the chip vendors. Some of the IDEs work under wine, some do not. Because serial port access is not yet fully supported under wine, none of the programming tools work with wine. Only one vendor, out of dozens, provides a cross platform program and that does not work on my laptop with which I use a USB/serial adpator (laptops don't have serial ports any more grrrr!) because the closed source programmer does not support USB serial ports. So.... I have an old PC which dual boots win98SE and Zenwalk, just so I can program chips and use the proprietary C compiler, its simulator and its IDE. In the meantime I am busy developing cross platform tools to replace these. You can see the results of some of this work at www.8052.com
IAn
-
Adam Bower -
Ian bell -
Peter Hunter -
Wayne Stallwood