Message-Id: <1385812990.14905.53777877.7646278B@webmail.messagingengine.com> (sfid-20131130_130314_673092_19016AAB)
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: <52968893.6060405@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>
Subject: Re: RTL8187 bugs
Date: Sat, 30 Nov 2013 04:03:10 -0800
Sender: linux-wireless-owner@vger.kernel.org

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