Converted files of the Windows distribution from LF format to CR/LF
authorThomas Lopatic <thomas@lopatic.de>
Thu, 16 Sep 2004 08:41:47 +0000 (08:41 +0000)
committerThomas Lopatic <thomas@lopatic.de>
Thu, 16 Sep 2004 08:41:47 +0000 (08:41 +0000)
format.

README-WIN32.txt
files/olsrd.conf.default.win32

index f1ed505..82aab46 100644 (file)
-
-                         olsr.org for Windows
-                         --------------------
-
-Welcome to the Windows release of olsr.org. Let's have a quick look at
-how this version differs from the original Linux version.
-
-
-                        ***** Stability *****
-
-  While the Windows version looks pretty stable in basic scenarios, it
-  hasn't yet received the extensive testing by the OLSR community that
-  the Linux version has gone through. So, if you experience any
-  strange behaviour, it's probably my fault. In this case please bear
-  with me and use the issue tracker on SourceForge. I'll then do my
-  best to find and fix the problem with your assistance. The
-  SourceForge homepage for olsrd.org has the following URL.
-
-                http://sourceforge.net/projects/olsrd/
-
-
-                    ***** Configuration file *****
-
-  If you do not specify a configuration file, the OLSR server
-  ("olsrd.exe") by default attempts to use "olsrd.conf" in your
-  Windows directory, e.g. "C:\WINDOWS\olsrd.conf".
-
-
-                     ***** Interface naming *****
-
-  On Linux network interfaces have nice names like "eth0". In
-  contrast, Windows internally identifies network interfaces by pretty
-  awkward names, for example:
-
-    "{EECD2AB6-C2FC-4826-B92E-CAA53B29D67C}"
-
-  Hence, the Windows version implements its own naming scheme that
-  maps each internal name to a made-up name like "if03", which is
-  easier to memorize. Simply invoke the OLSR server as follows to
-  obtain its view of your interfaces:
-
-    olsrd.exe -int
-
-  This lists the made-up interface names along with their current IP
-  addresses to enable you to find out which made-up interface name
-  corresponds to which of your physical interfaces.
-
-  "+" in front of the IP addresses means that the OLSR server has
-  identified the interface as a WLAN interface. "-" indicates that the
-  OLSR server considers this interface to be a wired interface. "?"
-  means "no idea". Detection currently only works on NT, 2000, and
-  XP. Windows 9x and ME will always display "?".
-
-  For techies: The made-up names consist of the string "if" followed
-  by a two-digit hex representation of the least significant byte of
-  the Windows-internal interface index, which should be different for
-  each interface and thus make each made-up name unique. Again, this
-  is undocumented and this assumption may be wrong in certain
-  cases. So, if the "-int" option reports two interfaces that have the
-  same name, please do let me know.
-
-
-                     ***** Running the GUI *****
-
-  We now have a native Windows GUI. No more GTK+. Simply make sure
-  that "Switch.exe", "Shim.exe", and "olsrd.exe" are located in the
-  same directory and run "Switch.exe". "Shim.exe" is just an auxiliary
-  console application that is required by "Switch.exe".
-
-  The GUI is pretty self-explanatory. The three buttons on the lower
-  right of the GUI window start the OLSR server, stop the OLSR server,
-  and exit the GUI.
-
-  Use the "Settings" tab to specify the options that the GUI uses to
-  run the OLSR server "olsrd.exe". When you click "Start" the GUI
-  generates a temporary configuration file from the information given
-  by the "Settings" tab. This temporary configuration file is passed
-  to the OLSR server via its "-f" option. If you need options that
-  cannot be controlled via the "Settings" tab, simply add them to the
-  "Manual additions" text box as you would add them to a configuration
-  file, e.g. "HNA 192.168.0.0 255.255.255.0". The contents of this
-  text box are appended to the temporary configuration file when it is
-  generated.
-
-  "Offer Internet connection" is only available if you have an
-  Internet connection, i.e. if you have a default route configured. If
-  you tick this option, "HNA 0.0.0.0 0.0.0.0" is added to the
-  temporary configuration file, allowing other nodes in the OLSR
-  network to use your Internet connection.
-
-  Gateway tunnelling and IP version 6 cannot currently be selected, as
-  support for these features is not yet complete in the Windows
-  version.
-
-  The three buttons on the lower right of the "Settings" tab open
-  previously saved settings, save the current settings to a
-  configuration file, and reset the current settings to default
-  values. When opening a saved configuration file, the GUI adds lines
-  that it cannot interpret to the "Manual additions" text box.
-
-  If you start the GUI with the path to a configuration file as the
-  only command line argument, the GUI opens the given configuration
-  file and runs the OLSR server with this configuration. So, saving a
-  configuration file with a ".olsr" extension, for example, and making
-  "Switch.exe" the handler for ".olsr" files enables you to run the
-  OLSR server with a simple double click on the configuration file.
-
-  The "Output" tab shows the output of the currently running OLSR
-  server. When you click "Start" The GUI simply invokes the OLSR
-  server "olsrd.exe" and intercepts its console output. Use the four
-  buttons on the upper right of the tab to freeze the output, resume
-  frozen output, save the output to a file, or clear the output.
-
-  The "Nodes" tab contains information about the nodes that the OLSR
-  server currently knows about. If you click on the address of a node
-  in the "Node list" list box, the GUI populates the three "Node
-  information" list boxes on the right with the multi-point relays of
-  the selected node (MPR), the interfaces of the selected node (MID),
-  and the non-OLSR networks accessible via the selected node (HNA).
-
-  The "Routes" tab shows the routes that the currently running OLSR
-  server has added.
-
-
-                   ***** Running the GTK+ GUI *****
-
-  Please use the native Windows GUI instead. The GTK+ GUI is no longer
-  supported on Windows.
-
-
-                     ***** Missing features *****
-
-  The Windows version currently does not implement the following
-  features known from the Linux release.
-
-    * IPv6.
-
-    * Link layer statistics.
-
-    * Gateway tunnelling. This is currently experimental on
-      Windows. It is intended to work reliably on Windows 2000 and
-      Windows XP in a later version. It is based on the ipinip.sys
-      device driver that comes with these operating systems, but which
-      is completely undocumented. I've figured out how to use the
-      device driver, but it looks like I've still missed one or two
-      little things. So, tunnelling might work on your OS version, but
-      it might as well not work. Unfortunately, currently I do not
-      even know why it works on some systems and fails on other
-      systems.
-
-      If you are brave, do the following, but be prepared for a BSOD
-      (blue screen of death) as a worst-case scenario. This is nothing
-      for the faint of the heart. :-) Never try this on production
-      systems.
-
-        * Start the IP-in-IP tunnel driver before running the OLSR
-          server:
-
-            net start ipinip
-
-        * When the OLSR server reports that the tunnel has been
-          established, find out, which interface index the tunnel
-          device has been assigned:
-
-            route print
-
-        * Let's assume that the interface index is 0x1234 and the
-          gateway's IP address is 1.2.3.4. Manually add a default
-          route through the other end of the tunnel:
-
-            route add 0.0.0.0 mask 0.0.0.0 1.2.3.4 if 0x1234
-
-        * Try to ping somebody beyond the gateway and let me know
-          whether it works. If it doesn't and if you have time, please
-          do a packet dump for me to determine whether IP-in-IP
-          packets are leaving your system and, if yes, what they look
-          like.
-
-      If you know of any freely available tunnel driver for Windows,
-      please let me know. We could then think about switching from the
-      native ipinip.sys driver to an alternative driver, perhaps one
-      that also works on Windows 9x.
-
-      If you are the Microsoft person that is responsible for the
-      tunnel driver, please have a look at my code in
-      src/win32/tunnel.* and tell me what I'm missing.
-
-    * Multiple interfaces in the same subnet. As they all share the
-      same subnet broadcast address, there's no way to tell Windows
-      which of these interfaces to send OLSR packets through. I guess
-      that we'll have to come up with a device driver that sits
-      between the TCP/IP stack and the network adapters and that
-      directs outbound OLSR packets to the correct interface after
-      they've been routed by the TCP/IP stack. Looks like there isn't
-      any other solution on Windows.
-
-  There are also some Windows-specific features that I currently work
-  on, but which have not made it into this release.
-
-    * The option to run the OLSR server as a Windows service on
-      Windows NT, 2000, and XP.
-
-
-                        ***** Compiling *****
-
-  To compile the Windows version of the OLSR server or the dot_draw
-  plugin you need a Cygwin installation with a current version of GCC
-  and Mingw32. Each of the corresponding subdirectories contains a
-  shell script named "mkmf.sh" that takes "Makefile.win32.in" as its
-  input, appends the dependencies, and outputs "Makefile.win32". Then
-  simply say
-
-    make -f Makefile.win32 clean
-
-  to remove any compiled files or
-
-    make -f Makefile.win32 mclean
-
-  to remove any compiled files and the generated makefile. Say
-
-    make -f Makefile.win32
-
-  to compile the source code.
-
-  The GUI has to be compiled with Visual C++ 6. Simply open the
-  "Frontend.dsw" workspace in the Visual C++ 6 IDE. Then compile
-  "Frontend" and "Shim", which creates "Switch.exe" and
-  "Shim.exe". Copy these two executables into the same directory as
-  "olsrd.exe" and you are ready to go.
-
-Well, thanks for using an early release of a piece of software and
-please bear with me if there are any problems. Please do also feel
-free to suggest any features that you'd like to see in future
-releases.
-
-Thomas Lopatic <thomas@lopatic.de>, 2004-09-15
+\r
+                         olsr.org for Windows\r
+                         --------------------\r
+\r
+Welcome to the Windows release of olsr.org. Let's have a quick look at\r
+how this version differs from the original Linux version.\r
+\r
+\r
+                        ***** Stability *****\r
+\r
+  While the Windows version looks pretty stable in basic scenarios, it\r
+  hasn't yet received the extensive testing by the OLSR community that\r
+  the Linux version has gone through. So, if you experience any\r
+  strange behaviour, it's probably my fault. In this case please bear\r
+  with me and use the issue tracker on SourceForge. I'll then do my\r
+  best to find and fix the problem with your assistance. The\r
+  SourceForge homepage for olsrd.org has the following URL.\r
+\r
+                http://sourceforge.net/projects/olsrd/\r
+\r
+\r
+                    ***** Configuration file *****\r
+\r
+  If you do not specify a configuration file, the OLSR server\r
+  ("olsrd.exe") by default attempts to use "olsrd.conf" in your\r
+  Windows directory, e.g. "C:\WINDOWS\olsrd.conf".\r
+\r
+\r
+                     ***** Interface naming *****\r
+\r
+  On Linux network interfaces have nice names like "eth0". In\r
+  contrast, Windows internally identifies network interfaces by pretty\r
+  awkward names, for example:\r
+\r
+    "{EECD2AB6-C2FC-4826-B92E-CAA53B29D67C}"\r
+\r
+  Hence, the Windows version implements its own naming scheme that\r
+  maps each internal name to a made-up name like "if03", which is\r
+  easier to memorize. Simply invoke the OLSR server as follows to\r
+  obtain its view of your interfaces:\r
+\r
+    olsrd.exe -int\r
+\r
+  This lists the made-up interface names along with their current IP\r
+  addresses to enable you to find out which made-up interface name\r
+  corresponds to which of your physical interfaces.\r
+\r
+  "+" in front of the IP addresses means that the OLSR server has\r
+  identified the interface as a WLAN interface. "-" indicates that the\r
+  OLSR server considers this interface to be a wired interface. "?"\r
+  means "no idea". Detection currently only works on NT, 2000, and\r
+  XP. Windows 9x and ME will always display "?".\r
+\r
+  For techies: The made-up names consist of the string "if" followed\r
+  by a two-digit hex representation of the least significant byte of\r
+  the Windows-internal interface index, which should be different for\r
+  each interface and thus make each made-up name unique. Again, this\r
+  is undocumented and this assumption may be wrong in certain\r
+  cases. So, if the "-int" option reports two interfaces that have the\r
+  same name, please do let me know.\r
+\r
+\r
+                     ***** Running the GUI *****\r
+\r
+  We now have a native Windows GUI. No more GTK+. Simply make sure\r
+  that "Switch.exe", "Shim.exe", and "olsrd.exe" are located in the\r
+  same directory and run "Switch.exe". "Shim.exe" is just an auxiliary\r
+  console application that is required by "Switch.exe".\r
+\r
+  The GUI is pretty self-explanatory. The three buttons on the lower\r
+  right of the GUI window start the OLSR server, stop the OLSR server,\r
+  and exit the GUI.\r
+\r
+  Use the "Settings" tab to specify the options that the GUI uses to\r
+  run the OLSR server "olsrd.exe". When you click "Start" the GUI\r
+  generates a temporary configuration file from the information given\r
+  by the "Settings" tab. This temporary configuration file is passed\r
+  to the OLSR server via its "-f" option. If you need options that\r
+  cannot be controlled via the "Settings" tab, simply add them to the\r
+  "Manual additions" text box as you would add them to a configuration\r
+  file, e.g. "HNA 192.168.0.0 255.255.255.0". The contents of this\r
+  text box are appended to the temporary configuration file when it is\r
+  generated.\r
+\r
+  "Offer Internet connection" is only available if you have an\r
+  Internet connection, i.e. if you have a default route configured. If\r
+  you tick this option, "HNA 0.0.0.0 0.0.0.0" is added to the\r
+  temporary configuration file, allowing other nodes in the OLSR\r
+  network to use your Internet connection.\r
+\r
+  Gateway tunnelling and IP version 6 cannot currently be selected, as\r
+  support for these features is not yet complete in the Windows\r
+  version.\r
+\r
+  The three buttons on the lower right of the "Settings" tab open\r
+  previously saved settings, save the current settings to a\r
+  configuration file, and reset the current settings to default\r
+  values. When opening a saved configuration file, the GUI adds lines\r
+  that it cannot interpret to the "Manual additions" text box.\r
+\r
+  If you start the GUI with the path to a configuration file as the\r
+  only command line argument, the GUI opens the given configuration\r
+  file and runs the OLSR server with this configuration. So, saving a\r
+  configuration file with a ".olsr" extension, for example, and making\r
+  "Switch.exe" the handler for ".olsr" files enables you to run the\r
+  OLSR server with a simple double click on the configuration file.\r
+\r
+  The "Output" tab shows the output of the currently running OLSR\r
+  server. When you click "Start" The GUI simply invokes the OLSR\r
+  server "olsrd.exe" and intercepts its console output. Use the four\r
+  buttons on the upper right of the tab to freeze the output, resume\r
+  frozen output, save the output to a file, or clear the output.\r
+\r
+  The "Nodes" tab contains information about the nodes that the OLSR\r
+  server currently knows about. If you click on the address of a node\r
+  in the "Node list" list box, the GUI populates the three "Node\r
+  information" list boxes on the right with the multi-point relays of\r
+  the selected node (MPR), the interfaces of the selected node (MID),\r
+  and the non-OLSR networks accessible via the selected node (HNA).\r
+\r
+  The "Routes" tab shows the routes that the currently running OLSR\r
+  server has added.\r
+\r
+\r
+                   ***** Running the GTK+ GUI *****\r
+\r
+  Please use the native Windows GUI instead. The GTK+ GUI is no longer\r
+  supported on Windows.\r
+\r
+\r
+                     ***** Missing features *****\r
+\r
+  The Windows version currently does not implement the following\r
+  features known from the Linux release.\r
+\r
+    * IPv6.\r
+\r
+    * Link layer statistics.\r
+\r
+    * Gateway tunnelling. This is currently experimental on\r
+      Windows. It is intended to work reliably on Windows 2000 and\r
+      Windows XP in a later version. It is based on the ipinip.sys\r
+      device driver that comes with these operating systems, but which\r
+      is completely undocumented. I've figured out how to use the\r
+      device driver, but it looks like I've still missed one or two\r
+      little things. So, tunnelling might work on your OS version, but\r
+      it might as well not work. Unfortunately, currently I do not\r
+      even know why it works on some systems and fails on other\r
+      systems.\r
+\r
+      If you are brave, do the following, but be prepared for a BSOD\r
+      (blue screen of death) as a worst-case scenario. This is nothing\r
+      for the faint of the heart. :-) Never try this on production\r
+      systems.\r
+\r
+        * Start the IP-in-IP tunnel driver before running the OLSR\r
+          server:\r
+\r
+            net start ipinip\r
+\r
+        * When the OLSR server reports that the tunnel has been\r
+          established, find out, which interface index the tunnel\r
+          device has been assigned:\r
+\r
+            route print\r
+\r
+        * Let's assume that the interface index is 0x1234 and the\r
+          gateway's IP address is 1.2.3.4. Manually add a default\r
+          route through the other end of the tunnel:\r
+\r
+            route add 0.0.0.0 mask 0.0.0.0 1.2.3.4 if 0x1234\r
+\r
+        * Try to ping somebody beyond the gateway and let me know\r
+          whether it works. If it doesn't and if you have time, please\r
+          do a packet dump for me to determine whether IP-in-IP\r
+          packets are leaving your system and, if yes, what they look\r
+          like.\r
+\r
+      If you know of any freely available tunnel driver for Windows,\r
+      please let me know. We could then think about switching from the\r
+      native ipinip.sys driver to an alternative driver, perhaps one\r
+      that also works on Windows 9x.\r
+\r
+      If you are the Microsoft person that is responsible for the\r
+      tunnel driver, please have a look at my code in\r
+      src/win32/tunnel.* and tell me what I'm missing.\r
+\r
+    * Multiple interfaces in the same subnet. As they all share the\r
+      same subnet broadcast address, there's no way to tell Windows\r
+      which of these interfaces to send OLSR packets through. I guess\r
+      that we'll have to come up with a device driver that sits\r
+      between the TCP/IP stack and the network adapters and that\r
+      directs outbound OLSR packets to the correct interface after\r
+      they've been routed by the TCP/IP stack. Looks like there isn't\r
+      any other solution on Windows.\r
+\r
+  There are also some Windows-specific features that I currently work\r
+  on, but which have not made it into this release.\r
+\r
+    * The option to run the OLSR server as a Windows service on\r
+      Windows NT, 2000, and XP.\r
+\r
+\r
+                        ***** Compiling *****\r
+\r
+  To compile the Windows version of the OLSR server or the dot_draw\r
+  plugin you need a Cygwin installation with a current version of GCC\r
+  and Mingw32. Each of the corresponding subdirectories contains a\r
+  shell script named "mkmf.sh" that takes "Makefile.win32.in" as its\r
+  input, appends the dependencies, and outputs "Makefile.win32". Then\r
+  simply say\r
+\r
+    make -f Makefile.win32 clean\r
+\r
+  to remove any compiled files or\r
+\r
+    make -f Makefile.win32 mclean\r
+\r
+  to remove any compiled files and the generated makefile. Say\r
+\r
+    make -f Makefile.win32\r
+\r
+  to compile the source code.\r
+\r
+  The GUI has to be compiled with Visual C++ 6. Simply open the\r
+  "Frontend.dsw" workspace in the Visual C++ 6 IDE. Then compile\r
+  "Frontend" and "Shim", which creates "Switch.exe" and\r
+  "Shim.exe". Copy these two executables into the same directory as\r
+  "olsrd.exe" and you are ready to go.\r
+\r
+Well, thanks for using an early release of a piece of software and\r
+please bear with me if there are any problems. Please do also feel\r
+free to suggest any features that you'd like to see in future\r
+releases.\r
+\r
+Thomas Lopatic <thomas@lopatic.de>, 2004-09-15\r
index 625e56b..7af5c83 100644 (file)
-#
-# UniK OLSR daemon config file
-#
-# This file was shipped with olsrd 0.4.6
-#
-# Lines starting with a # are discarded
-#
-
-# Debug level(0-9)
-# If set to 0 the daemon runs in the background
-
-DEBUG 1
-
-# IP version to use (4 or 6)
-
-IPVERSION 4
-
-# HNA IPv4 routes
-# syntax: netaddr netmask
-# Example Internet gateway:
-# HNA4 0.0.0.0 0.0.0.0
-
-#HNA4 15.15.0.0 255.255.255.0
-
-# HNA IPv6 routes
-# syntax: netaddr prefix
-# Example Internet gateway:
-#HNA6 :: 0
-
-#HNA6 fec0:2200:106:: 48
-
-# A list of whitespace separated interface names
-
-#INTERFACES if02
-
-# Should olsrd keep on running even if there are
-# no interfaces available? This is a good idea
-# for a PCMCIA/USB hotswap environment.
-# "yes" OR "no"
-
-ALLOW_NO_INT yes
-
-# Olsrd plugins to load
-# This must be the absolute path to the file
-# or the loader will use the following scheme:
-# - Try the paths in the LD_LIBRARY_PATH 
-#   environment variable.
-# - The list of libraries cached in /etc/ld.so.cache
-# - /lib, followed by /usr/lib
-#
-# ONE PLUGIN PR. LINE
-
-#LOAD_PLUGIN olsrd_secure.so.0.3
-#LOAD_PLUGIN olsrd_dyn_gw.so.0.1
-#LOAD_PLUGIN olsrd_power.so.0.1
-
-# IPv4 broadcast address to use. The
-# one usefull example would be 255.255.255.255
-# 'auto' uses the broadcastaddress
-# every card is configured with
-
-IP4BROAD auto
-
-# IPv6 address scope to use.
-# Must be 'site-local' or 'global'
-
-IP6ADDRTYPE site-local
-
-# IPv6 multicast address to use when
-# using site-local addresses.
-# 'auto' uses the default ff05::15
-
-IP6MULTI-SITE auto
-
-# IPv6 multicast address to use when
-# using global addresses
-# 'auto' uses the default ff0e::1
-
-IP6MULTI-GLOBAL auto
-
-# Polling rate in seconds(float). 
-# Auto uses default value 0.1 sec
-
-POLLRATE 0.1
-
-# Hello interval in seconds(float)
-# auto uses RFC proposed value
-
-HELLOINT 2.0
-
-# HELLO hold time as a multiplier
-# of the HELLOINT. Auto is the
-# RFC proposed interval
-
-HELLOMULTI 3.0
-
-# TC interval in seconds(float)
-# auto uses RFC proposed value
-
-TCINT 5.0
-
-# TC hold time as a multiplier
-# of the TCINT. Auto is the
-# RFC proposed interval
-
-TCMULTI 3.0
-
-# HELLO interval for sending
-# interval/holding time for wired
-# links. This is a multiplier of
-# the HELLOINT value. Auto is 2
-
-NWHELLOINT 2.0
-
-# HELLO hold time for wired links,
-# as a multiplier of the NWHELLOINT. 
-# Auto is NWHELLOINT * 3.
-
-NWHELLOMULTI 3.0
-
-# MID interval in seconds(float)
-# auto uses RFC proposed value
-
-MIDINT 5.0
-
-# MID hold time as a multiplier
-# of the MIDINT. Auto is the
-# RFC proposed interval
-
-MIDMULTI 3.0
-
-# HNA interval in seconds(float)
-# auto uses 3*TCINT
-
-HNAINT 10.0
-
-# HNA hold time as a multiplier
-# of the HNAINT. Auto is the
-# RFC proposed interval
-
-HNAMULTI 3.0
-
-# TOS(type of service) value for
-# the IP header of control traffic.
-# auto is 16
-
-TOSVALUE auto
-
-# The fixed willingness to use(0-7)
-# or "auto" to set willingness dynammically
-# based on battery/power status
-
-WILLINGNESS auto
-
-# Allow processes like the GUI front-end
-# to connect to the daemon. 'yes' or 'no'
-
-IPC-CONNECT yes
-
-# Wether to use hysteresis or not
-# Hysteresis adds more robustness to the
-# link sensing but delays neighbor registration.
-# Used by default. 'yes' or 'no'
-
-USE_HYSTERESIS yes
-
-# Hysteresis parameters
-# Do not alter these unless you know 
-# what you are doing!
-# Set to auto by default. Allowed
-# values are floating point values
-# in the interval 0,1
-# THR_LOW must always be lower than
-# THR_HIGH!!
-
-HYST_SCALING 0.5
-HYST_THR_HIGH 0.8
-HYST_THR_LOW 0.3
-
-# TC redundancy
-# Specifies how much neighbor info should
-# be sent in TC messages
-# Possible values are:
-# 0 - only send MPR selectors
-# 1 - send MPR selectors and MPRs
-# 2 - send all neighbors
-#
-# auto - defaults to 0
-
-TC_REDUNDANCY auto
-
-#
-# MPR redundancy
-# Specifies how many MPRs a node should
-# try select to reach every 2 hop neighbor
-#
-# Can be set to any integer >0
-#
-# auto - defaults to 1
-
-MPR_COVERAGE auto
+#\r
+# olsr.org config file\r
+#\r
+# This file was shipped with olsr.org 0.4.7\r
+#\r
+# Lines starting with a # are discarded\r
+#\r
+\r
+# Debug level(0-9)\r
+# If set to 0 the daemon runs in the background\r
+\r
+DEBUG 1\r
+\r
+# IP version to use (4 or 6)\r
+\r
+IPVERSION 4\r
+\r
+# HNA IPv4 routes\r
+# syntax: netaddr netmask\r
+# Example Internet gateway:\r
+# HNA4 0.0.0.0 0.0.0.0\r
+\r
+#HNA4 15.15.0.0 255.255.255.0\r
+\r
+# HNA IPv6 routes\r
+# syntax: netaddr prefix\r
+# Example Internet gateway:\r
+#HNA6 :: 0\r
+\r
+#HNA6 fec0:2200:106:: 48\r
+\r
+# A list of whitespace separated interface names\r
+\r
+#INTERFACES if02\r
+\r
+# Should olsrd keep on running even if there are\r
+# no interfaces available? This is a good idea\r
+# for a PCMCIA/USB hotswap environment.\r
+# "yes" OR "no"\r
+\r
+ALLOW_NO_INT yes\r
+\r
+# Olsrd plugins to load\r
+# This must be the absolute path to the file\r
+# or the loader will use the following scheme:\r
+# - Try the paths in the LD_LIBRARY_PATH \r
+#   environment variable.\r
+# - The list of libraries cached in /etc/ld.so.cache\r
+# - /lib, followed by /usr/lib\r
+#\r
+# ONE PLUGIN PR. LINE\r
+\r
+#LOAD_PLUGIN olsrd_secure.so.0.3\r
+#LOAD_PLUGIN olsrd_dyn_gw.so.0.1\r
+#LOAD_PLUGIN olsrd_power.so.0.1\r
+\r
+# IPv4 broadcast address to use. The\r
+# one usefull example would be 255.255.255.255\r
+# 'auto' uses the broadcastaddress\r
+# every card is configured with\r
+\r
+IP4BROAD auto\r
+\r
+# IPv6 address scope to use.\r
+# Must be 'site-local' or 'global'\r
+\r
+IP6ADDRTYPE site-local\r
+\r
+# IPv6 multicast address to use when\r
+# using site-local addresses.\r
+# 'auto' uses the default ff05::15\r
+\r
+IP6MULTI-SITE auto\r
+\r
+# IPv6 multicast address to use when\r
+# using global addresses\r
+# 'auto' uses the default ff0e::1\r
+\r
+IP6MULTI-GLOBAL auto\r
+\r
+# Polling rate in seconds(float). \r
+# Auto uses default value 0.1 sec\r
+\r
+POLLRATE 0.1\r
+\r
+# Hello interval in seconds(float)\r
+# auto uses RFC proposed value\r
+\r
+HELLOINT 2.0\r
+\r
+# HELLO hold time as a multiplier\r
+# of the HELLOINT. Auto is the\r
+# RFC proposed interval\r
+\r
+HELLOMULTI 3.0\r
+\r
+# TC interval in seconds(float)\r
+# auto uses RFC proposed value\r
+\r
+TCINT 5.0\r
+\r
+# TC hold time as a multiplier\r
+# of the TCINT. Auto is the\r
+# RFC proposed interval\r
+\r
+TCMULTI 3.0\r
+\r
+# HELLO interval for sending\r
+# interval/holding time for wired\r
+# links. This is a multiplier of\r
+# the HELLOINT value. Auto is 2\r
+\r
+NWHELLOINT 2.0\r
+\r
+# HELLO hold time for wired links,\r
+# as a multiplier of the NWHELLOINT. \r
+# Auto is NWHELLOINT * 3.\r
+\r
+NWHELLOMULTI 3.0\r
+\r
+# MID interval in seconds(float)\r
+# auto uses RFC proposed value\r
+\r
+MIDINT 5.0\r
+\r
+# MID hold time as a multiplier\r
+# of the MIDINT. Auto is the\r
+# RFC proposed interval\r
+\r
+MIDMULTI 3.0\r
+\r
+# HNA interval in seconds(float)\r
+# auto uses 3*TCINT\r
+\r
+HNAINT 10.0\r
+\r
+# HNA hold time as a multiplier\r
+# of the HNAINT. Auto is the\r
+# RFC proposed interval\r
+\r
+HNAMULTI 3.0\r
+\r
+# TOS(type of service) value for\r
+# the IP header of control traffic.\r
+# auto is 16\r
+\r
+TOSVALUE auto\r
+\r
+# The fixed willingness to use(0-7)\r
+# or "auto" to set willingness dynammically\r
+# based on battery/power status\r
+\r
+WILLINGNESS auto\r
+\r
+# Allow processes like the GUI front-end\r
+# to connect to the daemon. 'yes' or 'no'\r
+\r
+IPC-CONNECT yes\r
+\r
+# Wether to use hysteresis or not\r
+# Hysteresis adds more robustness to the\r
+# link sensing but delays neighbor registration.\r
+# Used by default. 'yes' or 'no'\r
+\r
+USE_HYSTERESIS yes\r
+\r
+# Hysteresis parameters\r
+# Do not alter these unless you know \r
+# what you are doing!\r
+# Set to auto by default. Allowed\r
+# values are floating point values\r
+# in the interval 0,1\r
+# THR_LOW must always be lower than\r
+# THR_HIGH!!\r
+\r
+HYST_SCALING 0.5\r
+HYST_THR_HIGH 0.8\r
+HYST_THR_LOW 0.3\r
+\r
+# TC redundancy\r
+# Specifies how much neighbor info should\r
+# be sent in TC messages\r
+# Possible values are:\r
+# 0 - only send MPR selectors\r
+# 1 - send MPR selectors and MPRs\r
+# 2 - send all neighbors\r
+#\r
+# auto - defaults to 0\r
+\r
+TC_REDUNDANCY auto\r
+\r
+#\r
+# MPR redundancy\r
+# Specifies how many MPRs a node should\r
+# try select to reach every 2 hop neighbor\r
+#\r
+# Can be set to any integer >0\r
+#\r
+# auto - defaults to 1\r
+\r
+MPR_COVERAGE auto\r