Repository : ssh://git@diktynna/doc
On branches: backup-redmine/2020-08-16,master
commit 692138343ec89f5fba98c7bfdd9424b41731a42a Author: Sven Eckelmann sven@narfation.org Date: Sun Aug 16 23:40:17 2020 +0200
doc: Drop outdated pages
692138343ec89f5fba98c7bfdd9424b41731a42a ...Batman-adv-openwrt-config-sophisticated.textile | 208 --------------------- batman-adv/Batman-adv-openwrt-config.textile | 53 +----- batman-adv/ELP.textile | 3 +- .../Multi-link-optimizations-technical.textile | 80 -------- batman-adv/Multi-link-optimize-old.textile | 39 ---- .../Network-wide-multi-link-optimization.textile | 2 +- batman-adv/interface_detection.dia | Bin 1723 -> 0 bytes batman-adv/interface_detection.dia.jpg | Bin 22506 -> 0 bytes batman-adv/primary_flag.dia | Bin 1548 -> 0 bytes batman-adv/primary_flag.png | Bin 16010 -> 0 bytes open-mesh/FFTrace.textile | 11 -- open-mesh/MeshLinux.textile | 7 - open-mesh/NetworkingTechnologies.textile | 33 ---- 13 files changed, 3 insertions(+), 433 deletions(-)
diff --git a/batman-adv/Batman-adv-openwrt-config-sophisticated.textile b/batman-adv/Batman-adv-openwrt-config-sophisticated.textile deleted file mode 100644 index 65dd874..0000000 --- a/batman-adv/Batman-adv-openwrt-config-sophisticated.textile +++ /dev/null @@ -1,208 +0,0 @@ -{{include(open-mesh:TemplateDeprecated)}} - -h1. Example B.A.T.M.A.N. configuration snippets on OpenWRT - -*Note*: The script below was written for batman-adv 2012.4.0 and older. With batman-adv 2013.0.0 came a new syntax as explained [[Batman-adv-openwrt-config|here]]. - -h2. 3-radio mesh-node, with one open VAP for roaming clients access, and another with WPA - -You should run the script inside the OpenWRT host, assuming: -* batman-adv is compiled in, or installed (opkg install kmod-batman-adv). -* your uci config resembles a vanilla OpenWRT (no esoteric setups done yet) -* all radios are connected -* drivers for all radios are compiled in or installed (ex. opkg install kmod-ath9k-htc) -* all your radios/drivers support adhoc mode properly (unfortunately most USB don't, as of May 2012) -* main radio (radio0) supports multiple, mixed VAPs (adhoc and ap) - -You can use this configuration (run this script) on a node with just 1 (or 2) radio(s) too, but you'll experience bandwidth degradation when passing through that point. - -<pre> -#!/bin/sh - -### Main radio0 will broadcast one AP with no encryption, another AP with WPA2, -### and both interfaces will be bridged together with eth0 and bat0 -### Another VAP in adhoc mode is added to main radio0, -### as well as adhoc networks in radio1 and radio2 if they are present. -### All three adhoc networks are added to bat0 and thus managed by batman-adv - -### Node-specific settings -export HOSTNAME="meshnodeX" -export IP="10.x.x.x" -export WPA_ESSID="$HOSTNAME.wpa" -export WPA_KEY="password" - -### These parameters should be consistent across all nodes -export NETMASK="255.0.0.0" -export DNS="" -export GATEWAY="" -export PUBLIC_ESSID="3radio.mesh" -export MESH0_BSSID="CA:CA:CA:CA:CA:00" -export MESH0_ESSID="mesh0" -export MESH0_CHANNEL="1" -export MESH1_MODE="adhoc" -export MESH1_BSSID="CA:CA:CA:CA:CA:01" -export MESH1_ESSID="mesh1" -export MESH1_CHANNEL="11" -export MESH2_MODE="adhoc" -export MESH2_BSSID="CA:CA:CA:CA:CA:02" -export MESH2_ESSID="mesh2" -export MESH2_CHANNEL="6" - -### Ensure of populating /etc/config/wireless with -### autodetected wifi-device entries (radioX) -### to get all list_capab and hwmode correct. Otherwise -### OpenWRT might fail to configure the radio properly. -wifi detect >>/etc/config/wireless - -### Clear preexisting wifi-iface sections to avoid conflicts or dups -( for i in `seq 0 9` ; do echo "delete wireless.@wifi-iface[]" ; done ) | uci batch -q - -### Create /etc/config/batman-adv if it's not there yet. -uci import -m batman-adv </dev/null - -echo " -set system.@system[0].hostname=$HOSTNAME - -set batman-adv.bat0=mesh -set batman-adv.bat0.interfaces='mesh0 mesh1 mesh2' - -set network.lan.ipaddr=$IP -set network.lan.netmask=$NETMASK -set network.lan.dns='$DNS' -set network.lan.gateway=$GATEWAY -set network.lan.ifname='eth0 bat0' -set network.bat0=interface -set network.bat0.ifname=bat0 -set network.bat0.proto=none -set network.bat0.mtu=1500 -set network.mesh0=interface -set network.mesh0.proto=none -set network.mesh0.mtu=1528 -set network.mesh1=interface -set network.mesh1.proto=none -set network.mesh1.mtu=1528 -set network.mesh2=interface -set network.mesh2.proto=none -set network.mesh2.mtu=1528 - -set wireless.radio0=wifi-device -set wireless.radio0.channel=$MESH0_CHANNEL -set wireless.radio0.disabled=0 -set wireless.radio0.phy=phy0 -set wireless.radio0.macaddr= - -set wireless.radio1=wifi-device -set wireless.radio1.channel=$MESH1_CHANNEL -set wireless.radio1.disabled=0 -set wireless.radio1.phy=phy1 -set wireless.radio1.macaddr= - -set wireless.radio2=wifi-device -set wireless.radio2.channel=$MESH2_CHANNEL -set wireless.radio2.disabled=0 -set wireless.radio2.phy=phy2 -set wireless.radio2.macaddr= - -add wireless wifi-iface -set wireless.@wifi-iface[-1].device=radio0 -set wireless.@wifi-iface[-1].encryption=none -set wireless.@wifi-iface[-1].network=lan -set wireless.@wifi-iface[-1].mode=ap -set wireless.@wifi-iface[-1].ssid='$PUBLIC_ESSID' - -add wireless wifi-iface -set wireless.@wifi-iface[-1].device=radio0 -set wireless.@wifi-iface[-1].encryption=psk2 -set wireless.@wifi-iface[-1].key='$WPA_KEY' -set wireless.@wifi-iface[-1].network=lan -set wireless.@wifi-iface[-1].mode=ap -set wireless.@wifi-iface[-1].ssid='$WPA_ESSID' - -add wireless wifi-iface -set wireless.@wifi-iface[-1].device=radio0 -set wireless.@wifi-iface[-1].encryption=none -set wireless.@wifi-iface[-1].network=mesh0 -set wireless.@wifi-iface[-1].mode=adhoc -set wireless.@wifi-iface[-1].bssid=$MESH0_BSSID -set wireless.@wifi-iface[-1].ssid='$MESH0_ESSID' -set wireless.@wifi-iface[-1].mcast_rate=11000 - -add wireless wifi-iface -set wireless.@wifi-iface[-1].device=radio1 -set wireless.@wifi-iface[-1].encryption=none -set wireless.@wifi-iface[-1].network=mesh1 -set wireless.@wifi-iface[-1].mode=$MESH1_MODE -set wireless.@wifi-iface[-1].bssid=$MESH1_BSSID -set wireless.@wifi-iface[-1].ssid='$MESH1_ESSID' -set wireless.@wifi-iface[-1].mcast_rate=11000 - -add wireless wifi-iface -set wireless.@wifi-iface[-1].device=radio2 -set wireless.@wifi-iface[-1].encryption=none -set wireless.@wifi-iface[-1].network=mesh2 -set wireless.@wifi-iface[-1].mode=$MESH2_MODE -set wireless.@wifi-iface[-1].bssid=$MESH2_BSSID -set wireless.@wifi-iface[-1].ssid='$MESH2_ESSID' -set wireless.@wifi-iface[-1].mcast_rate=11000 -commit" \ -| uci batch - -</pre> - -h3. What if radio1 and/or radio2 don't support adhoc mode properly? - -If the driver is buggy, unstable, or throughput is lower in adhoc mode, you can fallback to using an ap/client design, at the cost of redundancy. - -simply customize the MESHx_ parameters on a per-node basis: -<pre> -### Relative physical location: node1 <--ch6--> node2 <--ch11--> node3 - -# On node1 -export MESH1_MODE="client" -export MESH1_BSSID="" -export MESH1_ESSID="node2.ptp-channel6" -export MESH1_CHANNEL="6" - -# On node2 -export MESH1_MODE="ap" -export MESH1_BSSID="" -export MESH1_ESSID="node2.ptp-channel6" -export MESH1_CHANNEL="6" -export MESH2_MODE="client" -export MESH2_BSSID="" -export MESH2_ESSID="node3.ptp-channel11" -export MESH2_CHANNEL="11" - -# On node3 -export MESH1_MODE="ap" -export MESH1_BSSID="" -export MESH1_ESSID="node3.ptp-channel11" -export MESH1_CHANNEL="11" -</pre> - -h3. I like the script but I don't need/want an extra VAP with WPA2, how can I disable it? - -Just remove or comment out the corresponding section -<pre> -#add wireless wifi-iface -#set wireless.@wifi-iface[-1].device=radio0 -#set wireless.@wifi-iface[-1].encryption=psk2 -#set wireless.@wifi-iface[-1].key='$WPA_KEY' -#set wireless.@wifi-iface[-1].network=lan -#set wireless.@wifi-iface[-1].mode=ap -#set wireless.@wifi-iface[-1].ssid='$WPA_ESSID' -</pre> - -h3. What if I am running batman-adv 2013.0.0 or later ? - -Modify the bat0 and mesh0 networks to be as follows -<pre> -set network.bat0=interface -set network.bat0.ifname=bat0 -set network.bat0.proto=none -set network.bat0.mtu=1528 -set network.mesh0=interface -set network.mesh0.proto=batadv -set network.mesh0.mtu=1528 -set network.mesh0.mesh=bat0 -</pre> \ No newline at end of file diff --git a/batman-adv/Batman-adv-openwrt-config.textile b/batman-adv/Batman-adv-openwrt-config.textile index 9e935b5..9cf3b72 100644 --- a/batman-adv/Batman-adv-openwrt-config.textile +++ b/batman-adv/Batman-adv-openwrt-config.textile @@ -124,9 +124,7 @@ config interface 'my_bat_vlan1'
Any VLAN specific option can still be listed in the batadv meshif configuration for 'bat0' and in that case they will affect the behaviour only for the plain mesh interface (i.e. bat0 - the untagged LAN).
-h2. Batman-adv 2013.0.0 till 2019.0-2 - -With batman-adv 2013.0.0 the OpenWrt package was converted to integrate with OpenWrt's netifd system. This has some impact on the configuration but not much. +h2. Batman-adv 2019.0-2 and older
The wireless configuration in '/etc/config/wireless': <pre> @@ -199,52 +197,3 @@ config interface 'bat0_hardif_wlan' option mesh 'bat0' option routing_algo 'BATMAN_V' </pre> \ No newline at end of file - -h2. Batman-adv 2012.4.0 and older - -The wifi interface needs to be configured in '/etc/config/wireless': -<pre> -config wifi-device 'radio0' - option [..] - -config wifi-iface 'wmesh' - option device 'radio0' - option ifname 'adhoc0' - option network 'bat0_hardif_wlan' - option mode 'adhoc' - option ssid 'mesh' - option 'mcast_rate' '18000' - option bssid '02:CA:FE:CA:CA:40' -</pre> - -It is assumed you configured the 'wifi-device' depending on your requirements and your hardware. The interesting part is the 'wifi-iface' stanza with its options: - -* 'device' points back to your radio (wifi-device) interface -* 'ifname' allows you to specify an arbitrary name for your adhoc interface (which we are going to re-use later) -* 'network' points to the corresponding stanza in '/etc/config/network' -* 'mode' defines the wifi mode (adhoc in our case) -* 'mcast_rate' helps to avoid low bandwidth routes (routes with a lower throughput rate than the mcast rate will not be visible to batman-adv) -* 'ssid' and 'bssid' are basic wireless settings you might want to set to your liking - -More information can be found in the "OpenWrt wireless configuration":https://wiki.openwrt.org/doc/uci/wireless - -Configure the MTU in '/etc/config/network' -<pre> -config interface 'bat0_hardif_wlan' - option ifname 'adhoc0' - option mtu '1528' - option proto 'none' -</pre> - -The stanza's name 'mesh' as well as the ifname option have to match your wireless configuration. - -Batman-adv is configured through its own configuration in '/etc/config/batman-adv': -<pre> -config mesh 'bat0' - option interfaces 'adhoc0' - option 'aggregated_ogms' - option 'ap_isolation' - option [..] -</pre> - -The 'interfaces' option is the key element here, as it tells batman-adv which interface(s) to run on. All the other options enable / disable / tweak all the batman-adv features you can also access at runtime through batctl. \ No newline at end of file diff --git a/batman-adv/ELP.textile b/batman-adv/ELP.textile index 66b1c94..c4db231 100644 --- a/batman-adv/ELP.textile +++ b/batman-adv/ELP.textile @@ -1,8 +1,7 @@ -h1. This page is OUTDATED! +{{include(open-mesh:TemplateDeprecated)}}
This page is not in sync with the actual implementation. Neither the packet format matches nor the use as unicast probe frames is explained.
- h1. Echo Location Protocol (ELP)
!https://upload.wikimedia.org/wikipedia/commons/e/e1/Animal_echolocation.svg!... diff --git a/batman-adv/Multi-link-optimizations-technical.textile b/batman-adv/Multi-link-optimizations-technical.textile deleted file mode 100644 index ee7cc48..0000000 --- a/batman-adv/Multi-link-optimizations-technical.textile +++ /dev/null @@ -1,80 +0,0 @@ -h1. This page is OUTDATED! - -This page was superseded with an update for the feature, [[Network-wide-multi-link-optimization|documentered here]] - -h1. Multi-link Optimizations (technical documentation) - -Mesh nodes with multiple physical links to other mesh nodes can use this capability to gain various benefits, for example: - -* bonding: use multiple links for the same data stream to boost bandwidth -* interface alternating: send on other interfaces (and therefore other channels, if configured correctly) to minimize multi-hop bandwidth degradation - -These features operate under the following premises: - -* multiple links exist between two neighbors -* the routing decision is independent of the link a packet is received on - -Notably, these multi-interface features are independent of B.A.T.M.A.N. and could work with any routing algorithm/metric. The routing software only needs to detect that multiple peers belong to the same neighbor mesh node. This is also not related to Multi-Path Routing, which would require multiple independent links. - -The multi-link optimization procedure can be broken into these steps: - -# detect that a neighbor is reachable via multiple links -# select suitable candidates among the the available links -# use these multiple links for various manipulations - -h2. Link detection - -The detection part is specific to batman-adv. To understand how the link detection works it is necessary to recall how batman-adv handles multiple interfaces: - -The MAC address (Originator address) of the primary interface (usually the first added interface) is known throughout the mesh as OGMs containing the MAC address are broadcasted on all available interfaces with a big TTL. This ensures mesh nodes only reachable via secondary interfaces will know about this node. All remaining interfaces are "secondary" interfaces which are only known in the single hop neighborhood. The OGMs containing their MAC addresses are broadcasted with a small TTL on the respective interface only. These secondary OGMs uniquely serve the purpose of detecting local neighbors and estimate the link quality towards them. - -+Note+: It does not matter which interface is the primary interface, it is only used to have a single Originator known in the mesh, thus avoiding OGM overhead. - -To detect whether or not a neighbor has multiple links towards a node it suffices to analyze the incoming primary OGM. If the primary OGM is received via multiple interfaces a node can (almost) safely assume having multiple links towards its Originator. However, the OGM protocol demands to forward all incoming OGMs for the path detection which could confuse the multi-link detection because it has to distinguish single hop neighbors from neighbors that are further away. To resolve the issue the PRIMARIES_FIRST_HOP flag was introduced. Only primary OGMs are allowed to carry it and every node removes the flag before rebroadcasting the OGM. - -!primary_flag.png! - -In the illustration, A receives the OGM via A1 (sent out by B1) and A2 (sent out by B2) - and detects that these two Links A1-B1, A2-B2 exist. These link candidates are stored and further filtered - -h2. Candidate selection - -To be usable for the target features, the links must have a similar quality and should operate on a different frequency. Therefore, in batman-adv only links are further considered if: - -* the link quality is not much worse than the best link within a certain TQ threshold (now: 50) -* the link destination is different from the other already selected candidates - e.g. if A1-B1 was selected, A2-B1 would be forbidden as they would operate on the same frequency and therefore would interfere with each other - -In the illustration below, A1-B1 and A2-B2 meet this criteria and are therefore selected as candidates. - -!interface_detection.dia.jpg! - -Implementation note: Detected links are internally stored within the originator structure of the primary originator. The candidates are internally called "bonding candidates" - -h2. Using the candidates - -Once a neighbor mesh node has been selected by the classic routing algorithm, the individual links can now be equally be selected to send data to the next neighbor without tampering with routing. Possible mechanisms exploiting this fact are described below. - -More Info can be found in the [[multi-link-optimize|Multi-Link Optimization]] feature description page. - -Implementation note: the manipulations are hooked in the tx path when selecting a neighbor in find_router() - -h3. Interface Alternating - -Interface Alternating basically tries to forward a packet on another interface than on which the frame was received. This is only done if suitable candidate with another source interface exists. - -!alternation_chain.dia.jpg! - -This feature is always enabled. - -h3. Bonding - -In bonding, we split a single stream and distribute the packets over multiple links. Packets are sent in a round-robin fashion over the available candidates. This can be used to increase the throughput for data streams from node A to node B. In a perfect environment the throughput is n times higher, where n is the number of candidates. - -!bonding_roundrobin.dia.jpg! - -Practice shows however that the theoretical bandwidth gain is not reached - even if the links are physically disjoint. E.g. using a 2.4 GHz and a 5 GHz with a modulation of 54 Mbit/s both has shown to gain 150% bandwith boost over a single link, not 200% as expected in theory. Possible reasons may be the packet reordering and slightly different queue load caused by random backoffs, retries, etc. For these reasons, bonding must be enabled explicitly. - -h2. Discussion and further work - -As explained, the bonding mode stays behind the theoretical expectations. The packet loss based TQ metric is also not optimal for selecting bonding candidates - a bandwidth based metric would be more suitable for this task, as slow links will slow down the whole aggregated connection. - -These shortcomings would be subject to further improvements of this featureset. \ No newline at end of file diff --git a/batman-adv/Multi-link-optimize-old.textile b/batman-adv/Multi-link-optimize-old.textile deleted file mode 100644 index c5e1254..0000000 --- a/batman-adv/Multi-link-optimize-old.textile +++ /dev/null @@ -1,39 +0,0 @@ -h1. This page is OUTDATED! - -This page was superseded with an update for the feature, [[Multi-link-optimize|documentered here]] - -h1. Multi-link Optimizations - -batman-adv is able to work on different interfaces - multiple WiFi interfaces, but also Ethernet interfaces. If two or more nodes are interconnected through batman-adv on multiple interfaces, they may leverage some features to increase throughput, which are explained here. - -For more technical information, please see our [[multi-link-optimizations-technical|technical multi-link documentation]] - -h2. Interface alternating - -With Interface alternating, batman-adv forwards frames on a different interface than on which the frame was received. The purpose of this alternation is to reduce interference (we can either send or receive on a WiFi interface at one time) and to balance the network load better on the available interfaces, and eventually increases throughput. The mechanism is illustrated below for a chain of nodes with two interfaces. - -!alternation_chain.dia.jpg! - -Interface alternating is only performed if the two candidate links to the next hop have a similar quality. This feature is enabled by default and does not have to be enabled manually. - -h2. Interface bonding - -When multiple links (with similar transmit quality) are available to the same neighbor, batman-adv may distribute the frames to be sent over these available links. The individual frames are sent over the links in a round robin fashion as illustrated below. Using this technique, the throughput may be increased by the number of links involved in the bonding. In practical tests over two WiFi links, we have seen more than 50% of throughput gain. - -!bonding_roundrobin.dia.jpg! - -However, if the links have different speeds (batman-adv won't detect that), the throughput may even decrease due to the slower link slowing down the whole bonding. Therefore, this feature must be explicitly enabled. One may enable it for certain nodes in a known environment, the same setting does not have to be applied mesh wide. - -To enable bonding, use batctl: - -<pre> -batctl bonding enable -</pre> - -h2. Throughput gain - -At the [[open-mesh:2010-06-13-wbm2010-bracciano|WirelessBattleMesh v3]] we performed throughput tests to measure the gain of the various modes: - -!bonding_2hops.png! - -This graph shows a 3 node setup each with 2 802.11abg wifi interfaces connected to the mesh network (1x 2.4GHz and 1x 5.8GHz). As you can see the alternating mode is able to maintain the performance. The old default behavior sometimes manages to maintain a similar level of performance but is rather unstable. diff --git a/batman-adv/Network-wide-multi-link-optimization.textile b/batman-adv/Network-wide-multi-link-optimization.textile index b42b8e6..f70ca47 100644 --- a/batman-adv/Network-wide-multi-link-optimization.textile +++ b/batman-adv/Network-wide-multi-link-optimization.textile @@ -1,6 +1,6 @@ h1. Network Wide Multi Link Optimization (technical documentation)
-The original batman-adv multi link optimization ([[Multi-link-optimizations-technical]]) works on a local level - which is fairly easy to implement and works well as long as as all nodes are configured the same way and have similar link qualities. But local decision may be suboptimal network wide - for example, consider some dual radio mesh nodes where the first node starts on 5 GHz, but after some hops (alternating between 2.4 and 5 GHz) it stops at a 2.4 GHz-only device. If it had chosen the other (2.4 Ghz) link in the first hop, choosing the same frequency twice could have been avoided, and the total path quality would be better. +The original batman-adv multi link optimization worked on a local level - which is fairly easy to implement and works well as long as as all nodes are configured the same way and have similar link qualities. But local decision may be suboptimal network wide - for example, consider some dual radio mesh nodes where the first node starts on 5 GHz, but after some hops (alternating between 2.4 and 5 GHz) it stops at a 2.4 GHz-only device. If it had chosen the other (2.4 Ghz) link in the first hop, choosing the same frequency twice could have been avoided, and the total path quality would be better.
!alternating-limited-view.png!
diff --git a/batman-adv/interface_detection.dia b/batman-adv/interface_detection.dia deleted file mode 100644 index 21b9955..0000000 Binary files a/batman-adv/interface_detection.dia and /dev/null differ diff --git a/batman-adv/interface_detection.dia.jpg b/batman-adv/interface_detection.dia.jpg deleted file mode 100644 index 015df6e..0000000 Binary files a/batman-adv/interface_detection.dia.jpg and /dev/null differ diff --git a/batman-adv/primary_flag.dia b/batman-adv/primary_flag.dia deleted file mode 100644 index 2422806..0000000 Binary files a/batman-adv/primary_flag.dia and /dev/null differ diff --git a/batman-adv/primary_flag.png b/batman-adv/primary_flag.png deleted file mode 100644 index 0c3e3f8..0000000 Binary files a/batman-adv/primary_flag.png and /dev/null differ diff --git a/open-mesh/FFTrace.textile b/open-mesh/FFTrace.textile deleted file mode 100644 index 42cc471..0000000 --- a/open-mesh/FFTrace.textile +++ /dev/null @@ -1,11 +0,0 @@ -h1. FFTrace freifunk-traceroute - -*"fftrace"* is a console-based olsr-route-link-quality monitor - -Problem description: in OLSR mesh networks routing is very dynamic. Fine tools as traceroute give only a one-time impression, and mtr does not cope with routechanges as often as they happen. Both aim to measure and show the round trip times of packets as quality indicator. A wireless network consists of many diffrent-quality HF-connections, some with severe packet loss and some with less. The link-quality implementation of olsrd introduced a value do describe the quality of these connections. A tool to monitor the current route and the link-quality of its connections was missing. - -*"fftrace"* aims to fill this gap. It lists the single nodes of a route and displays the quality of the connections in between. Finally it shows the needed effort to get a packet through the whole route. - -The program uses ttl-manipulatet icmp-echo-requests to find the intermediate nodes and reads the udp-messages used and generated by the olsr-deamons to gather present information about the link-quality and neighbor-link-quality of node-node-pairs in the watched route. Due to this structure there is no instant information on a new node-node-pair. Until the information is available it is left blank and unregarded by the whole-route-etx. The code tries to be modular enough to exchange parts if desired, such as the udp-part by an olsr-plugin or the screen-output in something that can be diplayed graphical e.g. by olsr-viz. (gpl is gpl, be free to do so) - -* Download: https://downloads.open-mesh.org/fftrace/ diff --git a/open-mesh/MeshLinux.textile b/open-mesh/MeshLinux.textile deleted file mode 100644 index c4901a1..0000000 --- a/open-mesh/MeshLinux.textile +++ /dev/null @@ -1,7 +0,0 @@ -h1. MeshLinux - -Meshlinux is outdated and really old. The project hasn't been updated in a long time. It is unlikely that anyone will take up development on it again. We recommend to use OpenWrt for X86 platform. The only purpose we can think of today is software archaeology or the use of very old legacy WiFi hardware. - -Nothing is as outdated as old software. Meshlinux was created in the early days of mesh networking at the Freifunk community in 2004. It is a CD-Image that can be used to convert old PCs into wireless supernodes. There is a old Meshlinux version based on Linux (Kernel 2.4.26) available at (https://wiki.c-base.org/coredump/MeshLinux) This old version is based on Slackware and not maintained anymore. However it works nicely with old Atmel USB wireless devices (which is a problem nowadays with recent kernels), Prism-based Chipsets and Orinoco. But you won't find any modern mesh routing protocol implementations in it. If you want to build a meshrouter with nothing better than a 486 CPU and this kind of old wireless devices because you have them lying around and want to do something useful with it, you may still use it and install a recent version of Layer 3 B.A.T.M.A.N. - you can download a statically compiled version from this server. You can not use Batman-advanced, since this would r equire a recent Linux kernel. Some userland mesh protocol daemons like OLSR might still work with it. - -Sooner or later this information will be removed. \ No newline at end of file diff --git a/open-mesh/NetworkingTechnologies.textile b/open-mesh/NetworkingTechnologies.textile deleted file mode 100644 index b7155ee..0000000 --- a/open-mesh/NetworkingTechnologies.textile +++ /dev/null @@ -1,33 +0,0 @@ -{{include(open-mesh:TemplateDeprecated)}} - -h1. Networking Technologies - -h2. Introduction. - -Batmand and batman advanced rely on underlining network transport technologies like WIFI for instance. -This page explains the interaction between them and batmand or batmand-adv. - -h2. Batmand and IBSS (also known as ad-hoc wifi networks) - -IBSS permit the connection of more than two devices together in a big IBSS network. -Let's say you have 3 devices A,B and C connected that way: A<->B<->C with: -* C being out of the range of A -* A and B being in range -* B and C being in range -* A,B,C having the same SSID (it's called BSSID in IBSS networks) - -Batmand will simply route the packets from A to C. - -Given the nature of IBSS networks, B doesn't need to have 2 wifi cards(one is enough), however A,B,C need to have the same BSSID. - -h2. Batman-adv - -Batman-adv can run on top of all ethernet-compatible networks, that means: -* wifi (station, ibss, master) -* ethernet -* bridges -* layer 2 vpns -* etc... - - -