[Prism54-devel] Re: Active testing rules

[Jean-Baptiste Note]

Hello Feyd,

I've done much progress lately regarding the protocol decoding. I'm
proud to say I now can reliably send probe requests (active scanning
mode), and beacons (in STA mode). I've not tested data packets yet, but
this is a matter of available time, I know they'll be okay. I've done so
much progress I think a basic working driver is in sight once i've
turned this into code.

> A data frame could be easier I think, as it is "one shot". Or maybe it
> was the channel/rate mismatch?

It certainly is simpler, but not yet done. The non-one-shot packets are
OK, though :)

Just to show off, i give you the meaning of what you observed.

> 01 -> (no ack in 0.5s, retransmit the frame at 6c 06 02 00 ?)
> 00000000: 00 02 02 00 10 00 00 00 00 00 00 00 00 00 00 00 ................
> 00000010: 01 80 04 00 00 00 00 00 07 00 00 00 6C 06 02 00 ............l...

This asks for the packet in queue 6C 06 02 00 to be freed (as you said,
certainly because of the lack of an ack after some amount of time),
regardless of whether it has been ack'd or not.

> 81 <- (ack received)
> 00000000: 14 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> 00000010: 01 80 08 00 00 48 4A CF 08 00 07 07 01 00 00 00 .....HJ.........
> 00000020: 00 00 00 00                                     ....

This is the status of the packet returning due to the above "free the
slot" request. It has not been ack'ed : acked packets have a 00 01 field
@1C,1D, and the strength of the ack packet is written in 16 bit le
@1E,1F.

You can find a very rough writeup of what i found at :
                                                                                
http://jbnote.free.fr/prism54usb/DataSent.html

I'll try to add a "typical usage scenario" (what you'll be able to
observe in most logs) in order to make clear what i mean.

I now lack time to do the testing, which will be long and cumbersome, in
order to understand what each and every field precisely means. But i
think i've bridged the gap, it's now "only" a matter of work...

JB

PS: for now, experimenting with my simple ioctl seems to be enough for
me. Have any of you tried it ? It certainly is not as complete as your
userspace solution, but it helps... you can make the packets in an emacs
buffer and send them from there : this is really ad-hoc for this driver,
and unelegant, but it helps.

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