[Prism54-devel] Re: Active testing rules

[Feyd]

On Wed, 26 Jan 2005 17:49:56 +0100
Jean-Baptiste Note <jean-baptiste.note at wanadoo.fr> wrote:

> 
> * more fields to control rate : I'm sure the rate at which the transmit
> occurs is specified somewhere... Where ?

The logs were captured at channel 11, rate 54Mbit auto (IIRC). I would
rather think that the rate and channel are specified globaly, but if the
constants specify the rate and/or channel, the monitoring card probably
has to be set the same to see the frames.

> Also we're missing some interaction with other frames, because this is
> not sufficient to get the device to emit something. dumbly trying to
> replay the probe request, for instance, doesn't work for me :(

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

> 
> > 81 <- (caused by the update?)
> > 00000000: 14 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> > 00000010: 01 80 08 00[00 A8 07 C9|08 00 07 07]00 01 75 00 ..............u.
> > 00000020: 30 26 10 10                                     0&..
> 
> This is sent as a kind of acknowledge by the device. It holds the id
> referenced above, which for the windows driver is the adress of a
> pointer. It can be whetever value you want, it will return it as a
> reference for the transaction you engaged.
> The frame is standard, first line size, second line magic 0x01 0x80
> (response), then size of embedded data, then ID, then type (08 00 07
> 07, compare with 01 00 07 07 above), then data proper (8 bytes).

May be it could be the 802.11 ack notification:

0e -> (trigger update)
00000000: 0F 08 00 00 00 40 40 00 00 00                   .....@@...

01 -> (send deauth)
00000000: 6C 06 02 00 56 00 00 00 00 00 00 00 00 00 00 00 l...V...........
00000010: 00 40 1A 00 00 48 4A CF 01 00 07 07 00 00 00 00 . at ...HJ.........
00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000030: 00 00 00 00 00 00 00 00 02 00 00 00 00 00 00 00 ................
00000040: 00 00 02 7F 00 00 00 00 04 00 00 00 C0 00 00 00 ...............
00000050: 00 04 E2 80 9C 8E 00 0C 41 DA 29 4C 00 04 E2 80 ........A.)L....
00000060: 9C 8E 00 00 06 00 01 0F                         ........

81 <- (beacon received)
00000000: 69 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 i...............
00000010: 4D 00 55 00 94 09 00 00 56 00 00 0C 11 FC E3 00 M.U.....V.......
00000020: 00 00 00 00 80 00 00 00 FF FF FF FF FF FF 00 04 ................
00000030: E2 80 9C 8E 00 04 E2 80 9C 8E B0 1E DD F1 64 69 ..............di
00000040: 1E 00 00 00 64 00 31 04 00 0F 43 5A 46 72 65 65 ....d.1...CZFree
00000050: 2E 4E 65 74 2E 46 65 79 64 01 04 82 84 8B 96 03 .Net.Feyd.......
00000060: 01 0C 2A 01 00 32 08 0C 12 18 24 30 48 60 6C 05 ..*..2....$0H`l.
00000070: 04 00 01 00 00 61 29 01 A1 0F 90 E0             .....a).....

81 <- (beacon received)
81 <- (beacon received)
81 <- (beacon received)
81 <- (beacon received)

0e -> (trigger update)
00000000: 0F 08 00 00 00 40 40 00 00 00                   .....@@...

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...

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                                     ....

There is another type of acks, 4 bytes long and contain frequency of
(usualy) previous, not current freq change packet. I think they either
ack the freq change to be complete (most likely, it can take some time
to retune the radio), or they could notify about the template to be sent.

81 <- (frequency changed?)
00000000: 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000010: 01 80 04 00 00 00 00 00 02 00 00 00 00 00 94 09 ................

Feyd