On 01/26/2012 04:44 PM, Nikola Gacic wrote:
I don't know which device is RTL8187L but this device definitely isn't RTL8187B because it doesn't use RTL8187B routines and field rtl8187_priv.is_rtl8187b is FALSE.
If you only have the 3 endpoints, then it is an RTL8187L.
I am using MANAGED BSS STATION interface for device, but I also tried MONITOR interface to try to capture beacons from AP on any channel. It was the same, I can't read anything from 0x81 endpoint because I am always getting NAK packets. If I am not mistaken endpoint 2 is used for sending and 0x81 for receiving, but enumeration shows there is endpoint 3 also. Do you remember what is it used for?
No, we do not use it, and you are correct in that the endpoint with the address 0x81 is used for input, and the one for address 0x02 for output.
I again inspected rtl8187_start() routine and I am now inspecting rtl8187_probe() again but it is much bigger and I will need more time. Is the rtl8187_probe() crucial for initializing device or just for getting device information and allocating resources? I mean, will some false bits when writing to endpoint 0 cause the device to stop responding in this routine?
The devices are very sensitive to the initialization. A mistake there could completely lock the device. I have never tried to use raw in/out on any of these devices. If I were to do what you are trying, I would use the ioctl's that are used by aircrack to inject packets. Those should setup the receiver correctly. In particular, the RX descriptor would be critical.
Have you been using usbmon to look at the traffic between the CPU and the device? 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
