[Prism54-devel] Prism-USB in ad-hoc and master mode

[Jean-Baptiste Note]

Hello Jan,

I'm sorry i didn't make myself clear on the rate transmission problem.

> Mmh, to understand to concept behind: Does the 802.11 stack at some
> point decide to switch a link to a different speed (like you switch a
> RS232 line), or is this performed individually for every transmitted
> packet. 

This is device dependent. The problem is that i don't even know how it
works for the prism devices ! So we need to figure this out first.

> May we even have asymmetrical links (with respect to bitrate)
> between two stations? Do you already have a clue which interfaces of the
> madwifi stack and the prism driver are involved? Just to help me getting
> into this...

Madwifi stack is not involved for now, the most difficult part is
figuring out how to set the transmission rate

> Yea, I remember that different rate control modules of the madwifi
> driver. They are not part of the stack, so it's up to the driver to
> decide which speed to use?

The problem is not really to understand how madwifi works in this
respect; this is relatively easy, i outline it as thus :

The madwifi stack decides among available rates (intersection between
the rates authorized by the AP and the rates available to it) which rate
to set. According to an algorithm which measures the data rx/tx
failures, it chooses adaptatively the "optimal rate". Those algorithms
you can change are of no concern to us.

The madwifi stack then asks the device dependent part of the driver to
set the rate. Again, this is not the main problem here. 

Depending on the device way of setting the rate, the device-dependent
part will then set the tx rate of its packets to the asked value,
whether it be globally (ie one rate change for all the packets to be
transmitted), or individually (ie, one rate is specified for each
outgoing packets, which i think is the case for softmac prism).

THIS is our problem. Because i don't know how to do this. For now i'm
transmitting packets whithout knowing at which rate they are transmitted
(same goes for rx path). Once this is known, gluing this knowledge to
the madwifi code or any other stack will be a breeze.


> Again, to help me starting over, I would like to have some rough
> information about what is happening in the transmission path to convert
> a skb into some payload urb, maybe surrounded by further managment urbs.

Well, it fits well with the above problem. This is what happens in
islsm_output file. The  islsm_data_tx function take a 802.11 frame and
builds the hardware-specific header. The full frame tx'd is printk'd by
the driver. They are easy to recognize in the usb logs; you have some
samples of them in http://jbnote.free.fr/prism54usb/DataSent.html

Let's take the topmost one for instance. the 802.11 data to be
transmitted starts at 0x4b. all data above has an unknown meaning (read
the page for further details ; actually 0x00-0x1a is well-known, as is
byte 0x37 and byte 0x47). I guess, but may be wrong, that is contains
the TX rate of the packet from 0x1c to 0x23. IF the rate control is
per-packet, of which i'm not sure. Rate may alternatively be set in the
packets from http://jbnote.free.fr/prism54usb/FilterPacket.html.

We need to figure out how to tell the hardware to change its transmit
rate. This is why i proposed to gather coherent data : we will be able
to sort things out if we manage to get the windows driver to transmit
data at a fixed, known rate, and snoop the data. 

Then change the rate, and snoop the data again. Repeat. Compare, and
voila, all other things being equal, you know from what has changed in
the data you snooped *where* the rate control information sits.

Given that you can't trust the rate controls you find in windows or in
ndiswrapper (badly if at all implemented), the only way to reliably set
the rate is to get the device to associate to an Access Point which has
in its beacon frame the information "You can only talk with me at such,
such, such and such rate", with only one "such", whose value you
control.

I hope this is clearer and justifies the direction into which i'm trying
to send you ;) (this is tedious work, but very usefull).

> Can I just pick a different pipe for transmitting the data, or do the
> encoding of the urb(s) change when avoiding the management pipe? 

it doesn't change a bit. Well, actually, as you can see, the submit_urb
call is there because the frame is split (the encoding is somewhat
changed at this point).  This "special case" (the else part of the
conditional) which i decided would be caught by testing the size of the
packet is actually only needed at bootup for the packets transmitted by
the

int islsm_mgmt_readback(struct net_device *netdev)

function. It is *very* unlikely, and shouldn't be used for any other
packets.

It seems that testing only on the packet size was a really bad
idea (i knew it ! =] ).

So what would be needed is : 

1/ pass to the tx_submit_* function family an additional argument
specifying which pipe the packet should go through; or maybe have two
transmit functions, one for the mgmt, one for the data pipe. I don't
know. The decision on which pipe to use cannot be done so late in the tx
process, the upper layers have to make the decision.

2/ only split the frame aimed at the mgmt pipe if it's too long. Maybe
this is even only needed in the early bootup stage of the device setup,
i shouldn't know, as i don't have a datasheet around, and the logs show
no sign of such jumbo frames going through the mgmt pipe after bootup.
I think this decision can and should be done at this tx level. Please
note that if this filtering is done correctly, then calling submit_urb
is not problem as the mgmt readback is done in process context where you
can sleep.

I'm thinking about a proper answer to 1/. I need time or advice on this
one. When i'll be a seasoned programmer this may change :)

To sum up : this bug appears because the code path we're looking at
should only be reached for very special frames at device bootup, but due
to my being dumb it is also reached for normal data frames after boot...

> Which of your packet diagrams refer to these cases?

The part of code you're looking at is called for _all_ transmitted
packets; the links i sent were for particular packets.

You may want to have a look at some usbsnoop logs; maybe i should do a
commented example (should've done it when reverse-engeneering, now i
don't really feel like it :( ). In the islsm_output.c file, you'll find
code for generating all packets that i know of; for the rate control
proper, you need to understand only the two i sent links to (i think).

Double-cheers for reading up to this point,

JB

-- 
Jean-Baptiste Note
+33 (0)6 83 03 42 38
jean-baptiste.note at wanadoo.fr