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

[Jean-Baptiste Note]

Hi Jan,

> well, here is the patch to make your driver "work out of the box" with
> latext madwifi stack ;). I picked madwifi's BSD branch, AFAIK most
> advanced with respect to ad-hoc mode.

Thanks thanks thanks !

> As I'm not into all the 802.11 details and the stack structure, parts of
> the patch may cause regressions and further changes might be required
> too. However, I'm able to run ad-hoc mode and even to exchange some data
> now. Master mode is still broken (no association).

> Then I started some performance tests (bing). After switching off all
> slowing down debug messages, I managed to transmit data at about 1MBit -
> not much. 

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.

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.

> Unfortunately, both the atheros driver and prism-usb do not
> provide some bitrate information via iwconfig in ad-hoc mode (both
> report 0) to see if the problem is here. Then I noticed that the kernel
> console of the prism box gets flushed with such errors under high load:
>
> scheduling while atomic: swapper/0x00000300/0
>  [<c02640f8>] schedule+0x478/0x530
>  [<d0854ee0>] uhci_urb_enqueue+0x160/0x240 [uhci_hcd]
>  [<d0854f9c>] uhci_urb_enqueue+0x21c/0x240 [uhci_hcd]
>  [<d0854dab>] uhci_urb_enqueue+0x2b/0x240 [uhci_hcd]
>  [<c0264223>] wait_for_completion+0x73/0xb0
>  [<c010def0>] default_wake_function+0x0/0x20
>  [<c010def0>] default_wake_function+0x0/0x20
>  [<c01182ec>] __mod_timer+0x6c/0x80
>  [<d081e709>] usb_start_wait_urb+0x89/0x120 [usbcore]
>  [<d081e456>] usb_submit_urb+0x206/0x2b0 [usbcore]
>  [<c0130d8f>] __kmalloc+0x5f/0x80
>  [<d081e670>] timeout_kill+0x0/0x10 [usbcore]
>  [<d081e8da>] usb_bulk_msg+0x3a/0x90 [usbcore]
>  [<d086198b>] p54u_bulk_msg+0x4b/0x80 [islsm_usb]
>  [<d0862cac>] tx_submit_ver1+0xbc/0x130 [islsm_usb]
>  [<d083da8a>] islsm_make_tx_datapkt_skb+0x11a/0x170 [islsm]
>  [<d083e13e>] islsm_data_tx+0xfe/0x150 [islsm]
>  [<d083c153>] islsm_transmit+0xb3/0xf0 [islsm]
>  [<c02196ae>] qdisc_restart+0x4e/0x150
>  [<c020d0c5>] dev_queue_xmit+0x1d5/0x200
>  [<c0212101>] neigh_resolve_output+0xd1/0x170
>
> 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.

Thanks for this awesome work !

JB

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