Bug 432280 - Realtek 8187B wireless support with product id 0x8197/0x8189
Realtek 8187B wireless support with product id 0x8197/0x8189
Status: CLOSED UPSTREAM
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
8
All Linux
medium Severity low
: ---
: ---
Assigned To: John W. Linville
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-02-10 16:24 EST by Hin-Tak Leung
Modified: 2008-10-03 10:49 EDT (History)
13 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-09-30 09:35:40 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
realtek's official driver, hosted on a 3rd party site (855.03 KB, application/octet-stream)
2008-02-10 16:24 EST, Hin-Tak Leung
no flags Details
This is the diff made by the 3rd party site owner (1.94 KB, patch)
2008-02-10 16:26 EST, Hin-Tak Leung
no flags Details | Diff
This is the diff I am using myself (1.14 KB, patch)
2008-02-10 16:28 EST, Hin-Tak Leung
no flags Details | Diff
dkms configuration file (915 bytes, text/plain)
2008-02-15 18:32 EST, Hin-Tak Leung
no flags Details
additional patch for 2.6.24 (6.21 KB, patch)
2008-03-22 20:40 EDT, Hin-Tak Leung
no flags Details | Diff
rtl8187b.patch (38.58 KB, patch)
2008-04-22 13:16 EDT, John W. Linville
no flags Details | Diff
patch ripped out of the kmdl rpm (41.44 KB, patch)
2008-04-30 10:06 EDT, Hin-Tak Leung
no flags Details | Diff
usb endpoint 12 for management frames (986 bytes, patch)
2008-05-13 02:38 EDT, Hin-Tak Leung
no flags Details | Diff
THe last two kernel modules (x86_64) I used successfully. (301.92 KB, application/octet-stream)
2008-05-21 09:18 EDT, Hin-Tak Leung
no flags Details
Naive patch so module will build under kernel-2.6.25.4-30.fc9.i686 (1.31 KB, text/x-patch)
2008-06-07 20:26 EDT, Alan Schmidt
no flags Details
integrated patch to build against 2.6.25.6-55.fc9.x86_64 (40.16 KB, patch)
2008-06-14 20:15 EDT, Hin-Tak Leung
no flags Details | Diff
replacement for integrated patch 309378 (42.01 KB, patch)
2008-06-29 02:11 EDT, Hin-Tak Leung
no flags Details | Diff
tarball patches in 6 parts, about to post to wireless-testing (10.77 KB, application/x-compressed-tar)
2008-07-08 01:32 EDT, Hin-Tak Leung
no flags Details
single integrated patch (43.94 KB, patch)
2008-07-08 01:51 EDT, Hin-Tak Leung
no flags Details | Diff
latest driver code tgz'ed. (31.95 KB, application/octet-stream)
2008-07-30 20:25 EDT, Hin-Tak Leung
no flags Details
mac80211.h from 2.6.25.11-60.fc8 and 2.6.25.13-65.fc8 (64.13 KB, application/octet-stream)
2008-07-31 02:33 EDT, Gian Paolo Mureddu
no flags Details
latest rtl8187b code with fedora 8 (31.72 KB, application/octet-stream)
2008-07-31 23:51 EDT, Hin-Tak Leung
no flags Details
Patch for 8187 wireless statistics (2.14 KB, patch)
2008-08-20 10:01 EDT, Larry Finger
no flags Details | Diff
Patch for 8187 wireless statistics (revised) (2.07 KB, patch)
2008-08-20 14:50 EDT, Larry Finger
no flags Details | Diff


External Trackers
Tracker ID Priority Status Summary Last Updated
Linux Kernel 10900 None None None Never

  None (edit)
Description Hin-Tak Leung 2008-02-10 16:24:08 EST
Description of problem:

The shipped kernel does not support the realtek wireless 8197B chip with a
product id 0x8197 (or 0x8189 for that matter). 

Version-Release number of selected component (if applicable):

kernel-2.6.23.14-107.fc8

How reproducible:

Always

Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:

