This is a bug for me to log how to make wireless on this netbook work. # lspci -v|grep Real 01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8101E PCI Express Fast Ethernet controller (rev 02) 02:00.0 Network controller: Realtek Semiconductor Co., Ltd. Device 8199 (rev 22) # modprobe rtl8187 # dmesg usbcore: registered new interface driver rtl8187 # ifconfig wlan0 up (interface not found)
# /sbin/ifconfig -a (shows nothing extra)
There is no support for that hardware device upstream. FWIW, since this is a PCI device if anything it will be added to the rtl8180 driver. I know someone is working w/ the vendor to get that support added but I know of no ETA at the moment.
I haven't tested their open sourced drivers, but I've read they work. I will give them a go and hope they get into upstream.
For completeness, the page detailing the install is: http://wiki.msiwind.net/index.php/OpenSuse_11.0#Wireless_connection_.28Realtek_RTL8187SE.29
I can modprobe rtl8187, but ifconfig -a shows no wireless device. I also tried makedrv from the page above, I get: /root/rtl8187se_linux_26.1016.0716.2008/ieee80211/ieee80211_wx.c:66: error: too few arguments to function ‘iwe_stream_add_point’
The 8187se is not the same device has the 8187/8187b. The vendor's open-source driver is quite dated and have some other issues... The "too few arguments to function ‘iwe_stream_add_point’" error is due to incompatibility with newer (2.6.26/27(?)) kernels - it is quite easy to make to *compile*, just by adding an extra first argument. Use revision 2663->2668 (adaptation to 2.6.27) of ndiswrapper to help you: http://ndiswrapper.svn.sourceforge.net/viewvc/ndiswrapper/trunk/ndiswrapper/driver/iw_ndis.c?view=log However, from my experience with the vendor's 8187b driver (which is a different device from the 8187se, although with much code in common), just making the change does not result in a working driver. You better bet is to stay with an older kernel until a new driver matures. (the vendor's open-source driver is quite dirty...)
Thanks for that. I've found a better solution! http://code.google.com/p/msi-wind-linux/wiki/installer has the details After running, execute ./wlan0down ./wlan0up modprobe r8180 Then edit the connection with network manager. Finally!
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle. Changing version to '10'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
FWIW, I'm looking at using the vendor driver to enhance the rtl8180 driver to support the rtl8187se -- no timeline yet...
Thanks a lot! And to report back, the method in comment #7 is still working fine. A few replay errors, but it works. It's a real shame that Bugzilla is blocked from being indexed because other MSI Wind U100 users will not find this info :(
@John W. Linville: I think I saw a RHEL5.3 RFE bug for this driver, is this in Fedora yet? btw I am seeing more problems with the latest kernel 2.6.27.9-158. I see this sometimes: StaRateAdaptive87SE(): update init_gain to index 4 for date rate 22 etc. Then networking breaks or doesn't work for a while.
I vaguely remember that John Linville mentioned on the linux-wireless mailing list recently that there is some code written for that on wireless-testing git, if you feel adventurous. There is no support from the kernel developers for comment #7... the realtek vendor code is not quite workable architecture-wise.
lsof, there is no driver for this hardware in RHEL or Fedora. It looks like the vendor driver has been pulled into -staging FWIW.
*** Bug 483407 has been marked as a duplicate of this bug. ***
just for info: the coffee patch continues to work for me. Hopefully this will hit mainline some day.
(In reply to comment #15) > just for info: the coffee patch continues to work for me. Hopefully this will > hit mainline some day. The coffee patch is a derivative of the vendor driver in -staging mentioned in comment #13. It will not hit mainline kernel *at all*, AFAIK - the code as I said is unsatisfactory for many reasons (32-bit-ism/endianness and ieee80211 vs mac80211) and is kept there for reference and scavenging.
This message is a reminder that Fedora 10 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 10. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '10'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 10's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 10 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
This is still an issue in Fedora 12. Please, change the 'version' of this bug to '12', because I can't do this.
This problem just became somewhat more urgent. Until now, it was possible to run Realtek's RTL8187SE.inf driver under ndiswrapper and get a (somewhat unreliable) wlan connection. However the update to kernel 2.6.31.6-166.fc12.i686 seems to have broken this (at least for me). Uninstalling and reinstalling ndiswrapper didn't help.
Oooops, my bad - forgot to modprobe ndiswrapper. Please ignore previous comment (wish there was some way to remove it).
This is an issue that has to be resolved upstream.