[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Approaches to enabling scanning for AirPort (not Extreme)



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.

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

--
"Education is what remains after one has forgotten everything he learned in school."
	- Albert Einstein

Attachment: signature.asc
Description: OpenPGP digital signature


Reply to: