PUD: use dopMultiplier plugin parameter
[olsrd.git] / README-Olsr-Extensions
index 3cef2be..195c6a5 100644 (file)
@@ -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 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.
 
 
@@ -44,7 +44,7 @@ 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.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)
@@ -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.
 
+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).
@@ -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.
 
-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)
@@ -216,7 +220,7 @@ More information on NIIT can be found at: http://wiki.freifunk.net/Niit
     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
 the way to the gateway. OLSRd 0.6.0 can create an IPIP tunnel
@@ -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"
-(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
@@ -269,6 +273,58 @@ 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
+
+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
 ************************
@@ -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.
 
-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 +364,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