maemo.org - Talk - [Announce] Kismet + Fully functional WLAN monitor mode for the N900

maemo.org - Talk (https://talk.maemo.org/index.php)

- Applications (https://talk.maemo.org/forumdisplay.php?f=41)

- - [Announce] Kismet + Fully functional WLAN monitor mode for the N900 (https://talk.maemo.org/showthread.php?t=52393)

Re: [Announce] Kismet + Fully functional WLAN monitor mode for the N900

Thanks! You were off the grid for a few days (you usually respond right away on this thread), some of us may have thought something happened to you lol

Re: [Announce] Kismet + Fully functional WLAN monitor mode for the N900

Quote:

Originally Posted by mail_e36 (Post 719209)

Thanks! You were off the grid for a few days (you usually respond right away on this thread), some of us may have thought something happened to you lol

I am all right. I am currently just a bit busy.

Re: [Announce] Kismet + Fully functional WLAN monitor mode for the N900

Does anybody else still experience GSM drop-out / Offline mode activation WITHOUT automatic re-enabling?

I can set it back to "Normal" mode easily though, so not a real huge issue.

I've also given the PTW plugin a whirl and it works as described. Ran it against a network for about 12 minutes and it automagically determined the 104 bit key after around 80,000 IV's

Re: [Announce] Kismet + Fully functional WLAN monitor mode for the N900

hi
how did you load the autowep plugin in kismet ptw?

Re: [Announce] Kismet + Fully functional WLAN monitor mode for the N900

AutoWEP is a separate plugin from PTW.

David has also packaged the autowep and PTW plugins, they are sitting in the repository. Once installed, they are loaded by the server and work completely transparently.

Any more information you need, you can find at kismetwireless.net or the man pages.

Re: [Announce] Kismet + Fully functional WLAN monitor mode for the N900

hi!
thx, i will try home kismet ptw on my own network to see.

Re: [Announce] Kismet + Fully functional WLAN monitor mode for the N900

I installed it, but I made a huge mistake. I hitted yes when the app asked me about the font color. How can I change it now? I tryed to reinstall kismet, but it didnt worked...
:confused:

Re: [Announce] Kismet + Fully functional WLAN monitor mode for the N900

never used this before but most apps store their settings in an invisible folder in the home directory with the same name as the app (e.g. .kismet).

you could try uninstalling, then wiping that folder, and reinstalling.

Re: [Announce] Kismet + Fully functional WLAN monitor mode for the N900

As already stated, /opt/kismet/etc is the location.

That is all.

Re: [Announce] Kismet + Fully functional WLAN monitor mode for the N900

Quote:

Originally Posted by WillianWives (Post 749851)

I installed it, but I made a huge mistake. I hitted yes when the app asked me about the font color. How can I change it now?

The easiest way would be to remove the kismet_ui.conf.
The UI/Client configuration files are located in /home/user/.kismet or /root/.kismet (if running as root)
Afterwards you only need to run kismet and you will get asked again.
You don't need to reinstall it.

Re: [Announce] Kismet + Fully functional WLAN monitor mode for the N900

Good info, Hawaii. Here is the actual link:

http://maemo.org/packages/view/kismet-plugin-ptw/

"Wireless 802.11b monitoring tool - Plugin PTW

Kismet is a 802.11b wireless network sniffer. It is capable of sniffing using almost any supported wireless card using the Airo, HostAP, Wlan-NG, and Orinoco (with a kernel patch) drivers.

Kismet is a command-line only program and so should be used inside X Terminal.

WARNING: This plugin can cause heavy load.

Kismet-PTW is a Kismet plugin which performs the Aircrack-NG PTW attack against data captured by Kismet.

The Aircrack-NG PTW attack exploits flaws in WEP to expose the original keystream. Because the PTW attack needs relatively few packets (50,000 to 100,000) and is relatively CPU cheap, it makes sense to include this as an automatic feature.

While Aircrack-NG can use injection to accelerate the rate at which packets are generated, increasing the chances of deriving the key, the Kismet-PTW version is 100% passive. Kismet will NOT inject packets or actively attack a network, with this plugin it will simply examine the data it has already recorded.

The code for the PTW attack is directly extracted from Aircrack-NG, this plugin simply wraps the Aircrack-NG library into a form Kismet can use directly. For complete info about the PTW attack or Aircrack, see the Aircrack-NG project at: http://www.aircrack-ng.org"

Quote:

Originally Posted by hawaii (Post 734113)

Re: [Announce] Kismet + Fully functional WLAN monitor mode for the N900

I've adjusted the PTW plugin to require more packets before attempting to retrieve a key, this should reduce the load once you hit over 5k dumps. I've also chopped down client text updates to remove console scrolling of logs and cluttering.

FYI, a new release of Kismet was pushed out today. Hope to get it compiled and working soon. David will probably push to a repo before me, I tend to keep all my tools to myself :D

Re: [Announce] Kismet + Fully functional WLAN monitor mode for the N900

Hawaii,

If David (lxp) does not get it compiled and pushed to the repo it would be great if you would :)

I've enjoyed your blog, especially the part about MetaSploit on the N900, so please don't keep the N900 tools to yourself :)

Re: [Announce] Kismet + Fully functional WLAN monitor mode for the N900

Has anyone received the below error when trying to start the PTW plugin within Kismet?

"No Plugins Found"

"Server plugins cannot currently be loaded/unloaded frim the UI"

Please see attached image. Can anyone point me in the right direction to get this running?

Thank you

Quote:

Originally Posted by hawaii (Post 750549)

Re: [Announce] Kismet + Fully functional WLAN monitor mode for the N900

PTW plugin is attached at the server level, not client. The plugin is loaded in that screenshot, as indicative under the "server plugins" section right below the message you're reading.

Also, as it states, you can't unload a server plugin while it's running. If you want to temporarily disable it, rename the link/shared object in /opt/kismet/lib/kismet.

Thanks for the words regarding my site. I don't always have time to push packages to the repos, especially due to autobuilder, bleh. I'm off for the N97MiniTour with the Nokia Canada peeps soon, so I'll try and get something up; even if it's just a binary package attached to a post here.

I'LL DO IT FOR YOU BECAUSE YOU'RE SO NICE.

Re: [Announce] Kismet + Fully functional WLAN monitor mode for the N900

can anyone upload the kismet configuration files in /home/opt/kismet/etc ? Really appreciate it. Thanks!

Re: [Announce] Kismet + Fully functional WLAN monitor mode for the N900

Quote:

Originally Posted by wkit (Post 814573)

can anyone upload the kismet configuration files in /home/opt/kismet/etc ? Really appreciate it. Thanks!

kismet.conf:

Code:

# Kismet config file

# Most of the "static" configs have been moved to here -- the command line

# config was getting way too crowded and cryptic.  We want functionality,

# not continually reading --help!



# Version of Kismet config

version=2009-newcore



# Name of server (Purely for organizational purposes)

servername=Kismet_2009



# Prefix of where we log (as used in the logtemplate later)

logprefix=/home/user/MyDocs



# Do we allow plugins to be used?  This will load plugins from the system

# and user plugin directiories when set to true (See the README for the default

# plugin locations).

allowplugins=true



# See the README for full information on the new source format

# ncsource=interface:options

# for example:

# ncsource=wlan0

# ncsource=wifi0:type=madwifi

# ncsource=wlan0:name=intel,hop=false,channel=11

ncsource=wlan0



# Comma-separated list of sources to enable.  This is only needed if you defined

# multiple sources and only want to enable some of them.  By default, all defined

# sources are enabled.

# For example, if sources with name=prismsource and name=ciscosource are defined,

# and you only want to enable those two:

# enablesources=prismsource,ciscosource



# Control which channels we like to spend more time on.  By default, the list

# of channels is pulled from the driver automatically.  By setting preferred channels,

# if they are present in the channel list, they'll be set with a timing delay so that

# more time is spent on them.  Since 1, 6, 11 are the common default channels, it makes

# sense to spend more time monitoring them.

# For finer control, see further down in the config for the channellist= directives.

preferredchannels=1,6,11



# How many channels per second do we hop?  (1-10)

channelvelocity=3



# By setting the dwell time for channel hopping we override the channelvelocity

# setting above and dwell on each channel for the given number of seconds.

#channeldwell=10



# Channels are defined as:

# channellist=name:ch1,ch2,ch3

# or

# channellist=name:range-start-end-width-offset,ch,range,ch,...

#

# Channels may be a numeric channel or a frequency

#

# Channels may specify an additional wait period.  For common default channels,

# an additional wait period can be useful.  Wait periods delay for that number 

# of times per second - so a configuration hopping 10 times per second with a

# channel of 6:3 would delay 3/10ths of a second on channel 6.

#

# Channel lists may have up to 256 channels and ranges (combined).  For power 

# users scanning more than 256 channels with a single card, ranges must be used.

#

# Ranges are meant for "power users" who wish to define a very large number of

# channels.  A range may specify channels or frequencies, and will automatically

# sort themselves to cover channels in a non-overlapping fashion.  An example

# range for the normal 802.11b/g spectrum would be:

#

# range-1-11-3-1

#

# which indicates starting at 1, ending at 11, a channel width of 3 channels,

# incrementing by one.  A frequency based definition would be:

#

# range-2412-2462-22-5

#

# since 11g channels are 22 mhz wide and 5 mhz apart.

#

# Ranges have the flaw that they cannot be shared between sources in a non-overlapping

# way, so multiple sources using the same range may hop in lockstep with each other

# and duplicate the coverage.

#

# channellist=demo:1:3,6:3,11:3,range-5000-6000-20-10



# Default channel lists

# These channel lists MUST BE PRESENT for Kismet to work properly.  While it is

# possible to change these, it is not recommended.  These are used when the supported

# channel list can not be found for the source; to force using these instead of

# the detected supported channels, override with channellist= in the source defintion

#

# IN GENERAL, if you think you want to modify these, what you REALLY want to do is

# copy them and use channellist= in the packet source.

channellist=IEEE80211b:1:3,6:3,11:3,2,7,3,8,4,9,5,10

channellist=IEEE80211a:36,40,44,48,52,56,60,64,149,153,157,161,165

channellist=IEEE80211ab:1:3,6:3,11:3,2,7,3,8,4,9,5,10,36,40,44,48,52,56,60,64,149,153,157,161,165



# Client/server listen config

listen=tcp://127.0.0.1:2501

# People allowed to connect, comma seperated IP addresses or network/mask

# blocks.  Netmasks can be expressed as dotted quad (/255.255.255.0) or as

# numbers (/24)

allowedhosts=127.0.0.1

# Maximum number of concurrent GUI's

maxclients=5

# Maximum backlog before we start throwing out or killing clients.  The

# bigger this number, the more memory and the more power it will use.

maxbacklog=5000



# Server + Drone config options.  To have a Kismet server export live packets

# as if it were a drone, uncomment these.

# dronelisten=tcp://127.0.0.1:3501

# droneallowedhosts=127.0.0.1

# dronemaxclients=5

# droneringlen=65535



# OUI file, expected format 00:11:22<tab>manufname

# IEEE OUI file used to look up manufacturer info.  We default to the

# wireshark one since most people have that.

ouifile=/opt/kismet/etc/manuf

ouifile=/etc/manuf

ouifile=/usr/share/wireshark/wireshark/manuf

ouifile=/usr/share/wireshark/manuf



# Do we have a GPS?

gps=true

# Do we use a locally serial attached GPS, or use a gpsd server?

# (Pick only one)

gpstype=liblocation

# gpstype=serial

# What serial device do we look for the GPS on?

gpsdevice=/dev/rfcomm0

# Host:port that GPSD is running on.  This can be localhost OR remote!

gpshost=localhost:2947

# Do we lock the mode?  This overrides coordinates of lock "0", which will

# generate some bad information until you get a GPS lock, but it will 

# fix problems with GPS units with broken NMEA that report lock 0

gpsmodelock=false

# Do we try to reconnect if we lose our link to the GPS, or do we just

# let it die and be disabled?

gpsreconnect=true



# Do we export packets over tun/tap virtual interfaces?

tuntap_export=false

# What virtual interface do we use

tuntap_device=kistap0



# Packet filtering options:

# filter_tracker - Packets filtered from the tracker are not processed or

#                  recorded in any way.

# filter_export  - Controls what packets influence the exported CSV, network,

#                  xml, gps, etc files.

# All filtering options take arguments containing the type of address and

# addresses to be filtered.  Valid address types are 'ANY', 'BSSID',

# 'SOURCE', and 'DEST'.  Filtering can be inverted by the use of '!' before

# the address.  For example,

# filter_tracker=ANY(!"00:00:DE:AD:BE:EF")

# has the same effect as the previous mac_filter config file option.

# filter_tracker=...

# filter_dump=...

# filter_export=...

# filter_netclient=...



# Alerts to be reported and the throttling rates.

# alert=name,throttle/unit,burst

# The throttle/unit describes the number of alerts of this type that are

# sent per time unit.  Valid time units are second, minute, hour, and day.

# Burst describes the number of alerts sent before throttling takes place.

# For example:

# alert=FOO,10/min,5

# Would allow 5 alerts through before throttling is enabled, and will then

# limit the number of alerts to 10 per minute.

# A throttle rate of 0 disables throttling of the alert.

# See the README for a list of alert types.

alert=ADHOCCONFLICT,5/min,1/sec

alert=AIRJACKSSID,5/min,1/sec

alert=APSPOOF,10/min,1/sec

alert=BCASTDISCON,5/min,2/sec

alert=BSSTIMESTAMP,5/min,1/sec

alert=CHANCHANGE,5/min,1/sec

alert=CRYPTODROP,5/min,1/sec

alert=DISASSOCTRAFFIC,10/min,1/sec

alert=DEAUTHFLOOD,5/min,2/sec

alert=DEAUTHCODEINVALID,5/min,1/sec

alert=DISCONCODEINVALID,5/min,1/sec

alert=DHCPNAMECHANGE,5/min,1/sec

alert=DHCPOSCHANGE,5/min,1/sec

alert=DHCPCLIENTID,5/min,1/sec

alert=DHCPCONFLICT,10/min,1/sec

alert=NETSTUMBLER,5/min,1/sec

alert=LUCENTTEST,5/min,1/sec

alert=LONGSSID,5/min,1/sec

alert=MSFBCOMSSID,5/min,1/sec

alert=MSFDLINKRATE,5/min,1/sec

alert=MSFNETGEARBEACON,5/min,1/sec

alert=NULLPROBERESP,5/min,1/sec

#alert=PROBENOJOIN,5/min,1/sec



# Controls behavior of the APSPOOF alert.  SSID may be a literal match (ssid=) or

# a regex (ssidregex=) if PCRE was available when kismet was built.  The allowed 

# MAC list must be comma-separated and enclosed in quotes if there are multiple 

# MAC addresses allowed.  MAC address masks are allowed.

apspoof=Foo1:ssidregex="(?i:foobar)",validmacs=00:11:22:33:44:55

apspoof=Foo2:ssid="Foobar",validmacs="00:11:22:33:44:55,aa:bb:cc:dd:ee:ff"



# Known WEP keys to decrypt, bssid,hexkey.  This is only for networks where

# the keys are already known, and it may impact throughput on slower hardware.

# Multiple wepkey lines may be used for multiple BSSIDs.

# wepkey=00:DE:AD:C0:DE:00,FEEDFACEDEADBEEF01020304050607080900



# Is transmission of the keys to the client allowed?  This may be a security

# risk for some.  If you disable this, you will not be able to query keys from

# a client.

allowkeytransmit=true



# How often (in seconds) do we write all our data files (0 to disable)

writeinterval=300



# Do we use sound?

# Not to be confused with GUI sound parameter, this controls wether or not the

# server itself will play sound.  Primarily for headless or automated systems.

enablesound=false

# Path to sound player

soundbin=paplay



sound=newnet,true

sound=newcryptnet,true

sound=packet,true

sound=gpslock,true

sound=gpslost,true

sound=alert,true



# Does the server have speech? (Again, not to be confused with the GUI's speech)

enablespeech=false

# Binary used for speech (if not in path, full path must be specified)

speechbin=flite

# Specify raw or festival; Flite (and anything else that doesn't need formatting

# around the string to speak) is 'raw', festival requires the string be wrapped in

# SayText("...")

speechtype=raw



# How do we speak?  Valid options:

# speech    Normal speech

# nato      NATO spellings (alpha, bravo, charlie)

# spell     Spell the letters out (aye, bee, sea)

speechencoding=nato



speech=new,"New network detected s.s.i.d. %1 channel %2"

speech=alert,"Alert %1"

speech=gpslost,"G.P.S. signal lost"

speech=gpslock,"G.P.S. signal O.K."



# How many alerts do we backlog for new clients?  Only change this if you have

# a -very- low memory system and need those extra bytes, or if you have a high

# memory system and a huge number of alert conditions.

alertbacklog=50



# File types to log, comma seperated.  Built-in log file types:

# alert                Text file of alerts

# gpsxml            XML per-packet GPS log

# nettxt            Networks in text format

# netxml            Networks in XML format

# pcapdump            tcpdump/wireshark compatible pcap log file

# string            All strings seen (increases CPU load)

logtypes=pcapdump,gpsxml,netxml,nettxt,alert



# Format of the pcap dump (PPI or 80211)

pcapdumpformat=ppi

# pcapdumpformat=80211



# Default log title

logdefault=Kismet



# logtemplate - Filename logging template.

# This is, at first glance, really nasty and ugly, but you'll hardly ever

# have to touch it so don't complain too much.

#

# %p is replaced by the logging prefix + '/'

# %n is replaced by the logging instance name

# %d is replaced by the starting date as Mon-DD-YYYY

# %D is replaced by the current date as YYYYMMDD

# %t is replaced by the starting time as HH-MM-SS

# %i is replaced by the increment log in the case of multiple logs

# %l is replaced by the log type (pcapdump, strings, etc)

# %h is replaced by the home directory



logtemplate=%p%n-%D-%t-%i.%l



# Where state info, etc, is stored.  You shouldnt ever need to change this.

# This is a directory.

configdir=%h/.kismet/

Re: [Announce] Kismet + Fully functional WLAN monitor mode for the N900

Hey guys, I just want to say first off that this is a great forum and has answered a lot of questions to help get my n900 into a fully function wireless sniffer! YAY!

I know there has been some talk of injection on this forum, obviously because that's the first thing you want to do with aircrack-ng! I don't know if anyone here has come across the injection driver for the wl1251 card in the n900. But I KNOW it exists. There is even a module I have yet to find called wl1xx.ko which apparently is the patched injection driver. Also there are a bunch of videos on youtube right now of people cracking it:

http://www.youtube.com/watch?v=I6NcP3Fk-hc&feature=fvw

who apparently aren't the neopwn guys, which definitely have the injection driver! Don't know if they are willing to hand it out but I will ask them as well.

So my question is, has anyone come across this patched injection driver and can they PLEASE FOR THE LOVE OF GOD post a link to it? I will be forever great full, again, awesome forum, great admins thanks for all your work!

Re: [Announce] Kismet + Fully functional WLAN monitor mode for the N900

Hi,

I am also the developer of the injection patches. I originally developed them for Neopwn, but as it seems that Neopwn is stuck I will eventually publish them differently. Please just be patient for another week. Until then I should have cleared the situation with the Neopwn project.

Regards,
lxp

Re: [Announce] Kismet + Fully functional WLAN monitor mode for the N900

Quote:

Originally Posted by lxp (Post 877658)

wow. this is good news from you. we are eagerly and patiently waiting for this:D

Re: [Announce] Kismet + Fully functional WLAN monitor mode for the N900

ethernin: we aren't allowed to distribute neopwn or the injection driver here, so asking for it won't get you very far. unfortunately the beta version was a "give me $20 and you can try it" deal, and that was like 6 months ago and they never gave any more updates to the project. they also stopped accepting donations. lxp is at least giving us some hope here, so i won't disrespect him and post any hints about where to find it.
ethernin, you should really allow private messages, in case, you know, someone needs to send you something... completely unrelated, of course.

Re: [Announce] Kismet + Fully functional WLAN monitor mode for the N900

great news from lxp as i know alot of us are wanting this.:rolleyes:

Re: [Announce] Kismet + Fully functional WLAN monitor mode for the N900

thank you very much Ixp, i will wait for your next posts, and have some patience on you uploading new inyectiion drivers made by you

i really hope ypu can do this and for the new drivers to be compiled within the kernel power for everyone to se, like the monitor mode ones

thank you again for your great effort and for your kindness for allowing us to use ur stuff

cheers

Re: [Announce] Kismet + Fully functional WLAN monitor mode for the N900

It would be awesome LXP.
If you need testers just PM me.

Re: [Announce] Kismet + Fully functional WLAN monitor mode for the N900

I just want to give some updates regarding the packet injection driver:

I will definitively publish the patches on my own, because Neopwn hasn't answered my mails even one week after the deadline I set.

I am currently working on fixing a bug with managed/station mode. I have already invested much time into debugging this bug, but I still need some time to get the optimal workaround. (It seems to be a firmware issue.)
After I have fixed the bug I will forward-port the patches onto the current wireless-testing tree and do some testing with the current power kernel. Right before testing I also have to update my phone to PR1.3. (Still had no time to do that)

Re: [Announce] Kismet + Fully functional WLAN monitor mode for the N900

great news lxp, thx a lot!

Re: [Announce] Kismet + Fully functional WLAN monitor mode for the N900

how do u develp the driver? assembyly code?? programing language?? could u plz tell me?

Re: [Announce] Kismet + Fully functional WLAN monitor mode for the N900

it would be AWESOME if you could develop inyection drivers for the most recent kernel power, i am currencly using the inyection ones from neopwn and i had to install neopwn, dont want that i wanna use my mmc for other things like nitdroid lol

wish you success for the new drivers

cheers

Re: [Announce] Kismet + Fully functional WLAN monitor mode for the N900

Quote:

Originally Posted by lxp (Post 887186)

thank you very much mate, your work is awesome, is unbelievable that the neopwn people dont even answer you, i think that people dont deserve no one $ from the people buy the software and donate and even to talk again about neopwn.

Re: [Announce] Kismet + Fully functional WLAN monitor mode for the N900

Quote:

Originally Posted by naturegodtm (Post 887278)

how do u develp the driver? assembyly code?? programing language?? could u plz tell me?

First I haven't developed a new driver. It is still the normal wl1251 driver included within the Linux kernel. Like most of the Linux kernel, also the wl1251 driver is written in C.

Quote:

Originally Posted by arnoldux (Post 887313)

Of course, the latest power kernel will be supported.
I will include a new modified power kernel, when I publish the driver. After that the required changes will hopefully be incorporated into the power kernel itself, so we don't need modified power kernels in the future. (To not confuse people: that doesn't mean power kernel will support packet injection "out-of-the-box", it only means that the power kernel should then be compatible with compat-wireless)

