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)
On Sun, Aug 30, 2009 at 9:44 PM, Tobias
Schlemmer<[email protected]> 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.
On Mon, Aug 31, 2009 at 7:02 PM, Luis R. Rodriguez<[email protected]> wrote:
> On Mon, Aug 31, 2009 at 10:55 AM, Hin-Tak Leung<[email protected]> wrote:
>> On Sun, Aug 30, 2009 at 9:44 PM, Tobias
>> Schlemmer<[email protected]> 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...
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
On Mon, Aug 31, 2009 at 11:10 PM, Larry Finger<[email protected]> 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. :-)
On Mon, Aug 31, 2009 at 11:32 AM, Hin-Tak Leung<[email protected]> wrote:
> On Mon, Aug 31, 2009 at 7:02 PM, Luis R. Rodriguez<[email protected]> wrote:
>> On Mon, Aug 31, 2009 at 10:55 AM, Hin-Tak Leung<[email protected]> wrote:
>>> On Sun, Aug 30, 2009 at 9:44 PM, Tobias
>>> Schlemmer<[email protected]> 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
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
On Mon, Aug 31, 2009 at 7:41 PM, Luis R. Rodriguez<[email protected]> wrote:
> On Mon, Aug 31, 2009 at 11:32 AM, Hin-Tak Leung<[email protected]> wrote:
>> On Mon, Aug 31, 2009 at 7:02 PM, Luis R. Rodriguez<[email protected]> wrote:
>>> On Mon, Aug 31, 2009 at 10:55 AM, Hin-Tak Leung<[email protected]> wrote:
>>>> On Sun, Aug 30, 2009 at 9:44 PM, Tobias
>>>> Schlemmer<[email protected]> 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.
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.
[ 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
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
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
On Mon, Aug 31, 2009 at 10:55 AM, Hin-Tak Leung<[email protected]> wrote:
> On Sun, Aug 30, 2009 at 9:44 PM, Tobias
> Schlemmer<[email protected]> 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
2009/8/31 Gábor Stefanik <[email protected]>:
> On Mon, Aug 31, 2009 at 11:10 PM, Larry Finger<[email protected]> 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
2009/8/31 Larry Finger <[email protected]>:
> 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.
On Tue, Sep 01, 2009 at 12:16:04AM +0100, Hin-Tak Leung wrote:
> 2009/8/31 Larry Finger <[email protected]>:
> > 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
[email protected] might be all we have. Be ready.
On Mon, Aug 31, 2009 at 04:56:11PM -0700, Luis R. Rodriguez wrote:
> 2009/8/31 G?bor Stefanik <[email protected]>:
> > On Tue, Sep 1, 2009 at 1:37 AM, Luis R. Rodriguez<[email protected]> wrote:
> >> 2009/8/31 G?bor Stefanik <[email protected]>:
> >>> On Mon, Aug 31, 2009 at 11:10 PM, Larry Finger<[email protected]> 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
On Tue, Sep 1, 2009 at 1:37 AM, Luis R. Rodriguez<[email protected]> wrote:
> 2009/8/31 G?bor Stefanik <[email protected]>:
>> On Mon, Aug 31, 2009 at 11:10 PM, Larry Finger<[email protected]> 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. :-)
2009/8/31 Gábor Stefanik <[email protected]>:
> On Tue, Sep 1, 2009 at 1:37 AM, Luis R. Rodriguez<[email protected]> wrote:
>> 2009/8/31 Gábor Stefanik <[email protected]>:
>>> On Mon, Aug 31, 2009 at 11:10 PM, Larry Finger<[email protected]> 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
On Tue, Sep 1, 2009 at 5:37 PM, Larry Finger<[email protected]> 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
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