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

[Jean-Baptiste Note]

Hello Jan,

> today I gave the latest prism-usb version (patch-128) a try with my
> Linksys WUSB54G (version 1 device). Without any access point around, I
> started switching the device into ad-hoc mode. I was able to associate
> with my notebook (atheros card with madwifi or ndiswrapper) and to
> exchange some packets. But I also got a crash after a while.

I think i never ever tested ad-hoc mode, only wrote the code, so this is
good news.

>
> Tracking this crash down, I found out that it's enough to start up the
> WUSB54G in ad-hoc mode and leave it alone for a while. I got this ASSERT
> of the madwifi stack:
>
> not in ap mode, mode 0------------[ cut here ]------------
> kernel BUG at
> /usr/src/prism54/prism54-project/src/madwifi/net80211/ieee80211_node.c:1182!
> invalid operand: 0000 [#2]
> Modules linked in: islsm_usb netconsole islsm wlan 8139too mii uhci_hcd
> usbcore rtai_nucleus rtai_hal
> CPU:    0
> EIP:    0060:[<d08877f6>]    Not tainted VLI
> EFLAGS: 00010246   (2.6.11.8-adeos)
> EIP is at ieee80211_node_leave+0xa6/0xc0 [wlan]
> eax: 00000016   ebx: c130d400   ecx: d0891211   edx: c0309ec0
> esi: cf19542c   edi: c130d400   ebp: c0309f10   esp: c0309ebc
> ds: 007b   es: 007b   ss: 0068
> Process swapper (pid: 0, threadinfo=c0308000 task=c0298b20)
> Stack: d0891211 00000000 c130d400 00000006 cf19542c d088707e cf19542c
> c130d400
>        cf19542c c130d400 000000c0 00000002 cf19542c 00000100 d08803b0
> d0880414
>        cf19542c cf19542c c0118982 cf19542c c0308000 c0309f10 c0309f10
> 00000246
> Call Trace:
>  [<d088707e>] ieee80211_timeout_nodes+0xbe/0xf0 [wlan]
>  [<d08803b0>] ieee80211_watchdog+0x0/0x80 [wlan]
>  [<d0880414>] ieee80211_watchdog+0x64/0x80 [wlan]
>  [<c0118982>] run_timer_softirq+0xc2/0x1a0
>  [<c0115016>] __do_softirq+0x46/0xa0
>  [<c01150a0>] do_softirq+0x30/0x40
>  [<c010565d>] do_IRQ+0x3d/0x60
>
> It looks like ieee80211_node_leave() gets called in ad-mode while this
> function only likes to be used on AP mode...

Well, i did something wrong it seems :)

> Moreover, I noticed this message in the kernel dump quite frequently:
>
> ****** Problem in skb to be tx'd : headroom too small *******
>
> "Problem" indicates that there is something broken, some important part?

Not really. Actually the softmac device contain all that is needed to do
copyless TX (it means that in the code you write, you never ever have to
do a memcpy of the data you're being asked to transmit). I now consider
a problem to have to do such memcpy in the tx path (and in the rx path,
but as you have more control there, the problem is already taken care
of). Unfortunately, it seems the madwifi stack doesn't take into account
the netdev->hard_header_length, (or i didn't put a value large enough
there), so when asking it to encapsulate packets, i'm left with skb
without enough headroom to do add the hardware header and do the
copyless tx.

> I set up a nice test environment (kernel 2.6.11 + small rootfs initrd,
> provided via etherboot) to check the prism-usb driver against ad-hoc and
> master mode with my notebook. Let me know where I can help to make these
> use-cases work reliably. 

Well, by testing them ! -- you can also try to find the bugs by taking
the madwifi driver and trying to see what i do wrong. All the code for
madwifi interaction is in islsm_netdev.c, so you don't have many files
to look into. Please also note that at some point in time we'll go to
another wireless stack, so if you want to tackle the porting, you're
welcome :)

I'm using etherboot + netconsole + root-nfs for my test machine
too. this is really sweet indeed :)

> Especially master mode would be nice to have,

Indeed. I did _zero_ work on this as we don't have dumps of either PCI
or USB devices working in AP mode. But we're working with Viddy towards
this. Maybe we can be confident enough to try and improvise now rather
than mimicking, so you're welcome to try to do a basic AP mode with what
reverse-engeneering we currently have.

> but it seems to behave worse than ad-hoc mode ATM (no packet exchange).

I'm relieved, madwifi is not deep black magic which can do things on its
own ;)

JB

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