On 11/28/2013 11:44 AM, Nikita N. wrote:
answers follow
On Wed, Nov 27, 2013, at 03:30 PM, Larry Finger wrote:
On my system, my RTL8187B shows the following for kernel 13.1-rc1:
[11213.196114] usb 1-5: new high-speed USB device number 5 using ehci-pci
[11214.663577] rtl8187: inconsistency between id with OEM info!
[11214.666105] cfg80211: Updating information on frequency 2412 MHz with
regulatory rule:
[11214.666114] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (300
mBi, 2700 mBm)
[11214.666118] cfg80211: Updating information on frequency 2417 MHz with
regulatory rule:
--snip--
ieee80211 phy2: Selected rate control algorithm 'minstrel_ht'
ieee80211 phy2: hwaddr 00:11:6b:3e:c4:0a, RTL8187BvB(early) V0 +
rtl8225z2,
rfkill mask 2
rtl8187: Customer ID is 0x00
rtl8187: wireless switch is on
usbcore: registered new interface driver rtl8187
systemd-udevd[5796]: renamed network interface wlan1 to wlp0s2f1u5
Thanks for your answer again Larry, I finding impossible to bring
back monitor mode in my two, yes TWO different rtl8187 devices.
They BOTH started malfunction in monitor mode the same day after
installing 3.11, isnt it strange?
I repeat, they always worked no problem before 3.11.
From your report you have a "RTL8187BvB(early) V0".
I have a different interface, a "RTL8187vB (default) V1".
So we are talking about different hardware, isnt it?
Do you have a RTL8187vB for test too?
Mine is a B model. It is coded with an RTL8187L USB ID, but it needs the
RTL8187B code. My two other devices are both RTL8187L.
Here follows the lsusb output, if that can help to see the differences
between your and mine interface:
"
Bus 002 Device 002: ID 0bda:8187 Realtek Semiconductor Corp. RTL8187
Wireless 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 0x8187 RTL8187 Wireless Adapter
bcdDevice 1.00
iManufacturer 1 Realtek
iProduct 2 RTL8187 Wireless LAN Adapter
iSerial 3 00e04c000001
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 39
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 3
bInterfaceClass 0 (Defined at Interface level)
bInterfaceSubClass 0
bInterfaceProtocol 0
iInterface 5 Bulk-IN,Bulk-OUT,Bulk-OUT
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 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 0x02 EP 2 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 0x03 EP 3 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: 0x0002
(Bus Powered)
Remote Wakeup Enabled
"
Unfortunately, reverting back to original distro kernel didnt work.
Thats why I think something was "written" in the interface.
Thats why I suspect backports 3.11 has such a bug.
I use distros ONLY in live-RAM mode, I dont use distro permanently
installed, exactly for the reason I can always rollback.
The only distros I use are the following: BT5,Kali,Weaknet and Slitaz4 -
the issue now
appears in all of them!
Before 3.11 it did *NOT* appear in any of them!
As for updates, I only apply updates in Slitaz4.
FYI, I create a dedicated cpio fs at every new version, containing the
"updates" modules, so to load them at kernel runtime by syslinux.
I use this method from the early times of compat-wireless, even at job,
I have automated scripts for that, always works.
So I can e.g. switch between drivers version every time just applying
the cpio file I want at kernel runtime.
There is nothing in the code that will or can rewrite the EEPROM. In fact, the
necessary circuits are not built into the devices.
And thats what I did when "installed" 3.11: make install, created
cpio, reboot & loaded the 3.11 cpio, tested the interfaces, saw the
issues (mac and frames), removed the cpio from loading and put the 3.9
cpio back.
I do that all the times, its a no-fail procedure.
Unfortunately applying back 3.9 didnt solve the issue, my two rtl8187
remained STUCK in monitor malfunction.
As for managed mode, it still works perfectly.
As for the programs I use to test, here a list: airmon-ng, airbase-ng,
airodump-ng, apache2, dnsspoof, dnsmasq, iptables, iw, wireshark.. the
usual wifi net tools.
That was for historic background, so you understand the situation.
The rtlwifi package only includes the drivers that use rtlwifi for their
basic
communications. Driver rtl8187 is *NOT* one of them. You have to
configure it
separately. This is not a bug.
As for compiling rtl modules you say dont use rtlwifi, ok, infact that
was the first time I tried, just because defconfig-wifi did *NOT* work.
I repeat, I always used make defconfig-wifi & make install, even for
3.11 worked.
This time for 3.13, is *NOT* compiling rtl818x modules.
Any functionality change not documented?
If so, how can I instruct make to compile&install rtl8187 modules in new
3.13?
Use 'make menuconfig' and select wireless networking, mac80211, and the rtl8187
driver. That is what I did.
Larry
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
