Task List

Snoop log gathering

Simple snoop log gathering

If you have a second generation prism54 device, i'd very much like USBLogs from your device. (I have enough of logs for the first generation devices). You don't need to do anything special for this. Simply plug your device, snoop it while it emits a few pings, then send the logs.

Complex snoop log gathering

Here are the logs that i'd like to be able to understand a bit more the device protocol and capabilities. In order to report a very useful log, ideally you'd snoop the data with ethereal on a third 802.11 device along with the USB snoop. I'll call such a bundle simply a log from now on.

Rate control logs

[note : ethereal data is not really needed there, but be sure to tag the snoops with their data rate]

Gather several logs, making sure the USB device limits its rate to some fixed limit (and maybe make sure this is true with measuring a ftp transfert) (ideally, 54MBps, 11MBps, 1MBps, if you can add all the basic rates, then others). You can limit the rate :

Other means ?

( note to self, i'll try and tackle this tonight. the prism54 driver allows rate to be set, i'll verify in the beacon that it's okay, then try to associate to it with ndiswrapper, and see what happens. supported rates :

debian:/home/jb# iwpriv eth2 g_supprates
eth2      g_supprates:hex
data=02:04:0B:16:0C:12:18:24:30:48:60:6C:00:62:6C:6F:62:00:00:00:00:

Divide by two the rate values to get the X admissible values in

iwconfig eth2 set rate XMbps

I'll sniff with my other PCI prism54 card. Should also try with the atheros card. )

TX hardware queues logs

[ethereal data not really required]

Rather simple : do a full-speed transfert. I'd like to know if there's a hardware queuing mechanism, and i guess it'll kick on only under heavy traffic : do this ! -- under windows would certainly be better.

(I'll try and do this, but i fear my machine is not powerfull enough to be able to send data @54Mbps and log what happens at the same time...)

Complex 802.11 setup logs

[ethereal data preferred, but difficult. I have the hardware to carry out these kinds of experiment, so if you can do others more easily, don't bother with these]

Try complex setups in Ad-Hoc mode. I don't really understant IBSS mode, but i'd like to see three devices communicate, each in its own IBSS (is this at all possible ?), at the same time. What i mean here is :

This paves the way for SoftAP mode, and is of great value, but i'd like to solve the basic problems above first...

Task of things to understand in the protocol

Unknown fields in received packet

One field in the USB packet reported by the interface seems important, and has still to be understood. This is the 16 bits starting at offset 0x10.

Task
try to make sense of it
Howto
load the following log in ethereal. The incriminated field is present in the "" field of "prism2 header" of the frame (I distorted the use of this field, it really has nothing to do with ). The frame itself is presented in the standard manner. If ethereal reports malformed frame, it means it ! the frame is corrupted !
Already assimilated
(post here updates) this field seems to be related to the frame type + whether it's in the RX/TX filter + whether it's on the right channel (you can receive data from channel 11 on channel 9 because of overlapping, BTW i'd have to look at the prism54 driver, because i think they have to deal with this too).

Unknown fields in send packet

Many, many unknowns, possibly solved by the above logs.

Unknown fields in rx/tx filter (mode) packet

Driver task list