Android: Fixed missing plugin-help functions, added some hints on compiling
[olsrd.git] / README-Olsr-Extensions
index 62846e6..3eaef92 100644 (file)
@@ -1,6 +1,6 @@
-=======================================================
-      OLSRd (version 0.5.7.0) protocol extensions
-=======================================================
+=====================================================
+      OLSRd (version 0.6.0) protocol extensions
+=====================================================
 
 1.) Credits
 2.) Link quality algorithms
@@ -42,9 +42,9 @@ Concept:
 OLSRd (since version 0.5.6) use a dimensionless integer value for a
 representation of the 'cost' of each link. This is often called Link quality
 (LQ for short). There are multiple LQ-Plugins, each of them calculating a cost
-for the links of the router. At the moment (version 0.5.7.0) all lq_plugins are
+for the links of the router. At the moment (version 0.6.0) all lq_plugins are
 using an ETX-metric (expected transmission count) but others would be possible
-and imaginable, such as MIC [0], WCETT [1], etc.
+and imaginable, such as MIC [0], etc.
 
 
 Each link is described by a LQ (link quality) and a NLQ (neighbor link quality)
@@ -80,7 +80,7 @@ link quality algorithm in the config file. Some embedded OLSRd versions
 are only compiled with one plugin (mostly etx_ff), so don't use the
 configuration option with these agents.
 
-There are four different link quality algorithms in OLSRd 0.5.7.0, two
+There are four different link quality algorithms in OLSRd 0.6.0, two
 current Funkfeuer/Freifunk ETX implementations and two legacy implementations.
 
 LinkQuality-Algorithm "etx_ff":
@@ -168,7 +168,7 @@ meshs with hundreds of routers. Reducing the rate of TCs can reduce
 this overhead, but delay route changes and correction of errors
 in the routing tables.
 
-The Fisheye (sometimes called Hazy Sighted Link State Routing [2])
+The Fisheye (sometimes called Hazy Sighted Link State Routing [1])
 mechanism implements a strategy to reach a compromise between
 these two problems. When activated only every 8th TC is send
 to all mesh nodes. Most TCs are given a reduced TTL (time to live)
@@ -189,7 +189,7 @@ for most larger Funkfeuer/Freifunk meshs.
 (see https://dev.dd19.de/cgi-bin/gitweb.cgi?p=niit.git;a=summary)
 
 NIIT is a special linux kernel device that allows easy transmission of IPv4
-unicast traffic through an IPv6 network. Since version 0.5.7.0 OLSRd has
+unicast traffic through an IPv6 network. Since version 0.6.0 OLSRd has
 integrated support for NIIT in the routing daemon. So setting up IPv4 traffic
 over IPv6 OLSR meshs is very easy. Instead of creating routes and tunnels by
 hand all the administrator of a router needs to do is to, is to set up his own
@@ -219,7 +219,7 @@ More information on NIIT can be found at: http://wiki.freifunk.net/Niit
 The smartgateway mechanism was written by Markus Kittenberg and
 Henning Rogge to allow an OLSR user to directly choose their default
 internet gateway instead of relying on the hop by hop decisions on
-the way to the gateway. OLSRd 0.5.7.0 can create an IPIP tunnel
+the way to the gateway. OLSRd 0.6.0 can create an IPIP tunnel
 to the gateways OLSRd address to sidestep the same nasty effects
 described in the Nat-Threshold section.
 
@@ -269,6 +269,45 @@ SmartGatewayUplinkNAT <yes/no>
 SmartGatewaySpeed <uplink> <downlink>
 SmartGatewayPrefix <prefix>
 
+On the SmartGW server (the OLSR instance anncouning 'Internet here!' via
+HNA0/0 or similar) the implicit tunl0 interface is used to forward  incoming 
+packets originated by SmartGW clients to the internet route. This may be 
+protected by the sysctl rp_filter setting. Note, that at least with RedHat kernel 
+2.6.18, the net.ipv4.conf.tunl0.rp_filter sysctl file is not present after 
+loading the "ipip" kernel module. Which prevents OLSRD from switching off the 
+filter. As a workaround, add an "ip addr add 0.0.0.0/32 dev tunl0" after 
+the "modprobe ipip" line in your OLSRD startup script. 
+
+While the SmartGW function does a fine job on stand-alone PCs, system builders 
+should keep in mind the following facts when setting up routing, firewalls 
+and gateways:
+
+a) The SmartGW tunnel communicates asymmetrically. An IP packet destinned to 
+an Internet server is sent via the IPIP tunnel but returned via the standard 
+OLSRD host route.
+
+b) On the SmartGW server, you should double check your firewall rules and 
+rp_filter defaults. While it's normally not possible to simply encap e.g. 
+a "telnet 127.0.0.1" into IPIP and sent that to the SmartGW server, your 
+specific configuration may open up other attack vectors for an intruder.
+
+c) Do not forget to un-firewall tunl0->internet and (if required to 
+NAT/MASQUERADE) this communication path.
+
+d) While the SmartGW server does not use special routing, the SmartGW client
+inserts policy routing rules for it's function. By using the default configuration,
+the OLSRD standard default route is maintained in table 223 and the OLSRD SmartGW 
+default route in table 224. Both tables are examined only, if you do not have
+a default route in the main table (visible with "ip route ls"). Use "ip route ls
+table 223" or "ip route ls table 224" for debugging/monitoring. You may also
+activate the txtinfo plugin and "wget -O - http://localhost:2006/gateway".
+
+e) For the stand-alone client (Notebook user running OLSRD in order to browse) 
+the lowered IPIP tunnel MTU is no problem. If you do proxy routing, e.g. for 
+attached LAN clients without OLSRD, you may want MSS-clamping for the tunnel 
+interface created by OLSRD. Because OLSRD uses an arbitrary name for the tunnel
+iface (e.g. tnl_7c41c668) you may want to include a wildcard iptables rule. Example:
+iptables -A FORWARD -o tnl_+ -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
 
     6.) NatThreshold
 ************************
@@ -300,7 +339,7 @@ Fisheye can lead to  persistent routing loops.
 Please note that even with NatThreshold enabled, some users will still experience
 gateway switching. However, most users will not.
 
-Smart Gateways can replace NatThreshold alltogether because they allow sending
+Smart Gateways can replace NatThreshold all together because they allow sending
 traffic directly to a gateway circumventing the problems described above which
 stem from a hop-by-hop routing approach 
 
@@ -308,16 +347,10 @@ stem from a hop-by-hop routing approach
 
      7.) References
 ************************
- [0] MIC Metric: "Designing Routing Metrics for Mesh Networks", 
+[0] MIC Metric: "Designing Routing Metrics for Mesh Networks", 
        Yaling Yang, Jun Wang, Robin Kravets
        http://www.cs.ucdavis.edu/~prasant/WIMESH/p6.pdf
 
-  [1] WCETT Metric: Weighted Cumulative Expected Transmission Time,
-       "Routing in Multi-Radio, Multi-Hop Wireless Mesh Networks"
-       Authors: Richard Draves, Jitendra Padhye, Brian Zill
-       Published: MobiCom 2004
-       http://research.microsoft.com/apps/pubs/default.aspx?id=73099
-       
-  [2] "Making link-state routing scale for ad hoc networks",
+[1] "Making link-state routing scale for ad hoc networks",
        Cesar A. Santivanez, Ram Ramanathan, Ioannis Stavrakakis
        http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.16.5940