1 files changed, 0 insertions, 140 deletions

diff --git a/noncore/net/wellenreiter/docs/specification b/noncore/net/wellenreiter/docs/specification
deleted file mode 100644
index 0766ef4..0000000
--- a/noncore/net/wellenreiter/docs/specification
+++ b/dev/null
@@ -1,140 +0,0 @@
-
--[ Design of wellenreiter ]-
-
-written by: Martin J. Muench <mjm@codito.de>
-
--[ Introduction
-
-This is just a short overview of the new design of wellenreiter.
-There will for sure be some changes and most parts will be specified
-in more detail. 
-
-
--[ Program
-
-wellenreiter 1.7
-(will be named 2.0 after all the functions are implemented and the code
-is cleaned up and audited)
-
-
--[ Short description
-
-Wellenreiter is a wireless sniffing tool like netstumbler, kismet et al.
-It discovers Access Points and Ad-Hoc networks and displays all available
-information about them so that you can simply join unencrypted network 
-(without access restrictions) with the given informations.
-For the latest version of wellenreiter look at:
-http://wellenreiter.sourceforge.net.
-
-
--[ Overview
-
-The software is divided into 2 sections, the daemon and the GUI.
-The daemon does the active sniffing, analying stuff etc.pp. and
-sends the informations to the GUI which displays the results.
-
-
--[ Configuration
-
-The configuration is done by both, the GUI and the daemon so that the
-GUI only provides the graphical interface to the configuration library
-of the daemon. That means that the daemon loads the config file on 
-startup and sends the informations to the GUI. The GUI contains an option
-"configure" where the settings can be changed. They will be sent to the
-daemon which actually changes the configuration file.
-The configuration file is placed in /usr/local/etc/wellenreiter.conf.
-The whole content of this file cannot be specified yet.
-
-OPIE specific: Opie contains a bunch of high-level configuration classes,
-which are used by most Opie applications. It should be discussed whether
-to use this structure / API (preferred) or use a proprietary one.
-
-
--[ Interaction GUI<->daemon
-
-The GUI and the daemon will talk actively with eachother, meaning that 
-everyside who has informations for the other part will send it and not
-wait for the other part to poll.
-For example the sniffing function of the daemon is startet when a 
-"start_sniff" from the GUI arrived. And when the daemon found a network
-it will be directly send to the GUI to be able to sniff in realtime.
-
-
--[ Communication GUI<->daemon
-
-The GUI and the daemon run as threads within one process, where the GUI
-thread will be the main thread. Both the daemon and the GUI thread are
-(mostly) "free-running". Once the GUI thread is started and has finished
-its initializations, it jumps into the Qt event loop ( QApplication::exec() ).
-
-If the daemon thread is actively working and -
-for instance - has acquired interesting data for the GUI thread to display,
-it calls a special reentrant method of the GUI thread ( QApplication::postEvent )
-either transmitting the whole data structure or saying "Hey, there's interesting data
-for you", which the GUI thread then retrieves. 
-To enable a free running daemon thread to actually receive messages from the
-GUI thread, it's useful to to include a non-blocking check-for-messages-function
-within the daemon main loop <since it is waiting for messages from a GUI thread,
-this function has not be called very often>. If applicable, the daemon thread must
-not call this function but only monitor some guarded variables from time to time
-which the GUI thread can modify to alter the behaviour of the daemon thread.
-
-IMHO this is a much more leightweight design than to use a proprietary udp-socket protocol.
-
-
--[ Setting card modes
-
-One of the most interesting parts is the switching of the wirelesscards to
-different channels, to monitor mode and so on. In the older versions this
-actions were done by the calling of external programs, that is now obsolete.
-We will use the API of the wireless drivers to set it up. 
-
-
--[ Sniffing
-
-The sniffing will be done by capturing and analyzing all packets using the
-pcap library. The sniffer itself will be a function of the daemon which will
-probably be threaded so that this function is non-blocking.
-If a packet is found the sniffer sends it to an analyzer function which
-analyzes the packets, strips the results and sends it to the GUI.
-
-
--[ Logging
-
-The GUI should not need to log that much so it logs to STDERR. The daemon
-will be able to run in foreground and log to STDERR and syslog but normally
-it will only log to syslog (INFO/ERR).
-Logging of found networks, packets and so on will also be done by the daemon
-but set up by the GUI.
-
-
--[ GPS
-
-The gps daemon software will be used, hopefully by their API if they provide
-that. If not, we have to use system() calls, hope we do not.
-
-
--[ Security
-
-The programm and the daemon will have to run with SUID privileges for being
-able to change card modes etc. so the code has to be audited several times.
-Setuid 0 will only be called when really needing the privileges and dropped
-directly after every single systemcall.
-The daemon will implement an access control list where it specifies which
-IPs or network interfaces will have access to it. 
-The configuration file will be chmod'ed 0400, for writing the configuration
-library will change the mode. Of course the file will be locked during
-writing so no race conditions can occur.
-
-
--[ Documentation
-
-Wellenreiter will have it's own wellenreiter(8) manpage with most parts of 
-the README file in there.
-Also we will provide general documentation about wireless scanning, security
-risks with wireless devices and so on.
-Most documentation will be intern like this one. The GUI and the daemon
-should have a non-technical documentation and a developers version so we
-can easily develope with other peoples code without having to read it
-completely.
-