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
I put some printk() functions in driver functions to print arguments
in log and then I used these same arguments in my code for firmware in
microcontroller.
Good idea with aircrack and injecting raw packets. I will check this right now.
Nikola
On Fri, Jan 27, 2012 at 12:29 AM, Larry Finger
<[email protected]> wrote:
> 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