Message-Id: <1385835820.6559.53858669.5FD3F3A6@webmail.messagingengine.com> (sfid-20131130_192343_930708_5A7625BF)
From: "Nikita N." <nikitan@operamail.com>
To: Larry Finger <Larry.Finger@lwfinger.net>,
	linux-wireless@vger.kernel.org
MIME-Version: 1.0
Content-Type: text/plain
In-Reply-To: <529A1B52.6040605@lwfinger.net>
References: <1385589961.19021.52907237.3EE33E5B@webmail.messagingengine.com>
 <52966D64.2030805@lwfinger.net>
 <1385593188.3627.52911717.4E0712D9@webmail.messagingengine.com>
 <52968893.6060405@lwfinger.net>
 <1385812990.14905.53777877.7646278B@webmail.messagingengine.com>
 <529A1B52.6040605@lwfinger.net>
Subject: Re: RTL8187 bugs
Date: Sat, 30 Nov 2013 10:23:40 -0800
Sender: linux-wireless-owner@vger.kernel.org

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