[Prism54-devel] FreeBSD advances

[Feyd]

On Mon, 24 Jan 2005 15:20:26 +0100
Jean-Baptiste Note <jean-baptiste.note at wanadoo.fr> wrote:

> 
> I also have set up an iwpriv command + emacs (available in
> prism54-project) file to do active experimentation. What i miss is a
> good frame dumping program on linux (anyone knows of a good, simple one
> ?) that would show me all 802.11 frames (including management) on a
> given channel, to see if, and what, i emit. Isn't ethereal only dumping
> 802.3 frames ?

It can display 802.11 very well (the card has to be in monitor mode).

> 
> Secondly, i assumed the frame you show in the email below were complete
> 802.11 frames, but never checked. I will decode them according to the
> standard, but you seem to indicate that they are only "template" frames,
> with some parameters left for the device to fill in ?

Yes, there is one probe request template sent on essid change, then there
are the freq change packets (may be they also trigger the template to be
sent, but I remember seeing one more probe request just after association,
so maybe the sending is triggered by a timer and has to be explicitly
canceled).

> 
> Third, i don't understand the descrepency between your first two "probe
> request" frames, at offset :
> 
> 00000040: 00 00 00 00 00 00 00 00 04 00 00 00 40 00 00 00 ............ at ...
> 
> 00000040: 00 00 00 00 00 00 00 00 04 80 9C 8E 40 00 00 00 ............ at ...
> 
> This problem shows in every log that i have : some stange numbers are
> sometimes set [@0x49- at 0x4b], sometimes they're zeroed. They are in fact
> the three lower bytes of the AP usually (has this some sense in the
> 802.11 terminology ? a bss number ?).
> 
> It sucks, because i can't seem to understance when they are needed and
> when they're not... In short, what they really mean ! Any idea ? (i'll
> see if the 802.11 layer has information available for this ; for
> instance it could only be set when we target a specific bss).

Some of them could be caused by the driver reusing the buffers and leaving
garbage in the fields it doesn't have to touch, the frames themselvs begin
at 0x4c, not at 0x4a as I mistakenly thought before, and not all the attached
frames were probe requests (that begin with 40 00 00 00), two were beacons
(begin with 80 00 00 00 (I tried ad-hoc mode), those are template based too).
I will put the logs at http://sweb.cz/feyd/partialy_analyzed.

Feyd