[Prism54-devel] FreeBSD advances

[Jean-Baptiste Note]

Hi Sebastien, dear list,

> While writing this, I spotted a few bugs in the Linux driver :
> First, according to the source's comments, the selection of the alternate USB 
> settings doesn't work. I think it fails later in p54u_alloc_buffers because 
> of this line which, I think, selects alternate setting 0 regardless what 
> interface should be used :

My bad. It's not important though, the testing of alternate settings was
done to check Joerg's new device (in case it had a compliant interface,
which it had not). It appears that it was not necessary; all dongles we
have only one interface.

> struct usb_host_interface *iface_desc = &interface->altsetting[0];
> Since my device has no alternate settings, I haven't tested this.
> Then, in p54u_set_filter, memory is allocated by kmalloc() and is never freed. 
> The functions p54u_data_send and p54u_freq_change have the same bug.

OK, i'll bugfix this tonight along with an init problem in p54u_boot,
the INIT_WORK is not done in case there's no firmware, and this
segfaults later in p54_shutdown.

> JB, you said that understanding USB logs was a tedious job. If you have 
> frequency changes, and raw data sends and receivings, what can go
> wrong ? 

1/ I don't even know what data i'm receiving. There's a filter set up,
but i don't understand it. (We're not in monitor mode). So we'll have to
understand how the receive filter works. (the name there are now are
completely bogus. I assumed they were ok, but there's no
guarantee. Nobody double-checked the protocol reverse-engeneering that i
did).

2/ There seems to be many ways to send packets...

3/ when you send a packet, you specify such things as : send it once, or
send it repeatedly, at which rate, etc... If you cannot configure such
basic things, you're going nowhere.

To sum it up, there's no such thing as "raw emit/receive"... The
wireless medium is really complicated. For now getting "something" to
work, even without the intricacies, has been my aim. Yet, much remains
to be done. 

For now, not even the authentication process works... I need (hehe !) to
set up the correct receive filter, so that we can get the packets for
the authentication/association process back (which is not the case now,
assuming that we sent the authentication request right, which is not sure).

The ideal would be to know what the "monitor mode" filter packet
is. (thus we'd get a "raw receive" as you name it ; that's not the case
for now, the device sends back only broadcast frames).

I've set up an old machine for my development, which contains :

* an atheros pci card
* a SMC fullmac pci card
* 2 usb dongles.

The machine is SMP, so SMP issues can be tested. The machine is
diskless, with a watchdog, so in case of a lock up it automatically
reboots (well, sometimes it doesn't...).

Are there people interested in accessing such a machine (which means
i'll spend time securing it somewhat WRT my desktop machine) ?

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