I am just filing this bug so that I can attach the files/notes and patches...
Comment 1 Hin-Tak Leung 2008-02-10 16:24:08 EST
Created attachment 294513 [details]
realtek's official driver, hosted on a 3rd party site
Comment 2 Hin-Tak Leung 2008-02-10 16:26:42 EST
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
Comment 3 Hin-Tak Leung 2008-02-10 16:28:46 EST
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.
Comment 4 Hin-Tak Leung 2008-02-10 16:29:59 EST
The 3rd party site is:

http://www.datanorth.net/~cuervo/rtl8187b/
Comment 5 Hin-Tak Leung 2008-02-15 18:32:18 EST
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)?
Comment 6 John W. Linville 2008-02-16 17:59:23 EST
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!
Comment 7 Hin-Tak Leung 2008-02-16 19:13:04 EST
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...
Comment 8 Hin-Tak Leung 2008-03-12 16:28:49 EDT
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.
Comment 9 John W. Linville 2008-03-18 13:07:54 EDT
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!
Comment 10 Hin-Tak Leung 2008-03-22 20:40:11 EDT
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.*
Comment 11 Axel Thimm 2008-03-30 09:04:11 EDT
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).
Comment 12 Axel Thimm 2008-04-21 18:29:41 EDT
John, any chance you could find some time to look at this? Thanks!
Comment 13 John W. Linville 2008-04-22 13:16:21 EDT
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?
Comment 14 Axel Thimm 2008-04-22 16:18:42 EDT
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.
Comment 15 Axel Thimm 2008-04-23 12:09:54 EDT
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

