Can the devs give a short/expanded overview of WCN3660 and how it communicates with the driver?

[Farm Dve]

Well, the Prima driver does seem to have some bits and pieces
pertaining to monitor mode. Anyway, I did some (ugly)hacking of the
prima driver, specifically adding mon0 interface and then intercepting
frame reception from WDTS_RxPacket with a custom hdd_rx_packet_cbk
called hdd_mon_rx_packet_cbk, and I did receive some data via tcpdump,
upon loading the captured packets in Wireshark, it told me that the
packets were Unkown/Ethernet II.
Hopefully the fw isn't really stripping the frames from 802.11 to 802.3.

Unfortunately, there seems to be an issue where WDTS_RxPacket stops
being called after a while for some reason, but till I figure out how
to get 802.11 frames, I won't be bothered by that.



On Tue, Feb 17, 2015 at 9:59 AM, Eugene Krasnikov <k.eugene.e at gmail.com> wrote:
> I am not aware of monitor mode been supported by wcn36xx/prima drivers.
>
> 2015-02-13 3:18 GMT+00:00 Farm Dve <farmdve at data.bg>:
>> After poking around the Prima driver and doing some debug prints, I
>> discovered something interesting, I think. WLANTL_RxFrames which is
>> called as a callback from WDTS_RxPacket seem to be receiving packets
>> of type eWLAN_PAL_PKT_TYPE_RX_RAW(number 3) when not associated with
>> any access point. And while I have not verified it, I believe these
>> are full unstripped 802.11 frames that could be used, the only problem
>> is they seem to get filtered out somewhere, and I get 0 packets in
>> tcpdump.
>>
>> Here is my previous message that I failed to include in the list:
>>>>Thank you for the reply Mr. Bjorn.
>>
>>>>I've looked around in the original Prima driver, and as far as I saw,
>>>>it doesn't have the necessary code to set the chip in monitoring
>>>>mode(this happens with iwconfig wlan0 mode monitor which in turn does
>>>>an ioctl call with the SIOCSIWMODE. And even if it did, the fw needs
>>>>to not give us fake ethernet packets, but all the frame data we need.
>>>>So to sum it up, we need to instruct the fw that we want to not
>>>>connect to any specific AP, make the fw send us everything without
>>>>stripping the frames.
>>
>>>>Kind regards.
>>
>> On Thu, Feb 12, 2015 at 6:48 PM, Bjorn Andersson <bjorn at kryo.se> wrote:
>>> On Wed, Feb 11, 2015 at 4:52 PM, Farm Dve <farmdve at data.bg> wrote:
>>>> I asked Mr. Bjorn and he was very helpful, but I am looking at the
>>>> sources, all of them and I cannot wrap my head around it. I would like
>>>> to just throw this quickly, that I am not experienced with the linux
>>>> kernel. Lots of stuff are still hard to grasp, such as how wcn36xx
>>>> communicates with userspace APIs for networking(such as
>>>> socket,recv,buf).
>>>>
>>>> We have the wcn36xx driver, we also have drivers/staging/prima/CORE,
>>>> how exactly are they related?
>>>> If wcn36xx is the driver, what is the purpose of prima/CORE? I looked
>>>> at prima and there are a bunch of folders with..awful and
>>>> non-descriptive names, although the files are documented it leaves a
>>>> lot to be desired. Such as HDD,VOSS,DXE and so forth.
>>>
>>> The prima driver is the original Qualcomm/Atheros driver, the wcn36xx
>>> driver is a reimplementation of that driver using the frameworks
>>> provided by the Linux kernel. You can see the benefit of this by
>>> comparing the amount of code in the two implementations. (although
>>> wcn36xx isn't feature complete yet).
>>>
>>>> What about wcnss in net/wireless/wcnss, is it obsolete thanks to wcn36xx?
>>>>
>>>
>>> The wcn36xx driver is the driver for the WiFi part of the combo ship -
>>> also including BlueTooth and FM-receiver. The wcnss driver seems to be
>>> the driver for the combo chip itself.
>>>
>>> For my mainline testing I reworked the wcnss driver into something
>>> "understandable" more to the point. You can find this hack here:
>>>
>>> https://github.com/andersson/kernel/commit/f3b1e9ed5a803aafb4e4f76dc007fa33e38314a9
>>>
>>> [..]
>>>> I have not figured out if the actual firmware loaded by PIL has some
>>>> sort of strict verfication preventing altering of the firmware.
>>>
>>> Correct, but as far as I understand the firmware you have can work in
>>> monitoring mode with the official driver. So you should not need to
>>> change the firmware.
>>>
>>>> Basically too much info is still hidden, so much for Atheros/Qualcomm
>>>> participating in a joint open-source project.
>>>>
>>>
>>> Please look around the mainline kernel, Qualcomm is doing a lot of
>>> work in the Linux kernel. That work will lead to us having the
>>> dependencies in place for actually working on this driver in mainline.
>>>
>>> Regards,
>>> Bjorn
>>
>> _______________________________________________
>> wcn36xx mailing list
>> wcn36xx at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/wcn36xx
>
>
>
> --
> Best regards,
> Eugene