From owner-freebsd-mobile@FreeBSD.ORG Thu Jan 20 00:52:47 2005 Return-Path: Delivered-To: freebsd-mobile@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 43E2416A4CE for ; Thu, 20 Jan 2005 00:52:47 +0000 (GMT) Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.198.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id 04EDC43D2F for ; Thu, 20 Jan 2005 00:52:47 +0000 (GMT) (envelope-from bsdaemon@comcast.net) Received: from fw.home (pcp05404374pcs.norstn01.pa.comcast.net[68.80.144.252]) by comcast.net (rwcrmhc11) with SMTP id <20050120005246013009erjne>; Thu, 20 Jan 2005 00:52:46 +0000 Received: (qmail 47703 invoked from network); 20 Jan 2005 00:53:07 -0000 Received: from unknown (HELO ?192.168.1.251?) (192.168.1.251) by fw.home with SMTP; 20 Jan 2005 00:53:07 -0000 Message-ID: <41EEAD3E.6010104@comcast.net> Date: Wed, 19 Jan 2005 18:55:58 +0000 From: Kris Maglione User-Agent: Mozilla Thunderbird 1.0 (X11/20041213) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-mobile@freebsd.org References: <41ED1FD5.8090401@comcast.net> <20050118144209.GF3054@empiric.icir.org> <41ED3019.9020600@comcast.net> <41ED4652.8040902@errno.com> <41ED568D.8000405@comcast.net> <41EE9F44.3050308@errno.com> In-Reply-To: <41EE9F44.3050308@errno.com> X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: ath: a few questions [really kismet and radiotap] X-BeenThere: freebsd-mobile@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: freebsd-mobile@freebsd.org List-Id: Mobile computing with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2005 00:52:47 -0000 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.