Re: Approaches to enabling scanning for AirPort (not Extreme)
On Fri, Feb 25, 2005 at 08:30:42AM -0800, Eric Gaumer wrote:
> Sven Luther wrote:
> >>Or I can send you the patch if you'd like to build your own kernel.
> >
> >
> >What about filling a bug report against the debian kernels instead ?
> >
> >And for your information, there where such patches inside the 2.6.7/8
> >powerpc
> >kernels ages ago, but i don't know what Jens did to those, let me check the
> >changelog ... Oh, i think it was this one :
> >
> >kernel-patch-powerpc-2.6.6 (2.6.6-5) unstable; urgency=low
> >...
> > * Removed the patch adding monitor mode to the Airport card driver. It
> > is outdated, unstable, and was only intended as a placeholder from
> > the
> > very beginning.
> >...
> > -- Jens Schmalzing <jensen@debian.org> Fri, 28 May 2004 18:20:48 +0200
> >
> >I guess it was older than i remembered. What about your patch, where did
> >you
> >get it from, and any chance of it getting upstream ?
>
> The only way I see this getting into Linus' tree is by someone like Ben
> signing off on it.
> I've gone through the code but frankly don't posses the clout nor the
> experience to say that
> things are legit.
Who wrote that code ? And if you do, the first step to getting it in is to ask
for comment on the mailing lists, and to push for it. It may be a daunting
task, as there is chance those guys will just ignore you at first, maybe a
kind of selection process of waht code goes in, where code goes in only if
people care enough.
> From a user standpoint I can speak for its stability. I had 344 days up of
> uptime on my PB
> using this patch on Ben's 2.4.22 kernel. This is the same patch modified
> for the 2.6 API.
> I've been running it since 2.6.9 and have never experienced any serious
> problems. On 2.4 the
> module would loop itself if you ran kismet with the card active (interface
> up). Downing the
> interface would lower the reference count and then a simple rmmod would
> yank the code
> without a problem. Since then I just make sure I let kismet bring the
> interface up on it's
> own. I haven't tried this with any 2.6 kernel because I just assumed that
> in order to enter
> promiscuous mode, the card should be inactive from the start.
>
> Still all in all, I would recommend this patch to anyone with that one
> simple warning. And
> it could be kismet and not the module. Like I said I can remove the module
> which doesn't
> seem indicative of a serious problem inside kernel space. So what makes me
> think the module
> code loops? Well I can see printks on my terminal that show the module is
> in some type of
> loop and the CPU goes though the roof.
>
> The patch came from http://airsnort.shmoo.com/orinocoinfo.html
Ok, could you perhaps contact the authors and ask them about upstream status ?
Friendly,
Sven Luther
Reply to: