[Prism54-devel] XH8196 driver analysis

[Sebastien B]

Hello,

> Anyway, my aim is now to understand the closed-source hal in there,
> either by making this partially closed-source driver work and looking at
> the data it generates

I've just sucessfully linked the Softmac library against an usermode program, 
and it seems to work : there will be no need to go through kernel 
development...
I've simply implemented dummy functions that match the prototypes defined in 
softmac2.h, and ran the following code :
static uint32_t context;
static struct s_sm_setup setup;
static struct s_sm_initdata data;

int main(int argc, char *argv[])
{
  int32_t i;
  i = prism_softmac_create(&context, &setup, NULL, &data);
  printf("prism_softmac_create returned %i\n", i);
  prism_softmac_destroy(&context);
  return 0;
}
It has produced the following output (I display everything passed to 
prism_driver_printf() and log memory allocations by prism_driver_alloc()) :

allocating 268434528 bytes of memory
allocating 8196 bytes of memory
allocating 40 bytes of memory
allocating 1060 bytes of memory
(c)opyright 2004 Conexant
prism_softmac_create returned 8

Why does the softmac library allocated that enormous amount of memory when 
prism_softmac_create() is called ? It seems that such a large buffer is 
actually needed, when I return NULL in response to that request 
prism_softmac_create() fails, and if I return a smaller buffer the program 
segfaults right after the allocation. Perhaps we just need to initialize 
something in the structures passed to prism_softmac_create() ... I haven't 
searched much about that for now.
Anyway, that would allow us to know what the driver would send to the device 
to fulfill a particular request without constantly rebooting, replugging the 
device and filtering sniffed data.
But how different is the second-generation SoftMAC API used by that library ? 
But maybe we will be able to work first-generation devices with the 
second-generation firmware...

> (we'll have more control than on the ndis driver), 
> or by disassembling it (but it's 300k). Do you know a good decompiler
> for linux ? or do i need to go through the assembly code (it's rather
> long...) ?

You may try REC (http://www.backerstreet.com/rec/rec.htm) ; but I don't know 
what it's worth.

I haven't used netstumbler yet to capture special frames that would be sent to 
my device, I don't have any computer running Windows and my device doesn't 
work in VMware for some odd reason ; so I have to borrow a computer at 
school. Also, current netstumbler versions don't put the card in monitor 
mode.
Regards,
Sebastien