Comment 16 Hin-Tak Leung 2008-04-28 16:21:34 EDT
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. 
Comment 17 Hin-Tak Leung 2008-04-28 17:00:10 EDT
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.
Comment 18 Hin-Tak Leung 2008-04-29 21:19:34 EDT
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)
Comment 19 Axel Thimm 2008-04-30 03:40:03 EDT
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.
Comment 20 Hin-Tak Leung 2008-04-30 10:00:48 EDT
(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?
Comment 21 Hin-Tak Leung 2008-04-30 10:06:45 EDT
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.
Comment 22 Axel Thimm 2008-04-30 11:41:11 EDT
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.
Comment 23 Hin-Tak Leung 2008-04-30 13:40:14 EDT
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.
Comment 24 Hin-Tak Leung 2008-05-03 01:10:04 EDT
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...
Comment 25 Axel Thimm 2008-05-03 03:30:55 EDT
(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.
Comment 26 Hin-Tak Leung 2008-05-03 19:56:36 EDT
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.


Comment 27 Hin-Tak Leung 2008-05-03 19:57:32 EDT
oh, and the 'event too big' log is also a bit curious.
Comment 28 John W. Linville 2008-05-05 10:27:15 EDT
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?
Comment 29 Hin-Tak Leung 2008-05-05 11:37:35 EDT
(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.
Comment 30 Hin-Tak Leung 2008-05-08 22:36:09 EDT
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!). 
 
Comment 31 Hin-Tak Leung 2008-05-08 23:30:38 EDT
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).  
Comment 32 Axel Thimm 2008-05-08 23:46:27 EDT
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).
Comment 33 Hin-Tak Leung 2008-05-09 00:32:40 EDT
(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).
Comment 34 Hin-Tak Leung 2008-05-09 17:47:12 EDT
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).
Comment 35 Axel Thimm 2008-05-10 01:13:16 EDT
(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.
Comment 36 Hin-Tak Leung 2008-05-10 02:26:38 EDT
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.
Comment 37 Hin-Tak Leung 2008-05-12 01:40:13 EDT
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. 
Comment 38 Mike Chambers 2008-05-12 12:00:52 EDT
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?
Comment 39 Hin-Tak Leung 2008-05-13 02:38:11 EDT
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.
Comment 40 Hin-Tak Leung 2008-05-13 02:41:33 EDT
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
Comment 41 Mike Chambers 2008-05-13 02:58:32 EDT
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
Comment 42 Hin-Tak Leung 2008-05-13 03:04:22 EDT
(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 43 Hin-Tak Leung 2008-05-13 03:34:46 EDT
Comment on attachment 304231 [details]
patch ripped out of the kmdl rpm

changing mine-type so that it is browser-viewable
Comment 44 Hin-Tak Leung 2008-05-14 13:08:30 EDT
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.
Comment 45 Hin-Tak Leung 2008-05-15 19:00:40 EDT
shared key/WEP works with the new driver. (unlike the old, which kernel oops on it)
Comment 46 Axel Thimm 2008-05-16 00:38:54 EDT
(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)
Comment 47 Mike Chambers 2008-05-16 02:24:15 EDT
Sooo, what can someone do to try this out and see if it works with F9?  Baby
steps haha
Comment 48 Hin-Tak Leung 2008-05-16 06:20:04 EDT
(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>
Comment 49 Hin-Tak Leung 2008-05-16 06:26:35 EDT
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 :-))


Comment 50 Axel Thimm 2008-05-16 08:37:59 EDT
(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.
Comment 51 Axel Thimm 2008-05-16 08:40:44 EDT
(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.
Comment 52 Mike Chambers 2008-05-16 14:20:06 EDT
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.
Comment 53 Hin-Tak Leung 2008-05-16 15:09:35 EDT
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.




Comment 54 Hin-Tak Leung 2008-05-16 15:11:35 EDT
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...
Comment 55 Mike Chambers 2008-05-16 15:48:28 EDT
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.
Comment 56 Hin-Tak Leung 2008-05-16 16:14:43 EDT
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.
   
Comment 57 Mike Chambers 2008-05-17 02:47:20 EDT
(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".
Comment 58 Hin-Tak Leung 2008-05-17 03:52:28 EDT
(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. 
Comment 59 Mike Chambers 2008-05-17 10:06:51 EDT
It's connected via usb I guess, as lsusb shows the driver.
Comment 60 Hin-Tak Leung 2008-05-20 22:29:46 EDT
(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).

Comment 61 Hin-Tak Leung 2008-05-20 22:34:51 EDT
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.
Comment 62 Mike Chambers 2008-05-21 02:16:26 EDT
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?
Comment 63 Axel Thimm 2008-05-21 04:55:59 EDT
(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).
Comment 64 Hin-Tak Leung 2008-05-21 09:18:46 EDT
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.
Comment 65 Alan Schmidt 2008-05-22 20:41:12 EDT
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.
Comment 66 Hin-Tak Leung 2008-05-22 21:18:09 EDT
(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).
Comment 67 Alan Schmidt 2008-05-23 00:08:38 EDT
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.
Comment 68 Hin-Tak Leung 2008-05-23 00:35:44 EDT
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...) 

 
Comment 69 Mike Chambers 2008-05-23 02:53:52 EDT
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)?
Comment 70 Hin-Tak Leung 2008-05-23 10:47:12 EDT
(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.
Comment 71 Mike Chambers 2008-05-23 13:16:25 EDT
(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.
Comment 72 Hin-Tak Leung 2008-05-23 13:37:23 EDT
(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.
Comment 73 Mike Chambers 2008-05-23 14:56:41 EDT
(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?).
Comment 74 Mike Chambers 2008-05-25 00:24:47 EDT
Had problems and have returned the laptop to best buy.  Hope you guys get
everything working OK, so good luck.
Comment 75 Alan Schmidt 2008-06-07 20:26:39 EDT
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.
Comment 76 Hin-Tak Leung 2008-06-08 23:33:48 EDT
(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


Comment 77 Hin-Tak Leung 2008-06-08 23:35:08 EDT
(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!
Comment 78 Hin-Tak Leung 2008-06-08 23:42:01 EDT
*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?...
Comment 79 Hin-Tak Leung 2008-06-10 21:46:58 EDT
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... :-).
Comment 80 Alan Schmidt 2008-06-13 22:55:18 EDT
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.
Comment 81 Hin-Tak Leung 2008-06-14 11:55:31 EDT
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. 
 
Comment 82 Hin-Tak Leung 2008-06-14 20:07:20 EDT
(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
Comment 83 Hin-Tak Leung 2008-06-14 20:15:21 EDT
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.
Comment 84 Hin-Tak Leung 2008-06-14 20:16:56 EDT
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...
Comment 85 Alan Schmidt 2008-06-17 00:16:42 EDT
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.
Comment 86 Hin-Tak Leung 2008-06-18 20:24:19 EDT
(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. 
Comment 87 Matthew Garrett 2008-06-23 13:57:11 EDT
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.
Comment 88 Hin-Tak Leung 2008-06-24 19:23:01 EDT
(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...)
Comment 89 Larry Finger 2008-06-25 14:39:31 EDT
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.

Comment 90 Hin-Tak Leung 2008-06-29 02:11:42 EDT
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.
Comment 91 Hin-Tak Leung 2008-07-01 18:00:21 EDT
(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.
Comment 92 Martin Stadtler 2008-07-02 12:53:17 EDT
Watching this bugzilla, for personal Gateway M1600 that has 8187B for internal
wireless.  System is F9 running 2.6.25.9-76.fc9.i686.
Comment 93 John W. Linville 2008-07-07 14:25:15 EDT
"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...
Comment 94 Larry Finger 2008-07-07 16:44:58 EDT
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@yahoo.co.uk>, Herton Ronaldo Krzesinski
<herton@mandriva.com.br>, Pavel Roskin <proski@gnu.org> 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.
Comment 95 Hin-Tak Leung 2008-07-08 01:32:54 EDT
Created attachment 311226 [details]
tarball patches in 6 parts, about to post to wireless-testing

difference from 310527: removed procfs, and some tidy-ups.
Comment 96 Hin-Tak Leung 2008-07-08 01:39:58 EDT
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. 
Comment 97 Hin-Tak Leung 2008-07-08 01:51:32 EDT
Created attachment 311231 [details]
single integrated patch

For those who prefers the convenience of the 6 patches all in one.
Comment 98 John W. Linville 2008-07-09 10:03:38 EDT
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?
Comment 99 Hin-Tak Leung 2008-07-09 14:39:29 EDT
(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 :-).
Comment 100 Hin-Tak Leung 2008-07-10 13:38:53 EDT
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.

 
Comment 101 Hin-Tak Leung 2008-07-10 20:37:33 EDT
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.
Comment 102 Hin-Tak Leung 2008-07-11 17:11:14 EDT
users of fedora 8, could get an update kernel-2.6.25.10-53.fc8 :

http://koji.fedoraproject.org/koji/buildinfo?buildID=55723
Comment 103 Jonathan Taylor 2008-07-18 23:55:09 EDT
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.


Comment 104 Hin-Tak Leung 2008-07-19 09:00:36 EDT
(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.)
Comment 105 Alan Schmidt 2008-07-23 12:26:41 EDT
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?
Comment 106 Hin-Tak Leung 2008-07-24 19:22:08 EDT
(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? 
Comment 107 Axel Thimm 2008-07-25 10:56:37 EDT
(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?
Comment 108 Larry Finger 2008-07-25 11:08:30 EDT
NM/wpa_supplicant should work with rtl8187. I know that combination works on
openSUSE 11.0.
Comment 109 Hin-Tak Leung 2008-07-25 17:26:21 EDT
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.
Comment 110 Hin-Tak Leung 2008-07-26 20:36:11 EDT
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.
Comment 111 Gian Paolo Mureddu 2008-07-28 18:14:17 EDT
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. 
Comment 112 Hin-Tak Leung 2008-07-28 19:19:35 EDT
(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.
Comment 113 Hin-Tak Leung 2008-07-28 19:24:45 EDT
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
Comment 114 Gian Paolo Mureddu 2008-07-28 19:58:45 EDT
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. 
Comment 115 Gian Paolo Mureddu 2008-07-28 20:53:51 EDT
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.
Comment 116 Hin-Tak Leung 2008-07-28 23:12:32 EDT
(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.
Comment 117 Gian Paolo Mureddu 2008-07-28 23:54:09 EDT
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.
Comment 118 Hin-Tak Leung 2008-07-30 20:25:32 EDT
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?
Comment 119 Larry Finger 2008-07-30 21:33:41 EDT
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.
Comment 120 Gian Paolo Mureddu 2008-07-30 21:59:06 EDT
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.
Comment 121 Hin-Tak Leung 2008-07-30 22:19:23 EDT
(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
Comment 122 Gian Paolo Mureddu 2008-07-30 22:31:10 EDT
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!
Comment 123 Hin-Tak Leung 2008-07-30 22:44:52 EDT
(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?
Comment 124 Larry Finger 2008-07-30 22:59:48 EDT
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.
Comment 125 Gian Paolo Mureddu 2008-07-31 00:55:05 EDT
(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 :-) ).
Comment 126 Gian Paolo Mureddu 2008-07-31 02:33:56 EDT
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.
Comment 127 Hin-Tak Leung 2008-07-31 23:51:17 EDT
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).
Comment 128 Gian Paolo Mureddu 2008-08-01 00:59:32 EDT
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?
Comment 129 Gian Paolo Mureddu 2008-08-01 12:14:27 EDT
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?
Comment 130 Hin-Tak Leung 2008-08-04 11:34:40 EDT
(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.
Comment 131 Gian Paolo Mureddu 2008-08-04 16:02:37 EDT
(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).
Comment 132 Gian Paolo Mureddu 2008-08-13 21:47:37 EDT
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?
Comment 133 Alan Schmidt 2008-08-13 23:09:54 EDT
(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.
Comment 134 Hin-Tak Leung 2008-08-14 04:56:00 EDT
-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.
Comment 135 Gian Paolo Mureddu 2008-08-14 21:45:33 EDT
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.
Comment 136 Hin-Tak Leung 2008-08-15 16:04:45 EDT
(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.
Comment 137 Gian Paolo Mureddu 2008-08-17 10:10:16 EDT
I hadn't done it yet, most likely I'll be tinkering with that later today. Thanks for the heads up, anyway.
Comment 138 Matthias Saou 2008-08-19 15:44:55 EDT
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!
Comment 139 Larry Finger 2008-08-19 16:14:41 EDT
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
Comment 140 Matthias Saou 2008-08-20 08:09:07 EDT
(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.
Comment 141 Larry Finger 2008-08-20 08:46:42 EDT
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
Comment 142 Matthias Saou 2008-08-20 09:30:46 EDT
(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.
Comment 143 Larry Finger 2008-08-20 10:01:13 EDT
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
Comment 144 Axel Thimm 2008-08-20 10:23:54 EDT
(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!
Comment 145 Matthias Saou 2008-08-20 14:22:31 EDT
(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.
Comment 146 Hin-Tak Leung 2008-08-20 14:38:57 EDT
(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...
Comment 147 Larry Finger 2008-08-20 14:50:33 EDT
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
Comment 148 Hin-Tak Leung 2008-08-23 16:55:14 EDT
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).
Comment 149 Hin-Tak Leung 2008-08-24 19:21:40 EDT
The equivalent f8 kernel 2.6.26.3-5.fc8 to the previous comment:
http://koji.fedoraproject.org/koji/buildinfo?buildID=59986
Comment 150 Matthias Saou 2008-08-25 05:15:08 EDT
(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.
Comment 151 Michael Short 2008-09-29 21:32:32 EDT
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.
Comment 152 Larry Finger 2008-09-29 22:01:03 EDT
This driver is greatly inferior to the one in kernel 2.6.27-rc8.

Larry
Comment 153 Hin-Tak Leung 2008-09-29 22:43:14 EDT
(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?
Comment 154 Michael Short 2008-09-29 23:37:07 EDT
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.
Comment 155 Michael Short 2008-09-29 23:38:20 EDT
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.
Comment 156 John W. Linville 2008-09-30 09:35:40 EDT
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... :-)
Comment 157 Michael Short 2008-09-30 11:24:12 EDT
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.
Comment 158 Hin-Tak Leung 2008-09-30 15:00:02 EDT
(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".
Comment 159 Michael Short 2008-10-02 17:15:08 EDT
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
Comment 160 Hin-Tak Leung 2008-10-02 19:27:12 EDT
(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.
Comment 161 Michael Short 2008-10-03 08:48:28 EDT
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@w1.fi> 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.
Comment 162 Michael Short 2008-10-03 09:18:21 EDT
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.
Comment 163 Hin-Tak Leung 2008-10-03 10:00:29 EDT
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.
Comment 164 Michael Short 2008-10-03 10:15:22 EDT
I have re-run the test and NetworkManager and wpa_supplicant were killed.
Comment 165 John W. Linville 2008-10-03 10:49:57 EDT
I suspect that this discussion would be best conducted here:

   http://bugzilla.kernel.org/show_bug.cgi?id=9143

Note You need to log in before you can comment on or make changes to this bug.