dyn_gw: add uninstall target
[olsrd.git] / README-Olsr-Extensions
index 62846e6..195c6a5 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
 
 1.) Credits
 2.) Link quality algorithms
@@ -28,7 +28,7 @@ The LQ-Plugin rewrite was done by Henning Rogge in 2008.
 
 The NIIT kernel module was written by lynxis in 2009.
 
 
 The NIIT kernel module was written by lynxis in 2009.
 
-The asymmetric gateway tunnels was written by Markus Kittenberg
+The asymmetric gateway tunnels was written by Markus Kittenberger
 and Henning Rogge, but the concept was used by B.A.T.M.A.N before OLSRd.
 
 
 and Henning Rogge, but the concept was used by B.A.T.M.A.N before OLSRd.
 
 
@@ -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
 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
 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)
 
 
 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.
 
 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":
 current Funkfeuer/Freifunk ETX implementations and two legacy implementations.
 
 LinkQuality-Algorithm "etx_ff":
@@ -120,6 +120,10 @@ implementations detect etx_ffeth nodes with LQ 0 (ETX infinite).
 etx_ffeth only use integer arithmetic, so it performs well on embedded
 hardware.
 
 etx_ffeth only use integer arithmetic, so it performs well on embedded
 hardware.
 
+All ethernet interfaces must be marked with "mode ether" 
+(see olsrd.conf.default.full) in their interface configuration to get any
+useful advantage of etxff_eth.
+
 At the time of this writing, etx_ffeth is the prefered metric for building new
 mesh networks which include links over LAN cables (such as daisy chained
 linksys routers).
 At the time of this writing, etx_ffeth is the prefered metric for building new
 mesh networks which include links over LAN cables (such as daisy chained
 linksys routers).
@@ -168,7 +172,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.
 
 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)
 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 +193,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
 (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
 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
@@ -216,10 +220,10 @@ More information on NIIT can be found at: http://wiki.freifunk.net/Niit
     5.) Smart gateways (asymmetric gateway tunnels)
 *******************************************************
 
     5.) Smart gateways (asymmetric gateway tunnels)
 *******************************************************
 
-The smartgateway mechanism was written by Markus Kittenberg and
+The smartgateway mechanism was written by Markus Kittenberger 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
 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.
 
 to the gateways OLSRd address to sidestep the same nasty effects
 described in the Nat-Threshold section.
 
@@ -238,7 +242,7 @@ switched on/off by the following parameter:
 SmartGateway <yes/no>
 
 All other parameters will be ignored if SmartGateway is set to "no"
 SmartGateway <yes/no>
 
 All other parameters will be ignored if SmartGateway is set to "no"
-(the default is "yes").
+(the default is "no").
 
 On the client side there is a single additional parameter which
 controls if you want to allow the selection of an outgoing ipv4
 
 On the client side there is a single additional parameter which
 controls if you want to allow the selection of an outgoing ipv4
@@ -269,6 +273,58 @@ SmartGatewayUplinkNAT <yes/no>
 SmartGatewaySpeed <uplink> <downlink>
 SmartGatewayPrefix <prefix>
 
 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
+
+Furthermore (or alternatively) you might consider to clamp all traffic to your ipip mtu
+on your gateway nodes that is leaving your mesh. (regardless if the traffic comes out 
+of the smartgateway tunnel or not!)
+iptables -A FORWARD -o [your_gateway_interface] -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1480
+
+Especially as during olsrd startup, before an smartgateway is choosen (which is delayed), 
+new connections would use a larger MSS as the smartgateway tunnel can handle. 
+So the approach to clamp on the gateways should give better results.
+
+But if you don't NAT on your gateways (but want to use SmartGateway for some some 
+special reason), you would have to do this on ALL gateways (Even on gateways that 
+do not provide the SmartGateway functionality!)
 
     6.) NatThreshold
 ************************
 
     6.) NatThreshold
 ************************
@@ -300,7 +356,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.
 
 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 
 
 traffic directly to a gateway circumventing the problems described above which
 stem from a hop-by-hop routing approach 
 
@@ -308,16 +364,10 @@ stem from a hop-by-hop routing approach
 
      7.) References
 ************************
 
      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
 
        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
        Cesar A. Santivanez, Ram Ramanathan, Ioannis Stavrakakis
        http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.16.5940