Re: [Announce] Kismet + Fully functional WLAN monitor mode for the N900

Hi, i don't know if this is the correct place to ask this.

I've been trying to compile rtl8187.ko (r8187) for N900 and kernel-power v46... (Thanx to h-e-n)

Ok got it compiled but ...

ieee80211_crypt-rtl.ko
ieee80211_crypt_wep-rtl.ko
ieee80211_crypt_tkip-rtl.ko
ieee80211_crypt_ccmp-rtl.ko
ieee80211-rtl.ko
insmoded ok

but r8187.ko fails to insmod
insmod: error inserting 'r8187.ko': -1 Unknown symbol in module

I'm using this source http://dl.aircrack-ng.org/drivers/rt...ux_26.1010.zip

Can someone try to compile with scratchbox?

Re: [Announce] Kismet + Fully functional WLAN monitor mode for the N900

That is your third cross-post for this issue.

Re: [Announce] Kismet + Fully functional WLAN monitor mode for the N900

Sorry for that, i´ve been researching threats about this issue, and it seems to be lost in space.
I suppose im starting to get desperate.

Re: [Announce] Kismet + Fully functional WLAN monitor mode for the N900

Just bumping this thread...
Any updates for the modified drivers release?

Re: [Announce] Kismet + Fully functional WLAN monitor mode for the N900

Another bump only for this post.

Quote:

Originally Posted by lxp (Post 887186)

Re: [Announce] Kismet + Fully functional WLAN monitor mode for the N900

Another update regarding the packet injection driver:

It seems that I finally found the firmware issue causing the bug in managed/station mode. It wasn't too easy to figure this out due to the closed-source firmware, but I found a workaround.
Today I have successfully verified it at various locations and now I am continuing with upgrading my phone to PR1.3 and forward-porting the patches to current wireless-testing.
If nothing went wrong I may release the driver before Christmas.

Re: [Announce] Kismet + Fully functional WLAN monitor mode for the N900

*Cheers* lol You made my day lxp! ^_^

Re: [Announce] Kismet + Fully functional WLAN monitor mode for the N900

Gents,

Is there a repo I need to add to see the wireless-testing tree?

Thanks!
houz

Re: [Announce] Kismet + Fully functional WLAN monitor mode for the N900

No. Patches are going upstream and will get backported by the required people. Please wait until the kernel is released publicly, and any accompanying drivers can be compiled and provided.