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