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

[Jan Kiszka]

Jean-Baptiste Note wrote:
> ...
> Indeed. You can help me there =] Actually i didn't do any protocol
> reverse-engeneering on the data rate control. I know the information is
> embedded somewhere, for now i think that we are indeed transmitting the
> data @ around 1Mbps.  
> 
> What we can do to improve the situation is simple : either figure out by
> ourselves with the data we have how the rate is controlled, or gather
> structured more structured data.
> 
> The way to do this :
> 1/ run the windows driver for the usb stick.
> 
> 2/ associate with an AP on which you can control basic rates. Set the
> basic rate to a fixed set, (if possible, ideally this would be only one
> basic rate allowed), and associate to it (certainly this won't be
> possible for all rates), and TX some data (a ping or two will be okay).
> 
> Change the set of basic rates, repeat.
> 

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

> There's a patch by Denis on bugzilla to allow fine control of the beacon
> frame of prism54 fullmac cards in AP mode. This could do the trick for
> the AP part.
> 
> Then you'll ask me, where can we look ? Well, have a look at :
> 
> http://jbnote.free.fr/prism54usb/DataSent.html, section "some unknown
> fields".
> I think rate control is by-packet and embedded most probably in offsets
> 0x1c onwards. No guarantee though. It could also be in those packets :
> 
> http://jbnote.free.fr/prism54usb/FilterPacket.html
> at offset 0x30
> 
> When transcribing this knowledge in the driver, there will be
> interactions with the madwifi stack rate-control too.
> 

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?

>>...
>>Obviously, you are transmitting bulk urbs synchronously (usb_bulk_msg)
>>in the atomic context of hard_start_xmit (islsm_transmit). I tried to
>>check what would be required to convert this call to an asynchronous
>>one, but I do not yet understand what happens around p54u_bulk_msg, what
>>needs to be delayed (the succeeding urb submissions?) and what has to be
>>cleaned up after the bulk urb completion (the skb?).
> 
> 
> Am I ? Erk, the part that does this is plain ugly and was meant as a
> gross hack. 
> 
> This code path should only be used for mgmt readback at initialization
> time. Once the device is booted, data tx can happen on the data pipe
> with larger packets without them being split. If you have an idea on how
> to correct this properly, i need to think a bit about it and try to do
> it in a non-kludgy way.
> 

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.
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? Which
of your packet diagrams refer to these cases?

Jan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4760 bytes
Desc: S/MIME Cryptographic Signature
Url : http://prism54.org/pipermail/prism54-devel/attachments/20050514/4bc37f17/smime.bin