Hi All :) Its my first time in a mailinglist, so I apologize if Im
mistaken.
I would like to report about few bugs I found running latest modules for
RTL8187 and latest backports.
Is that the right place? Thanks
--
http://www.fastmail.fm - Choose from over 50 domains or use your own
On 11/27/2013 04:59 PM, Nikita N. wrote:
> Alright then :) lets start:
>
>
> - Bug #1:
> Im running on standard Slitaz4, updating modules, the following script:
> ./backports-3.13-rc1-1/scripts/compress_modules.sh
> the "if" is not able to detect the present compression, as result the
> new modules are not compressed, and get mixed with the old ones
> compressed, resulting in errors.
> My actual workaround is just to delete the "if" line.
> The issue is present in all backports releases, since the switch from
> compat-drivers.
That is a backports bug, not one in rtl8187. It should be reported separately.
> - Bug #2:
> I previously updated to backports-3.11-rc3, after install here the dmesg
> report:
> "
> Loading modules backported from Linux version v3.11-rc3-0-g5ae90d8
> Backport generated by backports.git v3.11-rc3-1-0-g4e81a94
> cfg80211: Calling CRDA to update world regulatory domain
> NET: Registered protocol family 10
> rtl8187: Invalid hwaddr! Using randomly generated MAC address
> ieee80211 phy0: Selected rate control algorithm 'minstrel_ht'
> ieee80211 phy0: hwaddr 6a:d5:65:93:2c:69, RTL8187vB (default) V1 +
> rtl8225z2, rfkill mask 2
> rtl8187: Customer ID is 0x00
> Registered led device: rtl8187-phy0::radio
> Registered led device: rtl8187-phy0::tx
> Registered led device: rtl8187-phy0::rx
> rtl8187: wireless switch is on
> usbcore: registered new interface driver rtl8187
> "
> The "Invalid hwaddr!" is the bug.
> As workaround I had to rollback to compat-drivers, where the problem
> does not exists, infact here dmesg:
> "
> Compat-drivers backport release: compat-drivers-v3.9-rc4-2-su
> Backport based on linux-stable.git v3.9-rc4
> compat.git: linux-stable.git
> cfg80211: Calling CRDA to update world regulatory domain
> NET: Registered protocol family 10
> ieee80211 phy0: Selected rate control algorithm 'minstrel_ht'
> ieee80211 phy0: hwaddr 00:e0:4c:X:X:X, RTL8187vB (default) V1 +
> rtl8225z2, rfkill mask 2
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
> - Bug #3:
> After reverting back to compat-drivers, my interface started behaving
> wrong in monitor mode.
> Monitor mode was always working properly before, but after applying
> backports-3.11 now is broken.
> The symptoms are the following: whatever is the channel, from airodump
> or wireshark I can see only broadcasts frames (dest ff:ff:ff..) and
> management frames (ack,probes,beacons,req send,block,
> assoc,auth,deauth,..)
> I tried also other live-RAM-only distros as BT5, Kali and Weaknet, the
> issue persists.
> The interface behaves like some kind of "wrong" data has been written
> permanently (in the eeprom?) which instructs the interface to discard
> all data frames when in monitor mode.
> Managed mode still works perfectly.
> I still could not find a workaround for this bug, as result my interface
> is still unusable in monitor mode.
I cannot address this problem very much as I have no idea what went wrong when
you installed backports. Refreshing your kernel from the distro, or regenerating
it again if you build your own should help. The device's EEPROM cannot be
changed, thus your conjecture about discarded frames is not right.
> - Bug #4:
> Today I tried install latest stable backports-3.13-rc1-1, but RTL
> modules are not compiled.
> Running make defconfig-rtlwifi, it compiles only generic modules.
> Running make defconfig-wifi, compilation is very fast, and skips lots of
> chipsets, again same issue - no RTL modules.
> No workaround - I reverted back again to compat-drivers.
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.
I have just dowloaded backports 3.13-rc1 and will try it.
Larry
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
On 11/30/2013 12:23 PM, Nikita N. wrote:
>
> Hi Larry, thanks for your answer, I respect your experience, because in
> fact I have 20+ years heavy professional experience in programming, but
> very little indeed in linux kernel programming.
> The frames I see in monitor mode are real, not made up.. are real probe,
> beacons, acks, auth, and so on, I can see the same using laptop
> interface of my friend, which never got in contact with 3.11 - and he
> gets also all data frames too.. lucky him! :)
> What do you mean "make up the data"?
I have no idea how it worked at all Without the entry points in the EEPROM
routine, module loading should have gotten an error. I hope you did not force
the module to load. The driver had to generate a random MAC address. That is
made up data.
> About the kernel behavior I know.. but what you say is illogical.. if
> what you say is true, how can you explain that before exposing my two
> interfaces to 3.11, my kernel was nice, and after 3.11 got "severely
> broken" ?? if what you say its true, also kernel configuration of BT5
> all versions, Kali all versions, Weaknet all version became suddenly
> broken just a few days ago.. by what, a collapsed star passing on Hearth
> orbit, a Solar Storm ? :))
> The issue appears *EVERYWHERE* now.. before *EXPOSING* my two interfaces
> to 3.11 I had no problems whatsoever.. is that concept clear?
> Sorry, I dont know how to explain that better..
Your attitude is really putting me off!
> Infact in the little free time I got today I have been analyzing some
> code.. and I see there are several calls to eeprom_93cx6_read and
> eeprom_93cx6_write.. so it looks possible to write data into eeprom,
> isnt it?
> Also the read operations imply some bit write into eeprom, isnt it?
> So, I think its possible that some bit got "flipped", due to some little
> bug/whatever around, isn'it?
> So, how can I "re-flip" back the right bit?
> I dont know.. but I guess you know what is the right bit to flip.. isn't
> it? ;)
When you want to read data from the PROM, you need to set up its controller to
allow the read. The PROM is not mapped to memory. That is what the write
operations do. As far as I know, there is no way to modify the data written into
the PROM.
>
> THAT IS EXACTLY WHAT I WANT TO DO! :D
> But for doing so I need my interfaces to go back operational, so I can
> reproduce all steps of last time, and catch the damned bug!
> Like that I cant see sh*t! if sh*t will happen again will mix with sh*t
> and I will keep seeing only sh*t! :))
>
>
> Nice to know that something is working.. ;)
> So, are you going to give me some help or not?
> And I repeat, its not for me only, its for the whole community, for
> whoever will fall in that issue too!
> Thanks :)
If you want to send me one of your devices, I'll check it out. Otherwise, there
is little I can do. It would be impossible to duplicate the path you have followed.
Larry
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?
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
"
>
> I cannot address this problem very much as I have no idea what went wrong
> when
> you installed backports. Refreshing your kernel from the distro, or
> regenerating
> it again if you build your own should help. The device's EEPROM cannot be
> changed, thus your conjecture about discarded frames is not right.
>
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.
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?
Thanks for your attention :)
--
http://www.fastmail.fm - A no graphics, no pop-ups email service
follow answers
On Sat, Nov 30, 2013, at 09:07 AM, Larry Finger wrote:
> On 11/30/2013 06:03 AM, Nikita N. wrote:
> > We got it Larry! :)
> > eeprom module is *MISSING*! :)
> > Here what I did - I just added the following debug line in rtl8187_probe
> > just after eeprom_93cx6_multiread call:
> > printk(KERN_WARNING "mac_addr= %pM\n",mac_addr);
> > the result was:
> > "
> > Loading modules backported from Linux version v3.13-rc1-0-g6ce4eac
> > Backport generated by backports.git v3.13-rc1-1-0-g988d789
> > cfg80211: Calling CRDA to update world regulatory domain
> > cfg80211: World regulatory domain updated:
> > cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain,
> > max_eirp)
> > cfg80211: (2402000 KHz - 2494000 KHz @ 40000 KHz), (N/A, 3000 mBm)
> > cfg80211: (4910000 KHz - 5235000 KHz @ 40000 KHz), (N/A, 3000 mBm)
> > NET: Registered protocol family 10
> > mac_addr= 00:00:00:00:00:00
> > rtl8187: Invalid hwaddr! Using randomly generated MAC address
> > ieee80211 phy0: Selected rate control algorithm 'minstrel_ht'
> > ieee80211 phy0: hwaddr f2:0c:b5:7e:10:b8, RTL8187vB (default) V1 +
> > rtl8225z2, rfkill mask 2
> > rtl8187: Customer ID is 0x00
> > Registered led device: rtl8187-phy0::radio
> > Registered led device: rtl8187-phy0::tx
> > Registered led device: rtl8187-phy0::rx
> > rtl8187: wireless switch is on
> > usbcore: registered new interface driver rtl8187
> > "
> >
> > mac_addr=00 told me that maybe something is wrong into eeprom library??
> > and in fact what a surprise, library is what, oops, missing! :))
> > Compilation gives no errors because in the .h eeprom functions are
> > defined as external, but at runtime.. who knows what system library
> > picked up to set/get eeprom params!? some lost old bugged code, thats
> > what scares me.. :P
> >
> > Anyway, I went back and copied the eeprom module from compat 3.9 to
> > backport 3.13 tree:
> > backports-3.13-rc1-1/drivers/misc/eeprom/Makefile
> > obj-$(CPTCFG_EEPROM_93CX6) += eeprom_93cx6.o
> > backports-3.13-rc1-1/Makefile.kernel
> > obj-$(CPTCFG_MAC80211) += drivers/misc/eeprom/
> > backports-3.13-rc1-1/drivers/misc/eeprom/eeprom_93cx6.c
> > Make install again, and voila:
> > "
> > Loading modules backported from Linux version v3.13-rc1-0-g6ce4eac
> > Backport generated by backports.git v3.13-rc1-1-0-g988d789
> > cfg80211: Calling CRDA to update world regulatory domain
> > NET: Registered protocol family 10
> > mac_addr= 00:e0:6c:X:X:X
> > ieee80211 phy0: Selected rate control algorithm 'minstrel_ht'
> > ieee80211 phy0: hwaddr 00:e0:6c:X:X:X, RTL8187vB (default) V1 +
> > rtl8225z2, rfkill mask 2
> > "
> > The right mac address is back! :)
> >
> > But unfortunately that didnt solve the issue with bad filtered frames in
> > monitor mode :(
> > I have the heavy suspect that this eeprom bug could be the cause, as we
> > dont know which library used to set the eeprom data - hence eeprom data
> > got corrupted.
> > And I indeed noticed, as you too I hope, that sometimes after changing
> > mac by WindowsXP tool or macchanger, the faked mac persists after reboot
> > and is detected by linux afterwords! some weird data could really be
> > left persistent into interface..
> >
> > So, I really count on your honest professionalism to help me in fixing
> > this frames issue, because if it happened now, it can happen again with
> > other users and other interfaces.. and we cant keep trashing interfaces
> > because we dont know where the problem comes from.. dont you agree?
>
> I still do not believe that you "trashed" your device. You were not
> corrupting
> the EEPROM data, you were missing the driver to load the data, thus the
> driver
> was making up the data.
Hi Larry, thanks for your answer, I respect your experience, because in
fact I have 20+ years heavy professional experience in programming, but
very little indeed in linux kernel programming.
The frames I see in monitor mode are real, not made up.. are real probe,
beacons, acks, auth, and so on, I can see the same using laptop
interface of my friend, which never got in contact with 3.11 - and he
gets also all data frames too.. lucky him! :)
What do you mean "make up the data"?
> In the kernel, the configuration process forces
> the
> EEPROM driver to be selected whenever the RTL8187 driver is selected,
> thus I
> cannot even simulate this "problem". From this and other "bugs" you are
> reporting, it is clear that your kernel configuration is severely broken.
About the kernel behavior I know.. but what you say is illogical.. if
what you say is true, how can you explain that before exposing my two
interfaces to 3.11, my kernel was nice, and after 3.11 got "severely
broken" ?? if what you say its true, also kernel configuration of BT5
all versions, Kali all versions, Weaknet all version became suddenly
broken just a few days ago.. by what, a collapsed star passing on Hearth
orbit, a Solar Storm ? :))
The issue appears *EVERYWHERE* now.. before *EXPOSING* my two interfaces
to 3.11 I had no problems whatsoever.. is that concept clear?
Sorry, I dont know how to explain that better..
>
> You are perfectly welcome to hack at the driver as much as you want, but
> be
> aware that the kind of packet filtering you are asking about is done by
> the
> firmware on the device. As we have no access to that firmware, there is
> little
> that can be done.
Infact in the little free time I got today I have been analyzing some
code.. and I see there are several calls to eeprom_93cx6_read and
eeprom_93cx6_write.. so it looks possible to write data into eeprom,
isnt it?
Also the read operations imply some bit write into eeprom, isnt it?
So, I think its possible that some bit got "flipped", due to some little
bug/whatever around, isn'it?
So, how can I "re-flip" back the right bit?
I dont know.. but I guess you know what is the right bit to flip.. isn't
it? ;)
> If you are correct that there was a regression that caused monitor mode
> to fail
> at some point, then I suggest that you bisect the problem.
THAT IS EXACTLY WHAT I WANT TO DO! :D
But for doing so I need my interfaces to go back operational, so I can
reproduce all steps of last time, and catch the damned bug!
Like that I cant see sh*t! if sh*t will happen again will mix with sh*t
and I will keep seeing only sh*t! :))
> As rtl8187 has
> not
> changed in several years, that regression is likely caused by some other
> part of
> the wireless stack. The last time I used one of my rtl8187 devices in
> monitor
> mode was with a 3.12 kernel, and it worked with kismet and captured all
> the data
> I needed.
Nice to know that something is working.. ;)
So, are you going to give me some help or not?
And I repeat, its not for me only, its for the whole community, for
whoever will fall in that issue too!
Thanks :)
--
http://www.fastmail.fm - Access your email from home and the web
On 11/27/2013 04:06 PM, Nikita N. wrote:
> Hi All :) Its my first time in a mailinglist, so I apologize if Im
> mistaken.
> I would like to report about few bugs I found running latest modules for
> RTL8187 and latest backports.
> Is that the right place? Thanks
Yes, this is the right place.
Larry
We got it Larry! :)
eeprom module is *MISSING*! :)
Here what I did - I just added the following debug line in rtl8187_probe
just after eeprom_93cx6_multiread call:
printk(KERN_WARNING "mac_addr= %pM\n",mac_addr);
the result was:
"
Loading modules backported from Linux version v3.13-rc1-0-g6ce4eac
Backport generated by backports.git v3.13-rc1-1-0-g988d789
cfg80211: Calling CRDA to update world regulatory domain
cfg80211: World regulatory domain updated:
cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain,
max_eirp)
cfg80211: (2402000 KHz - 2494000 KHz @ 40000 KHz), (N/A, 3000 mBm)
cfg80211: (4910000 KHz - 5235000 KHz @ 40000 KHz), (N/A, 3000 mBm)
NET: Registered protocol family 10
mac_addr= 00:00:00:00:00:00
rtl8187: Invalid hwaddr! Using randomly generated MAC address
ieee80211 phy0: Selected rate control algorithm 'minstrel_ht'
ieee80211 phy0: hwaddr f2:0c:b5:7e:10:b8, RTL8187vB (default) V1 +
rtl8225z2, rfkill mask 2
rtl8187: Customer ID is 0x00
Registered led device: rtl8187-phy0::radio
Registered led device: rtl8187-phy0::tx
Registered led device: rtl8187-phy0::rx
rtl8187: wireless switch is on
usbcore: registered new interface driver rtl8187
"
mac_addr=00 told me that maybe something is wrong into eeprom library??
and in fact what a surprise, library is what, oops, missing! :))
Compilation gives no errors because in the .h eeprom functions are
defined as external, but at runtime.. who knows what system library
picked up to set/get eeprom params!? some lost old bugged code, thats
what scares me.. :P
Anyway, I went back and copied the eeprom module from compat 3.9 to
backport 3.13 tree:
backports-3.13-rc1-1/drivers/misc/eeprom/Makefile
obj-$(CPTCFG_EEPROM_93CX6) += eeprom_93cx6.o
backports-3.13-rc1-1/Makefile.kernel
obj-$(CPTCFG_MAC80211) += drivers/misc/eeprom/
backports-3.13-rc1-1/drivers/misc/eeprom/eeprom_93cx6.c
Make install again, and voila:
"
Loading modules backported from Linux version v3.13-rc1-0-g6ce4eac
Backport generated by backports.git v3.13-rc1-1-0-g988d789
cfg80211: Calling CRDA to update world regulatory domain
NET: Registered protocol family 10
mac_addr= 00:e0:6c:X:X:X
ieee80211 phy0: Selected rate control algorithm 'minstrel_ht'
ieee80211 phy0: hwaddr 00:e0:6c:X:X:X, RTL8187vB (default) V1 +
rtl8225z2, rfkill mask 2
"
The right mac address is back! :)
But unfortunately that didnt solve the issue with bad filtered frames in
monitor mode :(
I have the heavy suspect that this eeprom bug could be the cause, as we
dont know which library used to set the eeprom data - hence eeprom data
got corrupted.
And I indeed noticed, as you too I hope, that sometimes after changing
mac by WindowsXP tool or macchanger, the faked mac persists after reboot
and is detected by linux afterwords! some weird data could really be
left persistent into interface..
So, I really count on your honest professionalism to help me in fixing
this frames issue, because if it happened now, it can happen again with
other users and other interfaces.. and we cant keep trashing interfaces
because we dont know where the problem comes from.. dont you agree?
Thanks :)
On Wed, Nov 27, 2013, at 04:04 PM, Larry Finger wrote:
> Since my previous reply, I have built rtl8187 from backports-3.13-rc1. It
> works
> without any problems.
>
> Larry
>
>
--
http://www.fastmail.fm - The professional email service
ok I see.
well, the last question, where you guys did put in the code the "if"
clauses which filter/dispatch the frames? something like "IF frame is
like that AND interface is in monitor THEN dispatch frame ELSE drop it"?
if its not a secret..
So I will be able to debug the bug myself.. in a few weekends I should
be able to find it and report to you, ok? if there is nothing more
interesting on tv.. ;) thanks
On Thu, Nov 28, 2013, at 06:46 PM, Larry Finger wrote:
> 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
>
>
--
http://www.fastmail.fm - Or how I learned to stop worrying and
love email again
On 11/27/2013 04:59 PM, Nikita N. wrote:
> Alright then :) lets start:
>
>
> - Bug #1:
> Im running on standard Slitaz4, updating modules, the following script:
> ./backports-3.13-rc1-1/scripts/compress_modules.sh
> the "if" is not able to detect the present compression, as result the
> new modules are not compressed, and get mixed with the old ones
> compressed, resulting in errors.
> My actual workaround is just to delete the "if" line.
> The issue is present in all backports releases, since the switch from
> compat-drivers.
>
>
>
>
>
> - Bug #2:
> I previously updated to backports-3.11-rc3, after install here the dmesg
> report:
> "
> Loading modules backported from Linux version v3.11-rc3-0-g5ae90d8
> Backport generated by backports.git v3.11-rc3-1-0-g4e81a94
> cfg80211: Calling CRDA to update world regulatory domain
> NET: Registered protocol family 10
> rtl8187: Invalid hwaddr! Using randomly generated MAC address
> ieee80211 phy0: Selected rate control algorithm 'minstrel_ht'
> ieee80211 phy0: hwaddr 6a:d5:65:93:2c:69, RTL8187vB (default) V1 +
> rtl8225z2, rfkill mask 2
> rtl8187: Customer ID is 0x00
> Registered led device: rtl8187-phy0::radio
> Registered led device: rtl8187-phy0::tx
> Registered led device: rtl8187-phy0::rx
> rtl8187: wireless switch is on
> usbcore: registered new interface driver rtl8187
> "
> The "Invalid hwaddr!" is the bug.
> As workaround I had to rollback to compat-drivers, where the problem
> does not exists, infact here dmesg:
> "
> Compat-drivers backport release: compat-drivers-v3.9-rc4-2-su
> Backport based on linux-stable.git v3.9-rc4
> compat.git: linux-stable.git
> cfg80211: Calling CRDA to update world regulatory domain
> NET: Registered protocol family 10
> ieee80211 phy0: Selected rate control algorithm 'minstrel_ht'
> ieee80211 phy0: hwaddr 00:e0:4c:X:X:X, RTL8187vB (default) V1 +
> rtl8225z2, rfkill mask 2
> "
>
>
>
> - Bug #3:
> After reverting back to compat-drivers, my interface started behaving
> wrong in monitor mode.
> Monitor mode was always working properly before, but after applying
> backports-3.11 now is broken.
> The symptoms are the following: whatever is the channel, from airodump
> or wireshark I can see only broadcasts frames (dest ff:ff:ff..) and
> management frames (ack,probes,beacons,req send,block,
> assoc,auth,deauth,..)
> I tried also other live-RAM-only distros as BT5, Kali and Weaknet, the
> issue persists.
> The interface behaves like some kind of "wrong" data has been written
> permanently (in the eeprom?) which instructs the interface to discard
> all data frames when in monitor mode.
> Managed mode still works perfectly.
> I still could not find a workaround for this bug, as result my interface
> is still unusable in monitor mode.
>
>
>
>
> - Bug #4:
> Today I tried install latest stable backports-3.13-rc1-1, but RTL
> modules are not compiled.
> Running make defconfig-rtlwifi, it compiles only generic modules.
> Running make defconfig-wifi, compilation is very fast, and skips lots of
> chipsets, again same issue - no RTL modules.
> No workaround - I reverted back again to compat-drivers.
>
>
> I believe the highest priority bug is the #3, because turned my
> interface unusable.
> Of course its possible that the cause of the monitor malfunction doesnt
> come from backports, I cant say that for sure, but for sure happened
> after reverting to compat-drivers - where it always worked perfectly.
>
> Please feel free to ask all further infos you possibly need!
> Thanks for the attention :)
Since my previous reply, I have built rtl8187 from backports-3.13-rc1. It works
without any problems.
Larry
On 11/30/2013 06:03 AM, Nikita N. wrote:
> We got it Larry! :)
> eeprom module is *MISSING*! :)
> Here what I did - I just added the following debug line in rtl8187_probe
> just after eeprom_93cx6_multiread call:
> printk(KERN_WARNING "mac_addr= %pM\n",mac_addr);
> the result was:
> "
> Loading modules backported from Linux version v3.13-rc1-0-g6ce4eac
> Backport generated by backports.git v3.13-rc1-1-0-g988d789
> cfg80211: Calling CRDA to update world regulatory domain
> cfg80211: World regulatory domain updated:
> cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain,
> max_eirp)
> cfg80211: (2402000 KHz - 2494000 KHz @ 40000 KHz), (N/A, 3000 mBm)
> cfg80211: (4910000 KHz - 5235000 KHz @ 40000 KHz), (N/A, 3000 mBm)
> NET: Registered protocol family 10
> mac_addr= 00:00:00:00:00:00
> rtl8187: Invalid hwaddr! Using randomly generated MAC address
> ieee80211 phy0: Selected rate control algorithm 'minstrel_ht'
> ieee80211 phy0: hwaddr f2:0c:b5:7e:10:b8, RTL8187vB (default) V1 +
> rtl8225z2, rfkill mask 2
> rtl8187: Customer ID is 0x00
> Registered led device: rtl8187-phy0::radio
> Registered led device: rtl8187-phy0::tx
> Registered led device: rtl8187-phy0::rx
> rtl8187: wireless switch is on
> usbcore: registered new interface driver rtl8187
> "
>
> mac_addr=00 told me that maybe something is wrong into eeprom library??
> and in fact what a surprise, library is what, oops, missing! :))
> Compilation gives no errors because in the .h eeprom functions are
> defined as external, but at runtime.. who knows what system library
> picked up to set/get eeprom params!? some lost old bugged code, thats
> what scares me.. :P
>
> Anyway, I went back and copied the eeprom module from compat 3.9 to
> backport 3.13 tree:
> backports-3.13-rc1-1/drivers/misc/eeprom/Makefile
> obj-$(CPTCFG_EEPROM_93CX6) += eeprom_93cx6.o
> backports-3.13-rc1-1/Makefile.kernel
> obj-$(CPTCFG_MAC80211) += drivers/misc/eeprom/
> backports-3.13-rc1-1/drivers/misc/eeprom/eeprom_93cx6.c
> Make install again, and voila:
> "
> Loading modules backported from Linux version v3.13-rc1-0-g6ce4eac
> Backport generated by backports.git v3.13-rc1-1-0-g988d789
> cfg80211: Calling CRDA to update world regulatory domain
> NET: Registered protocol family 10
> mac_addr= 00:e0:6c:X:X:X
> ieee80211 phy0: Selected rate control algorithm 'minstrel_ht'
> ieee80211 phy0: hwaddr 00:e0:6c:X:X:X, RTL8187vB (default) V1 +
> rtl8225z2, rfkill mask 2
> "
> The right mac address is back! :)
>
> But unfortunately that didnt solve the issue with bad filtered frames in
> monitor mode :(
> I have the heavy suspect that this eeprom bug could be the cause, as we
> dont know which library used to set the eeprom data - hence eeprom data
> got corrupted.
> And I indeed noticed, as you too I hope, that sometimes after changing
> mac by WindowsXP tool or macchanger, the faked mac persists after reboot
> and is detected by linux afterwords! some weird data could really be
> left persistent into interface..
>
> So, I really count on your honest professionalism to help me in fixing
> this frames issue, because if it happened now, it can happen again with
> other users and other interfaces.. and we cant keep trashing interfaces
> because we dont know where the problem comes from.. dont you agree?
I still do not believe that you "trashed" your device. You were not corrupting
the EEPROM data, you were missing the driver to load the data, thus the driver
was making up the data. In the kernel, the configuration process forces the
EEPROM driver to be selected whenever the RTL8187 driver is selected, thus I
cannot even simulate this "problem". From this and other "bugs" you are
reporting, it is clear that your kernel configuration is severely broken.
You are perfectly welcome to hack at the driver as much as you want, but be
aware that the kind of packet filtering you are asking about is done by the
firmware on the device. As we have no access to that firmware, there is little
that can be done.
If you are correct that there was a regression that caused monitor mode to fail
at some point, then I suggest that you bisect the problem. As rtl8187 has not
changed in several years, that regression is likely caused by some other part of
the wireless stack. The last time I used one of my rtl8187 devices in monitor
mode was with a 3.12 kernel, and it worked with kismet and captured all the data
I needed.
Larry
Alright then :) lets start:
- Bug #1:
Im running on standard Slitaz4, updating modules, the following script:
./backports-3.13-rc1-1/scripts/compress_modules.sh
the "if" is not able to detect the present compression, as result the
new modules are not compressed, and get mixed with the old ones
compressed, resulting in errors.
My actual workaround is just to delete the "if" line.
The issue is present in all backports releases, since the switch from
compat-drivers.
- Bug #2:
I previously updated to backports-3.11-rc3, after install here the dmesg
report:
"
Loading modules backported from Linux version v3.11-rc3-0-g5ae90d8
Backport generated by backports.git v3.11-rc3-1-0-g4e81a94
cfg80211: Calling CRDA to update world regulatory domain
NET: Registered protocol family 10
rtl8187: Invalid hwaddr! Using randomly generated MAC address
ieee80211 phy0: Selected rate control algorithm 'minstrel_ht'
ieee80211 phy0: hwaddr 6a:d5:65:93:2c:69, RTL8187vB (default) V1 +
rtl8225z2, rfkill mask 2
rtl8187: Customer ID is 0x00
Registered led device: rtl8187-phy0::radio
Registered led device: rtl8187-phy0::tx
Registered led device: rtl8187-phy0::rx
rtl8187: wireless switch is on
usbcore: registered new interface driver rtl8187
"
The "Invalid hwaddr!" is the bug.
As workaround I had to rollback to compat-drivers, where the problem
does not exists, infact here dmesg:
"
Compat-drivers backport release: compat-drivers-v3.9-rc4-2-su
Backport based on linux-stable.git v3.9-rc4
compat.git: linux-stable.git
cfg80211: Calling CRDA to update world regulatory domain
NET: Registered protocol family 10
ieee80211 phy0: Selected rate control algorithm 'minstrel_ht'
ieee80211 phy0: hwaddr 00:e0:4c:X:X:X, RTL8187vB (default) V1 +
rtl8225z2, rfkill mask 2
"
- Bug #3:
After reverting back to compat-drivers, my interface started behaving
wrong in monitor mode.
Monitor mode was always working properly before, but after applying
backports-3.11 now is broken.
The symptoms are the following: whatever is the channel, from airodump
or wireshark I can see only broadcasts frames (dest ff:ff:ff..) and
management frames (ack,probes,beacons,req send,block,
assoc,auth,deauth,..)
I tried also other live-RAM-only distros as BT5, Kali and Weaknet, the
issue persists.
The interface behaves like some kind of "wrong" data has been written
permanently (in the eeprom?) which instructs the interface to discard
all data frames when in monitor mode.
Managed mode still works perfectly.
I still could not find a workaround for this bug, as result my interface
is still unusable in monitor mode.
- Bug #4:
Today I tried install latest stable backports-3.13-rc1-1, but RTL
modules are not compiled.
Running make defconfig-rtlwifi, it compiles only generic modules.
Running make defconfig-wifi, compilation is very fast, and skips lots of
chipsets, again same issue - no RTL modules.
No workaround - I reverted back again to compat-drivers.
I believe the highest priority bug is the #3, because turned my
interface unusable.
Of course its possible that the cause of the monitor malfunction doesnt
come from backports, I cant say that for sure, but for sure happened
after reverting to compat-drivers - where it always worked perfectly.
Please feel free to ask all further infos you possibly need!
Thanks for the attention :)
On Wed, Nov 27, 2013, at 02:08 PM, Larry Finger wrote:
> On 11/27/2013 04:06 PM, Nikita N. wrote:
> > Hi All :) Its my first time in a mailinglist, so I apologize if Im
> > mistaken.
> > I would like to report about few bugs I found running latest modules for
> > RTL8187 and latest backports.
> > Is that the right place? Thanks
>
> Yes, this is the right place.
>
> Larry
>
>
--
http://www.fastmail.fm - Send your email first class
BTW you right, got nervous me too.. configure_filter is called too many
times.. mostly in managed mode! is that correct behavior?
If its correct, the function needs a little optimization, in my
opinion..I mean, I noticed that, after the first few calls, later the
value of priv->rx_conf becomes redundant, IN value of priv->rx_conf is
the same as OUT.. and rtl818x_iowrite32_async unleashes a hell of stack
at every call.. :P
Is it worth putting one more condition such as, only if priv->rx_conf
IN!=OUT then call rtl818x_iowrite32_async ?
Thanks :)
On Wed, Dec 4, 2013, at 12:49 PM, Larry Finger wrote:
> Until I fixed your patch, I could not be assured that it would work. I
> get
> nervous when that small a patch generates that many warhings.
--
http://www.fastmail.fm - Does exactly what it says on the tin
Hi Larry :) Im afraid I didnt receive your answer to my last email.. in
case you sent, please resend, thanks :)
As for "dissecting" the issue, as you suggested, I have been filling
your code with debug lines.
Very interesting in my opinion is the report from
drivers/net/wireless/rtl818x/rtl8187/dev.c#rtl8187_configure_filter(),
as follows:
IN>changed_flags=240,total_flags=2147483888,multicast=0,priv->rx_conf=2425682954
>FIF_CONTROL
>FIF_OTHER_BSS
>not FIF_ALLMULTI
drivers/net/wireless/rtl818x/rtl8187/dev.c#rtl818x_iowrite32_async
drivers/net/wireless/rtl818x/rtl8187/dev.c#rtl8187_iowrite_async
OUT>total_flags=96,priv->rx_conf=2426207243
.. after, some daemon calls it again multiple times, but result is
always the same as follows:
IN>changed_flags=144,total_flags=2147483888,multicast=0,priv->rx_conf=2426207243
>not FIF_ALLMULTI
drivers/net/wireless/rtl818x/rtl8187/dev.c#rtl818x_iowrite32_async
drivers/net/wireless/rtl818x/rtl8187/dev.c#rtl8187_iowrite_async
net/mac80211/util.c#ieee80211_queue_work
OUT>total_flags=96,priv->rx_conf=2426207243
.. seeing anything unusual?
I have the strange feeling that "IN" value of priv->rx_conf could be
bugged.. as result the relative OUT value is maybe wrong.. :P
Anyway, could you please perform the same test on your working
interfaces, and report me the output?
The values of IN/OUT and so on, of rtl8187_configure_filter(), *AFTER*
calling "airmon-ng start wlan0"?
>From your probe, my interface type is as follow:
- "RTL8187vB (default)"
- PCI_EEPROM_WIDTH_93C46
- customer id 0
Please insert the following debug lines, as I did:
static void rtl8187_configure_filter()
{
printk(KERN_WARNING
"drivers/net/wireless/rtl818x/rtl8187/dev.c#rtl8187_configure_filter");
struct rtl8187_priv *priv = dev->priv;
printk(KERN_WARNING
"IN>changed_flags=%u,total_flags=%u,multicast=%llu,priv->rx_conf=%u",changed_flags,*total_flags,multicast,priv->rx_conf);
if (changed_flags & FIF_FCSFAIL) {
priv->rx_conf ^= RTL818X_RX_CONF_FCS;
printk(KERN_WARNING ">FIF_FCSFAIL");}
if (changed_flags & FIF_CONTROL) {
priv->rx_conf ^= RTL818X_RX_CONF_CTRL;
printk(KERN_WARNING ">FIF_CONTROL");}
if (changed_flags & FIF_OTHER_BSS) {
priv->rx_conf ^= RTL818X_RX_CONF_MONITOR;
printk(KERN_WARNING ">FIF_OTHER_BSS");}
if (*total_flags & FIF_ALLMULTI || multicast > 0) {
priv->rx_conf |= RTL818X_RX_CONF_MULTICAST;
printk(KERN_WARNING ">FIF_ALLMULTI");}
else {
priv->rx_conf &= ~RTL818X_RX_CONF_MULTICAST;
printk(KERN_WARNING ">not FIF_ALLMULTI");}
rtl818x_iowrite32_async(priv, &priv->map->RX_CONF,
priv->rx_conf);
printk(KERN_WARNING
"OUT>total_flags=%u,priv->rx_conf=%u",*total_flags,priv->rx_conf);
}
If you get different outputs also between your interfaces, please send
me all different outputs!
thanks :)
On Sat, Nov 30, 2013, at 11:04 AM, Larry Finger wrote:
> If you want to send me one of your devices, I'll check it out. Otherwise,
> there
> is little I can do. It would be impossible to duplicate the path you have
> followed.
>
> Larry
>
>
>
--
http://www.fastmail.fm - A fast, anti-spam email service.
Hi Larry :)
If I can give you my humble suggestion - keep the rest of your 8187
interfaces park, far from 3.13 .. I lost both mine like that.. :P
Instead if you can, please test another working 8187 on a different safe
distro, e.g. Backtrack5 Live, any version, and install our patch, ok?
Would be nice to see logs there..
As you know, Backtrack5 is a live distro, means yes, when reboot all
changes are lost.. but you workaround that running on VMWare and
choosing "save state" (instead of power-off)
The times I have been running on BT5, monitor mode always worked with no
issues.. kinda of, at last 3 years no-problems testing :)
As I see from your log, your 8187 goes in monitor (promiscuous) with
different patterns: priv->rx_conf shifts from 0e:fc:94:90 (0x9094fc0e)
to 0f:fc:9c:90 (0x909cfc0f) plus more options.. in mine, priv->rx_conf
shifts from 0a:fc:94:90 to 0b:fc:9c:90.
The last 3 bytes of priv->rx_conf are the same in mine and yours, just
the first is different (0b/0f) but it still doesnt put interface in
functional monitor mode.
FYI, in backports Hauke Mehrtens wrote me about a eeprom bug they
discovered.. could it be related?
thanks :)
On Wed, Dec 4, 2013, at 12:49 PM, Larry Finger wrote:
>
> Until I fixed your patch, I could not be assured that it would work. I
> get
> nervous when that small a patch generates that many warhings.
>
> I was finally able to test monitor mode this morning, and found that it
> is
> failing for kernel 3.13-rc2 as you said. The system set promiscous mode,
> but no
> off-channel data is returned. I use openSUSE 13.1 on an ancient laptop.
> It is
> installed without X - not enough memory. I use kismet to capture
> over-the-air
> data. I am currently building a v3.0 kernel to see when the failure
> happened. At
> least I am pretty sure that I used rtl8187 in monitor mode in the past.
>
> The logged data for my most recent run is
>
> [ 295.841561] device wlan2 entered promiscuous mode
> [ 295.842068] rtl8187_configure_filter
> [ 295.842104] IN>changed_flags=0x3 ,total_flags=0x80000001
> ,multicast=0x3
> ,priv->rx_conf=0x9094fc0e
> [ 295.842114] >FIF_ALLMULTI
> [ 295.842190] OUT>total_flags=0x2 ,priv->rx_conf=0x9094fc0e
> [ 295.901636] rtl8187_configure_filter
> [ 295.901690] IN>changed_flags=0xf3 ,total_flags=0x800000f1
> ,multicast=0x3
> ,priv->rx_conf=0x9094fc0e
> [ 295.901702] >FIF_CONTROL
> [ 295.901711] >FIF_OTHER_BSS
> [ 295.902016] >FIF_ALLMULTI, ***** Also has FIF_PSPOLL and FIF_PROBE_REQ
> set
> [ 295.902113] OUT>total_flags=0x62 ,priv->rx_conf=0x909cfc0f
> [ 296.279678] device wlan2mon entered promiscuous mode
> [ 296.282327] rtl8187_configure_filter
> [ 296.282363] IN>changed_flags=0x93 ,total_flags=0x800000f1
> ,multicast=0x3
> ,priv->rx_conf=0x909cfc0f
> [ 296.282373] >FIF_ALLMULTI
> [ 296.282445] OUT>total_flags=0x62 ,priv->rx_conf=0x909cfc0f
>
> Larry
>
--
http://www.fastmail.fm - A no graphics, no pop-ups email service
On 12/03/2013 03:21 PM, Nikita N. wrote:
After rewriting your patch a bit (see attached copy), I got the following:
usb 1-5: new high-speed USB device number 5 using ehci-pci
rtl8187: inconsistency between id with OEM info!
-- regulatory rules --
ieee80211 phy3: Selected rate control algorithm 'minstrel_ht'
ieee80211 phy3: 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[5366]: renamed network interface wlan1 to wlp0s2f1u5
rtl8187_configure_filter
IN>changed_flags=0x0 ,total_flags=0x80000000 ,multicast=0x1
,priv->rx_conf=0x9094fc0e
>FIF_ALLMULTI
OUT>total_flags=0x2 ,priv->rx_conf=0x9094fc0e
rtl8187_configure_filter
IN>changed_flags=0x2 ,total_flags=0x80000000 ,multicast=0x1
,priv->rx_conf=0x9094fc0e
>FIF_ALLMULTI
OUT>total_flags=0x2 ,priv->rx_conf=0x9094fc0e
IPv6: ADDRCONF(NETDEV_UP): wlp0s2f1u5: link is not ready
rtl8187_configure_filter
IN>changed_flags=0x2 ,total_flags=0x80000000 ,multicast=0x2
,priv->rx_conf=0x9094fc0e
>FIF_ALLMULTI
OUT>total_flags=0x2 ,priv->rx_conf=0x9094fc0e
rtl8187_configure_filter
IN>changed_flags=0x12 ,total_flags=0x80000010 ,multicast=0x2
,priv->rx_conf=0x9094fc0e
>FIF_ALLMULTI
OUT>total_flags=0x2 ,priv->rx_conf=0x9094fc0e
rtl8187_configure_filter
IN>changed_flags=0x2 ,total_flags=0x80000000 ,multicast=0x2
,priv->rx_conf=0x9094fc0e
>FIF_ALLMULTI
OUT>total_flags=0x2 ,priv->rx_conf=0x9094fc0e
rtl8187_configure_filter
IN>changed_flags=0x12 ,total_flags=0x80000010 ,multicast=0x2
,priv->rx_conf=0x9094fc0e
>FIF_ALLMULTI
OUT>total_flags=0x2 ,priv->rx_conf=0x9094fc0e
wlp0s2f1u5: authenticate with 20:e5:2a:01:f7:ea
rtl8187_configure_filter
IN>changed_flags=0x2 ,total_flags=0x80000000 ,multicast=0x2
,priv->rx_conf=0x9094fc0e
>FIF_ALLMULTI
OUT>total_flags=0x2 ,priv->rx_conf=0x9094fc0e
wlp0s2f1u5: send auth to 20:e5:2a:01:f7:ea (try 1/3)
wlp0s2f1u5: authenticated
wlp0s2f1u5: associate with 20:e5:2a:01:f7:ea (try 1/3)
wlp0s2f1u5: RX AssocResp from 20:e5:2a:01:f7:ea (capab=0x411 status=0 aid=7)
wlp0s2f1u5: associated
IPv6: ADDRCONF(NETDEV_CHANGE): wlp0s2f1u5: link becomes ready
rtl8187_configure_filter
IN>changed_flags=0x2 ,total_flags=0x80000000 ,multicast=0x3
,priv->rx_conf=0x9094fc0e
>FIF_ALLMULTI
OUT>total_flags=0x2 ,priv->rx_conf=0x9094fc0e
rtl8187_configure_filter
IN>changed_flags=0x2 ,total_flags=0x80000000 ,multicast=0x4
,priv->rx_conf=0x9094fc0e
>FIF_ALLMULTI
OUT>total_flags=0x2 ,priv->rx_conf=0x9094fc0e
rtl8187_configure_filter
IN>changed_flags=0x2 ,total_flags=0x80000000 ,multicast=0x5
,priv->rx_conf=0x9094fc0e
>FIF_ALLMULTI
OUT>total_flags=0x2 ,priv->rx_conf=0x9094fc0e
rtl8187_configure_filter
IN>changed_flags=0x12 ,total_flags=0x80000010 ,multicast=0x5
,priv->rx_conf=0x9094fc0e
>FIF_ALLMULTI
OUT>total_flags=0x2 ,priv->rx_conf=0x9094fc0e
Some comments on your patch:
1. The routine can be gotten from ("%s\n", __func__). That is a lot easier than
hand coding the routine name.
2. Every printk should be terminated with \n (new line).
3. You can print multi-byte values with 0x%x. No need to split out the bytes the
way you did.
I do not have aircrack running on my system, thus I cannot issue exactly the
same command that you did.
The "daemon" that keeps calling rtl8187_configure_filter() is the transmit
packet process of the kernel. You get one call for every packet out.
Larry
Hi Larry :) thank you very much for the comments on my patch, really
appreciated.
Anyway, lets try to stick on the issue, ok?
The issue is the malfunction of *MONITOR* mode.
I can't see any monitor mode call from your log, you tested only managed
mode, isn't it?
I repeat, managed mode works perfectly also in my interfaces, no need to
test it.
We need to test *MONITOR* mode.
Since you say that at you, the *MONITOR* mode works ok, I need to
reproduce your environment here, in order to test the *MONITOR* mode.
As already asked in previous email, what OS Linux distro do you use
exactly when you test *MONITOR* mode in your 8187 interfaces?
What programs suite do you use exactly when you test *MONITOR* mode in
your 8187 interfaces?
Thanks :)
On Tue, Dec 3, 2013, at 06:32 PM, Larry Finger wrote:
> On 12/03/2013 03:21 PM, Nikita N. wrote:
>
> After rewriting your patch a bit (see attached copy), I got the
> following:
>
> usb 1-5: new high-speed USB device number 5 using ehci-pci
> rtl8187: inconsistency between id with OEM info!
> -- regulatory rules --
> ieee80211 phy3: Selected rate control algorithm 'minstrel_ht'
> ieee80211 phy3: 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[5366]: renamed network interface wlan1 to wlp0s2f1u5
> rtl8187_configure_filter
> IN>changed_flags=0x0 ,total_flags=0x80000000 ,multicast=0x1
> ,priv->rx_conf=0x9094fc0e
> >FIF_ALLMULTI
> OUT>total_flags=0x2 ,priv->rx_conf=0x9094fc0e
> rtl8187_configure_filter
> IN>changed_flags=0x2 ,total_flags=0x80000000 ,multicast=0x1
> ,priv->rx_conf=0x9094fc0e
> >FIF_ALLMULTI
> OUT>total_flags=0x2 ,priv->rx_conf=0x9094fc0e
> IPv6: ADDRCONF(NETDEV_UP): wlp0s2f1u5: link is not ready
> rtl8187_configure_filter
> IN>changed_flags=0x2 ,total_flags=0x80000000 ,multicast=0x2
> ,priv->rx_conf=0x9094fc0e
> >FIF_ALLMULTI
> OUT>total_flags=0x2 ,priv->rx_conf=0x9094fc0e
> rtl8187_configure_filter
> IN>changed_flags=0x12 ,total_flags=0x80000010 ,multicast=0x2
> ,priv->rx_conf=0x9094fc0e
> >FIF_ALLMULTI
> OUT>total_flags=0x2 ,priv->rx_conf=0x9094fc0e
> rtl8187_configure_filter
> IN>changed_flags=0x2 ,total_flags=0x80000000 ,multicast=0x2
> ,priv->rx_conf=0x9094fc0e
> >FIF_ALLMULTI
> OUT>total_flags=0x2 ,priv->rx_conf=0x9094fc0e
> rtl8187_configure_filter
> IN>changed_flags=0x12 ,total_flags=0x80000010 ,multicast=0x2
> ,priv->rx_conf=0x9094fc0e
> >FIF_ALLMULTI
> OUT>total_flags=0x2 ,priv->rx_conf=0x9094fc0e
> wlp0s2f1u5: authenticate with 20:e5:2a:01:f7:ea
> rtl8187_configure_filter
> IN>changed_flags=0x2 ,total_flags=0x80000000 ,multicast=0x2
> ,priv->rx_conf=0x9094fc0e
> >FIF_ALLMULTI
> OUT>total_flags=0x2 ,priv->rx_conf=0x9094fc0e
> wlp0s2f1u5: send auth to 20:e5:2a:01:f7:ea (try 1/3)
> wlp0s2f1u5: authenticated
> wlp0s2f1u5: associate with 20:e5:2a:01:f7:ea (try 1/3)
> wlp0s2f1u5: RX AssocResp from 20:e5:2a:01:f7:ea (capab=0x411 status=0
> aid=7)
> wlp0s2f1u5: associated
> IPv6: ADDRCONF(NETDEV_CHANGE): wlp0s2f1u5: link becomes ready
> rtl8187_configure_filter
> IN>changed_flags=0x2 ,total_flags=0x80000000 ,multicast=0x3
> ,priv->rx_conf=0x9094fc0e
> >FIF_ALLMULTI
> OUT>total_flags=0x2 ,priv->rx_conf=0x9094fc0e
> rtl8187_configure_filter
> IN>changed_flags=0x2 ,total_flags=0x80000000 ,multicast=0x4
> ,priv->rx_conf=0x9094fc0e
> >FIF_ALLMULTI
> OUT>total_flags=0x2 ,priv->rx_conf=0x9094fc0e
> rtl8187_configure_filter
> IN>changed_flags=0x2 ,total_flags=0x80000000 ,multicast=0x5
> ,priv->rx_conf=0x9094fc0e
> >FIF_ALLMULTI
> OUT>total_flags=0x2 ,priv->rx_conf=0x9094fc0e
> rtl8187_configure_filter
> IN>changed_flags=0x12 ,total_flags=0x80000010 ,multicast=0x5
> ,priv->rx_conf=0x9094fc0e
> >FIF_ALLMULTI
> OUT>total_flags=0x2 ,priv->rx_conf=0x9094fc0e
>
> Some comments on your patch:
>
> 1. The routine can be gotten from ("%s\n", __func__). That is a lot
> easier than
> hand coding the routine name.
>
> 2. Every printk should be terminated with \n (new line).
>
> 3. You can print multi-byte values with 0x%x. No need to split out the
> bytes the
> way you did.
>
> I do not have aircrack running on my system, thus I cannot issue exactly
> the
> same command that you did.
>
> The "daemon" that keeps calling rtl8187_configure_filter() is the
> transmit
> packet process of the kernel. You get one call for every packet out.
>
> Larry
>
> Email had 1 attachment:
> + nikita8187.patch
> 2k (text/x-patch)
--
http://www.fastmail.fm - Choose from over 50 domains or use your own
On 12/04/2013 01:52 AM, Nikita N. wrote:
> Hi Larry :) thank you very much for the comments on my patch, really
> appreciated.
>
> Anyway, lets try to stick on the issue, ok?
> The issue is the malfunction of *MONITOR* mode.
> I can't see any monitor mode call from your log, you tested only managed
> mode, isn't it?
> I repeat, managed mode works perfectly also in my interfaces, no need to
> test it.
> We need to test *MONITOR* mode.
>
> Since you say that at you, the *MONITOR* mode works ok, I need to
> reproduce your environment here, in order to test the *MONITOR* mode.
> As already asked in previous email, what OS Linux distro do you use
> exactly when you test *MONITOR* mode in your 8187 interfaces?
> What programs suite do you use exactly when you test *MONITOR* mode in
> your 8187 interfaces?
Until I fixed your patch, I could not be assured that it would work. I get
nervous when that small a patch generates that many warhings.
I was finally able to test monitor mode this morning, and found that it is
failing for kernel 3.13-rc2 as you said. The system set promiscous mode, but no
off-channel data is returned. I use openSUSE 13.1 on an ancient laptop. It is
installed without X - not enough memory. I use kismet to capture over-the-air
data. I am currently building a v3.0 kernel to see when the failure happened. At
least I am pretty sure that I used rtl8187 in monitor mode in the past.
The logged data for my most recent run is
[ 295.841561] device wlan2 entered promiscuous mode
[ 295.842068] rtl8187_configure_filter
[ 295.842104] IN>changed_flags=0x3 ,total_flags=0x80000001 ,multicast=0x3
,priv->rx_conf=0x9094fc0e
[ 295.842114] >FIF_ALLMULTI
[ 295.842190] OUT>total_flags=0x2 ,priv->rx_conf=0x9094fc0e
[ 295.901636] rtl8187_configure_filter
[ 295.901690] IN>changed_flags=0xf3 ,total_flags=0x800000f1 ,multicast=0x3
,priv->rx_conf=0x9094fc0e
[ 295.901702] >FIF_CONTROL
[ 295.901711] >FIF_OTHER_BSS
[ 295.902016] >FIF_ALLMULTI, ***** Also has FIF_PSPOLL and FIF_PROBE_REQ set
[ 295.902113] OUT>total_flags=0x62 ,priv->rx_conf=0x909cfc0f
[ 296.279678] device wlan2mon entered promiscuous mode
[ 296.282327] rtl8187_configure_filter
[ 296.282363] IN>changed_flags=0x93 ,total_flags=0x800000f1 ,multicast=0x3
,priv->rx_conf=0x909cfc0f
[ 296.282373] >FIF_ALLMULTI
[ 296.282445] OUT>total_flags=0x62 ,priv->rx_conf=0x909cfc0f
Larry
On 12/03/2013 07:59 AM, Nikita N. wrote:
> Hi Larry :) Im afraid I didnt receive your answer to my last email.. in
> case you sent, please resend, thanks :)
>
> As for "dissecting" the issue, as you suggested, I have been filling
> your code with debug lines.
> Very interesting in my opinion is the report from
> drivers/net/wireless/rtl818x/rtl8187/dev.c#rtl8187_configure_filter(),
> as follows:
>
> IN>changed_flags=240,total_flags=2147483888,multicast=0,priv->rx_conf=2425682954
>> FIF_CONTROL
>> FIF_OTHER_BSS
>> not FIF_ALLMULTI
> drivers/net/wireless/rtl818x/rtl8187/dev.c#rtl818x_iowrite32_async
> drivers/net/wireless/rtl818x/rtl8187/dev.c#rtl8187_iowrite_async
> OUT>total_flags=96,priv->rx_conf=2426207243
Please do not dump pointers, flags, etc. as a decimal value. In most cases, you
need to hexadecimal value to interpret them. Why not output them in hex to begin
with?
> .. after, some daemon calls it again multiple times, but result is
> always the same as follows:
> IN>changed_flags=144,total_flags=2147483888,multicast=0,priv->rx_conf=2426207243
>> not FIF_ALLMULTI
> drivers/net/wireless/rtl818x/rtl8187/dev.c#rtl818x_iowrite32_async
> drivers/net/wireless/rtl818x/rtl8187/dev.c#rtl8187_iowrite_async
> net/mac80211/util.c#ieee80211_queue_work
> OUT>total_flags=96,priv->rx_conf=2426207243
>
> .. seeing anything unusual?
>
> I have the strange feeling that "IN" value of priv->rx_conf could be
> bugged.. as result the relative OUT value is maybe wrong.. :P
>
> Anyway, could you please perform the same test on your working
> interfaces, and report me the output?
> The values of IN/OUT and so on, of rtl8187_configure_filter(), *AFTER*
> calling "airmon-ng start wlan0"?
If you want me to test anything, you need to send me patches that I can apply.
Having to regenerate your patches here is something I have no interest in doing.
>>From your probe, my interface type is as follow:
> - "RTL8187vB (default)"
> - PCI_EEPROM_WIDTH_93C46
> - customer id 0
>
> Please insert the following debug lines, as I did:
> static void rtl8187_configure_filter()
> {
> printk(KERN_WARNING
> "drivers/net/wireless/rtl818x/rtl8187/dev.c#rtl8187_configure_filter");
> struct rtl8187_priv *priv = dev->priv;
> printk(KERN_WARNING
> "IN>changed_flags=%u,total_flags=%u,multicast=%llu,priv->rx_conf=%u",changed_flags,*total_flags,multicast,priv->rx_conf);
> if (changed_flags & FIF_FCSFAIL) {
> priv->rx_conf ^= RTL818X_RX_CONF_FCS;
> printk(KERN_WARNING ">FIF_FCSFAIL");}
> if (changed_flags & FIF_CONTROL) {
> priv->rx_conf ^= RTL818X_RX_CONF_CTRL;
> printk(KERN_WARNING ">FIF_CONTROL");}
> if (changed_flags & FIF_OTHER_BSS) {
> priv->rx_conf ^= RTL818X_RX_CONF_MONITOR;
> printk(KERN_WARNING ">FIF_OTHER_BSS");}
> if (*total_flags & FIF_ALLMULTI || multicast > 0) {
> priv->rx_conf |= RTL818X_RX_CONF_MULTICAST;
> printk(KERN_WARNING ">FIF_ALLMULTI");}
> else {
> priv->rx_conf &= ~RTL818X_RX_CONF_MULTICAST;
> printk(KERN_WARNING ">not FIF_ALLMULTI");}
>
> rtl818x_iowrite32_async(priv, &priv->map->RX_CONF,
> priv->rx_conf);
> printk(KERN_WARNING
> "OUT>total_flags=%u,priv->rx_conf=%u",*total_flags,priv->rx_conf);
> }
>
> If you get different outputs also between your interfaces, please send
> me all different outputs!
> thanks :)
Larry
On Sat, Nov 30, 2013, at 11:04 AM, Larry Finger wrote:
> On 11/30/2013 12:23 PM, Nikita N. wrote:
> >
> > Hi Larry, thanks for your answer, I respect your experience, because in
> > fact I have 20+ years heavy professional experience in programming, but
> > very little indeed in linux kernel programming.
> > The frames I see in monitor mode are real, not made up.. are real probe,
> > beacons, acks, auth, and so on, I can see the same using laptop
> > interface of my friend, which never got in contact with 3.11 - and he
> > gets also all data frames too.. lucky him! :)
> > What do you mean "make up the data"?
>
> I have no idea how it worked at all Without the entry points in the
> EEPROM
> routine, module loading should have gotten an error. I hope you did not
> force
> the module to load. The driver had to generate a random MAC address. That
> is
> made up data.
Good day Larry :) As Hauke Mehrtens confirmed me, they removed eeprom
modules from backports, in order to rely on distro native eeprom
libraries.. unfortunately Slitaz doesnt seems to have such evolved
eeprom native libraries.. :P hence I dont know which strange kind of
library was called to generate that mac=00..
Anyway, now Im going to fill all your code of debug messages, so we will
know whats going on, you bet! :)
You said you run successfully monitor mode on your rtl8187, what distro
exactly did you use? I want to download it too and try tests also
there.. what do you think?
>
> > About the kernel behavior I know.. but what you say is illogical.. if
> > what you say is true, how can you explain that before exposing my two
> > interfaces to 3.11, my kernel was nice, and after 3.11 got "severely
> > broken" ?? if what you say its true, also kernel configuration of BT5
> > all versions, Kali all versions, Weaknet all version became suddenly
> > broken just a few days ago.. by what, a collapsed star passing on Hearth
> > orbit, a Solar Storm ? :))
> > The issue appears *EVERYWHERE* now.. before *EXPOSING* my two interfaces
> > to 3.11 I had no problems whatsoever.. is that concept clear?
> > Sorry, I dont know how to explain that better..
>
> Your attitude is really putting me off!
>
> > Infact in the little free time I got today I have been analyzing some
> > code.. and I see there are several calls to eeprom_93cx6_read and
> > eeprom_93cx6_write.. so it looks possible to write data into eeprom,
> > isnt it?
> > Also the read operations imply some bit write into eeprom, isnt it?
> > So, I think its possible that some bit got "flipped", due to some little
> > bug/whatever around, isn'it?
> > So, how can I "re-flip" back the right bit?
> > I dont know.. but I guess you know what is the right bit to flip.. isn't
> > it? ;)
>
> When you want to read data from the PROM, you need to set up its
> controller to
> allow the read. The PROM is not mapped to memory. That is what the write
> operations do. As far as I know, there is no way to modify the data
> written into
> the PROM
Maybe the circuit allows permanent changes only for some selected data
range?
Can I dump (read only op) the whole eeprom memory using sequential calls
to eeprom_93cx6_read?
>
> >
> > THAT IS EXACTLY WHAT I WANT TO DO! :D
> > But for doing so I need my interfaces to go back operational, so I can
> > reproduce all steps of last time, and catch the damned bug!
> > Like that I cant see sh*t! if sh*t will happen again will mix with sh*t
> > and I will keep seeing only sh*t! :))
> >
> >
> > Nice to know that something is working.. ;)
> > So, are you going to give me some help or not?
> > And I repeat, its not for me only, its for the whole community, for
> > whoever will fall in that issue too!
> > Thanks :)
>
> If you want to send me one of your devices, I'll check it out. Otherwise,
> there
> is little I can do. It would be impossible to duplicate the path you have
> followed.
So nice from you Larry! :) but for now I just need some remote support,
as I want to see if I can fix that here. Im going to write an article
about that indeed. If you search around forums, you will see quite few
users suffered this issue, but no solution was proposed.. hence most of
users "trashed" their rtl8187 and purchased other chipsets.. very sad
indeed, dont you think? :(
Now we have the chance to find a solution for that issue once and for
all, so yes, we have to take advantage of it.. ;)
--
http://www.fastmail.fm - Faster than the air-speed velocity of an
unladen european swallow
Ok Larry, I try again :)
I have been filling your code with debug lines. Very interesting in my
opinion is the report from
drivers/net/wireless/rtl818x/rtl8187/dev.c#rtl8187_configure_filter(),
as follows:
drivers/net/wireless/rtl818x/rtl8187/dev.c#rtl8187_configure_filter
IN>changed_flags=f0:00:00:00 ,total_flags=f0:00:00:80
,multicast=00:00:00:00:00:00:00:00 ,priv->rx_conf=0a:fc:94:90
>FIF_CONTROL
>FIF_OTHER_BSS
>not FIF_ALLMULTI
drivers/net/wireless/rtl818x/rtl8187/dev.c#rtl818x_iowrite32_async
OUT>total_flags=60:00:00:00 ,priv->rx_conf=0b:fc:9c:90
.. which pops in dmesg just after running "airmon-ng start wlan0" for
the first time.
.. after, maybe some daemon, calls it again multiple times, but debug
report is always the same as follows:
IN>changed_flags=90:00:00:00 ,total_flags=f0:00:00:80
,multicast=00:00:00:00:00:00:00:00 ,priv->rx_conf=0b:fc:9c:90
>not FIF_ALLMULTI
drivers/net/wireless/rtl818x/rtl8187/dev.c#rtl818x_iowrite32_async
OUT>total_flags=60:00:00:00 ,priv->rx_conf=0b:fc:9c:90
.. seeing anything suspect??
I have the feeling that first "IN" value of priv->rx_conf could be
bugged.. as result the relative OUT value sent to eeprom is maybe
wrong.. :P
Could you please perform the same test on your working interfaces, and
report me the output?
If you get different output than mine, please send me all outputs, even
if it differs also between your working interfaces.
Here in attach the patch file as requested, its a very simple debug
patch, and you can apply to any backports/compat version you prefer,
latest included.
Just make install, plug the interface, run "airmon-ng start wlan0", and
collect the output from dmesg.
FYI, from probe, my interface type should be as follow:
- RTL8187vB (default) V1
- PCI_EEPROM_WIDTH_93C46
- customer id 0
Thanks :)
On Tue, Dec 3, 2013, at 08:05 AM, Larry Finger wrote:
> If you want me to test anything, you need to send me patches that I can
> apply.
> Having to regenerate your patches here is something I have no interest in
> doing.
--
http://www.fastmail.fm - Choose from over 50 domains or use your own