Re: ath: a few questions [really kismet and radiotap]

Sam Leffler wrote:

> Kris Maglione wrote:
>
>> Sam Leffler wrote:
>>
>>> Kris Maglione wrote:
>>>
>>>> Bruce M Simpson wrote:
>>>>
>>>>> On Tue, Jan 18, 2005 at 09:40:21AM -0500, Kris Maglione wrote:
>>>>>  
>>>>>
>>>>>> Second, according to CVS, hw.ath.outdoors was made tunable a year 
>>>>>> ago, but sysctl says it's readonly when I try to change it. It's 
>>>>>> stuck at 1, which seems to be a possible explanation for why it's 
>>>>>> indoor use sucks so badly compared to the windows driver, 
>>>>>> especially through walls.
>>>>>>   
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> I'm running 5.3-STABLE as of last Wednesday and do not see this 
>>>>> sysctl.
>>>>>
>>>>> Please give version information (uname -a) when posting this kind 
>>>>> of query,
>>>>> as it's next to impossible to give useful advice otherwise.
>>>>>  
>>>>>
>>>> Sorry about that. No uname -a, but it's the 5-STABLE from about a 
>>>> few days ago. The kernel config file is actually the (minimally 
>>>> modified) FreesBIE config file from a few months ago, but why is a 
>>>> long story.
>>>
>>>
>>>
>>>
>>> The setting is a read-only sysctl because once the module is loaded 
>>> changing it has no effect.  Set it before you kldload the module or 
>>> in your hints file if you want it different than the default.
>>>
>>>>
>>>>> You should be able to 'tcpdump -i ath0 -y ieee802_11' to verify 
>>>>> that you
>>>>> can capture 802.11 packets straight off the card.
>>>>>  
>>>>>
>>>> I have done that, and I have used kismet. My problem with kismet 
>>>> turned out to just be a wierd way that kismet reports things.
>>>
>>>
>>>
>>>
>>> kismet has been broken for a while.  It used to work but something 
>>> broke it and I've had no time to dig (it's painful to debug as it's 
>>> a multi-process app written in C++ and makes heavy use of STL so 
>>> inspecting data structures is a pain).
>>
>
> Against my better judgement I looked at kismet again :)  The problem 
> is that kismet is discarding most all packets because it thinks they 
> are corrupt.  The reason it thinks this is because the frames are 
> being delivered to kismet with the trailing FCS intact and kismet 
> interprets FCS as information elements and discards the packets when 
> it validates the packet's contents.  While you likely don't care about 
> the details, the fix is probably something that must go in kismet.  
> FWIW ethereal deals with this issue by having a checkbox in the UI 
> that you can use to enable acceptance of such packets.
>
> The radiotap format should have a flag to indicate FCS is included but 
> it never happened.  I will discuss this (again) with the 
> radiotap-meister.
>
>     Sam

I implemented a temporary solution for my client. I decremented the data 
length (packet->caplength) and packet length (packet->len) variables in 
the Radiotap2KisPacket function by 4 (as long as the data was longer 
than 4 bytes) before the data is memcpy's into the packet->data array.  
This is by no means a definitive solution, since I didn't actually check 
to see of those 4 bytes were really the FCS, but at some point, I 
probably will do so and submit a patch. I have no intention of trying to 
implement it anywhere else, since, for what I know, kismet doesn't use 
the data.

Anyway, it solved the problem. It's barely throwing away any packets now 
and detecting the networks that it should.

Thanks for the info.
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-mobile
To unsubscribe, send any mail to "[email protected]"