Date: Wed, 19 Jan 2005 18:55:58 +0000 From: Kris Maglione <bsdaemon@comcast.net> To: freebsd-mobile@freebsd.org Subject: Re: ath: a few questions [really kismet and radiotap] Message-ID: <41EEAD3E.6010104@comcast.net> In-Reply-To: <41EE9F44.3050308@errno.com> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?41EEAD3E.6010104>