[Prism54-devel] XH8196 driver tests ?

[Sebastien B]

Hello,

> Sebastien B <sebastien.b at swissinfo.org> said :
> > Hello,
> > Has anyone tested the XH8196 driver with a new (ISL3887-based) USB device

> There's still a problem, Sebastien, in this code : though it should,
> theoretically, work, i can't get the lmac to parse correctly the
> firmware sent ! I don't know why, because in userland, this works
> OK...

I copied the exact code from your driver into an usermode program (I just 
changed trivial things such as replacement of kmalloc() by malloc()), and it 
coredumps in prism_softmac_parse_bra() when attempting to parse the bra at 
offset 1. I think this function is unreliable when fed with bogus data so 
your loop to guess the position of the bra is a bad idea ; you should parse 
directly at offset 20 ; anyway I don't think we can be able for now to use a 
different firmware image than the one provided in the driver (I tried several 
ones and I was never able to make prism_softmac_parse_bra() return SM_ENONE).

> I've given up on this and now concentrate on understanding the 
> protocol

This driver may help us to figure out how to send packets... We have a far 
better control over what is sent than using the Windows driver. For now, we 
are trying to understand packets about which we don't even know what they 
contain, we can only make suppositions. And there is no way to send raw 
802.11 data using the Windows driver ; according to the MSDN, wireless 
drivers receive 802.3 data from the upper layers and then translate it to 
802.11.
With the UMAC library, we could just ask it to send a well-known 802.11 packet 
and see how it behaves... Unfortunately, this is for SoftMAC2, I hope it is 
not too far from SoftMAC1...
I wish I had an ISL3887 based device, I could write a libusb-based usermode 
quickhack (I'm damn sick of kernel panics) which would boot the Prism chipset 
and so, and then send predefined 802.11 frames using the UMAC...

> Cool, so you understood the packet meaning :) I'm wondering if the LED
> blinking would not be a side effect of something else, though : blinking
> for the "red led" (on the iogear stick) is present in the driver for my
> WUSB54G device, though it has no red led, and produces not apparent
> effect.

I've looked at the contents of several Windows drivers, they look very similar 
and generic. In my opinion, wireless devices manufacturers buy circuits 
schematics and the driver from Conexant, add their brand name on it and 
resell with minor modifications (USB IDs, LEDs, ...). So the driver may send 
packets to control the red LED, even if no one is installed in the device.

> Feyd, Sebastien, I've heard your problems with my doc (which was at the
> beginning only quick notes put there for my own use). I'll try to put
> this in shape in a more logical and understandable way.

Ok, thanks :)
Sebastien