Re: RTL8187 bugs

[Larry Finger <Larry.Finger@lwfinger.net>]

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