--- /dev/null
+#
+# $Id: NOTES 2844 2009-06-22 10:59:35Z luigi $
+#
+
+---------------------------------------------------------------------
+--- DEVELOPER NOTES ------------------------------------------------
+
+Both the client and the kernel code use almost unmodified sources
+from FreeBSD (just a very small number of sections #ifdef'ed out
+for features not relevant or not implemented).
+
+In both cases we provide two set of headers:
+ - one set is made of empty files, automatically generated, to replace
+ FreeBSD headers not available or conflicting on the ported platforms.
+ - one set is made of custom files, sometimes copied verbatim
+ from FreeBSD, sometimes containing only the minimal set of
+ macros/ struct/ prototypes required by the port.
+
+Additionally, we have a small set of .c files providing functions not
+available in the port platforms, and hooks for the sockopt/packet
+data.
+
+
+TODO (LINUX), 20090622:
++ use an appropriate identifier instead of LINUX24
++ find the discharging module hook, in order to force a queue flush
++ use the output interface as a clock for the pipe
++ better matching on interface names (case insensitive etc ?)
++ match by interface address
++ verify path
++ send keepalives
++ tables support
++ uid/gid match (through the socket ?)
++ pullup or data in external buffers
++ O_TAG
++ O_DIVERT
++ O_TEE
++ O_SETFIB
++ kmem_cache_alloc
+
+TODO (WINDOWS) 20090622
++ all of the above, once it works
+# svn
+https://svn.sourceforge.net/svnroot/wipfw
+
+TODO (OpenWRT) 20090622
++ add a module compilation for 2.6
+
+TODO (FreeBSD, general)
++ New features related to the forthcoming IPv6 are missing, as the IPv6
+support for lookup tables that currently support IPv4 addresses only.
+One of the goal of this project is to add the tables feature to the
+IPv6 protocol.
+
++ The current code implements rules listing requests as a single
+request returning both static and dynamic rules as a whole block. This
+operation requires a lock to be held for the time needed to get the
+full list of rules, regardless of the requested rules. I propose to
+break up the rule request in two parts, for static and dynamic rules, in
+order to avoid to lock the whole struct for a subset of rules required.
+
++ At last, due to improvement and contribution to the code, the tool
+significantly grown over the time with new functionalities and features,
+leaving the general view aside. An example of this will be the use of
+dispatching table instead some very long switch case, making the resulting
+code more readable and hopefully a faster execution.
+
++ XXX can't find the ipfw_* indirection...
+
+DETAILED PORTING INFO
+
+--- ipfw (userland) on linux ---
+
+The port is relatively trivial. Communication with the kernel occurs
+through a raw socket using [gs]etsockopt(), and all is needed is the
+availability of ip_fw.h and ip_dummynet.h headers to describe the
+relevant data structures.
+
+--- kernel ipfw on linux ---
+
+Sources are mostly unmodified, except for commenting out
+unsupported features (tables, in-kernel nat...).
+The port requires a rather large number of empty headers.
+Other porting issues are in ipfw2_mod.c
+
+--- build as an Openwrt package
+
+------ WINDOWS PORT ------
+
+A port to windows is still in progress.
+This directory contain a port of ipfw and dummynet to Windows.
+
+--- BACKGROUND:
+
+We started from the wipfw port available at [WIPFW] , but
+most of the port is done from scratch using the most recent
+version of ipfw+dummynet from HEAD/RELENG_7 as of March 2009
+
+# WIPFW: wipfw.sourceforge.net
+#binary:
+http://downloads.sourceforge.net/wipfw/wipfw-0.3.2b.zip?use_mirror=mesh
+http://downloads.sourceforge.net/wipfw/wipfw-0.2.8-source.zip
+
+--- DEVELOPMENT TOOLS:
+
+At least initially, to build the code you need a pc with
+windows installed and the [WINDDK] from the microsoft site.
+Other tools like the new WDK should work as well.
+
+The 'standard' way used by WDK/WINDDK is to run a 'build'
+script which in turn calls nmake and then the microsoft
+compiler [CL] and linker [LINK]. See the documentation for
+command line switches for these tools, they are similar but
+not the same as the equivalent gcc switches. In particular,
+a / is often used to replace - though both forms are accepted.
+
+The steps to do in order to launch the build environment follows:
+
+ + download winddk from microsoft.com
+ + install
+ + run the Free Build Enviroment from:
+
+ Start -> All Program -> WINDDK ->
+ [NT|XP|2000] -> Free Build Environment
+
+ + change dir to .src and type `build' in command line
+
+For our purposes, however, it is much more convenient to use
+cygwin [CYGWIN] and invoke CL and LINK using gmake
+
+A debugging tools is:
+ http://technet.microsoft.com/en-us/sysinternals/bb896647.aspx
+it simply display the kernel-mode debug output.
+Use the DbgPrint() function, that is something similar to printk().
+Can be lauched with dbgview.exe.
+
+After a succesfully compilation and link, you can launch the program
+in user space simply executing the binary file, while for the kernel
+space you need to do the following steps:
+
+cp ipfw.sys /cygdrive/c/WINDOWS/system32/drivers/
+ipfw install_drv System32\DRIVERS\ip_fw.sys
+net start ip_fw
+
+
+=======
+--- ARCHITECTURE ---
+
+The main part of the userland program mostly work as the
+unix equivalent, the only issue is to provide empty
+header files to replace those not available in Windows,
+and include the winsock2 headers to access some network
+related functions and headers.
+
+Communication with the kernel module does not use a raw IP socket
+as in the unix version. Instead, we inherit the same method
+used in ipfw -- a replacement for socket() creates a handle
+to access the control structure, and setsockopt/getsockopt
+replacements are also used to communicate with the kernel
+side. This is implemented in win32.c
+
+In order to load the module and activate it, we also use
+the same technique suggested in wipfw -- the main() is
+extended (with a wrapper) so that it can handle additional
+commands to install/control/deinstall the service and
+call the appropriate actions. See svcmain.c for details.
+
+--- PORTING ISSUES:
+
+Most of the unix hierarchy of headers is not available so we
+have to replicate them.
+
+gcc attributes are also not present.
+
+C99 types are not present, remapped in <sys/cdefs.h>
+
+--- USEFUL LINKS:
+
+[WIPFW]
+ http://wipfw.sourceforge.net/
+
+[WINDDK]
+ http://www.microsoft.com/whdc/devtools/ddk/default.mspx
+
+[CL]
+ http://msdn.microsoft.com/en-us/library/610ecb4h.aspx
+ command line syntax
+
+[CYGWIN]
+ http://www.cygwin.com/setup.exe
git://git.onelab.eu / ipfw.git / blobdiff