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 -- 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
