AR9170 documentation for a driver port?

AR9170 documentation for a driver port?

[Stephen P]

Hi all,

I'm interested in writing a USB driver for the AR9170 chipset in Java
(for Android's USB host mode API).

I've looked through carl9170 briefly, but is there anywhere I can find
an explanation of the USB protocol and documentation about the chipset?

Essentially I just want to put the device into monitor mode, be able
to change channels, etc. Any information would be appreciated.

Thanks!

Re: AR9170 documentation for a driver port?

[Christian Lamparter]

On Wednesday, April 25, 2012 09:29:52 PM Stephen P wrote:
> I've looked through carl9170 briefly, but is there anywhere I can find
> an explanation of the USB protocol and documentation about the chipset?
In the headers:
eeprom.h - eeprom layout (i.e.: calibration, gain, ...)
fwcmd.h  - firmware commands (read/write register, set channel, set key, ...)
fwdesc.h - definitions about the firmware descriptor
		 (at first, that's probably not very important)
hw.h     - hardware register file (mostly the MAC registers)
phy.h	- hardware register file (PHY registers)
wlan.h	- definition of the tx and rx headers (and tails)

other than that, there's still the original ar9170 (less complex,
but different firmware) and of course the original vendor driver:
otus. 

So much for carl9170. If you want documents about the chip then
you have to ask a Qualcomm rep.

> Essentially I just want to put the device into monitor mode, be able
> to change channels, etc. Any information would be appreciated.
Actually, you could just capture what the driver does to setup the device
[the userspace usbmon tools can help there] and simply replay the commands.
But if you want, you can of course port the code from phy.c, mac.c into
java and start from there. Good luck!

Regards,
	Chr

CARL9170 driver/firmware questions

[David Lynch Jr.]

I am working on another AR9170 project. 
This essentially requires injecting broadcast packets of specific size,
frequency, ... at extremely precise intervals.

I am trying to understand the data flow in the firmware. 

Initially I was looking to generate the frames in the firmware. 
The payload is simple. Though I am pondering the wisdom of that right
now. Regardless, I will have to control my frames in firmware, so I need
to separate them from normal traffic and then feed them into the Radio
Queues at the appropriate times. 

Am I correct that the same struct dma_desc is being used by both USB and
the Radio ?

Each dma_desc points to a payload, for tx packets this is a  struct
carl9170_tx_superframe, which must also be what the skb pointed to by 
void carl9170_usb_tx(struct ar9170 *ar, struct sk_buff *skb) is
sending ?

Can I construct a carl9170_tx_superframe on the host side, with
something to allow me to identify it in handle_download in the firmware,
perform minor mangling of the contents, and repeatedly transmit it at
fixed intervals using wlan_tx() ?


 

 

Re: CARL9170 driver/firmware questions

[Christian Lamparter]

On Sunday 17 June 2012 04:53:47 David Lynch Jr. wrote:
> I am working on another AR9170 project. 
> This essentially requires injecting broadcast packets
> of specific size, frequency, ... at extremely precise
> intervals.
Sounds pretty much like TDOA (and Gary). But anyway, if
you are just looking for a noise "pattern generator", you
might as well look into the "radar" branch of the carl9170
firmware.

> I am trying to understand the data flow in the firmware. 
> 
> Initially I was looking to generate the frames in the firmware.
Well, there's "wlan_tx_fw" in wlan.c. Which can be used by the
firmware code to send out frames (Note: it's currently used to
sent BA when the device received a BAR from a HT peer)

> Am I correct that the same struct dma_desc is being used by
> both USB and the Radio?
Yes, it's a common data structure for lockless, vectored IO.

> Each dma_desc points to a payload, for tx packets this is a struct
> carl9170_tx_superframe, which must also be what the skb pointed to by 
> void carl9170_usb_tx(struct ar9170 *ar, struct sk_buff *skb) is
> sending ?
Yes. Altough, the (wlan) hardware will only cares about the 
ar9170_tx_frame struct which is embedded in the superframe.
So, the carl9170_tx_superdesc is "hidden" by wlan_tx before
the frame is sent down to the MAC's tx queue.
And likewise: unhide_super when the frame is given back to
the USB download queue.

> Can I construct a carl9170_tx_superframe on the host side, with
> something to allow me to identify it in handle_download in the firmware,
> perform minor mangling of the contents, and repeatedly transmit it at
> fixed intervals using wlan_tx() ?
Sure, the carl9170_tx_superdesc still has a unused u8 ["padding2"].
So, you can define your own set of flags and values right there. 
(Of course, you could also hijack rix and cnt - Note: this will work
if you only need to detect that the frames it needs to be handled
differently in handle_download since wlan_tx does override these
early on).

But if you need to repeatedly transmit frames, then the beaconing
mechanism might be worth a look. In theory it should be jitter
free since it is completely handled by the hardware.

Regards,
	Chr

Re: CARL9170 driver/firmware questions

[David Lynch Jr.]

I am moving this back to the list so everyone can benefit. 

I set both the sending and receiving AR9170 to monitor mode using 
airmon-ng start wlan3

I set the sending device to channel 40 5200Mhz
iw wlan3 set channel 40


I run 
airomon-ng --channel 40 mon0
on the receiver. 
and I am able to send and receive a packet using a RadioTap raw sockets
test program I found on the web

I separately instrumented carl9170.ko so that I could observe bot the
calls and the register IO's to initialize the AR9170 and set the
frequency. 

After that worked, I sent a custom command to the AR9170 Firmware that
called a routine similar to  void wlan_wol_connection_monitor(void)
 and void wlan_send_buffered_ba(void), in this routing I set the
ieee80211_hdr addresses 1-3 to all 0xff's as my experience with ethernet
sugested that should always work if you do not need a reply back.
i also implimented a callback function for wlan_tx_fw() in the hope that
it would report any errors.

Anyway I got no errors, but did not receive a packet. 
So i added debugging code to dump the various things in wlan_tx(), 
so that I could trap both the packets that were being sent and those
that were not to see what was different. 

When I set addr2 & addr3 to  0x00, 0x12, 0x34, 0x56, 0x78, 0x9a 
wlan_tx_fw() started actually transmitting packets. 
  
My observations regarding carlu where just in passing. 
I am not using carlu, though I might have had I started with it.
Being able to bypass the entire linux network stack and talk to the
firmware directly, would be very useful for the projects i seem to get.
I have essentially implemented a variation on carlu, using debugfs
inside the carl9170 driver.  







On Sun, 2012-07-08 at 14:43 +0200, Christian Lamparter wrote:
> On Sunday 08 July 2012 10:08:13 David Lynch Jr. wrote:
> > I worked out the wlan_tx_fw() problem. 
> > It had to do with mac address values. 
> > Either the code or the radio was silently
> > rejecting packets with all addresses as 0xff.
> 
> AFAICT, the fw doesn't care much about any MAC
> addresses. Do you sent your generated frame 
> with a device that is in pure monitor mode as
> well?
> 
> > As an aside I have also tried some stuff with carlu. 
> > And i do not seem to be getting any packets from 
> > carlu -t either
> carlu -t does a loopback test to test if the usb code
> in the firmware is doing its job. Sadly, there is not
> any support for MAC or PHY code, but the program is
> written in C and the kernel driver is also C and the
> license is the same.
> 
> Regards,
> 	Chr