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>
index | next in thread | previous in thread | raw e-mail
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.home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?41EEAD3E.6010104>