Re David, tech-kern, tech-net,

Basically I wrote some "kismet-like" tool for NetBSD,
since I had not found any other equivalent tools.

I'm obviously putting the card into monitor mode, while
sniffing all traffic using libpcap 0.8.3 (the one provided by pkgsrc),
since the system one is not providing 802.11 datalinktype.

my main problem was badly received packets that could lead,
to misinterpretation of the 802.11 header and registering
(in the tool) a non-"really"-existing AP in my list.

so I thought of using FCS (crc32)to be sure that the packet is valid, 
etc.. etc. (you know the rest of the story :)

Anyway after some digging, and the will to build the proposed patch,
I just realized that an(4) was not providing any RADIOTAP enhanced 
header, I saw some differences between other wireless device drivers 
(wi(4), ath(4)) and the an(4), most of them seems to implement RADIOTAP 
"stuff" (which I don't know about yet), so my questions are the following :

* what is the purpose of RADIOTAP ?
   carry some extra infos about the frame,
   that are not delivered to bpf ?! other ?

* where this "header" is filled ? or how ?
   wi(4) seems to have the wi_{rx|tx}_radiotap_header
   why is there some header for outgoing packets ?

* what is the difference between RADIOTAP and monitor ?

* what is the purposes of bpfattach2() in other drivers
   (wi(4), ath(4), etc..)?
   in an(4) during _MONITOR_ each mbuf is directly copied
   to bpf using bpf_mtap().

* am I missing/misunderstanding some other things ?

This tool/work is some fun to learn basics about NetBSD internals,
and give me opportunity to make steps into the NetBSD kernel which
I don't understand yet.

I'm on the learning path and far far from being a kernel hacker.

Hope you can enlighten me,
Best Regards,
Eric.

David Young wrote:
> On Fri, Jun 03, 2005 at 09:35:10AM +0200, Eric Auge wrote:
> 
>>David Young wrote:
>>
>>>All 802.11 NICs check the FCS.  Most NICs will indicate to the driver
>>>whether the FCS was correct or not.  The radiotap header was designed
>>>to carry that kind of "meta-information" about frames.  If you were
>>>so inclined, you could modify the drivers to set a "FCS (in)correct"
>>>flag in the radiotap header, and submit a patch. :-)
>>
>>right, I first wanted to ask if I was not missing something obvious,
>>and to get an idea of a clean patch, which you gave.
>>
>>I'll do one and submit here for review, or should I send-pr ?
> 
> 
> Both! :-)
> 
> 
>>Thanks for your help,
> 
> 
> No problem.
> 
> Dave
>