Skip to contentSkip to conversation

rtl8187b Problem with tx level

DISCUSSION Tobias Schlemmer 7 participants 21 messages Aug 30, 2009 – Sep 2, 2009

lore
Share & tools
lore
#0 lore raw

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

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

[  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

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)

#1 lore raw
Quoted 4 lines · Tobias Schlemmer

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.

#2 lore raw

Hi,

thank you for your quick answer.

Quoted 5 lines · Larry Finger
Quoted 3 lines · Tobias Schlemmer

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.

Quoted 7 lines

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.

Quoted 3 lines

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.

Quoted 3 lines

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

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 <[email protected]>
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 <[email protected]>
version:        V 11sD1.0
license:        Proprietary
srcversion:     4F5B438A81B73DDF03155C5

depends:
vermagic: 2.6.24-19-generic SMP mod_unload 586

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 <[email protected]>
author:         Hin-Tak Leung <[email protected]>
author:         Herton Ronaldo Krzesinski <[email protected]>
author:         Andrea Merello <[email protected]>
author:         Michael Wu <[email protected]>
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 
#3 lore raw
Quoted 39 lines · Tobias Schlemmer

Hi,

thank you for your quick answer.

Quoted 5 lines · Larry Finger
Quoted 3 lines · Tobias Schlemmer

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.

Quoted 7 lines

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.

Quoted 3 lines

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).

Quoted 8 lines

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

Quoted 3 lines

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

#4 lore raw
Quoted 5 lines · Larry Finger

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.

Quoted 1 line

Have a good vacation.

Thank you very much.

Tobias

[  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
#5 lore raw
In reply to Tobias Schlemmer
Quoted 5 lines · Tobias Schlemmer

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

Quoted 8 lines

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.

Quoted 7 lines

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.

#6 lore raw
Quoted 9 lines · Hin-Tak Leung
Quoted 5 lines · Tobias Schlemmer

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

#7 lore raw
Quoted 9 lines · Luis R. Rodriguez
Quoted 8 lines · Hin-Tak Leung
Quoted 5 lines · Tobias Schlemmer

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.

Quoted 8 lines
Quoted 1 line

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...

#8 lore raw
Quoted 12 lines · Hin-Tak Leung
Quoted 11 lines · Luis R. Rodriguez
Quoted 9 lines · Hin-Tak Leung
Quoted 5 lines · Tobias Schlemmer

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?

Quoted 8 lines
Quoted 6 lines

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.

Quoted 3 lines

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

#9 lore raw
Quoted 39 lines · Luis R. Rodriguez
Quoted 12 lines · Hin-Tak Leung
Quoted 11 lines · Luis R. Rodriguez
Quoted 9 lines · Hin-Tak Leung
Quoted 5 lines · Tobias Schlemmer

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?

Quoted 8 lines
Quoted 6 lines

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.

Quoted 3 lines

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.

Quoted 2 lines

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.

#10 lore raw
Quoted 6 lines · Hin-Tak Leung

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

#11 lore raw
Quoted 8 lines · Larry Finger
Quoted 6 lines · Hin-Tak Leung

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.

Quoted 7 lines

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.)

Signature · 1 line
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
#12 lore raw
Quoted 10 lines · Gábor Stefanik

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

#13 lore raw

2009/8/31 Larry Finger <[email protected]>:

Quoted 13 lines
Quoted 10 lines · Gábor Stefanik

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.)

Quoted 4 lines

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.

#14 lore raw
Quoted 17 lines · Hin-Tak Leung

2009/8/31 Larry Finger <[email protected]>:

Quoted 16 lines
Quoted 10 lines · Gábor Stefanik

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?

Quoted 8 lines
Quoted 1 line

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

Signature · 2 lines
John W. Linville		Someday the world will need a hero, and you
[email protected]			might be all we have.  Be ready.
#15 lore raw
In reply to Hin-Tak Leung
Quoted 7 lines · Hin-Tak Leung

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

#16 lore raw
Quoted 9 lines · Larry Finger
Quoted 7 lines · Hin-Tak Leung

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.

Quoted 5 lines

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

#17 lore raw
In reply to Gábor Stefanik

2009/8/31 Gábor Stefanik <[email protected]>:

Quoted 17 lines · Larry Finger
Quoted 8 lines
Quoted 6 lines · Hin-Tak Leung

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.

Quoted 7 lines

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

Quoted 9 lines

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

#18 lore raw
Quoted 28 lines · Luis R. Rodriguez

2009/8/31 Gábor Stefanik <[email protected]>:

Quoted 17 lines · Larry Finger
Quoted 8 lines
Quoted 6 lines · Hin-Tak Leung

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.

Quoted 7 lines

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

Quoted 9 lines

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.)

Quoted 5 lines

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).

Signature · 1 line
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
#19 lore raw

2009/8/31 Gábor Stefanik <[email protected]>:

Quoted 35 lines · Luis R. Rodriguez
Quoted 28 lines

2009/8/31 Gábor Stefanik <[email protected]>:

Quoted 17 lines · Larry Finger
Quoted 8 lines
Quoted 6 lines · Hin-Tak Leung

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.

Quoted 7 lines

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

Quoted 9 lines

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.)

Quoted 5 lines

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

Quoted 7 lines

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

#20 lore raw
Quoted 44 lines · Luis R. Rodriguez

2009/8/31 Gábor Stefanik <[email protected]>:

Quoted 35 lines · Luis R. Rodriguez
Quoted 28 lines

2009/8/31 Gábor Stefanik <[email protected]>:

Quoted 17 lines · Larry Finger
Quoted 8 lines
Quoted 6 lines · Hin-Tak Leung

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.

Quoted 7 lines

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

Quoted 9 lines

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.)

Quoted 5 lines

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

Quoted 7 lines

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).

Quoted 2 lines

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