rtl8187b Problem with tx level

rtl8187b Problem with tx level

[Tobias Schlemmer]

[-- Attachment #1: Type: text/plain, Size: 1527 bytes --]

Hi,

I have some problem with my rtl8187b device. It is included in my laptop 
running Ubuntu linux 2.6.28. I've tested several compat-wireless 
releases including 2.6.30 and 2.6.31-rc7.

The problem is that the network adapter looses the connection to the 
access point at very low distances. It seems to be as if the driver is 
too optimistic about tx power. I monitored the singnal strength on the 
access point (Buffalo running DD-WRT). When I associate the laptop with 
it the recieved signal strength starts full and drops rapidly in the 
first seconds. At the end it is about 0 at a distance of 4m. At this 
moment no ping will arrive the destination. Tests with other access 
points show similar results.

After several attempts to get different drivers working I used an Ubuntu 
8.04 boot CD this morning which seems to work out of the box. It has 
kernel 2.6.24 using a module called r8187. I compared these two drivers 
and got much better signal strengths, at least more stable connections. 
Maybe it's interesting that the two drivers report different signal 
strength (compat-wireless reports about 10dBm higher values than the old 
driver) also in signal quality the compat wireless driver seems to be 
more optimistic.

Interestingly iwconfig always reports TX power of 20dBm, regardless of 
the actual tx power, but always a TX rate of 1M. Setting the latter to a 
higher value results in packet loss.

As I leave for holidays on Tuesday I can give further information only 
tomorrow and in two weeks.

Tobias

[-- Attachment #2: eventlog --]
[-- Type: text/plain, Size: 3844 bytes --]

Log of iw event -t 
Sun Aug 30 21:26:57 2009

iwdied with signal 2

Sun Aug 30 21:27:22 2009
----------------
1251660460.087134: wlan0 (phy #0): scan finished: 2412 2417 2422 2427 2432 2437 2442 2447 2452 2457 2462 2467 2472 2484, ""
1251660481.753561: wlan0 (phy #0): disassoc 00:16:44:fb:52:6c -> 00:17:3f:7e:ab:08 reason 1: Unspecified
1251660486.831135: wlan0 (phy #0): scan finished: 2412 2417 2422 2427 2432 2437 2442 2447 2452 2457 2462 2467 2472 2484, ""
1251660487.041865: wlan0 (phy #0): auth 00:17:3f:7e:ab:08 -> 00:16:44:fb:52:6c status: 0: Successful
1251660487.050600: wlan0 (phy #0): assoc 00:17:3f:7e:ab:08 -> 00:16:44:fb:52:6c status: 0: Successful
1251660588.213505: wlan0 (phy #0): deauth 00:16:44:fb:52:6c -> 00:17:3f:7e:ab:08 reason 3: Deauthenticated because sending station is leaving (or has left) the IBSS or ESS
1251660600.900453: wlan0 (phy #0): scan aborted: 2412 2417 2422 2427 2432 2437 2442 2447 2452 2457 2462 2467 2472 2484, ""
1251660607.237699: wlan0 (phy #0): disassoc 00:16:44:fb:52:6c -> 00:17:3f:7e:ab:08 reason 1: Unspecified
1251660613.427166: wlan0 (phy #0): scan finished: 2412 2417 2422 2427 2432 2437 2442 2447 2452 2457 2462 2467 2472 2484, ""
1251660614.348485: wlan0 (phy #0): auth: timed out
1251660620.263160: wlan0 (phy #0): scan finished: 2412 2417 2422 2427 2432 2437 2442 2447 2452 2457 2462 2467 2472 2484, ""
1251660621.152487: wlan0 (phy #0): auth: timed out
1251660626.311193: wlan0 (phy #0): scan finished: 2412 2417 2422 2427 2432 2437 2442 2447 2452 2457 2462 2467 2472 2484, ""
1251660627.200489: wlan0 (phy #0): auth: timed out
1251660632.359167: wlan0 (phy #0): scan finished: 2412 2417 2422 2427 2432 2437 2442 2447 2452 2457 2462 2467 2472 2484, ""
1251660633.248491: wlan0 (phy #0): auth: timed out
1251660638.415165: wlan0 (phy #0): scan finished: 2412 2417 2422 2427 2432 2437 2442 2447 2452 2457 2462 2467 2472 2484, ""
1251660639.304490: wlan0 (phy #0): auth: timed out
1251660644.467730: wlan0 (phy #0): scan finished: 2412 2417 2422 2427 2432 2437 2442 2447 2452 2457 2462 2467 2472 2484, ""
1251660645.356493: wlan0 (phy #0): auth: timed out
1251660650.519172: wlan0 (phy #0): scan finished: 2412 2417 2422 2427 2432 2437 2442 2447 2452 2457 2462 2467 2472 2484, ""
1251660651.419254: wlan0 (phy #0): auth: timed out
1251660656.587182: wlan0 (phy #0): scan finished: 2412 2417 2422 2427 2432 2437 2442 2447 2452 2457 2462 2467 2472 2484, ""
1251660657.512517: wlan0 (phy #0): auth: timed out
1251660662.655181: wlan0 (phy #0): scan finished: 2412 2417 2422 2427 2432 2437 2442 2447 2452 2457 2462 2467 2472 2484, ""
1251660663.532509: wlan0 (phy #0): auth: timed out
1251660668.711181: wlan0 (phy #0): scan finished: 2412 2417 2422 2427 2432 2437 2442 2447 2452 2457 2462 2467 2472 2484, ""
1251660669.588513: wlan0 (phy #0): auth: timed out
1251660674.779164: wlan0 (phy #0): scan finished: 2412 2417 2422 2427 2432 2437 2442 2447 2452 2457 2462 2467 2472 2484, ""
1251660675.656519: wlan0 (phy #0): auth: timed out
1251660680.943163: wlan0 (phy #0): scan finished: 2412 2417 2422 2427 2432 2437 2442 2447 2452 2457 2462 2467 2472 2484, ""
1251660681.836528: wlan0 (phy #0): auth: timed out
1251660686.879163: wlan0 (phy #0): scan finished: 2412 2417 2422 2427 2432 2437 2442 2447 2452 2457 2462 2467 2472 2484, ""
1251660687.768520: wlan0 (phy #0): auth: timed out
1251660692.927168: wlan0 (phy #0): scan finished: 2412 2417 2422 2427 2432 2437 2442 2447 2452 2457 2462 2467 2472 2484, ""
1251660693.816525: wlan0 (phy #0): auth: timed out
1251660698.975165: wlan0 (phy #0): scan finished: 2412 2417 2422 2427 2432 2437 2442 2447 2452 2457 2462 2467 2472 2484, ""
1251660699.400865: wlan0 (phy #0): auth 00:17:3f:7e:ab:08 -> 00:16:44:fb:52:6c status: 0: Successful
1251660699.412964: wlan0 (phy #0): assoc 00:17:3f:7e:ab:08 -> 00:16:44:fb:52:6c status: 0: Successful


[-- Attachment #3: kernel-short.log --]
[-- Type: text/x-log, Size: 3813 bytes --]

[  346.940054] usb 1-1: new high speed USB device using ehci_hcd and address 4
[  347.086851] usb 1-1: configuration #1 chosen from 1 choice
[  347.418280] cfg80211: Calling CRDA for country: EU
[  348.348579] phy0: Selected rate control algorithm 'minstrel'
[  348.349108] phy0: hwaddr e3c7a080, RTL8187BvE V0 + rtl8225z2
[  348.349131] usbcore: registered new interface driver rtl8187
[  361.807409] phy0: device now idle
[  361.878423] ADDRCONF(NETDEV_UP): wlan0: link is not ready
[  361.893826] phy0: device no longer idle - scanning
[  364.225226] phy0: device now idle
[  364.806379] phy0: device no longer idle - scanning
[  366.893227] phy0: device now idle
[  390.835706] phy0: device no longer idle - scanning
[  392.917362] phy0: device now idle
[  412.002426] ADDRCONF(NETDEV_UP): wlan0: link is not ready
[  412.371061] phy0: device no longer idle - scanning
[  414.498373] wlan0: authenticate with AP e3c7b708
[  414.498397] wlan0: privacy configuration mismatch and mixed-cell disabled - disassociate
[  414.499742] phy0: device now idle
[  417.572157] phy0: device no longer idle - scanning
[  419.649259] phy0: device now idle
[  419.718250] phy0: device no longer idle - in use
[  419.785249] wlan0: authenticate with AP e3c7b708
[  419.786755] wlan0: authenticated
[  419.786756] wlan0: associate with AP e3c7b708
[  419.789134] wlan0: RX AssocResp from e3f8201a (capab=0x411 status=0 aid=3)
[  419.789138] wlan0: associated
[  419.789142] phy0: Allocated STA e3c00a08
[  419.789403] phy0: Inserted STA e3c00a08
[  419.790372] wlan0: switched to short barker preamble (BSSID=e3c7b708)
[  419.790374] wlan0: switched to short slot time (BSSID=e3c7b708)
[  419.795862] ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[  420.664625] padlock: VIA PadLock not detected.
[  426.992527] wlan0: setting MTU 1492
[  429.796020] wlan0: no IPv6 routers present
[  465.032820] usb 2-2: USB disconnect, address 2
[  520.958259] wlan0: deauthenticating by local choice (reason=3)
[  520.959293] phy0: device now idle
[  521.037304] phy0: Removed STA e3c00a08
[  521.037411] phy0: Destroyed STA e3c00a08
[  524.902800] ADDRCONF(NETDEV_UP): wlan0: link is not ready
[  533.450798] ADDRCONF(NETDEV_UP): wlan0: link is not ready
[  533.452844] phy0: device no longer idle - scanning
[  533.645340] phy0: device now idle
[  537.890760] ADDRCONF(NETDEV_UP): wlan0: link is not ready
[  537.890876] phy0: device no longer idle - scanning
[  539.982438] wlan0: direct probe to AP e3c7b708 try 1
[  539.982476] wlan0: privacy configuration mismatch and mixed-cell disabled - disassociate
[  539.983926] phy0: device now idle
[  543.973724] phy0: device no longer idle - scanning
[  546.270791] phy0: device now idle
[  546.358314] phy0: device no longer idle - in use
[  546.425311] wlan0: direct probe to AP e3c7b708 try 1
[  546.624050] wlan0: direct probe to AP e3c7b708 try 2
[  546.824039] wlan0: direct probe to AP e3c7b708 try 3
[  547.024037] wlan0: direct probe to AP e3c7b708 timed out
[  547.024044] phy0: device now idle
[  551.030732] phy0: device no longer idle - scanning
[  553.093323] phy0: device now idle
[  553.162315] phy0: device no longer idle - in use
[  553.229316] wlan0: direct probe to AP e3c7b708 try 1
[  553.428042] wlan0: direct probe to AP e3c7b708 try 2
[  553.628037] wlan0: direct probe to AP e3c7b708 try 3
[  553.828036] wlan0: direct probe to AP e3c7b708 timed out
[  553.828043] phy0: device now idle
[  557.082433] phy0: device no longer idle - scanning
[  559.141327] phy0: device now idle
[  559.210312] phy0: device no longer idle - in use
[  559.277319] wlan0: direct probe to AP e3c7b708 try 1
[  559.476045] wlan0: direct probe to AP e3c7b708 try 2
[  559.676044] wlan0: direct probe to AP e3c7b708 try 3
[  559.876044] wlan0: direct probe to AP e3c7b708 timed out


[-- Attachment #4: lsusb --]
[-- Type: text/plain, Size: 5080 bytes --]

Bus 001 Device 004: ID 0bda:8189 Realtek Semiconductor Corp. RTL8187B Wireless 802.11g 54Mbps Network Adapter
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          0x8189 RTL8187B Wireless 802.11g 54Mbps Network Adapter
  bcdDevice            2.00
  iManufacturer           1 Manufacturer_Realtek
  iProduct                2 
  iSerial                 3 00e04c000001
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           81
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          4 Wireless Network Card
    bmAttributes         0x80
      (Bus Powered)
    MaxPower              500mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           9
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass    255 Vendor Specific Subclass
      bInterfaceProtocol    255 Vendor Specific Protocol
      iInterface              2 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x83  EP 3 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x04  EP 4 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x05  EP 5 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x06  EP 6 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x07  EP 7 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x89  EP 9 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x0a  EP 10 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x0b  EP 11 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x0c  EP 12 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
Device Qualifier (for other device speed):
  bLength                10
  bDescriptorType         6
  bcdUSB               2.00
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0        64
  bNumConfigurations      1
Device Status:     0x0000
  (Bus Powered)

Re: rtl8187b Problem with tx level

[Larry Finger]

Tobias Schlemmer wrote:
> 
> Interestingly iwconfig always reports TX power of 20dBm, regardless of
> the actual tx power, but always a TX rate of 1M. Setting the latter to a
> higher value results in packet loss.

Where are you located? Your log says you are using the EU regulatory
domain; however, that is no longer valid. You should add a line like

options cfg80211 ieee80211_regdom=XX

to /etc/modprobe.conf.local. From your name, I would guess the XX
should be DE.

It is likely that the 20 dBm is set by mac80211 as the maximum allowed
by your local regulations. That value is in fact correct for most
locations in the EU.

My rtl8187b runs at a full 54 Mbs and operates at at least 15 m from
my AP. I don't run AP firmware that lets me see the signal strength
from the STA.

Re: rtl8187b Problem with tx level

[Tobias Schlemmer]

[-- Attachment #1: Type: text/plain, Size: 1888 bytes --]

Hi,

thank you for your quick answer.

Larry Finger schrieb:
> Tobias Schlemmer wrote:
>> Interestingly iwconfig always reports TX power of 20dBm, regardless of
>> the actual tx power, but always a TX rate of 1M. Setting the latter to a
>> higher value results in packet loss.
> 
> Where are you located? Your log says you are using the EU regulatory
> domain; however, that is no longer valid. You should add a line like
> 
> options cfg80211 ieee80211_regdom=XX
> 
> to /etc/modprobe.conf.local. From your name, I would guess the XX
> should be DE.

I guess, too. For some reason it is not corrected in some tutorials.

> It is likely that the 20 dBm is set by mac80211 as the maximum allowed
> by your local regulations. That value is in fact correct for most
> locations in the EU.

As far as I know, Germany has a maximum of 100mW, which should be 20dBm, 
if I'm right. This means the driver reports full power though the device 
actually seems to send with much less power. The power gets lost 
somewhere between this display and the antenna. Since there exists a 
working driver, I can hardly expect it on the hardware side.

I've attached the output of iwconfig for the two drivers. The 
proprietary works, the compat-wireless one even failed to authenticate 
(auth timeout) today. I don't know which tx power the proprietary driver 
uses. If you can tell me how to find out, I'll try that.

Some additional information: The automatic rate setting seems to work 
somehow. Last night it grow to 11M for a short time (reporting signal 
stregth of -3dBm).

Maybe, the tx power gets only reduced, but never increased. That's what 
the AP sees.

> My rtl8187b runs at a full 54 Mbs and operates at at least 15 m from
> my AP. I don't run AP firmware that lets me see the signal strength
> from the STA.

That dosn't surprise me. The archives don't talk about similar problems.

Tobias

[-- Attachment #2: iwconfig1 --]
[-- Type: text/plain, Size: 1483 bytes --]

wlan0     802.11b/g linked  ESSID:"Malter"  
          Mode:Managed  Channel=8  Access Point: 00:17:3F:7E:AB:08   
          Bit Rate=48 Mb/s   
          Retry:on   Fragment thr:off
          Link Quality=72/100  Signal level=-45 dBm  Noise level=-102 dBm
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:0   Missed beacon:0

filename:       /lib/modules/2.6.24-19-generic/kernel/drivers/nb/r8187.ko
description:    Linux driver for Realtek RTL8187 WiFi cards
author:         Andrea Merello <andreamrl@tiscali.it>
version:        V 1.1
license:        GPL
srcversion:     CE57E03B376EA9ED408E23E
alias:          usb:v0846p6A00d*dc*dsc*dp*ic*isc*ip*
alias:          usb:v0846p6100d*dc*dsc*dp*ic*isc*ip*
alias:          usb:v0BDAp8189d*dc*dsc*dp*ic*isc*ip*
alias:          usb:v0BDAp8187d*dc*dsc*dp*ic*isc*ip*
depends:        usbcore
vermagic:       2.6.24-19-generic SMP mod_unload 586 
parm:           ifname:charp
parm:           devname: Net interface name, wlan%d=default
parm:           channels: Channel bitmask for specific locales. NYI (int)

filename:       /lib/modules/2.6.24-19-generic/kernel/drivers/nb/r8187msh.ko
description:    Linux extension module for Realtek RTL8187 WiFi cards
author:         Stanley Chang <changsl@cs.nctu.edu.tw>
version:        V 11sD1.0
license:        Proprietary
srcversion:     4F5B438A81B73DDF03155C5
depends:        
vermagic:       2.6.24-19-generic SMP mod_unload 586 

[-- Attachment #3: iwconfig2 --]
[-- Type: text/plain, Size: 2123 bytes --]

wlan0     IEEE 802.11bg  ESSID:"Malter"  
          Mode:Managed  Frequency:2.447 GHz  Access Point: 00:17:3F:7E:AB:08   
          Bit Rate=1 Mb/s   Tx-Power=20 dBm   
          Retry  long limit:7   RTS thr:off   Fragment thr:off
          Power Management:off
          Link Quality=69/70  Signal level=-41 dBm  
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:0   Missed beacon:0

filename:       /lib/modules/2.6.28-15-generic/updates/drivers/net/wireless/rtl818x/rtl8187.ko
license:        GPL
description:    RTL8187/RTL8187B USB wireless driver
author:         Larry Finger <Larry.Finger@lwfinger.net>
author:         Hin-Tak Leung <htl10@users.sourceforge.net>
author:         Herton Ronaldo Krzesinski <herton@mandriva.com.br>
author:         Andrea Merello <andreamrl@tiscali.it>
author:         Michael Wu <flamingice@sourmilk.net>
srcversion:     ACC7FDA7EFE2500D0DC1B50
alias:          usb:v1737p0073d*dc*dsc*dp*ic*isc*ip*
alias:          usb:v1B75p8187d*dc*dsc*dp*ic*isc*ip*
alias:          usb:v18E8p6232d*dc*dsc*dp*ic*isc*ip*
alias:          usb:v13D1pABE6d*dc*dsc*dp*ic*isc*ip*
alias:          usb:v1371p9401d*dc*dsc*dp*ic*isc*ip*
alias:          usb:v114Bp0150d*dc*dsc*dp*ic*isc*ip*
alias:          usb:v0DF6p0028d*dc*dsc*dp*ic*isc*ip*
alias:          usb:v0DF6p000Dd*dc*dsc*dp*ic*isc*ip*
alias:          usb:v03F0pCA02d*dc*dsc*dp*ic*isc*ip*
alias:          usb:v0846p4260d*dc*dsc*dp*ic*isc*ip*
alias:          usb:v0846p6A00d*dc*dsc*dp*ic*isc*ip*
alias:          usb:v0846p6100d*dc*dsc*dp*ic*isc*ip*
alias:          usb:v0789p010Cd*dc*dsc*dp*ic*isc*ip*
alias:          usb:v0769p11F2d*dc*dsc*dp*ic*isc*ip*
alias:          usb:v0BDAp8198d*dc*dsc*dp*ic*isc*ip*
alias:          usb:v0BDAp8197d*dc*dsc*dp*ic*isc*ip*
alias:          usb:v0BDAp8189d*dc*dsc*dp*ic*isc*ip*
alias:          usb:v0BDAp8187d*dc*dsc*dp*ic*isc*ip*
alias:          usb:v050Dp705Ed*dc*dsc*dp*ic*isc*ip*
alias:          usb:v0B05p171Dd*dc*dsc*dp*ic*isc*ip*
depends:        mac80211,eeprom_93cx6,cfg80211
vermagic:       2.6.28-15-generic SMP mod_unload modversions 586 

Re: rtl8187b Problem with tx level

[Larry Finger]

Tobias Schlemmer wrote:
> Hi,
> 
> thank you for your quick answer.
> 
> Larry Finger schrieb:
>> Tobias Schlemmer wrote:
>>> Interestingly iwconfig always reports TX power of 20dBm, regardless of
>>> the actual tx power, but always a TX rate of 1M. Setting the latter to a
>>> higher value results in packet loss.
>>
>> Where are you located? Your log says you are using the EU regulatory
>> domain; however, that is no longer valid. You should add a line like
>>
>> options cfg80211 ieee80211_regdom=XX
>>
>> to /etc/modprobe.conf.local. From your name, I would guess the XX
>> should be DE.
> 
> I guess, too. For some reason it is not corrected in some tutorials.
> 
>> It is likely that the 20 dBm is set by mac80211 as the maximum allowed
>> by your local regulations. That value is in fact correct for most
>> locations in the EU.
> 
> As far as I know, Germany has a maximum of 100mW, which should be 20dBm,
> if I'm right. This means the driver reports full power though the device
> actually seems to send with much less power. The power gets lost
> somewhere between this display and the antenna. Since there exists a
> working driver, I can hardly expect it on the hardware side.
> 
> I've attached the output of iwconfig for the two drivers. The
> proprietary works, the compat-wireless one even failed to authenticate
> (auth timeout) today. I don't know which tx power the proprietary driver
> uses. If you can tell me how to find out, I'll try that.
> 
> Some additional information: The automatic rate setting seems to work
> somehow. Last night it grow to 11M for a short time (reporting signal
> stregth of -3dBm).
> 
> Maybe, the tx power gets only reduced, but never increased. That's what
> the AP sees.
> 
>> My rtl8187b runs at a full 54 Mbs and operates at at least 15 m from
>> my AP. I don't run AP firmware that lets me see the signal strength
>> from the STA.
> 
> That dosn't surprise me. The archives don't talk about similar problems.

While you are still available, please provide the dmesg output for the
r8187 (vendor) driver beginning at the point that the USB device is
recognized. With rtl8187, it looks like:

[  346.940054] usb 1-1: new high speed USB device using ehci_hcd and
address 4
[  347.086851] usb 1-1: configuration #1 chosen from 1 choice
[  347.418280] cfg80211: Calling CRDA for country: EU
[  348.348579] phy0: Selected rate control algorithm 'minstrel'
[  348.349108] phy0: hwaddr e3c7a080, RTL8187BvE V0 + rtl8225z2
[  348.349131] usbcore: registered new interface driver rtl8187

There may be additional info following this.

In looking at my copy of the r8187 driver code, I see some branches
that may not be in our driver, but I need to see what ID info their
driver sees.

Have a good vacation.

Larry

Re: rtl8187b Problem with tx level

[Tobias Schlemmer]

[-- Attachment #1: Type: text/plain, Size: 386 bytes --]

Larry Finger schrieb:
> There may be additional info following this.
> 
> In looking at my copy of the r8187 driver code, I see some branches
> that may not be in our driver, but I need to see what ID info their
> driver sees.

Hm… the output is attached. It seems not to be very informative to me. 
But maybe you can read more.

> Have a good vacation.

Thank you very much.

Tobias

[-- Attachment #2: kernel-log-r8187.txt --]
[-- Type: text/plain, Size: 3503 bytes --]

[  168.274893] usb 3-1: new high speed USB device using ehci_hcd and address 4
[  168.414599] usb 3-1: configuration #1 chosen from 1 choice
[  168.475975] ieee80211_crypt: registered algorithm 'NULL'
[  168.483909] ieee80211_crypt: registered algorithm 'CCMP'
[  168.491680] ieee80211_crypt: registered algorithm 'WEP'
[  168.495562] ieee80211_crypt: registered algorithm 'TKIP'
[  168.535959] r8187msh: module license 'Proprietary' taints kernel.
[  168.536038] r8187msh: no version for "notify_wx_assoc_event" found: kernel tainted.
[  168.558140] 
[  168.558142] Linux kernel driver for RTL8187/RTL8187B based WLAN cards
[  168.558146] Copyright (c) 2004-2005, Andrea Merello
[  168.558148] rtl8187: Initializing module
[  168.558149] rtl8187: Wireless extensions version 22
[  168.558150] rtl8187: Initializing proc filesystem
[  168.635246] rtl8187: Reported EEPROM chip is a 93c46 (1Kbit)
[  168.860244] rtl8187: Card MAC address is 00:16:44:fb:52:6d
[  169.198241] rtl8187: PAPE from CONFIG2: 0
[  169.235989] rtl8187: EEPROM Customer ID: 00
[  169.235990] 
[  169.236472] rtl8187: Driver probe completed
[  169.236473] 
[  169.236490] usbcore: registered new interface driver rtl8187
[  286.804391] NET: Registered protocol family 17
[  287.149124] rtl8187: Card successfully reset
[  295.619702] WIRELESS_MODE_G
[  295.690942] ADDRCONF(NETDEV_UP): wlan0: link is not ready
[  360.727206] rtl8180_close process 
[  360.727219] rtl8180_down process 
[  360.740307] rtl8187: Mangement RX process aborted due to explicit shutdown
[  361.191136] rtl8187: Card successfully reset
[  369.966180] WIRELESS_MODE_G
[  370.061948] ADDRCONF(NETDEV_UP): wlan0: link is not ready
[  370.479245] Linking with deleted
[  370.636366] Linking with deleted
[  370.735865] Linking with deleted
[  373.286377] Linking with deleted
[  373.345154] Associated successfully
[  373.345161] Using G rates
[  373.406594] ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[  374.169721] alg name:CCMP
[  376.210329] padlock: VIA PadLock not detected.
[  376.959471] alg name:TKIP
[  383.529746] wlan0: no IPv6 routers present
[  383.817734] rtl8180_close process 
[  383.817741] rtl8180_down process 
[  383.830149] rtl8187: Mangement RX process aborted due to explicit shutdown
[  384.727525] rtl8187: Card successfully reset
[  393.528271] WIRELESS_MODE_G
[  393.598464] Linking with deleted
[  393.599752] ADDRCONF(NETDEV_UP): wlan0: link is not ready
[  393.821712] Linking with deleted
[  394.014709] Linking with deleted
[  394.070779] Associated successfully
[  394.070785] Using G rates
[  394.128104] ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[  394.495577] Linking with deleted
[  394.553274] Associated successfully
[  394.553280] Using G rates
[  394.561075] rtl8180_close process 
[  394.561077] rtl8180_down process 
[  394.576644] rtl8187: Mangement RX process aborted due to explicit shutdown
[  394.992566] rtl8187: Card successfully reset
[  403.365152] WIRELESS_MODE_G
[  403.451719] Linking with deleted
[  403.613717] Linking with deleted
[  403.675288] Associated successfully
[  403.675294] Using G rates
[  403.827342] Linking with deleted
[  403.983464] Linking with deleted
[  404.039909] Associated successfully
[  404.039915] Using G rates
[  413.531913] wlan0: no IPv6 routers present
[  419.261156] Linking with deleted
[  419.409459] Linking with deleted
[  419.470723] Associated successfully
[  419.470729] Using G rates
[  420.238284] alg name:CCMP
[  420.238308] alg name:TKIP

Re: rtl8187b Problem with tx level

[Hin-Tak Leung]

On Sun, Aug 30, 2009 at 9:44 PM, Tobias
Schlemmer<keinstein_junior@gmx.net> wrote:
> Hi,
>
> I have some problem with my rtl8187b device. It is included in my laptop
> running Ubuntu linux 2.6.28. I've tested several compat-wireless releases
> including 2.6.30 and 2.6.31-rc7.

Hmm, are compat-wireless versioned against kernels? I thought they
just have dates and git describe tags. Could you try the
latest-and-greatest? (the latest and greatest is ahead of 2.6.31-rc7
by a few months)
http://linuxwireless.org/en/users/Download

> The problem is that the network adapter looses the connection to the access
> point at very low distances. It seems to be as if the driver is too
> optimistic about tx power. I monitored the singnal strength on the access
> point (Buffalo running DD-WRT). When I associate the laptop with it the
> recieved signal strength starts full and drops rapidly in the first seconds.
> At the end it is about 0 at a distance of 4m. At this moment no ping will
> arrive the destination. Tests with other access points show similar results.
>
> After several attempts to get different drivers working I used an Ubuntu
> 8.04 boot CD this morning which seems to work out of the box. It has kernel
> 2.6.24 using a module called r8187. I compared these two drivers and got
> much better signal strengths, at least more stable connections. Maybe it's
> interesting that the two drivers report different signal strength
> (compat-wireless reports about 10dBm higher values than the old driver) also
> in signal quality the compat wireless driver seems to be more optimistic.

We are familiar with the r8187 module - what version did Ubuntu ship?
(the module headers are not updated so modinfo is useless). I see you
have the mesh code so that's quite recent.

I have compat-wireless from a few days ago, and iwconfig says - Bit
Rate=11 Mb/s   Tx-Power=20 dBm - and I am in a different room from AP,
probably 4m through wall & furniture.

Re: rtl8187b Problem with tx level

[Luis R. Rodriguez]

On Mon, Aug 31, 2009 at 10:55 AM, Hin-Tak Leung<hintak.leung@gmail.com> wrote:
> On Sun, Aug 30, 2009 at 9:44 PM, Tobias
> Schlemmer<keinstein_junior@gmx.net> wrote:
>> Hi,
>>
>> I have some problem with my rtl8187b device. It is included in my laptop
>> running Ubuntu linux 2.6.28. I've tested several compat-wireless releases
>> including 2.6.30 and 2.6.31-rc7.
>
> Hmm, are compat-wireless versioned against kernels?

The stable ones are:

http://wireless.kernel.org/en/users/Download/stable/

  Luis

Re: rtl8187b Problem with tx level

[Hin-Tak Leung]

On Mon, Aug 31, 2009 at 7:02 PM, Luis R. Rodriguez<mcgrof@gmail.com> wrote:
> On Mon, Aug 31, 2009 at 10:55 AM, Hin-Tak Leung<hintak.leung@gmail.com> wrote:
>> On Sun, Aug 30, 2009 at 9:44 PM, Tobias
>> Schlemmer<keinstein_junior@gmx.net> wrote:
>>> Hi,
>>>
>>> I have some problem with my rtl8187b device. It is included in my laptop
>>> running Ubuntu linux 2.6.28. I've tested several compat-wireless releases
>>> including 2.6.30 and 2.6.31-rc7.
>>
>> Hmm, are compat-wireless versioned against kernels?
>
> The stable ones are:
>
> http://wireless.kernel.org/en/users/Download/stable/
>
>  Luis
>

Thanks - it is new addition to the web-site :-), I see. Anyway, Larry
and Herton have made more changes/improvements in rtl8187 in
latest-and-greatest than 2.6.31-rc7...

Re: rtl8187b Problem with tx level

[Luis R. Rodriguez]

On Mon, Aug 31, 2009 at 11:32 AM, Hin-Tak Leung<hintak.leung@gmail.com> wrote:
> On Mon, Aug 31, 2009 at 7:02 PM, Luis R. Rodriguez<mcgrof@gmail.com> wrote:
>> On Mon, Aug 31, 2009 at 10:55 AM, Hin-Tak Leung<hintak.leung@gmail.com> wrote:
>>> On Sun, Aug 30, 2009 at 9:44 PM, Tobias
>>> Schlemmer<keinstein_junior@gmx.net> wrote:
>>>> Hi,
>>>>
>>>> I have some problem with my rtl8187b device. It is included in my laptop
>>>> running Ubuntu linux 2.6.28. I've tested several compat-wireless releases
>>>> including 2.6.30 and 2.6.31-rc7.
>>>
>>> Hmm, are compat-wireless versioned against kernels?
>>
>> The stable ones are:
>>
>> http://wireless.kernel.org/en/users/Download/stable/
>>
>>  Luis
>>
>
> Thanks - it is new addition to the web-site :-), I see.

Yup, and when 2.6.32-rc1 is released we'll have another
compat-wireless tarball made from that as well.

> Anyway, Larry
> and Herton have made more changes/improvements in rtl8187 in
> latest-and-greatest than 2.6.31-rc7...

Thanks for the heads up, what I recommend is you edit the
wireless.kernel.org wiki page for rtl8187 and put there a section of
'recommended version' and explain what kernel release you expect to
work the best, and if you do recommend latest and greatest put that on
the wiki. This is what we did for ath9k as ath9k changes kept coming
in for ath9k through kernel releases and distributions were still on
old versions of it. What I hope is eventually users will just know to
check wireless.kernel.org driver page for details for their own
drivers.

  Luis

Re: rtl8187b Problem with tx level

[Hin-Tak Leung]

On Mon, Aug 31, 2009 at 7:41 PM, Luis R. Rodriguez<mcgrof@gmail.com> wrote:
> On Mon, Aug 31, 2009 at 11:32 AM, Hin-Tak Leung<hintak.leung@gmail.com> wrote:
>> On Mon, Aug 31, 2009 at 7:02 PM, Luis R. Rodriguez<mcgrof@gmail.com> wrote:
>>> On Mon, Aug 31, 2009 at 10:55 AM, Hin-Tak Leung<hintak.leung@gmail.com> wrote:
>>>> On Sun, Aug 30, 2009 at 9:44 PM, Tobias
>>>> Schlemmer<keinstein_junior@gmx.net> wrote:
>>>>> Hi,
>>>>>
>>>>> I have some problem with my rtl8187b device. It is included in my laptop
>>>>> running Ubuntu linux 2.6.28. I've tested several compat-wireless releases
>>>>> including 2.6.30 and 2.6.31-rc7.
>>>>
>>>> Hmm, are compat-wireless versioned against kernels?
>>>
>>> The stable ones are:
>>>
>>> http://wireless.kernel.org/en/users/Download/stable/
>>>
>>>  Luis
>>>
>>
>> Thanks - it is new addition to the web-site :-), I see.
>
> Yup, and when 2.6.32-rc1 is released we'll have another
> compat-wireless tarball made from that as well.
>
>> Anyway, Larry
>> and Herton have made more changes/improvements in rtl8187 in
>> latest-and-greatest than 2.6.31-rc7...
>
> Thanks for the heads up, what I recommend is you edit the
> wireless.kernel.org wiki page for rtl8187 and put there a section of
> 'recommended version' and explain what kernel release you expect to
> work the best, and if you do recommend latest and greatest put that on
> the wiki. This is what we did for ath9k as ath9k changes kept coming
> in for ath9k through kernel releases and distributions were still on
> old versions of it. What I hope is eventually users will just know to
> check wireless.kernel.org driver page for details for their own
> drivers.
>
>  Luis
>

I just took a look at the history - there aren't obvious bug fixes, a
bunch of work queue-related changes from you & Johannes; feature-wise,
Larry added LED blinking after 2.6.30, and Herton added rfkill support
quite recently after 2.6.31-rc7 . But no, there isn't any change that
would affect tx level beyond 2.6.31-rc7, I think.

Re: rtl8187b Problem with tx level

[Larry Finger]

Hin-Tak Leung wrote:
> 
> I just took a look at the history - there aren't obvious bug fixes, a
> bunch of work queue-related changes from you & Johannes; feature-wise,
> Larry added LED blinking after 2.6.30, and Herton added rfkill support
> quite recently after 2.6.31-rc7 . But no, there isn't any change that
> would affect tx level beyond 2.6.31-rc7, I think.

Your analysis matches my recollection.

Apparently RealTek is supplying a closed-source driver for RTL8187B
these days. There are no sources for the B on their web site. In
addition, the one that Tobias loaded tainted his kernel.

Larry

Re: rtl8187b Problem with tx level

[Gábor Stefanik]

On Mon, Aug 31, 2009 at 11:10 PM, Larry Finger<Larry.Finger@lwfinger.net> wrote:
> Hin-Tak Leung wrote:
>>
>> I just took a look at the history - there aren't obvious bug fixes, a
>> bunch of work queue-related changes from you & Johannes; feature-wise,
>> Larry added LED blinking after 2.6.30, and Herton added rfkill support
>> quite recently after 2.6.31-rc7 . But no, there isn't any change that
>> would affect tx level beyond 2.6.31-rc7, I think.
>
> Your analysis matches my recollection.
>
> Apparently RealTek is supplying a closed-source driver for RTL8187B
> these days. There are no sources for the B on their web site. In
> addition, the one that Tobias loaded tainted his kernel.
>
> Larry

The driver is not actually closed-source; they just don't provide any
drivers on their site anymore, instead they send their reference
drivers to OEMs, expecting the OEMs to release their own versions
(with sources - most vendors who do release Linux drivers in fact only
release sources, without binaries). The reason for this appears to be
that Realtek now encourages vendors to sell RTL81xx wireless chips
with modified USB IDs. (Or are you seeing a binary-only driver on
realtek.com.tw? That would definitely be a GPL violation, given that
they use a modified version of the GPLed libipw stack.)

-- 
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)

Re: rtl8187b Problem with tx level

[Larry Finger]

Gábor Stefanik wrote:
> 
> The driver is not actually closed-source; they just don't provide any
> drivers on their site anymore, instead they send their reference
> drivers to OEMs, expecting the OEMs to release their own versions
> (with sources - most vendors who do release Linux drivers in fact only
> release sources, without binaries). The reason for this appears to be
> that Realtek now encourages vendors to sell RTL81xx wireless chips
> with modified USB IDs. (Or are you seeing a binary-only driver on
> realtek.com.tw? That would definitely be a GPL violation, given that
> they use a modified version of the GPLed libipw stack.)


No driver at all. I looked at the Toshiba site, but found only Windows
drivers. Which OEM has the driver available?

Larry

Re: rtl8187b Problem with tx level

[Hin-Tak Leung]

2009/8/31 Larry Finger <Larry.Finger@lwfinger.net>:
> Gábor Stefanik wrote:
>>
>> The driver is not actually closed-source; they just don't provide any
>> drivers on their site anymore, instead they send their reference
>> drivers to OEMs, expecting the OEMs to release their own versions
>> (with sources - most vendors who do release Linux drivers in fact only
>> release sources, without binaries). The reason for this appears to be
>> that Realtek now encourages vendors to sell RTL81xx wireless chips
>> with modified USB IDs. (Or are you seeing a binary-only driver on
>> realtek.com.tw? That would definitely be a GPL violation, given that
>> they use a modified version of the GPLed libipw stack.)
>
>
> No driver at all. I looked at the Toshiba site, but found only Windows
> drivers. Which OEM has the driver available?
>
> Larry

The r8187 is distributed from OEMs - stand to reason, as realtek don't
really sell their own brand on high-street shops? We got one release
e-mailed to us, and there are a few floating around on the internet
under some laptop or usb hardware vendors. It is available under this,
for example: http://service.one.de/index.php?&direction=0&order=&directory=NOTEBOOKS/ONE_A1XX/LINUX/Source-code/Wireless
r8187mesh is the one in the mesh directory.

Re: rtl8187b Problem with tx level

[John W. Linville]

On Tue, Sep 01, 2009 at 12:16:04AM +0100, Hin-Tak Leung wrote:
> 2009/8/31 Larry Finger <Larry.Finger@lwfinger.net>:
> > Gábor Stefanik wrote:
> >>
> >> The driver is not actually closed-source; they just don't provide any
> >> drivers on their site anymore, instead they send their reference
> >> drivers to OEMs, expecting the OEMs to release their own versions
> >> (with sources - most vendors who do release Linux drivers in fact only
> >> release sources, without binaries). The reason for this appears to be
> >> that Realtek now encourages vendors to sell RTL81xx wireless chips
> >> with modified USB IDs. (Or are you seeing a binary-only driver on
> >> realtek.com.tw? That would definitely be a GPL violation, given that
> >> they use a modified version of the GPLed libipw stack.)
> >
> >
> > No driver at all. I looked at the Toshiba site, but found only Windows
> > drivers. Which OEM has the driver available?
> >
> > Larry
> 
> The r8187 is distributed from OEMs - stand to reason, as realtek don't
> really sell their own brand on high-street shops? We got one release
> e-mailed to us, and there are a few floating around on the internet
> under some laptop or usb hardware vendors. It is available under this,
> for example: http://service.one.de/index.php?&direction=0&order=&directory=NOTEBOOKS/ONE_A1XX/LINUX/Source-code/Wireless
> r8187mesh is the one in the mesh directory.

*sigh*

So Realtek is actually going backwards in their level of support?
Wonderful.

Anyone have any real-life contacts at Realtek?  We really need to
get them on-board with the drivers in the kernel.

John
-- 
John W. Linville		Someday the world will need a hero, and you
linville@tuxdriver.com			might be all we have.  Be ready.

Re: rtl8187b Problem with tx level

[Larry Finger]

Hin-Tak Leung wrote:
> 
> The r8187 is distributed from OEMs - stand to reason, as realtek don't
> really sell their own brand on high-street shops? We got one release
> e-mailed to us, and there are a few floating around on the internet
> under some laptop or usb hardware vendors. It is available under this,
> for example: http://service.one.de/index.php?&direction=0&order=&directory=NOTEBOOKS/ONE_A1XX/LINUX/Source-code/Wireless
> r8187mesh is the one in the mesh directory.

Thanks for this link. I got this code and I am in the process of
comparing it with the current rtl8187. So far, I find that the code
that sets the TX power levels is identical with ours.

Larry

Re: rtl8187b Problem with tx level

[Hin-Tak Leung]

On Tue, Sep 1, 2009 at 5:37 PM, Larry Finger<Larry.Finger@lwfinger.net> wrote:
> Hin-Tak Leung wrote:
>>
>> The r8187 is distributed from OEMs - stand to reason, as realtek don't
>> really sell their own brand on high-street shops? We got one release
>> e-mailed to us, and there are a few floating around on the internet
>> under some laptop or usb hardware vendors. It is available under this,
>> for example: http://service.one.de/index.php?&direction=0&order=&directory=NOTEBOOKS/ONE_A1XX/LINUX/Source-code/Wireless
>> r8187mesh is the one in the mesh directory.
>
> Thanks for this link. I got this code and I am in the process of
> comparing it with the current rtl8187. So far, I find that the code
> that sets the TX power levels is identical with ours.
>
> Larry

We had a later version of the driver, and either you or Herton had
looked at that already... the mesh code isn't being looked at though.

Hin-Tak

Re: rtl8187b Problem with tx level

[Luis R. Rodriguez]

2009/8/31 Gábor Stefanik <netrolller.3d@gmail.com>:
> On Mon, Aug 31, 2009 at 11:10 PM, Larry Finger<Larry.Finger@lwfinger.net> wrote:
>> Hin-Tak Leung wrote:
>>>
>>> I just took a look at the history - there aren't obvious bug fixes, a
>>> bunch of work queue-related changes from you & Johannes; feature-wise,
>>> Larry added LED blinking after 2.6.30, and Herton added rfkill support
>>> quite recently after 2.6.31-rc7 . But no, there isn't any change that
>>> would affect tx level beyond 2.6.31-rc7, I think.
>>
>> Your analysis matches my recollection.
>>
>> Apparently RealTek is supplying a closed-source driver for RTL8187B
>> these days. There are no sources for the B on their web site. In
>> addition, the one that Tobias loaded tainted his kernel.
>>
>> Larry
>
> The driver is not actually closed-source; they just don't provide any
> drivers on their site anymore, instead they send their reference
> drivers to OEMs, expecting the OEMs to release their own versions
> (with sources - most vendors who do release Linux drivers in fact only
> release sources, without binaries). The reason for this appears to be
> that Realtek now encourages vendors to sell RTL81xx wireless chips
> with modified USB IDs. (Or are you seeing a binary-only driver on
> realtek.com.tw? That would definitely be a GPL violation, given that
> they use a modified version of the GPLed libipw stack.)

Gabor, do you speak to RealkTek folks? It seems what may be best for
OEMs and RealTek themselves is to post drivers for inclusion into
staging first and then for interested parties to port them properly.

  Luis

Re: rtl8187b Problem with tx level

[Gábor Stefanik]

On Tue, Sep 1, 2009 at 1:37 AM, Luis R. Rodriguez<mcgrof@gmail.com> wrote:
> 2009/8/31 Gábor Stefanik <netrolller.3d@gmail.com>:
>> On Mon, Aug 31, 2009 at 11:10 PM, Larry Finger<Larry.Finger@lwfinger.net> wrote:
>>> Hin-Tak Leung wrote:
>>>>
>>>> I just took a look at the history - there aren't obvious bug fixes, a
>>>> bunch of work queue-related changes from you & Johannes; feature-wise,
>>>> Larry added LED blinking after 2.6.30, and Herton added rfkill support
>>>> quite recently after 2.6.31-rc7 . But no, there isn't any change that
>>>> would affect tx level beyond 2.6.31-rc7, I think.
>>>
>>> Your analysis matches my recollection.
>>>
>>> Apparently RealTek is supplying a closed-source driver for RTL8187B
>>> these days. There are no sources for the B on their web site. In
>>> addition, the one that Tobias loaded tainted his kernel.
>>>
>>> Larry
>>
>> The driver is not actually closed-source; they just don't provide any
>> drivers on their site anymore, instead they send their reference
>> drivers to OEMs, expecting the OEMs to release their own versions
>> (with sources - most vendors who do release Linux drivers in fact only
>> release sources, without binaries). The reason for this appears to be
>> that Realtek now encourages vendors to sell RTL81xx wireless chips
>> with modified USB IDs. (Or are you seeing a binary-only driver on
>> realtek.com.tw? That would definitely be a GPL violation, given that
>> they use a modified version of the GPLed libipw stack.)
>
> Gabor, do you speak to RealkTek folks? It seems what may be best for
> OEMs and RealTek themselves is to post drivers for inclusion into
> staging first and then for interested parties to port them properly.
>
>  Luis

Not yet, I haven't tried contacting them. I simply based my comments
on the fact that OEMs are releasing sources. However, contacting them
about work to include their drivers in the kernel is a good idea -
apparently there is nothing keeping Realtek from taking community
contributions (unlike e.g. Zydas - the vendor driver is based on
Andrea Merello's old r8180-sa2400 driver, and was not developed
in-house by Realtek).

-- 
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)

Re: rtl8187b Problem with tx level

[Luis R. Rodriguez]

2009/8/31 Gábor Stefanik <netrolller.3d@gmail.com>:
> On Tue, Sep 1, 2009 at 1:37 AM, Luis R. Rodriguez<mcgrof@gmail.com> wrote:
>> 2009/8/31 Gábor Stefanik <netrolller.3d@gmail.com>:
>>> On Mon, Aug 31, 2009 at 11:10 PM, Larry Finger<Larry.Finger@lwfinger.net> wrote:
>>>> Hin-Tak Leung wrote:
>>>>>
>>>>> I just took a look at the history - there aren't obvious bug fixes, a
>>>>> bunch of work queue-related changes from you & Johannes; feature-wise,
>>>>> Larry added LED blinking after 2.6.30, and Herton added rfkill support
>>>>> quite recently after 2.6.31-rc7 . But no, there isn't any change that
>>>>> would affect tx level beyond 2.6.31-rc7, I think.
>>>>
>>>> Your analysis matches my recollection.
>>>>
>>>> Apparently RealTek is supplying a closed-source driver for RTL8187B
>>>> these days. There are no sources for the B on their web site. In
>>>> addition, the one that Tobias loaded tainted his kernel.
>>>>
>>>> Larry
>>>
>>> The driver is not actually closed-source; they just don't provide any
>>> drivers on their site anymore, instead they send their reference
>>> drivers to OEMs, expecting the OEMs to release their own versions
>>> (with sources - most vendors who do release Linux drivers in fact only
>>> release sources, without binaries). The reason for this appears to be
>>> that Realtek now encourages vendors to sell RTL81xx wireless chips
>>> with modified USB IDs. (Or are you seeing a binary-only driver on
>>> realtek.com.tw? That would definitely be a GPL violation, given that
>>> they use a modified version of the GPLed libipw stack.)
>>
>> Gabor, do you speak to RealkTek folks? It seems what may be best for
>> OEMs and RealTek themselves is to post drivers for inclusion into
>> staging first and then for interested parties to port them properly.
>>
>>  Luis
>
> Not yet, I haven't tried contacting them. I simply based my comments
> on the fact that OEMs are releasing sources. However, contacting them
> about work to include their drivers in the kernel is a good idea -
> apparently there is nothing keeping Realtek from taking community
> contributions (unlike e.g. Zydas - the vendor driver is based on
> Andrea Merello's old r8180-sa2400 driver, and was not developed
> in-house by Realtek).

If anyone has contacts that does indeed seem reasonable to do, seems
like it could help them and their customers.

  Luis

Re: rtl8187b Problem with tx level

[Greg KH]

On Mon, Aug 31, 2009 at 04:56:11PM -0700, Luis R. Rodriguez wrote:
> 2009/8/31 Gábor Stefanik <netrolller.3d@gmail.com>:
> > On Tue, Sep 1, 2009 at 1:37 AM, Luis R. Rodriguez<mcgrof@gmail.com> wrote:
> >> 2009/8/31 Gábor Stefanik <netrolller.3d@gmail.com>:
> >>> On Mon, Aug 31, 2009 at 11:10 PM, Larry Finger<Larry.Finger@lwfinger.net> wrote:
> >>>> Hin-Tak Leung wrote:
> >>>>>
> >>>>> I just took a look at the history - there aren't obvious bug fixes, a
> >>>>> bunch of work queue-related changes from you & Johannes; feature-wise,
> >>>>> Larry added LED blinking after 2.6.30, and Herton added rfkill support
> >>>>> quite recently after 2.6.31-rc7 . But no, there isn't any change that
> >>>>> would affect tx level beyond 2.6.31-rc7, I think.
> >>>>
> >>>> Your analysis matches my recollection.
> >>>>
> >>>> Apparently RealTek is supplying a closed-source driver for RTL8187B
> >>>> these days. There are no sources for the B on their web site. In
> >>>> addition, the one that Tobias loaded tainted his kernel.
> >>>>
> >>>> Larry
> >>>
> >>> The driver is not actually closed-source; they just don't provide any
> >>> drivers on their site anymore, instead they send their reference
> >>> drivers to OEMs, expecting the OEMs to release their own versions
> >>> (with sources - most vendors who do release Linux drivers in fact only
> >>> release sources, without binaries). The reason for this appears to be
> >>> that Realtek now encourages vendors to sell RTL81xx wireless chips
> >>> with modified USB IDs. (Or are you seeing a binary-only driver on
> >>> realtek.com.tw? That would definitely be a GPL violation, given that
> >>> they use a modified version of the GPLed libipw stack.)
> >>
> >> Gabor, do you speak to RealkTek folks? It seems what may be best for
> >> OEMs and RealTek themselves is to post drivers for inclusion into
> >> staging first and then for interested parties to port them properly.
> >>
> >>  Luis
> >
> > Not yet, I haven't tried contacting them. I simply based my comments
> > on the fact that OEMs are releasing sources. However, contacting them
> > about work to include their drivers in the kernel is a good idea -
> > apparently there is nothing keeping Realtek from taking community
> > contributions (unlike e.g. Zydas - the vendor driver is based on
> > Andrea Merello's old r8180-sa2400 driver, and was not developed
> > in-house by Realtek).
> 
> If anyone has contacts that does indeed seem reasonable to do, seems
> like it could help them and their customers.

I do have a few contacts there, and have been trying to work with them
to do this, but it is slow going :(

thanks,

greg k-h