Bug 432280
|
Description
Hin-Tak Leung
2008-02-10 21:24:08 UTC
Created attachment 294513 [details]
realtek's official driver, hosted on a 3rd party site
Created attachment 294514 [details]
This is the diff made by the 3rd party site owner
This is the diff made by the 3rd party site owner to add support to the id
0x8197
Created attachment 294515 [details]
This is the diff I am using myself
This is the diff I am using myself (right this moment, on my laptop with
wireless) - with a more relevant kernel message
and some comments about how dropping through to the default case doesn't work.
The 3rd party site is: http://www.datanorth.net/~cuervo/rtl8187b/ Created attachment 295052 [details]
dkms configuration file
I have made a dkms config file.
If I want to submit an rpm for a dkms package, what's the correct process?
Since this is hardware support, and all the code posted so far are GPL,
it is appropriate to add to fedora (rather than freshrpms/livna, etc)?
Fedora has gone back and forth on accepting kernel module packages. I'm not sure what the current policy is, but I think they don't accept them. I'm not sure if DKMS stuff was ever accepted. You might check with a 3rd party packager (e.g. Livna) instead. FWIW, I'm working on using the vendor driver you cited as a resource for augmenting the in-kernel rtl8187 driver. I hope to have some patches for you to test next week. Also, can you identify the manufacturer and model number of the rtl8187b device you have? I would like to acquire a device for my own testing...thanks! I'll be happy to test if the in-kernel rtl8187 driver can be augmented. I'll just be happier not having a special local customization. I have also contacted the author of the in-kernel rtl8187 driver, Andrea Merello. He is quite positive but said he is involved with the newer mac80211 drivers. Licensing permitting, enhancing the in-kernel drivers is a better way than dkms. I have looked for other dkms modules for reference when I made my dkms config, and almost all of them has some non-GPL/licensing issues (ntfs, ati's dri, ndiswrapper). As for actual device - it comes built-in to my new Toshiba A210 1B1 laptop. It is a somewhat preculiar setup where the laptop has an "internal" USB bus with this chip hanging off it. From what I have read on the net, other owners of the device seems to be in the same boat - it comes built-in to some laptops of Toshiba and also Dell's brand... so I am afraid you might need to get a new laptop to get one of these... Any chance of a status update? It has been about a month - the problem is, the latest kernel update via yum (from 2.6.23-X to 2.6.24-X) breaks my dkms set up, because the rest of the wireless code in 2.6.24 is substantially changed from 2.6.23 . If you are going to enhance the in-kernel driver, I could skip my effort in forward-porting my dkms code... So I am booting a slightly not-up-to-date kernel just to go on-line. I'm sorry, I've gotten a bit behind on that. I still intend to get to it "soon", but I cannot be sure when exactly that will be -- sorry! Created attachment 298857 [details] additional patch for 2.6.24 As I mentioned earlier 2.6.23<->2.6.24 changes broke the official vendor driver... So I spent some time a few days ago to look into it, and this is the result. To be applied in addition to attachment 294515 [details] to the official vendor driver in attachment 294513 [details]. I don't claim to understand it enough to do it correctly, but I am using this new change of mine with 2.6.24.3-34.fc8, right now on this laptop I am submitting this change on, so obviously it seems to work okay... This is an interrim solution until the in-kernel realtek driver supports the chip... The dkms config file (in attachment 295052 [details]) needs two additional lines to get this working with dkms with 2.6.24.*: PATCH[1]=rtl8187B_linux_24.6.1024.0822.2007.2.6.24.diff PATCH_MATCH[1]=2.6.24.* I've been struggling to get the 0bda:8197 running on rawhide for quite a while as well, and have just found this bug - I wasn't looking for F8 bugs before ... :/ I didn't have any luck with 2.6.25 based kernels until now. The best I could come up with was to have the modified driver patched up a bit for 2.6.25 scan the network signal strength, but that was all. It oopses in what looks to be the ieee80211 part of it (the r8187 driver found in the wild is still ieee80211 based). Needless to say I would test anything you throw at me on a rawhide system. :) FWIW I had done similar patch creation and packaging like Hin-Tak did only for kmdl schemes. The packages may (still) work for older kernels (<= 2.6.25) and can be found at http://atrpms.net/name/rtl8187/ Since the same driver also supports id 0bda:8189 I changed the summary a bit to help people looking for this to come to the right place. And last, but not least: Thanks John, for picking this up! I had also contacted upstream, but Andrea wrote that he hadn't any time currently (that was on February 26th, maybe that has changed by now). John, any chance you could find some time to look at this? Thanks! Created attachment 303341 [details]
rtl8187b.patch
This patch was posted upstream, but I haven't merged it yet. Would you like to
give it a try and let me know if it is working for you?
Thanks a lot, I'll test it and report back.
One thing I already see in the code review is that it's missing an
{USB_DEVICE(0x0bda, 0x8197), .driver_info = DEVICE_RTL8187B},
but this is trivial to add.
I tried the patch with the additional usbid mentioned in comment #14. The APs can be scanned, but there is no association happening. I turned off all access control mechanisms on the AP and tried manually to associate, but it times out. What kind of diagnosis is helpful to you? Here are some poking of what I tried to look at (some are with the router back on wpa/tkip): dmesg: usb 1-2: configuration #1 chosen from 1 choice usb 1-2: New USB device found, idVendor=0bda, idProduct=8197 usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 usb 1-2: Product: RTL8187B_WLAN_Adapter usb 1-2: Manufacturer: Manufacturer_Realtek usb 1-2: SerialNumber: 00e04c000001 [...] phy0: Selected rate control algorithm 'pid' [...] phy0: hwaddr 00:16:44:7c:d1:82, RTL8187BvE V0 + rtl8225z2 usbcore: registered new interface driver rtl8187 [...] wlan0: Initial auth_alg=0 wlan0: authenticate with AP 00:09:5b:97:1c:ce wlan0: authenticate with AP 00:09:5b:97:1c:ce wlan0: authenticate with AP 00:09:5b:97:1c:ce wlan0: authentication with AP 00:09:5b:97:1c:ce timed out wlan0: RX deauthentication from 00:09:5b:97:1c:ce (reason=2) wlan0: RX deauthentication from 00:09:5b:97:1c:ce (reason=2) [...] # iwconfig wlan0 essid xanthos ap 00:09:5B:97:1C:CE # iwconfig wlan0 wlan0 IEEE 802.11 ESSID:"xanthos" Mode:Managed Frequency:2.437 GHz Access Point: 00:09:5B:97:1C:CE Tx-Power=0 dBm Retry min limit:7 RTS thr:off Fragment thr=2352 B Encryption key:off Link Quality:0 Signal level:0 Noise level:0 Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:0 Missed beacon:0 (the zeros never changed, e.g. no tx/rx at any time) # iwlist wlan0 scan wlan0 Scan completed : Cell 01 - Address: 00:09:5B:97:1C:CE ESSID:"xanthos" Mode:Master Frequency:2.437 GHz (Channel 6) Channel:6 Quality=0/64 Signal level=65/65 Encryption key:on IE: WPA Version 1 Group Cipher : TKIP Pairwise Ciphers (1) : TKIP Authentication Suites (1) : PSK Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 6 Mb/s 12 Mb/s; 24 Mb/s; 36 Mb/s; 9 Mb/s; 18 Mb/s 48 Mb/s; 54 Mb/s Extra:tsf=00000000ce52c181 what does ifconfig wlan0 says? Does it say 'UP' in the 3rd line-ish? I have the most curious symptom: 'ifconfig wlan2 up' says SIOCSIFFLAGS: Operation not supported Sort of expected, when the interface refuses to be 'up', nothing happens, but the wireless interface shouldn't refuse to be brought up... I have applied the patch against 2.6.24.4-64 (redhat f8's mod) as it won't apply cleanly against unmoded 2.6.24.4. I'll have a look at what ifconfig up is supposed to do (change something in /proc ?) and see what I can make of it. My previous inability to ifconfig up apparently is because I had mode=ad-hoc; but if I change it to managed, ifconfig up works, but iwlist scan then locks up the whole machine. Am doing some on-line reading, and attachement 303341 seems to be this: http://www.spinics.net/lists/linux-wireless/msg13439.html (for those who are interested in the surrounding discussions, etc - which is why I looked for it) Hin-Tak, I contacted directly Herton Ronaldo Krzesinski, and he provided me with an enhanched patch that has some debugging concerning exposing registers under proc etc. The patch applies cleanly on a 2.6.25 kernel, so for 2.6.24.x you may have problems both with applying and with running it. I would try it on a 2.6.25 kernel either from rawhide or straight vanilla. I created kmdls out of this patch (http://atrpms.net/dist/f9/rtl8187/), so I can track rawhide with it, but the device doesn't yet work properly. I can scan and retrieve all parameters from APs, but it looks like the transmissions go nowhere w/o any traces of errors/warnings in logs (other than timeouts). So I think the patch is almost there, maybe there are still some unknown differences between 8189 and 8197 usbids. (In reply to comment #19) > Hin-Tak, I contacted directly Herton Ronaldo Krzesinski, and he provided me with > an enhanched patch that has some debugging concerning exposing registers under > proc etc. Mind attaching the patch itself to the bug? I did wonder about the quality of patch 303341 since it contains almost absolutely no debug info or even just comments about what it does. Just to save my trouble of ripping it out of the src rpm. > The patch applies cleanly on a 2.6.25 kernel, so for 2.6.24.x you may have > problems both with applying and with running it. I would try it on a 2.6.25 > kernel either from rawhide or straight vanilla. patch 303341 did apply cleanly to the redhat mod'ed 2.6.24.4-64, and *not* to vanilla 2.6.24.4; I guess it is just because redhat mod'ed kernel is closer to 2.6.25. > > I created kmdls out of this patch (http://atrpms.net/dist/f9/rtl8187/), so I can > track rawhide with it, but the device doesn't yet work properly. I can scan and > retrieve all parameters from APs, but it looks like the transmissions go nowhere > w/o any traces of errors/warnings in logs (other than timeouts). > > So I think the patch is almost there, maybe there are still some unknown > differences between 8189 and 8197 usbids. > I see you were doing managed mode - can you do ifconfig up if you are in ad-hoc mode? Created attachment 304231 [details] patch ripped out of the kmdl rpm patch ripped out of the kmdl rpm memtioned in comment 19; to be applied to kernel 2.6.25 or there abouts. You didn't give me enough time to upload it :) Here are some comments from Herton: "It also has some additional debug code that creates a /proc/net/rtl8187 dir, that would be removed for another patch submission that don't matter too now, I was tring to read information from hardware/registers trying to advance more." E.g. the debugging part of the patch is transient. Still it may be useful - I for one discovered that all probed registers are zero in my case. On managed vs ad-hoc: In the environment I have access to the rtl8187b I can only test managed mode, there are no other nodes to form an ad-hoc network with only an AP. Well, the previous patch is not usable in my case (and mostly results in painful lock-ups - the chip is built into a laptop), so I'd like as much debug info as I can get at, and stripping out debug code is a bit premature from where I am looking at it :-). Can you actually do "ifconfig up" if you set mod Ad-hoc? There doesn't need to be another node; the operation should succeed regardless of the presence of other nodes - but in my case, it won't be brought up. Tried the latest ripped out patch; I can iwlist scan in managed mode and it gives correct results (found some neighbours' APs I have no access to), but since I don't have an AP around to test, I need ad-hoc mode to work, and it still refuse to be ifconfig up in ad-hoc mode. i checked 2.6.25 against the last of f8's 2.6.24.4-64, and the only difference is this: http://article.gmane.org/gmane.linux.kernel.wireless.general/13451 plus two le32_to_cpu(u32 *)<->cpu_to_le32(le32 *) -like changes, which I think is no-op on small-endian CPU's, so the crash I mentioned experiened in comment 17 is apparently exactly what the priv->vif oops is about. The priv->vif fix is in 2.5.25 and in fact also in rawhide 2.6.24.4-85; so anybody who wants to stay in fedora 8 for a few more weeks needs to apply it before playing with the rtl8187 patch... The driver seems to be stable but just doesn't work in ad-hoc mode yet (in managed mode it can scan, but I don't know if I can connect since I don't have a AP nearby), so I guess I'll poke around to see why ad-hoc mode refuses to ifconfig up... (In reply to comment #24) > Tried the latest ripped out patch; I can iwlist scan in managed mode and it > gives correct results (found some neighbours' APs I have no access to), but > since I don't have an AP around to test > The driver seems to be stable but just doesn't work in ad-hoc mode yet (in > managed mode it can scan, but I don't know if I can connect since I don't > have a AP nearby), so I guess I'll poke around to see why ad-hoc mode refuses > to ifconfig up... You can try connecting to the neighbours' AP and if you have the same symptoms as I do, then you will not get an authentication error, but a timeout like if your tx is muted. Trying to connect to neighbour's AP - it seems to work to some extent, I got
some transmission and some reply (removing some id details):
-------------------
dmesg:
wlan2: Initial auth_alg=0
wlan2: authenticate with AP <removed>
wlan2: authenticate with AP <removed>
wlan2: RX authentication from <removed> (alg=0 transaction=2 status=0)
wlan2: authenticated
wlan2: associate with AP <removed>
wlan2: authentication frame received from <removed>, but not in authenticate
state - ignored
wlan2: RX AssocResp from <removed> (capab=0x431 status=0 aid=1)
wlan2: associated
wlan2 (WE) : Wireless Event too big (366)
ifconfig:
wlan2 Link encap:Ethernet HWaddr <removed>
inet6 addr: <removed>/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:19 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 b) TX bytes:5294 (5.1 KiB)
wmaster0 Link encap:UNSPEC HWaddr <removed>
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
iwconfig:
wlan2 IEEE 802.11 ESSID:"<removed>"
Mode:Managed Frequency:2.462 GHz Access Point: <removed>
Bit Rate=54 Mb/s Tx-Power=0 dBm
Retry min limit:7 RTS thr:off Fragment thr=2352 B
Encryption key:DEAD-BEEF
Link Quality=53/64 Signal level=42/65
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0
------------
I have been reading - some of the Tx/Rx numbers are just not filled in by some
drivers, so zeros are probably not meaningful; but I have some number in
ifconfig but not in iwconfig, which is curious.
oh, and the 'event too big' log is also a bit curious. So in comment 24, are you saying that the priv->vif fix is actually _preventing_ rtl8187b from working? Or that it is required to make it work? (In reply to comment #28) > So in comment 24, are you saying that the priv->vif fix is actually > _preventing_ rtl8187b from working? Or that it is required to make it work? The prev->vif fix is required to make it work. The crash I experienced was apparently because I was patching 2.6.24.4-64 which does not contain it. Okay, I am a very sad person - I have a wireless access point under my full control now within 1/2 meter, using another hacked-up linux driver. (http://sourceforge.net/mailarchive/forum.php?thread_name=975228.5464.qm%40web23103.mail.ird.yahoo.com&forum_name=zd1211-devs) Since that sourceforge post, I have got my access point working in 802.11g mode. Because I am hacking that driver as well, I have full debugging on the access-point side. Basically the access point is not even registering anything from the compat-wireless-2008-05-07 + attachment 304231 [details] driver, but I am using the realtek vendor driver on the client right now, so identical hardware, one driver works and the other doesn't; and the access point is not detecting anything for the attachment 304231 [details] driver. Is there any way I can get the new realtek driver to give me some debug info? the attachment 304231 [details] driver is very lacking in that department. (not even commented out, just don't have debug statements!). I just noticed a strange issue - the last byte of the mac address of the realtek chip seems to change by 1 between different drivers; it is 0x94 when using the realtek vendor linux driver, but 0x93 when binding to ndiswrapper or the new prototype driver (neither working), and in Vista (working). Are you saying the zd1211rw driver can handle rtl8187(b) as well? As to ndiswrapper adding a one to the MAC address, I've seen that, too. Also the findings about the AP not registering anything agrees with what I see, e.g. the chip acts as if muted on Tx, but gladly scans the environment (I have a hardware switch, but maybe the chip also has some additional software switch). (In reply to comment #32) > Are you saying the zd1211rw driver can handle rtl8187(b) as well? No, I am just saying that since I have full control over the zd1211 access point, I can tell if the realtek client is trying to associate or not. There is *no* sign that the new driver is trying to associate; so it is scanning but not associating. I also have a hardware switch which I have not noticed until I booted Vista. The realtek Vista driver is sensitive to the hardware switch, but the vendor realtek linux driver by-passes it (hence I have never noticed it until I used Vista). The new driver is not associating regardless of the position of the hardware switch. (FWIW, the situation with the ZD1211B chip is similiar - The vendor linux driver is ugly as hell but more functional than the community linux driver: the community linux driver does not support access-point mode operation). There is a simple way of studying how the two linux drivers differ - enabling kernel USB debugging and just log the USB data transfer and compare the two; however, I think the community driver is poorly written in that there is absolutely no debug code (and it doesn't check usb_*_transfer() status either, from what I see) - and I suspect there has got to be a version of it with *some* debug code so I have e-mailed Herton Ronaldo Krzesinski, before going the the kernel usb data transfer route. (this is tedious). (In reply to comment #33) > I also have a hardware switch which I have not noticed until I booted Vista. > The realtek Vista driver is sensitive to the hardware switch, but the vendor > realtek linux driver by-passes it (hence I have never noticed it until I used > Vista). The new driver is not associating regardless of the position of the > hardware switch. I guess that is the missing piece. Something in the driver needs to either acknowledge the setting of the fake hardware switch and mute/unmute the transmission or ignore it and keep the transmission unmuted. Unfortunately the rfswitch project has Toshibas listed as being hardware switch driven, maybe the new generation has just this fake switch and the switching itself is software. Perhaps we're barking up the wrong tree then. The difference between hardware switch and software switch is a bit blur - even the power button does different things whether you are waking up from a suspend, or press it for longer than X sec to reset a lock up. What I don't understand (and may need a USB dump) is how the new linux driver can behave differently from the old, when the new driver is based on the old linux (rather than the windows driver). So it must be a coding mistake or some sort somewhere to not be able to by-pass whatever the position of the switch says, if that's why the new code is misbehaving. Note that the new driver doesn't check status of usb transfers, which doesn't help (now that I have seen the code of *4* wireless device drivers, two for realtek and two for zd1211; and I used to do device driver programming of a different usb device type). One of them could have failed due to a typo and so any subsequent commands ignored, against silently. I have not heard from Herton Ronaldo Krzesinski; but I have gone the kernel debugfs usbmon route, and found a difference between the old vendor driver and Herton's: The vendor that works uses USB endpoint 12 for sending most of its bulk data (and some through endpoint 6); Herton's only ever uses endpoint 6. This is just for doing an iwlist scan and tries to associate. 6,7,5,4 are in order of priority; but endpoint 12 is 'MANAGE_PRIORITY'. This is used in rtl8180_hard_start_xmit() for tranmitting management frames. rtl8180_hard_data_xmit() uses normal endpoints 6,7,5,4. In the new driver, rtl8187_rx() is the equivalent, but there is no special treatment of management frames. I believe this might be the problem... however, I don't know enough about the code to go any further. hope this is of some use to somebody. I can attach the debugfs usbmon dump of both cases if needed. Soo, got a gateway m-1625 laptop this weekend, and it has same realtek wired/wireless drivers. I got Axel's driver and it has worked a couple of times, but it seems random. If I have it connected, and then maybe reboot or whatever, it doesn't come back. I can say this, when I change the key for using wpa2 personal to correct key, then go back and look (check mark in the box to see characters), it seems the password isn't what I put in before. Either just showing random stuff to hide it, or it's changing on it's own and part of the problem? Created attachment 305203 [details]
usb endpoint 12 for management frames
Hurray! I have got connectivity with Herton's new driver (patch 304231) with an
additional change which directs management frames to usb endpoint 12. Here is
the diff to be applied on top of attachement 304231.
I seem to need to wait or do ifconfig up/down a couple of times to get this to
work, but it seems to work alright now.
There is a strange side effect of my new change (attachment 305203 [details]) which I
don't understand - now some of the usb traffic is going through endpoint 5
(rather than 6), in addition to the expected endpoint 12:
9374 Bi:1:002:3
68 Bo:1:002:12
616 Bo:1:002:5
1530 Ci:1:002:0
33202 Co:1:002:0
Soo, does this mean your patch went into the driver/kernel and barring some fine tuning, that this will be out in a hope to be soon kernel update? Or what does this mean to the general public and when will they experience the happiness? LOL (In reply to comment #41) > Soo, does this mean your patch went into the driver/kernel and barring some fine > tuning, that this will be out in a hope to be soon kernel update? Or what does > this mean to the general public and when will they experience the happiness? LOL I think John Linville (the assignee of this bug) is the guy to push wireless-related kernel changes to Linus... Comment on attachment 304231 [details]
patch ripped out of the kmdl rpm
changing mine-type so that it is browser-viewable
I should add that one doesn't need a whole new kernel to try out the new driver - I was applying attachment 304231 [details] then attachment 305203 [details] against compat-wireless-2.6-2008-05-07 (package from linuxwireless.org - it basically replaces all the wireless-related kernel modules in your current kernel without requiring a new kernel) with kernel 2.6.24.5-85.fc8 [the lastest f8 kernel] ; and in fact only replaced one file shipped in f8, rtl8187.ko . - I think there are some advantages of replacing also mac80211.ko, etc, but I haven't. To make the change acceptable to John/Linus, I suppose I'll need to check out wireless-2.6 git... On the subject of the drifting mac addresses (mentioned in comment 31), I looked at the sticker at the bottom of my laptop and apparently Vista, ndiswrapper and the new driver are using the the 'correct' mac address, while the older vendor driver is using a mac address differing by 1 from it. Curious. Would like to hear what other's experience is. shared key/WEP works with the new driver. (unlike the old, which kernel oops on it) (In reply to comment #39) > Created an attachment (id=305203) [edit] > usb endpoint 12 for management frames > > Hurray! I have got connectivity with Herton's new driver (patch 304231) with an > additional change which directs management frames to usb endpoint 12. Here is > the diff to be applied on top of attachement 304231. > > I seem to need to wait or do ifconfig up/down a couple of times to get this to > work, but it seems to work alright now. I tried as well, but my results are still the same - no tx to anywhere :( But if it starts to work for you we're on the right track! :) (I tried in F9 if that would make any difference, but I think it doesn't, as you used the compat stuff) Sooo, what can someone do to try this out and see if it works with F9? Baby steps haha (In reply to comment #46) > I tried as well, but my results are still the same - no tx to anywhere :( Hmm, do you have the AP's mac address? if you do an explicit iwconfig wlan<whatever> AP <mac_address>, dmesg should say something even if unsuccessful, with the rippped out patch. Also, follow the usbmon.txt instruction in the kernel-doc package, capture a debug trace, and do a cut -f 4 -d ' ' on it to see which end points it is using. (In reply to comment #47) > Sooo, what can someone do to try this out and see if it works with F9? Baby > steps haha download the compat-wireless-2.6 tar ball from linuxwireless.org, patch it with the *two* patches I mentioned (patch -p1 < should work if you cd into the untared directory; follow the README to build and run it. As a variation, I didn't have the patience to build the whole tree and run the whole tree, so I go into driver/net/wireless and only did a make -C /lib/modules/<current_kernel>/build \ M=`pwd` rtl8187.ko copy rtl8187.ko over the one somewhere under /lib/modules/<current_kernel>/ (after backing up the old - probably not necessary since the old isn't any good), run 'depmod -a' to refresh dependencies, then 'modprobe rtl8187' (without the .ko part) to load the kernel module by hand. a couple of lines should appear in dmesg at this stage. After that it is a few iwconfig, and ifconfig <interface> up, and it worked for me alright; some lines should appear in dmesg for trying to associate to an AP if you do an explicit iwconfig <interface> AP <mac_address> Something like this should appear in dmesg after modprobe:
-----------
rtl8187: 8187B chip detected. Support is EXPERIMENTAL, and could damage your
hardware, use at your own risk
phy0: Selected rate control algorithm 'pid'
phy0: hwaddr <address>, RTL8187BvE V0 + rtl8225z2
usbcore: registered new interface driver rtl8187
udev: renamed network interface wlan0 to wlan2
ADDRCONF(NETDEV_UP): wlan2: link is not ready
------------
and with an explicit iwconfig wlan<interface> AP <ap's address>, this should
appear: (even if nothing happens from AP):
-----------
wlan2: Initial auth_alg=0
wlan2: authenticate with AP <address>
wlan2: authenticate with AP <address>
wlan2: authenticate with AP <address>
wlan2: authentication with AP <address> timed out
-----------
(my AP is a bit flaky and occasionally needs resetting to work - problem of
beta-drivers :-))
(In reply to comment #47) > Sooo, what can someone do to try this out and see if it works with F9? Baby > steps haha The patch by Herton with Hin-Tak's fixes is available in kmdl form (version 2.6.25-4) for F9 and F8 at http://atrpms.net/dist/f9/rtl8187/ (Don't pick the ieee80211 version of the packages) Let's know how it works or not for you. (In reply to comment #49) > Something like this should appear in dmesg after modprobe: > wlan2: Initial auth_alg=0 > wlan2: authenticate with AP <address> > wlan2: authenticate with AP <address> > wlan2: authenticate with AP <address> > wlan2: authentication with AP <address> timed out > ----------- > > (my AP is a bit flaky and occasionally needs resetting to work - problem of > beta-drivers :-)) Well, that's what I get as well, unfortunately I always have timeouts and never a successful authentication and the other side doesn't see any traffic at all, e.g. still a TX muting like situation. Think I am getting timeouts as well, cause I cant' get it to connect either. I am getting to the point of frustration with this thing, as windows obviously works fine, and even the wired part works just dandy, just no wireless and this sucks. I would almost buy a card to get it working better if need be. both of you see 'authentication with AP <mac> timed out' if you do
"iwconfig wlanX ap <ap's mac address>", right?
Just to make sure you are using the aditional mod I made - try the procedure in
usbmon.txt under /usr/share/doc/kernel-doc-<version>/Documentation/usb/:
1. mount -t debugfs none_debugs /sys/kernel/debug
2. Find which bus connects to the desired device
Run "cat /proc/bus/usb/devices"
3. if you can't tell bus id, just use 0,
cat /sys/kernel/debug/usbmon/0u > /tmp/1.mon.out
4. in a different terminal, iwconfig wlanX ap <ap's mac address>
5. go back to terminal 4, contrl-c to kill it.
6. if you do
cut -f 4 -d ' ' /tmp/1.mon.out | sort | uniq -c
you should see something like what was in comment 40:
9374 Bi:1:002:3
68 Bo:1:002:12 <- this is endpoint 12 or bus 1, device 2, bulk out.
616 Bo:1:002:5
1530 Ci:1:002:0
33202 Co:1:002:0
if you don't have a Bo:...:12 entry, you are not using my mod.
BTW, the mac address of your AP should show up in "iwlist wlanX scan", if you don't have it written down near the access point... 1 - iwlist doesn't show the ap mac addy, but iwconfig shows it, but the last letter is wrong (had to look on linksys router info to get it) 2 - I don't get a timeout at all when doing iwconfig wlan0 ap mac:addy:here 3 - the entry I have after following those 6 steps is below... 592 Ii:2:002:1 (2 being the bus) I am using Axel's mod from his site. hmm, 1. iwlist should find the access point (the routers). otherwise the router probably is at fault. BTW, the realtek driver doesn't auto-negotiate rate (although I think some new 2.6.25.x patches may make it so), so your router needs to be in mixed mode or pure-G mode; but the mode is irrelevant for list scanning. 2. the timeout message is in 'dmesg', not in stdout. 3. what other entries are there - you know my command just cut, sort and count number of USB data entries, so 'Bo:X:00Y:12' could be anywhere. If you don't have an Bo:...:12 entry, these are the possibilities: a) you are not loading the right kernel module b) iwconfig ... ap <mac> isn't executing *during* the cat operation c) cat'ing the wrong bus? d) ??? regardless of whether the wireless chip is working or not, this procedure captures the data that goes between the USB host controller and the usb device, so even if the device is completely dead something should show. (In reply to comment #53) > both of you see 'authentication with AP <mac> timed out' if you do > "iwconfig wlanX ap <ap's mac address>", right? Yes I do see the time out. > 1. mount -t debugfs none_debugs /sys/kernel/debug Done. > 2. Find which bus connects to the desired device > Run "cat /proc/bus/usb/devices" Bus=01 > 3. if you can't tell bus id, just use 0, > cat /sys/kernel/debug/usbmon/0u > /tmp/1.mon.out Done - using 1u > 4. in a different terminal, iwconfig wlanX ap <ap's mac address> Done > 5. go back to terminal 4, contrl-c to kill it. Done > 6. if you do > cut -f 4 -d ' ' /tmp/1.mon.out | sort | uniq -c > you should see something like what was in comment 40: > 9374 Bi:1:002:3 > 68 Bo:1:002:12 <- this is endpoint 12 or bus 1, device 2, bulk out. > 616 Bo:1:002:5 > 1530 Ci:1:002:0 > 33202 Co:1:002:0 > if you don't have a Bo:...:12 entry, you are not using my mod. I get 2 Bo's, such as below.. 328 Bo:1:003:1 44 Bo:1:004:12 iwlist wlan0 scan shows "no scan results". (In reply to comment #57) > I get 2 Bo's, such as below.. > > 328 Bo:1:003:1 > 44 Bo:1:004:12 > > iwlist wlan0 scan shows "no scan results". Probably some other issues with your router? (say, hardware switch, etc). What is your realtek chip connected to? You have some other device on the same bus. The 12 seems to be correct. It's connected via usb I guess, as lsusb shows the driver. (In reply to comment #59) > It's connected via usb I guess, as lsusb shows the driver. I meant what's on your 1:003, for example (mine is device 2, and device 1 is the hub in the laptop's board). Just installed the fedora-release 9 rpm and did yum upgrade from 2.6.24.7-92.fc8 to f9. The new driver worked okay downloading 3.5GB for the upgrade. Am using the new driver with 2.6.25.3-18.fc9.x86_64 now. Hrm, soo is this driver already patched and used on Axel's site? Cause that one hasn't worked since he changed it I guess. I have been trying to use ndiswrapper and that hasn't worked neither. I know the router is fine, as it's seen and is connected from Vista machines just fine. If not on Axels site, care to compile/build it into an rpm to use for the latest kernel? Or tell me where to get it, how to compile it (quick install method shall I say) and get it installed? (In reply to comment #62) > Hrm, soo is this driver already patched and used on Axel's site? Yes, the kmdls contain both patches, the one from Herton and Hin-Tak's endpoint 12 adjustments. And if you throw any more patches to me I'll try them out as well, as I'm also in the same boat as Mike (e.g. watching others having success while whining over my wifi muted laptop - I think I'll go & buy a USB wifi). Created attachment 306244 [details]
THe last two kernel modules (x86_64) I used successfully.
I don't know why others haven't been able to get to where I am, so I suppose
one way forward is to try to clone my set-up elsewhere...
WARNING: you need to have the as-shipped *fedora* kernel packages for
*x86_64* platforms of the *exact* versions - don't try to mix and match
(arch or a different version), or very bad thing is likely to happen.
Be warned that bad thing can happen in any case.
This is a tarball containing the last two kernels modules I have used
successfully, both for *x86_64* platforms; one of them is for the last of
the f8 as-redhat-shipped kernels, and the other for the current f9.
You need to have the exact same kernel packages of the same *versions*,
but those should cover both up-to-date f8 x86_64 and f9 x86_64 systems.
Basically you just "cd / && tar -xzvf <tarball>" and it should overwrite
the two corresponding unpatched modules in those two kernel versions. (I
moved the old one out of the way and did a cp, but you get the idea).
Then you do "depmod -a" to update the kernel module dependences. If you
have either of those two kernel versions, you should then have a very
similiar system to mine. Then "modprobe rtl8187" should load the kernel module
(or you need to unload the old one first if you have been playing with Axel's
etc), or udev should load it automatically next time you reboot to those
kernels. Then it is just the usual iwconfig ifconfig thing.
On f9, I seem to need to put the same WEP settings in wpa_supplicant as
what I do on iwconfig manually. But that's encryption and not relevant before
anybody else get association/connectivity at all.
You can do "iwconfig wlan<?> ap <router's mac>" to force the realtek device
to re-try even when it has given up or timed out. I need to do that
occasionally, but that's because the router is also running beta-driver-
software :-) - 10 out of 10, a re-try works when I reset the router's end.
I struggled with this procedure for some time. All the commands executed successfully. However, I couldn't connect. It wasn't until I stopped NetworkManager that everything started Just Working. Since this is on by default, perhaps this is disrupting the attempts of other testers, too? I'm using the rtl8187 package from atrpms.net, have an RTL8187B attached to USB bus 2 (apparently), have NetworkManager OFF, and have the "network" service ON, and am using a WEP key configured with system-config-network, and the network Just Works on boot. (In reply to comment #65) <snipped> > It wasn't until I stopped NetworkManager that everything started Just Working. > Since this is on by default, perhaps this is disrupting the attempts of other > testers, too? <snipped> Good too hear to know somebody else has got it working. Are you on f8 or f9, and you are using the atrpm packages with the endpoint 12 patch, I hope? My experience with NetworkManager on f9 is also similiar - on f8, I never noticed it, and it basically leaves wireless devices alone and everything was working via manual configuration; since I upgraded to f9 a couple of days ago, I found that NetworkManager was constantly resetting my ESSID and WEP to null and cancelling/interfering with my manual configuration. I assumed that this is just 'growing pain' with recent upgrade and if I use f9 for longer and use NetworkManager 'properly' it will eventually work for me rather than against me :-). *But*, the symptom of NetworkManager interfering and say, not having the endpoint 12 patch is different. If you don't have the endpoint 12 patch, you can scan list but trying to associate times out after 3 attempts (dmesg says so). If the failure is due to NetworkManager, you would find that your ESSID and WEP key has been reset to something different from what you expect (such as empty) from iwconfig; and in your dmesg, you get 'authentication' failure about mixing different cell types. (the message actually makes sense if you look at it at hind-sight - when NetworkManager is resetting your manual config, basically your card is trying to associate with the same access point with the correct authentication credentials and without, so both are rejected because it looks suspicious security-wise). I'm on F9. I have the rtl8187 package with the endpoint 12 patch (rpm -q --changelog says "- Add Hin-Tak Leung's patch for the endpoint 12 setup." Also I remember seeing the :12 when I was running through the diagnostic recipe, above). NetworkManager didn't reset the ESSID for me, but this DOES explain why setting the key with iwconfig never seemed to "take" until NetworkManager was off (though I'm not entirely sure I understand why providing the key to the NetworkManager applet was ineffective as well). The dmesg messages complained of timeouts. Though if I looked suspicious to the router, ignoring me is the same as rejecting me, I suppose. resetting ESSID was probably me being inaccurate - but the WEP key was definitely resetted - one minute it was in, next minute it was gone. The multiple-lines dmesg messages I got is not about time out but about deauthenticated due to mixed cell types for 'reason=6', if I remember correctly. I just took a look at my /var/log/message - apparently NetworkManager tried to use WEP with an empty WEP key. (despite the fact that I gave it one, and wpa_spplicant's config also have the right WEP key as far as I can see) - I think it uses wpa_supplicant even for WEP configurations. (I never quite understand wpa_spplicant does WEP, but I never took the time to work it out...) Wish one of you would had spoken up bout NM not working correctly and trying the ole reliable s-c-n. I have tried it, says it's connectd, ifconfig shows an ip, but I can't get out to the internet. So something is amiss. I am wondering if not authenticating correctly or not. Can one of you that has their wireless working with regular network on and not MM, post your ifcfg-wlan0 file so can see how ti's setup? Does using it this way still let you use wpa2 encryption or you have to use something else (wep (which bit do you select?), what)? (In reply to comment #69) Please do not change release/priority/severity - changing it up in the hope giving it more urgency will only annoy the Redhat folks and others, and does the reverse. Does your router (and its configuration) work for other wireless clients? I am doubtful of that. There is nothing of interests in my ifcfg-wlan2 . If you get an ip address assigned via dhcp (higher level network functionality on top of wireless) from the router, your wireless card driver is already fully working - you should be able to ping your router, and it is your router not letting the traffic through to the rest of the world. The common wisedom is try *not* to do everything at once - try doing without encryption first (although it seems to work for you already) if you have any control over the router, and try to ping your router first to establish TCP/IP connectivity to the router before trying the internet, etc. My router can't do WPA/WAP2 so I would not have needed/wanted wap_supplicant or NetworkManager to get in the way anyway, and as is such usual for such bleed-edge work, disabling any auto-configuration tool is the routine way to start. If you feel uncomfortable 'getting your hands dirty', maybe you should just wait (and wait patiently and *quietly*) unless the rest of us sort it out. Your problem no longer seem to concern the hardware driver but of TCP/IP networking configuration, and at the router's end rather than at the wireless client's end. (In reply to comment #70) > (In reply to comment #69) > Please do not change release/priority/severity - changing it up in the hope > giving it more urgency will only annoy the Redhat folks and others, and does the > reverse. Set it to whatever you want, doesn't matter. I don't know why I changed it cause that isn't looked at anyway. But you and most of us are using F9 now and think maybe it should be changed to at least reflect that version now? > Does your router (and its configuration) work for other wireless clients? I am > doubtful of that. Works just fine for other clients, as well as the laptop. > > There is nothing of interests in my ifcfg-wlan2 . If you get an ip address > assigned via dhcp (higher level network functionality on top of wireless) from > the router, your wireless card driver is already fully working - you should be > able to ping your router, and it is your router not letting the traffic through > to the rest of the world. The common wisedom is try *not* to do everything at > once - try doing without encryption first (although it seems to work for you > already) if you have any control over the router, and try to ping your router > first to establish TCP/IP connectivity to the router before trying the internet, > etc. My router can't do WPA/WAP2 so I would not have needed/wanted > wap_supplicant or NetworkManager to get in the way anyway, and as is such usual > for such bleed-edge work, disabling any auto-configuration tool is the routine > way to start. I got it working by disabling NM, enabling the ole network service, and using WEP encryption so it would accept and share with each other. > If you feel uncomfortable 'getting your hands dirty', maybe you should just wait > (and wait patiently and *quietly*) unless the rest of us sort it out. Your > problem no longer seem to concern the hardware driver but of TCP/IP networking > configuration, and at the router's end rather than at the wireless client's end. Getting my hands dirty is NOT a problem, I like digging in and finding out what the problem is, even if frustrated. I was asking bout the file and such, because laptops are new to me as far as wireless and using linux with them. So I wanted to clarify if what I was doing was correct (I am a confirmation type person, a fault I guess). At any rate, thank you to both for mentioned NM not handing this driver and encryption stuff correctly and to use the network service until NM is fixed to work better. (In reply to comment #71) > I got it working by disabling NM, enabling the ole network service, and using > WEP encryption so it would accept and share with each other. So just to confirm, you have managed to get TCP/IP connectivity with the router and/or other machines through wireless? As for WEP vs WPA/WPA2, and NM interfering, maybe there is a 'correct way' to configure NM so that it at least handles only wired connections and leave the wireless ones alone; maybe the realtek client driver can't do WPA/WPA2 (I can't test since my "cheap" access point doesn't do it). But those are separate issues, and maybe the material for filing another bug, possibly against NM, or at least the lack of documentation on it. (In reply to comment #72) > So just to confirm, you have managed to get TCP/IP connectivity with the router > and/or other machines through wireless? Yes, it is connected to the network via wireless, with the driver from Axel's site. I am typing this on the laptop as I speak. FYI I am using the regular network service, not NM. > > As for WEP vs WPA/WPA2, and NM interfering, maybe there is a 'correct way' to > configure NM so that it at least handles only wired connections and leave the > wireless ones alone; maybe the realtek client driver can't do WPA/WPA2 (I > can't test since my "cheap" access point doesn't do it). But those are separate > issues, and maybe the material for filing another bug, possibly against NM, > or at least the lack of documentation on it. My router supports wpa/wpa2 no problems, as both of these laptops can connect via Vista easily. This one did it before, using NM, but won't now. I wasn't sure if WPA would work or how to make network service use it compared to WEP, but not changing it now as this is fine. My router is a Linksys wireless wrt54g (sp?). Had problems and have returned the laptop to best buy. Hope you guys get everything working OK, so good luck. Created attachment 308624 [details]
Naive patch so module will build under kernel-2.6.25.4-30.fc9.i686
There seem to be some elements mysteriously missing from include/net/mac80211.h
in the Fedora kernel source which nevertheless continue to persist in the
kernel source from kernel org.
Naively removing references to the offending ssi and max_ssi elements results
in a module that compiles and works for me. However, I don't truly understand
what's going on, so this should probably be reviewed by somebody who actually
knows what they're doing.
This patch is against source which was FIRST patched by patch 304231, THEN
patched by patch 305203.
(In reply to comment #75) > Created an attachment (id=308624) [edit] > Naive patch so module will build under kernel-2.6.25.4-30.fc9.i686 > > There seem to be some elements mysteriously missing from include/net/mac80211.h > in the Fedora kernel source which nevertheless continue to persist in the > kernel source from kernel org. You really should *not* try to mix-and-match compat-wireless with stock kernel. stock kernel is *older* than compat-wireless's, and you should not be using stock kernel's wireless headers but use those in compat-wireless's. On wireless matters, John Linville's tree (and hence redhat's) is more authoritative and up to date than Linus'. Those missing elements are deliberately removed last month and not mysterious, and Linus' tree will have them removed eventually. I think this is the patch (found by google) that Linus has't got yet: http://thread.gmane.org/gmane.linux.kernel.wireless.general/14549 or on John's web site: http://www.kernel.org/pub/linux/kernel/people/linville/wireless-testing/merged-upstream/0119-mac80211-use-hardware-flags-for-signal-noise-units.patch (In reply to comment #75) > Created an attachment (id=308624) [edit] > Naive patch so module will build under kernel-2.6.25.4-30.fc9.i686 What I meant was, you should patch your kernel headers, not patching the driver code! *Apologies to all*
Some of last two comments did not make sense (too late at night...).
One should look at the referenced use-hardware-flags-for-signals-noise-units
patch and update attachment 308624 [details] accordingly. Should be easy to do the update
(if any is needed) by referencing the use-hardware-flags-for-signals-noise-units
patch .
On that note, any chance of the driver going into the redhat kernel any time
soon?...
Any chance of the driver going into the redhat kernel any time soon? Although I don't use WPA (just WEP), and there are some issues with NetworkManager - so things need to be set up manually, etc; but with the new driver, I have ifconfig/ifconfig down, reconnect after suspend/resume or hibernate/resume (I am surprised that the new driver suspends and hibernates and it sleeps happy - the old vendor driver didn't, as far as I remember), etc, and there is not just me having it working, and don't seem to have any crashes/oops at all. Also, if/when the change goes in, can I get some "honary mention" for working out the endpoint 12 difference? Just for bragging... :-). Well, Hin-Tak, it looks like you have your answer. kernel-2.6.25.6-55.fc9 is out. In response to your request to have the driver included in the kernel source, they have analyzed the driver code, and immediately deleted the ieee80211_tx_status structure from mac80211.h, which prevents the rtl8187b driver code from compiling. Since I don't know what I'm doing, I'll stay away from trying to make it compile again. Just thought I'd report that the driver doesn't work anymore. okay, the heron driver doesn't patch cleanly against compat-wireless-2008-06-14 . No need to get angry about this... I am sure there is a reason. The wireless stack is still in constant change, and I know it is best to have the new driver in as soon as possible, so that others are aware of it, and it is modified and updated together with the rest of the other wireless driver codes, and that's the only long term solution. I'll have a look later today and see if I can work out what's changed and what need to be done. obviously it is going to be an integrated patch then, if/when I get it done. (In reply to comment #75) > Created an attachment (id=308624) [edit] > Naive patch so module will build under kernel-2.6.25.4-30.fc9.i686 <snipped> > > Naively removing references to the offending ssi and max_ssi elements results > in a module that compiles and works for me. However, I don't truly understand > what's going on, so this should probably be reviewed by somebody who actually > knows what they're doing. I have got through the changes, and it seems that the role of ssi and max_ssi has been taken over by signals and max_signals. removing them are "correct", but occasionally the value is assigned to signal or max_signals next to the removed line instead. Anyway, I am attaching my integrated patch for 2.6.25.6-55.fc9.x86_64 and I am using it right now... YMMV Created attachment 309378 [details] integrated patch to build against 2.6.25.6-55.fc9.x86_64 diff against compat-wireless-2008-06-14. It seems that compat-wireless is slightly newer than 2.6.25.6-55.fc9.x86_64 and uses an extra inlined routine from a patch submitted 10 days ago http://article.gmane.org/gmane.linux.kernel.wireless.general/15830 which isn't in the redhat-shipped kernel headers. Anyway, I added it to the top of the rtl8187_dev.c source file with an ifndef but it sould be taken out when the kernel itself moves forward. I am using it right now against 2.6.25.6-55.fc9.x86_64 so it works for me. YMMV, and I have a few questions to ask linuxwireless-dev... Fabulous! I started with Axel's .spec file from April 30 (Comment 19), downloaded the compat-wireless tarball, and made a .tar with just the rtl- stuff it, added your patch, built it for 2.6.25.6-55, installed the resultant -kmdl, and rebooted from 2.6.25.4 to 2.6.25.6-55. Couldn't get the interface up, so I figured I was playing a little too fast and loose by not building ALL of compat-wireless, so I rebooted again with the intention of downloading the tarball again (I had deleted the original by accident), got distracted, and ended up in 2.6.25.6-55 again--but suddenly the network was working on boot. So it works for me, too. (In reply to comment #85) Very good. Did you do 'depmod -a' before reboot? It is done automatically during reboot, so that might be how it works after reboot. I have a couple of very long download or network-usage sessions with 2.6.25.x, but also a few where I lost connectivity after 5-10 minutes of obtaining an IP address via dhcp and reading web pages, etc. I think I may have made a mistake or two in the forward port; also, it is supposed to switch between usb end point 6,7,5,4, but the structure controlling the switch has disappearred so I just wrote 6, which obivously works but probably considered not-optimal. Some vendors are shipping 8187bs with the 0x8187 product id, so the driver really needs to probe rather than having a static setup of which is which. (In reply to comment #87) > Some vendors are shipping 8187bs with the 0x8187 product id, so the driver > really needs to probe rather than having a static setup of which is which. Do you know which vendor, and anybody who has procession of such a product? The driver is working alright but needs more testing under different usage, etc and not going into wireless-testing is not helping... (posted to linux-wireless and had no comments, replies, whatsoever...) My Level 1 WNC-0301USB has a product id of 0x8187, but really is an 8187b. Earlier, I had figured out how to detect the condition and sent a patch to Herton, which was included in the one he posted. My device is able to receive correctly, but cannot transmit reliably - it associates 1 time in 10. I'll try to debug the condition. Created attachment 310527 [details]
replacement for integrated patch 309378
I did make a mistake with patch 309378 with the tranmission queuening. So
anybody using 309378 please update with this. This is against wireless-testing,
but patch cleanly with compat-wireless 2008-06-25, and built alright against
2.6.25.9-76.fc9.x86_64. (and am using it to post this).
Am working on merging all the slightly different efforts on polishing the
patch.
(In reply to comment #87) > Some vendors are shipping 8187bs with the 0x8187 product id, so the driver > really needs to probe rather than having a static setup of which is which. Between the 4 of us (Herton/Pavel/Larry) I think we located the bit of code which probe for 8187b's with a 8187 id - it is in the vendor driver but not in new driver yet. The latest vendor driver also seems to drop the power level for such chip - which may account for why Larry's 8187b blew up. Watching this bugzilla, for personal Gateway M1600 that has 8187B for internal wireless. System is F9 running 2.6.25.9-76.fc9.i686. "The latest vendor driver also seems to drop the power level for such chip - which may account for why Larry's 8187b blew up." Any word on that? I would feel better merging the driver upstream if I thought we were doing what we could not to damage anyone's hardware... Yes, we found the place that the vendor driver drops the power for early 8187B chips. With that fix, my device runs a lot cooler. We still have the warning that the driver is experimental, but that is mostly CYA material. The group (Hin-Tak Leung <hintak_leung.uk>, Herton Ronaldo Krzesinski <herton.br>, Pavel Roskin <proski> and me) are nearly ready to submit to the wireless list. For review purposes, the single patch has been broken into 6 different files, but in such a way that bisection will compile. Created attachment 311226 [details]
tarball patches in 6 parts, about to post to wireless-testing
difference from 310527: removed procfs, and some tidy-ups.
We have been bouncing patches to and fro about detecting early 8187b's with 8187 id (and their weaknesses) between the 4 of us - it will be up to Larry, since only he has the right hardware. I think a while back maybe another person on wireless-testing also has the same hardware though from my googling, it might be worth contacting that person. Created attachment 311231 [details]
single integrated patch
For those who prefers the convenience of the 6 patches all in one.
Those of you adventurous enough to try a rawhide kernel may want to try this one: http://koji.fedoraproject.org/koji/buildinfo?buildID=55271 Any takers? If so, is it working for you? (In reply to comment #98) > Any takers? If so, is it working for you? Just did a rpm -ivh and am running 2.6.26-0.122.rc9.git4.fc10.x86_64 right now - am surprised that it grafted on fedora 9 okay. Connectivity is alright. However as a rawhide kernel, it is a bit funny - it has libata.ko built-in rather than as a kernel module, so there was a warning during rpm -ivh, and during boot there is another warning about softreset ata1 failed (my DVD drive) - both seems to be harmless since I am playing an audio CD right now. Also I can't build fglrx's dri kernel module with its headers. I can live without dri for a while - the ati proprietary graphic driver works alright without dri - it is still better than the open-source driver at supporting the LCD's native 1280x800 resolution. Those issues are unrelated to the wireless driver, of course - I am just mentioning them so others can make up their own mind. So I'll keep running the rawhide kernel until I miss dri, or a non-rawhide kernel coming with the driver. (not-so-subtle hints...) You probably would prefer to hear from somebody else trying it out other than me :-). The rawhide kernel is doing alright - had 3GB of traffic going through in 7
hours (just normal usage + downloads).
$ ifconfig wlan2
wlan2 Link encap:Ethernet HWaddr <removed>
inet addr:192.168.0.2 Bcast:192.168.0.255 Mask:255.255.255.0
inet6 addr <removed> Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:2342147 errors:0 dropped:0 overruns:0 frame:0
TX packets:1374268 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:3490077055 (3.2 GiB) TX bytes:122068782 (116.4 MiB)
Unrelated, I also found a couple of patches to address my lack-of-fglrx-dri with
the rawhide kernel:
https://bugs.launchpad.net/ubuntu/+source/fglrx-installer/+bug/239967
Not very keen on having too many local modifications, but for the sake of
eat-my-own-dog-food, I'll run one of these rawhide kernels until an f9 update
is available.
John had built a f9 2.6.25.10 update: http://koji.fedoraproject.org/koji/buildinfo?buildID=55587 and I just using it right now. users of fedora 8, could get an update kernel-2.6.25.10-53.fc8 : http://koji.fedoraproject.org/koji/buildinfo?buildID=55723 Hey all, I've been trying to follow this thread because I have this wireless device in my laptop. To be honest, this is all over my head, so I wanted to ask if the driver was ready to be used for newbies to F9 like me? I really appreciate all the time you all have been putting in on this as it is the only reason I have not dumped Vista for Fedora. (In reply to comment #103) > I've been trying to follow this thread because I have this wireless device in > my laptop. To be honest, this is all over my head, so I wanted to ask if the > driver was ready to be used for newbies to F9 like me? You probably don't have a choice. The driver has already been incoporated into F8/F9/F10 testing, so it will arrive on your machine as an F9 update in a week or two, if you keep your system up to date. (this kind of question is not constructive - nobody knows how good/bad your competence on linux is. An f9/f8 testing kernel has been available for 10 days now, after the first slightly funny f10 - The worst thing that can happen to you is that you cannot get the device to work, which is what your current situation is.) I've been using this driver for a little while now, and I'm delighted that the network works as well as it does. I'm currently using the kernel package referenced in comment #101. However, I do have the odd case, still, where I lose connectivity, and I have to open system-config-network and stop and start the interface--sometimes more than once--to restore my connection. I wish I could give a recipe for how to make this happen, but it's infrequent, and I haven't been able to identify a trigger. This is a dual boot machine with Another Operating System, and that Other Operating System doesn't experience network stoppages (though I couldn't say whether that Other Operating System automatically re-initializes network drivers or re-negotiates connections automatically when they fail). I offer this because it makes me think it's not a hardware problem. If/When this happens again what kind of forensics could I perform that would be helpful/informative? When this driver is eventually made to work with Network Manager, would Network Manager automatically perform the re-negotiations I'm doing by hand? (In reply to comment #105) I can confirm that the occasional lost of connectivity requiring a start/stop does happen. You are not the only one. Realtek has been very co-operative - they have supplied the source of a new version of the vendor driver (which unfortunately doesn't work with recent kernels) which has some useful features like suspend/resume; and also gave us a detailed datasheet pdf. It is just the nature of constant changes in the wireless stack, and lack of time and man power that the driver is not as good/complete as it could be. Actually it is Network Manager (or rather, wpa_supplicant) which is supposed to perform re-negotiation - as part of its ability of roaming between meshes, etc - because system-config-network gears towards static/stable settings from *wired* network - so give Network Manager a try and see if negotiation/re-negotiation works? (In reply to comment #106) > Actually it is Network Manager (or rather, wpa_supplicant) which is supposed to > perform re-negotiation - as part of its ability of roaming between meshes, etc - > because system-config-network gears towards static/stable settings from *wired* > network - so give Network Manager a try and see if negotiation/re-negotiation > works? Wasn't NM/wpa_supplicant supposed to be non-functional with this driver? At least that's what the previous comments in this report suggested. I'm not sure whether this was due to the driver or due to NM needing some patches for supporting this driver, so perhaps this has all been fixed now? NM/wpa_supplicant should work with rtl8187. I know that combination works on openSUSE 11.0. Regarding NM/wpa_supplicant - Larry already said it works, but he is using the latest code. If I am to make a guess, the earlier driver code had an issue with taking time to start up (this has since been improved), and various networking tools involved - e.g. dhclient? - likes to ifconfig up/down the device as a way of resetting it or even just to set parameters - some ip parameters are not resettable while the device is up. Since NW/wpa_supplicants allows for roaming between networks and meshes (unlike system-config-network, which assumes a static set up and will wait for as long as it takes), there is the possibility of a race condition: the device taking time to go up, NW/wpa_supplicant thinks it is not working and try ifconfig down/up again and things just fall apart. The start-up time improvement is a little latter than comment 101. This is just a guess, and hope to be useful to somebody who like NM to work. kernel-2.6.25.11-97.fc9 has hit fedora 9 updates - this is the first "official" kernel update that ships the new driver, so some of us will notice that it detects and binds to the hardware at reboot, for the first time. Unfortunately some wireless protocol chanages after -93 (2 kernel test builds after -91 mentioned in comment 101) has broke the driver in later builds. This is just the people working on the protocol stacks not aware of the new driver and us not noticing developments in the protocol stacks. So apologies to those who are looking forward to running an unmodified vendor kernel (I myself is one). We are aware of the issues - we know of two, one to do with tx seq numbers and another to do with power management - and have good ideas about fixing those. Stayed tuned. I wish I saw this thread earlier. I also have one of those Toshiba Satellite laptops which has this chip (0bda:8197) embedded into the motherboard. I had been using Cuervo's driver built by myself and inserted the modules through /etc/rc.d/rc.local, in Fedora 8. But since 2.6.25.10-47, the driver (unmodified) stopped working. Then, with 2.6.25.11-60 the driver DOES recognize the device, but it fails to connect to any network (despite of security protocol, open or WEP). I'm a bit hesitant to update this laptop to F9 for a couple of reasons (graphics being one). I'd be willing to test any improvements and developments regarding this driver (and Fedora). Currently in F8 I get a message in dmesg about WLAN is one about timeout authenticating with the AP: wlan1: authenticate with AP ##:##:##:##:##:03 wlan1: authenticate with AP ##:##:##:##:##:03 wlan1: authenticate with AP ##:##:##:##:##:03 wlan1: authentication with AP ##:##:##:##:##:03 timed out I wish I could provide more information on this, but it looks like you guys have discussed all that I've found with this hardware already. If anything I think I can add something about the "loss of connectivity". With the "reference" driver (as I'll hence forth refer to Cuervo's driver) I did not experience connection "loss" as such, however there would be periods of "increased latency" at somewhat regular intervals. Funnily enough, this also is the case with that Other OS (which I'm keeping due to warranty). This may very well be the same issue you have already discussed, but wpa_supplicant successfully resetting the connection. However, nothing ever showed on dmesg to be absolutely sure that wpa_supplicant may be ifdown/ifup'ing the link. This happens at regular intervals and has more to do with traffic than time the link has been up (or maybe it would be time "transmitting" regardless of the rate and amount of data transferred?). Since I lost the ability to connect using the device, I cannot test more currently, but will be happy to add whatever information I can to this and hopefully get a fully functional driver. By the way, I noticed that the in-kernel driver also has the same limitation tha thte reference driver does: support only for WEP wireless security encryption, as that is the only option visible in NM. (In reply to comment #111) You porbably had not read this thread carefully - my comment 110 applies to f8 as well: f8 update in the last day or two gives you a kernel update which binds to the device for the first time (looks like it is "...-60"), but we already know it doesn't work. For fedora 8, you should use -53 I mentioned in comment 102, or -54: http://koji.fedoraproject.org/koji/buildinfo?buildID=55887 -60 in fedora 8 update (just like -97 in fefora 9 update) available in the last day or two, is known *not* to work. FWIW, the vendor driver supports WPA/WPA2 via a hacked up wpa_supplicant (which they shipped in a sub-directory of the vendor driver). The in-kernel driver should work with unmod'ed wpa_supplicant. For fedora 8, you should use -53 I mentioned in comment 102, or -54: http://koji.fedoraproject.org/koji/buildinfo?buildID=55887 Indeed I should have not read all too carefully. I did read that the latest update wasn't working, but may have skipped which versions *were* the working ones. Thanks for the pointers. Will install one or both these kernels and report back. Well, installed both 2.6.25.10-53 and 2.6.25.11-54. I was not able to get a connection. The error seems to be the same as with the final 2.6.25.11-60 kernel: a timeout. At this point, though I'm not sure if this is due to architectural differences, as I'm using F8 x86_64, then again, maybe not. (In reply to comment #115) The earliest version of the driver takes a bit of time to start, and you may need to try a couple of times to get a connection. Don't try to think you have the most unique problems: I am using f9.x86_64. -91.f9/-92.f9 did work alright, although I am currently using -103.f9 with additional updates now, on a Toshiba laptop. Maybe the issue is how am I trying to connect? I'm using NM only to connect wirelessly (as I did with the vendor driver). I have tried each kernel more than 5 times each before I determined it wasn't working. Every time I try to connect it times out. At least I'm hopeful that it is only a matter of time now before support for this chip is somewhat directly into the kernel. I can see my network and now with better signal strength gauge than with the reference driver, and probably by the time I decide to update the laptop (to F10) support for this chip will not be an issue. Created attachment 313057 [details] latest driver code tgz'ed. (In reply to comment #117) This is the latest driver code (I would suggest you build it against -60 in f8 or -97 in f9). To build it, follow these steps: 1) unpack with "tar -xzpvf" ; then "cd rtl8187b", and make -C /lib/modules/`uname -r`/build M=`pwd` rtl8187.ko (those are backtices, or substitute the result of "uname -r" and "pwd"). 2) replace /lib/modules/2.6.25.11-97.fc9.x86_64/kernel/drivers/net/wireless/rtl8187.ko with the newly built kernel module (possibly after back-up the shipped one). 3) run "depmod -a" to update module dependencies. Reboot or modprobe to load the kernel module, etc, and proceed as usual. I switched from scripted network to NetworkManager/ wpa_supplicant and can't get it to work reliably either - had one long good session then it won't reconnect afterwards and the driver module needs to be unloaded and reloaded to do anything useful. Larry/Herton came up with a patch to do with locking conf resource locking related to power saving. I think that might be how wpa_supplicant is not working nicely with the driver as well. I had looked at wpa_supplicant and all it does seems to be just the equivalent of a few iw*'s but in quick successions, so is probably affected by SMP systems - and it also depends on the complexity of the connectivity parameters. With this I have disconnected and reconnected a few times so NetworkManager/wpa_supplicant seems to work okay with this latest change in f9. Larry: what kind of machine (UP/SMP? x86/x86_64?) and what encryption (WEP/WPA/WPA2) are you using? My machine is an 2.0 GHz AMD Turion X2 running an x86_64 SMP system. I use WPA-PSK/TKIP encryption. With the latest 3 patches, my 8187B has been up for about 20 hours with only 1 deauthentication in that time - it automatically reauthenticated with no human intervention. This is funny... I was writing a reply to Hin-Tak Leung and my wired network started to freak out. I tried to build the code he posted but I couldn't... here's what I had written when my network started failing: "Thank you very much for this, however I don't seem able to build: make -C /lib/modules/`uname -r`/build M=`pwd` rtl8187.ko make: entering directory `/usr/src/kernels/2.6.25.11-60.fc8-x86_64' CC [M] /home/gianni/rtl8187b/rtl8180_dev.o CC [M] /home/gianni/rtl8187b/rtl8180_rtl8225.o CC [M] /home/gianni/rtl8187b/rtl8180_sa2400.o CC [M] /home/gianni/rtl8187b/rtl8180_max2820.o CC [M] /home/gianni/rtl8187b/rtl8180_grf5101.o CC [M] /home/gianni/rtl8187b/rtl8187_dev.o /home/gianni/rtl8187b/rtl8187_dev.c: In function ‘rtl8187_tx’: /home/gianni/rtl8187b/rtl8187_dev.c:245: error: ‘IEEE80211_TX_CTL_ASSIGN_SEQ’ was not declared here (first use in this function) /home/gianni/rtl8187b/rtl8187_dev.c:245: error: (Each identifier not declared is only reported once /home/gianni/rtl8187b/rtl8187_dev.c:245: error: for each function that it appears in.) make[1]: *** [/home/gianni/rtl8187b/rtl8187_dev.o] Error 1 make: *** [rtl8187.ko] Error 2 make: exiting directory `/usr/src/kernels/2.6.25.11-60.fc8-x86_64 I had to translate some stings from Spanish, so I'm sorry if they're not 100% accurate to the English version. This would look as if I'm missing an updated header file or something to that end, but since there is no error about an .h file, I have no way of knowing which might that be. Maybe a grep through the included headers from file rtl8187_dev.c might shed some light. I'm booting my F9 testing machine now to see what that file might be." I was ssh'ing my F9 machine to grep for the Macro that failed while building, trying to resurrect my network, ran out of ideas, so I reboot, and when I reboot all of a sudden at the first attempt upon reboot, wlan1 is working... HOW ODD IS THAT? I can't complain, I have wireless back... But now I fear something is wrong with the wired one :-\ Will have to test. Just wanted to point out two things: Hin-Tak thank you so very much for your perseverance, and keeping on top of this now "issue". I know I still have much more testing to do in order to assess that the WLAN is working OK now. Thanks. Secondly to all those involved at getting this chipset working with Fedora and (I'm sure) upstream in the kernel. Will reboot now and hopefully wlan1 will come up live again. (In reply to comment #120) > "Thank you very much for this, however I don't seem able to build: Building kernel modules depends on three packages, and they should all be of exact same version: kernel, kernel-devel, and kernel-headers . Grab -65.f8: http://koji.fedoraproject.org/koji/buildinfo?buildID=57827 I know what kernel modules depend up on... I just don't have that Macro defined in any of my .h files. I'll try this other kernel. As noted I was able to connect with my wireless router. But it was lost upon reboot. Thanks again for your continued efforts. And I do realise that if Linux itself is a moving target, the Mac8211 API seems to be even faster! (In reply to comment #119) > My machine is an 2.0 GHz AMD Turion X2 running an x86_64 SMP system. I use > WPA-PSK/TKIP encryption. > > With the latest 3 patches, my 8187B has been up for about 20 hours with only 1 > deauthentication in that time - it automatically reauthenticated with no human > intervention. Does NetworkManager/wpa_supplicant always work for you (without those 3 patches)? I haven't tried NW until yesterday - have the same setting for ages so running a script is easier. I had one long useful session and then many times outs without the mutex lock patch nor the improved stats patch. The hardware is essentially identical, but NetworkManager/wpa_supplicant on f9 are both dev snapshots (and I think it is the same case with NW on SUSE, but maybe not the same snapshot). IEEE80211_TX_CTL_ASSIGN_SEQ is in /usr/src/kernels/<version>/include/net/mac80211.h , and is part of the change which requires the tx seq number patch to fix; it should be in the -60.f8 devel? Without the patches, NM was hit or miss; however, using ifup never worked for me. The improved stats patch does nothing important with respect to connecting - it just makes the output be more realistic. The mutex lock patch is the critical one - this bug has been in the driver forever. It affects the RTL8187 as well as the RTL8187B. (In reply to comment #123) > > IEEE80211_TX_CTL_ASSIGN_SEQ is in > /usr/src/kernels/<version>/include/net/mac80211.h , and is part of the change > which requires the tx seq > number patch to fix; it should be in the -60.f8 devel? > For some reason, IEEE80211_TX_CTL_ASSIGN_SEQ is not defined in /usr/src/kernels/2.6.25.11-60.fc8/include/net/mac80211.h, and I do have kernel-devel installed, and the headers as you can see. Alas, I don't have that defined in there. Will try that other kernel you pointed out. Currently I've had to boot up Windows as my ethernet switch fried with the last network burp, and been unable to connect again wirelessly on Linux. At any rate, will give it another try. Currently downloading 2.6.25.13-65.fc8 (-devel and -headers of course :-) ). Created attachment 313071 [details]
mac80211.h from 2.6.25.11-60.fc8 and 2.6.25.13-65.fc8
I did a diff on both files and they turned out to be identical. So I attach the
file here. As you can see, there is no definition for
IEEE80211_TX_CTL_ASSIGN_SEQ anywhere in that file, nor any of the other
ieee80211 header files I searched. So, it seems clear, that I'm missing at
least one definition. Where did it come from?
As far as I can tell (through rpm -qf) both the files are indeed different, in
that they come from different packages. It would look like this driver code
requires an additional patch that I'm clearly missing.
Created attachment 313160 [details] latest rtl8187b code with fedora 8 (In reply to comment #126) This is the latest driver code, with V3 of the mutex patch, minus the TX seq number fix. I have tried this with 65.f8 headers, but it should work for any f8 headers from -53.f8 onwards. Don't use this with f9. IEEE80211_TX_CTL_ASSIGN_SEQ came from the fix to the TX seq number breakage, and fedora 8 didn't have the TX seq number breakage so doesn't need the fix either :-). (I assume wrongly that f8 also have most of wireless testing. While 53.f8 = 91.f9, the one that breaks with TX seq (93.f9) has no equivalent in f8). THANK YOU!!! This driver worked like a charm with 2.6.25.11-60 on F8! Any idea of when will this be included in a future update? By the way, I think I now understand what did you mean when you said that the "driver takes a bit to start". It does connect fast (as in as soon as I enter my keyring password it connects to the AP), however the WLAN won't transmit any data over the connection for several minutes. It takes a while before I can reliably use the network connection. Is this normal or just some peculiarity of my setup/driver version? (In reply to comment #128) > Any idea of when will this be included in a future update? All of it has gone into wireless-testing, so it will hopefully be the next update - finger-crossed no other changes break it before then :-). (In reply to comment #129) > By the way, I think I now understand what did you mean when you said that the > "driver takes a bit to start". It does connect fast (as in as soon as I enter my > keyring password it connects to the AP), however the WLAN won't transmit any > data over the connection for several minutes. It takes a while before I can > reliably use the network connection. Is this normal or just some peculiarity of > my setup/driver version? That's a bit wrong - how do you measure the "several minutes"? /var/log/messages is time-stamped for what NetworkManager tries to do - It is about 40 seconds here: some of it is the device taking time to start (as I wrote), some of it is wpa_supplicant noticing the device is up, and some of it is getting ip address assigned by DHCP from the AP. You can also see it graphically if you add "system monitor" to the gnome panel and configure it to display network traffic. (In reply to comment #130) > All of it has gone into wireless-testing, so it will hopefully be the next > update > - finger-crossed no other changes break it before then :-). Excellent! I hope it is! > That's a bit wrong - how do you measure the "several minutes"? > /var/log/messages is time-stamped for what NetworkManager tries to do - It is > about 40 seconds here: some of it is the device taking time to start (as I > wrote), some of it is wpa_supplicant noticing the device is up, and some of it > is getting ip address assigned by DHCP from the AP. > > You can also see it graphically if you add "system monitor" to the gnome panel > and configure it to display network traffic. What I am experiencing is that after I get a connection (authentication, IP address, etc) I have to wait for some time (anywhere between a minute to several) for the connection to actually become active. I have GKrellm running and I can see (sort of) that the connection is active with lots of outbound traffic, and very little inbound and very, very slow (20-60 bits or bytes). I have not used the laptop for the whole weekend, and as soon as I can will test again and check /var/log/messages what are wpa_supplicant or NetworkManager trying to do, as nothing shows in dmesg (which had been the only log I checked). I tried to install F9 onto my laptop today. After updating the distribution with the wired network, I rebooted into 2.6.25.14-108.fc9 kernel to find that I still cannot connect with the stock kernel driver. Now, however, I do not know which of the other driver code to try with F9. I thought the latest code would be merged to the kernel with this update, but seems it is not yet. Does the driver in 2.6.25.14-108.fc9 work for others? (In reply to comment #132) > Does the driver in 2.6.25.14-108.fc9 work for others? It works for me. But I still have NetworkManager disabled from earlier incarnations of the driver. Try disabling NetworkManager and using system-config-network. -108.fc9 was built in rawhide and a day or two older than comment 118, despite the fact it just arrived in fedora update. Please follow the instructions in comment 118. I have been using what's in comment 118 with 2.6.26.1-9.fc9/2.6.26.2-14.fc9 with Network Manager for a few weeks. Set up Gnome key-ring manager to get at the key-rings, and it is very sweet - as soon as I log into the desktop, Network Manager automatically connects to the wireless access point. Basically I have connectivity for as long as I am log-in without much effort, which is quite nice. The driver works alright with suspend/hibernate and usually just re-connect on resume or just a click over the NM icon on the desktop, so I tend to keep logging on and just suspend/resume for days. Every couple of days wpa_supplicant/NetworkManager gets a bit confused, and I found that killing wpa_supplicant (/etc/rc.d/init.d/wpa_supplicant stop) and restarting NetworkManager (/etc/rc.d/init.d/NetworkManager restart - normally wpa_supplicant is started by NM on demand) works. So there is still some issue with interaction with NM/WPAS, but killing them both once every couple of days is not too much bother. Excellent, Hin-Tak. Indeed, I ended up using that driver and crossing my fingers. It did build and worked perfectly, as a matter of fact I'm writing this using the driver. I still have the "loss of connectivity" from time to time with this driver. Characterized by the fact that even if the link is up, there is no traffic on it whatsoever. But all in all it has been working just fine. Once again, I *do* appreciate very much your efforts and dedication to this, and am very thankful for it. Indeed, enabling Key-Ring Manager to automatically unlock the key-ring NM uses is pretty sweet :-D I still have to see security support as I'd like to get back to WPA-TKIP for my home AP, and to connect in the office with WPA2. (In reply to comment #135) > I still have to see security support as I'd like to get back to WPA-TKIP for my > home AP, and to connect in the office with WPA2. Does WPA-TKIP/WPA2 not work? It is provided by the rest of the wireless stack (unlike the vendor driver which has its own [flaky/old] implementation), so it should just work. I hadn't done it yet, most likely I'll be tinkering with that later today. Thanks for the heads up, anyway. I've got a 8187 USB adapter, mounted internally in a HTPC, and with the latest Fedora 9 kernels, everything was properly detected but not really working : When reconnecting NM to my WPA-PSK protected network, if I left a ping running to some external IP address, I could see up to one go through... then nothing. I'm now using the module from comment #118 and now the same setup actually works. The only annoying leftover is that NM/iwconfig still report about 13-14% signal strength for all available WIFI networks, but that's very minor. Thanks a lot for all this testing and these patches! Is your card an RTL8187 or an 8187B? I modified the wireless statistics for the 8187B to provide something useful, but as I did not have an 8187, I had to leave the original code. Larry (In reply to comment #139) > Is your card an RTL8187 or an 8187B? I have no idea. It's a USB "stick", internally mounted and connected to an internal USB connector of an ATX motherboard. I bought it last month. Here's part of the lsusb -v output for it: Bus 001 Device 003: ID 0bda:8187 Realtek Semiconductor Corp. RTL8187 Wireless Ad apter Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 idVendor 0x0bda Realtek Semiconductor Corp. idProduct 0x8187 RTL8187 Wireless Adapter bcdDevice 1.00 iManufacturer 1 iProduct 2 iSerial 3 bNumConfigurations 1 [...] Right now I'm running 2.6.25.14-108.fc9.x86_64 with the included module and it seems to be working too, but with the 13% signal reported. I could have sworn I was having issues yesterday with that very same kernel... but maybe it was after a suspend/resume. It is an 8187, not an 8187B. If I were to prepare a patch with revised wireless statistics, could you recompile the driver and test it? Larry (In reply to comment #141) > It is an 8187, not an 8187B. > > If I were to prepare a patch with revised wireless statistics, could you > recompile the driver and test it? Of course! Just mention if it's a patch against the tarball from comment #118 or against the sources of a given fc9 kernel, and I'll go ahead and test it. Created attachment 314630 [details] Patch for 8187 wireless statistics This patch is against the mainline kernel, but it should apply to the tarball from comment #118. If it does not apply, please let me know. As you test this, please report the quality, signal level, and distance to each AP that is reported. If you have another wireless card, the data it reports would be useful as well. The calculation in this version is the same as for the 8187B, and the constants will likely need tweaking. Larry (In reply to comment #73) > Yes, it is connected to the network via wireless, with the driver from Axel's > site. I am typing this on the laptop as I speak. FYI I am using the regular > network service, not NM. I updated the kmdls to the attachment in comment #118. It only builds for F8/F9, so no RHEL builds anymore. The driver works here under F9/x86_64 with kernel 108. If I move away (10m in the building) from the AP it stops working w/o any indication in NM or dmesg/logs, so something is still amiss with the error recovery I guess. Anyway for everyone testing along you can install the driver from ATrpms with yum install rtl8187 it will pull along the kmdl as rtl8187-kmdl-2.6.25.14-108.fc9 currently. You will have to rmmod the old module and modprobe it again to get the new one, or if you want to play it safe better reboot. Thanks for the work on the driver! I finally can do some work w/o carrying an extra dongle along! (In reply to comment #143) > This patch is against the mainline kernel, but it should apply to the tarball > from comment #118. If it does not apply, please let me know. This is what I get against the tarball from comment #118, I haven't checked any further : # patch -p4 --dry-run < ../patch patching file rtl8187_dev.c Hunk #1 FAILED at 296. Hunk #2 succeeded at 1034 (offset -12 lines). 1 out of 3 hunks FAILED -- saving rejects to file rtl8187_dev.c.rej I'll try to get the latest mainline kernel and do an out of tree rebuild of the patched module, hoping that'll work. (In reply to comment #144 and comment #145) After establishing connnectivity, NetworkManager/wpa_supplicant only scan the network once every minute or so to confirm, I think, so it takes some time for it to notice an AP is gone. But you should see something in /var/log/wpa_supplicant.log and dmesg eventually. comment #118 is basically wireless-testing (and -108.fc9 is a slightly older wireless testing) so patch against main line kernel probably does not work on top of it... Created attachment 314650 [details] Patch for 8187 wireless statistics (revised) I fixed the failure of the previous patch. This one will apply against the attachment comment #118. Sorry about the problem. Larry There is a new f9 kernel (2.6.26.3-17.fc9): http://koji.fedoraproject.org/koji/buildinfo?buildID=59863 It isn't wireless-testing but seems to have all the good bits - am using it right now, the first unmod'ed working kernel since 2.6.25.11-92.fc9. (mentioned in comment #110). The equivalent f8 kernel 2.6.26.3-5.fc8 to the previous comment: http://koji.fedoraproject.org/koji/buildinfo?buildID=59986 (In reply to comment #147) > Created an attachment (id=314650) [details] > Patch for 8187 wireless statistics (revised) > > I fixed the failure of the previous patch. This one will apply against the > attachment comment #118. I've tested these changes, patching the code from comment #118. Things don't seem quite right : * Networks which are usually at 50-70% are now always at 100% * Networks which are lower than 50% are now at 20-30% maximum * No networks are in between 30% and 100% (these are estimates from looking at the nm-applet bars, not iwconfig) When moving my antenna around, my own network would always stay below 20% and when going even lower (10% or less) it sometimes reported 100% all of a sudden for a few seconds... there is no way this can be true since it was always with more objects in the way. Here I was running "watch iwconfig wlan0" to see it. The connection itself it working okay. Definitely not as well as from my laptop (ipw2200) when put in the same location, though. A few days ago I decided to send an e-mail to Realtek regarding this issue. Today I received a reply containing Linux drivers for the RTL8187b. I have uploaded these drivers, perhaps they will be useful to someone else who needs them. http://www.sictaar.com/files/rtl8187B_linux_26.1033.0611.2008_LedDefault.tar.gz I have not personally tested these drivers as of yet. This driver is greatly inferior to the one in kernel 2.6.27-rc8. Larry (In reply to comment #151) As Larry said, we knew about the vendor driver and it is inferior (64-bit portability issue, requires customized wpa_supplicant to work, based on old kernel and obsolete wireless stack, etc). I am using http://koji.fedoraproject.org/koji/packageinfo?packageID=8 mostly, which is ahead of fedora update, and the only issue is that after suspend/resume occasionally I need to "/etc/rc.d/init.d/wpa_supplicant stop" a few times (wpa_supplicant is persistent) and "/etc/rc.d/init.d/NetworkManager restart" to re-establish connectivity. That's probably suspend/resume bug to do with wpa_supplicant/Networkmanager. According to https://admin.fedoraproject.org/updates/kernel kernel-2.6.26.3-29.fc9 kernel-2.6.26.3-14.fc8 are out as updates, so this bug should be considered fixed. Anybody feel strongly against this bug being resolved as fixed? I realize I'm no expert in kernel device drivers, but when I tested the newest kernel (2.6.27-rc4) the performance of the RTL8187B device driver was less than spectacular. When connecting to a network the performance was abysmal and the connection was unreliable. These new drivers from Realtek (8-8-08) seem to be working for now (WEP and WPA). I am willing to test any new kernel updates on my hardware. Sorry for the double post, when I said newest I meant the newest kernel in the latest ubuntu repo, which is 2.6.27-rc4. I realize that the newest vanilla kernel is rc8. Closing based on upstream status, availability of driver in Fedora, and comment 153. "Less than spectacular" performance of the community driver is far from justification for merging a vendor driver... :-) Actually, I don't feel that the vendor driver should be merged, I was just comparing the performance of the new kernel driver with the one sent by Realtek. (In reply to comment #157) > Actually, I don't feel that the vendor driver should be merged, I was just > comparing the performance of the new kernel driver with the one sent by > Realtek. I wonder what performance matrix you are basing your comment on. In my usage - connecting two computers, the other machine acts as cable-uplink - I can get about 230kB/s with wget, which is about the same as the advertised cable speed (2Mb/s), and just between machines, I get about 350kB/s, which is limited by the other machine having its interface on usb 1.0(?) and running at 802.11b mode; both of these numbers are close to the theorectical maximum. As for the issue with suspend/resume, if I remember correctly the vendor driver actually do some very very bad things in those circumstances, so it isn't any better in any sense of the word. I don't want to sound defensive, but we can only try, if you can be a little bit more specific than just "less than spectacular". I have posted another bug report on bugzilla.kernel.org, you may find additional information about my performance problems there. http://bugzilla.kernel.org/show_bug.cgi?id=11680 (In reply to comment #159) You missed on crucial piece of information - which version of wpa_supplicant you are running. Specifically, whether you are running the vendor's outdated and modified bundled wpa_supplicant, instead of an unmodified but up-to-date one. Mix-and-match (vendor wpa_supplicant with community driver or unmod'ed wpa_supplicant with vendor driver) is not likely to work well. The pause every 15-30 seconds sounds like wpa_supplicant problem. wpa_supplicant polls the kernel driver over that kind of period to feed the signal strengths, etc back up d-bus to NetworkManager's applet; and if you are using the vendor's wpa_supplicant, it is likely to be disruptive. You can test this shutting down wpa_supplicant and NetworkManager and configure networking by good old fashioned means, to see if you can get rid of the pause. If that works, please close the kernel bug report. Does the new kernel driver use wpa_supplicant as well? michael@michael-laptop:/wifi$ wpa_supplicant -v wpa_supplicant v0.5.8 Copyright (c) 2003-2007, Jouni Malinen <j> and contributors As far as I know, I'm not using the vendor's wpa_supplicant driver. The sources are included in the vender driver sent by Realtek, but they are unused. The wpa_supplicant driver I am using is provided by my Ubuntu distribution. I disabled NetworkManager and wpa_supplicant in order to accurately test the new kernel driver. I found that the connection still stops after 2-3 minutes. wpa_supplicant may be responsible for the intermittent speed problems, but the real issue concerning the driver is still present. I am using wpa_supplicant 0.6.3 (there is a 0.6.4 in rawhide). Note that wpa_supplicant is very persistent and you have to kill it a few times before it would go away, and do 'ps -ef |grep wpa' to make sure. I have re-run the test and NetworkManager and wpa_supplicant were killed. I suspect that this discussion would be best conducted here: http://bugzilla.kernel.org/show_bug.cgi?id=9143 |