| Both sides previous revision Previous revision Next revision | Previous revision Next revisionBoth sides next revision |
| docs:guide-user:network:wifi:mesh:batman [2021/09/09 08:55] – [Bridging with DSA] Added an info box for further reading freezeheat | docs:guide-user:network:wifi:mesh:batman [2022/01/02 15:10] – [Installation] plural lastedit |
|---|
| To enable use of 802.11s mesh: | To enable use of 802.11s mesh: |
| <code> | <code> |
| | # Remove |
| opkg remove wpad-basic | opkg remove wpad-basic |
| | opkg remove wpad-basic-wolfssl |
| | |
| | # Install |
| opkg install wpad-mesh-openssl # or wpad-mesh-wolfssl | opkg install wpad-mesh-openssl # or wpad-mesh-wolfssl |
| </code> | </code> |
| |
| If building/assembling your own image, you will need to remove the default ''wpad-basic'' as it conflicts with ''wpad-mesh=*''. | If building/assembling your own image, you will need to remove the default ''wpad-basic'' as it conflicts with ''wpad-mesh-*''. |
| | |
| | [[https://github.com/openwrt/openwrt/commit/49cc712b44c76e99bfb716c06700817692975e05|As of September 2019]], ''wpad-openssl'' or ''wpad-wolfssl'' are //**also**// sufficient for 802.11s use and are the **full version** of ''wpad''. |
| | |
| | **Notes:** |
| | - ''wpad-mesh-openssl'' and ''wpad-mesh-wolfssl'' are ''wpad-basic'' (trimmed ''wpad'') with support for ''802.11s'' (mesh). |
| | - ''wpad-openssl'' and ''wpad-wolfssl'' are the **full version** of ''wpad'', they support ''802.11k'', ''802.11v'' and ''802.11s'' (mesh). |
| | - The **full version** of ''wpad'' means that nothing was trimmed and ''wpad-basic'' is the trimmed version of ''wpad'', it was trimmed to reduce its size and can be installed on routers with **low memory**. |
| |
| ''wpad'' (full) is //**not**// sufficient for 802.11s use. | |
| |
| ===== Configuration ===== | ===== Configuration ===== |
| option ipaddr '192.168.1.254' | option ipaddr '192.168.1.254' |
| option netmask '255.255.255.0' | option netmask '255.255.255.0' |
| list dns '1.1.1.1 8.8.8.8' | |
| option force_link 'yes' | option force_link 'yes' |
| |
| option ipaddr '192.168.2.254' | option ipaddr '192.168.2.254' |
| option netmask '255.255.255.0' | option netmask '255.255.255.0' |
| list dns '1.1.1.1 8.8.8.8' | |
| option force_link 'yes' | option force_link 'yes' |
| </code> | </code> |
| option ipaddr '192.168.1.100' | option ipaddr '192.168.1.100' |
| option netmask '255.255.255.0' | option netmask '255.255.255.0' |
| list dns '1.1.1.1 8.8.8.8' | |
| option force_link 'yes' | option force_link 'yes' |
| |
| option ipaddr '192.168.2.100' | option ipaddr '192.168.2.100' |
| option netmask '255.255.255.0' | option netmask '255.255.255.0' |
| list dns '1.1.1.1 8.8.8.8' | |
| option force_link 'yes' | option force_link 'yes' |
| </code> | </code> |
| | ''aggregated_ogms'' | boolean | ''1'' | ''0'', ''1'' | **OGMs** AKA **Originator Messages** are messages used to determine the qualities needed to direct neighbors and spreading this message throughout the whole mesh, aggregating them reduces the number of packets being sent. | | | ''aggregated_ogms'' | boolean | ''1'' | ''0'', ''1'' | **OGMs** AKA **Originator Messages** are messages used to determine the qualities needed to direct neighbors and spreading this message throughout the whole mesh, aggregating them reduces the number of packets being sent. | |
| | ''routing_algo'' | string | ''BATMAN_IV'' | ''BATMAN_IV'' or ''BATMAN_V'' | Which routing algorithm to use - more info below but for now use ''BATMAN_IV'' until ''BATMAN_V'' is ready for actual use. | | | ''routing_algo'' | string | ''BATMAN_IV'' | ''BATMAN_IV'' or ''BATMAN_V'' | Which routing algorithm to use - more info below but for now use ''BATMAN_IV'' until ''BATMAN_V'' is ready for actual use. | |
| | ''bonding'' | boolean | ''1'' | ''0'', ''1'' | If some interfaces are similar in quality and speed, it's possible to distribute frames through them using Round Robin which shows a 50% throughput increase, but if the links aren't similar in speed and since it isn't detected by BATMAN_IV, you may actually lose throughput, so it should be done explicitly on known nodes. | | | ''bonding'' | boolean | ''0'' | ''0'', ''1'' | If some interfaces are similar in quality and speed, it's possible to distribute frames through them using Round Robin which shows a 50% throughput increase, but if the links aren't similar in speed and since it isn't detected by BATMAN_IV, you may actually lose throughput, so it should be done explicitly on known nodes. | |
| | ''fragmentation'' | boolean | ''1'' | ''0'', ''1'' | Since batman-adv prepends its own headers and some clients aren't aware of that, packets are optimized for 1500 MTU even though 1528 is required, if it isn't possible with some devices fragmentation is used(the algorithm that handles fragmented data). | | | ''fragmentation'' | boolean | ''1'' | ''0'', ''1'' | Since batman-adv prepends its own headers and some clients aren't aware of that, packets are optimized for 1500 MTU even though 1528 is required, if it isn't possible with some devices fragmentation is used(the algorithm that handles fragmented data). | |
| | ''gw_mode'' | string | ''off'' | ''off'', ''client'', ''server'' | Gateway mode, if set to ''server'' other nodes are notified of that node's internet connection and **must** be complemented by ''gw_bandwidth'', that notifies the algorithm that server is one of the best paths for internet access. \\ If set to ''client'', the criteria by which batman-adv will choose a gateway(other nodes with ''gw_mode'' set as ''server'') is **required** to be set with ''gw_sel_class''. | | | ''gw_mode'' | string | ''off'' | ''off'', ''client'', ''server'' | Gateway mode, if set to ''server'' other nodes are notified of that node's internet connection and **must** be complemented by ''gw_bandwidth'', that notifies the algorithm that server is one of the best paths for internet access. \\ If set to ''client'', the criteria by which batman-adv will choose a gateway(other nodes with ''gw_mode'' set as ''server'') is **required** to be set with ''gw_sel_class''. | |
| | ''gw_bandwidth'' | string | ''10000/2000'' | ''not specified'' | **(Server)** Set the bandwidth, so ''client'' nodes will know about the gateway's quality stated by ''download/upload'', units can be suffixed with ''mbit'' or ''kbit'' (''10mbit/2mbit''), if you state download but not upload, upload defaults to the value of ''download / 5'', so 100mbit without upload would default to 100 / 5 = 20mbit. | | | ''gw_bandwidth'' | string | ''10000/2000'' | ''not specified'' | **(Server)** Set the bandwidth, so ''client'' nodes will know about the gateway's quality stated by ''download/upload'', units can be suffixed with ''mbit'' or ''kbit'' (''10mbit/2mbit''), if you state download but not upload, upload defaults to the value of ''download / 5'', so 100mbit without upload would default to 100 / 5 = 20mbit. | |
| | ''gw_sel_class'' | integer | **BATMAN_IV** ''20'' \\ **BATMAN_V** ''5000'' | **BATMAN_IV** ''1'', ''256'' \\ **BATMAN_V** ''0'', ''Not specified'' | **(Client)** Set the criteria by which to select a gateway(internet connection) indicated by TQ. \\ With **BATMAN_IV_** set in ''routed_algo'': \\ default: ''20'' (late switch) \\ ''1'' (Fast), prioritize by advertised throughput and link quality, use until gateway disappears. \\ ''2'' (Stable), prioritize by link quality only, use until gateway disappears. \\ ''3'' (Fast Switch), prioritize link quality only, but scan and switch to a better gateway if found. \\ ''XX'' (Late Switch), prioritize link quality only, but scan and switch to a better gateway if found, which is at least ''XX'' TQ better than the currently selected gateway, where XX is between 3-256. \\ With **BATMAN_V** set in ''routed_algo'': \\ default: ''5000'' (Late Switch), 5000 kbit/s throughput. \\ example: ''1500'' (Fast Switch), scan and switch to another gateway only if its throughput is at least 1500 kbit/s faster than the current, throughput is evaluated by determining what's lower: advertised throughput or the maximum bandwidth across the entire path. | | | ''gw_sel_class'' | integer | **BATMAN_IV** ''20'' \\ **BATMAN_V** ''5000'' | **BATMAN_IV** ''1'', ''256'' \\ **BATMAN_V** ''0'', ''Not specified'' | **(Client)** Set the criteria by which to select a gateway(internet connection) indicated by TQ. \\ With **BATMAN_IV_** set in ''routed_algo'': \\ default: ''20'' (late switch) \\ ''1'' (Fast), prioritize by advertised throughput and link quality, use until gateway disappears. \\ ''2'' (Stable), prioritize by link quality only, use until gateway disappears. \\ ''3'' (Fast Switch), prioritize link quality only, but scan and switch to a better gateway if found. \\ ''XX'' (Late Switch), prioritize link quality only, but scan and switch to a better gateway if found, which is at least ''XX'' TQ better than the currently selected gateway, where XX is between 3-256. \\ With **BATMAN_V** set in ''routed_algo'': \\ default: ''5000'' (Late Switch), 5000 kbit/s throughput. \\ example: ''1500'' (Fast Switch), scan and switch to another gateway only if its throughput is at least 1500 kbit/s faster than the current, throughput is evaluated by determining what's lower: advertised throughput or the maximum bandwidth across the entire path. | |
| | ''log_level'' | integer | ''0'' | ''0'', ''not specified'' (assumed to be 8) | Standard warning/error messages are sent to the kernel log, but more is possible(depending if compiling with debugging enabled). \\ [0] all debug output disabled (none) \\ [1] messages related to routing / flooding / broadcasting (batman) \\ [2] messages related to route added / changed / deleted (routes) \\ [3] messages related to translation table operations (tt) \\ [4] messages related to bridge loop avoidance (bla) \\ [5] messages related to arp snooping and distributed arp table (dat) \\ [6] messages related to network coding (nc) \\ [7] messages related to multicast (mcast) \\ [8] messages related to throughput meter (tp) \\ **NOTE:** It's assumed it's between 0-8, but it's not specified, it might also be the strings, like ''batman'', ''routes'', ''tt'' etc..| | | ''log_level'' | integer | ''0'' | ''0'', ''255'' (8 bit Bitmask) | Standard warning/error messages are sent to the kernel log, but more is possible(depending if compiling with debugging enabled). \\ [0] all debug output disabled (none) \\ [1](BIT 0 set) messages related to routing / flooding / broadcasting (batman), \\ [2](BIT 1 set) messages related to route added / changed / deleted (routes) \\ [4](BIT 2 set) messages related to translation table operations (tt) \\ [8](BIT 3 set) messages related to bridge loop avoidance (bla) \\ [16](BIT 4 set) messages related to arp snooping and distributed arp table (dat) \\ [32](BIT 5 set) messages related to network coding (nc) \\ [64](BIT 6 set) messages related to multicast (mcast) \\ [128](BIT 7 set) messages related to throughput meter (tp) \\ [255](ALL BITS set) Enable all messages \\ **NOTE:** Integer values are form the [[ https://www.kernel.org/doc/html/v5.0/networking/batman-adv.html#logging-debugging | Kernel docs]] and bitfield from [[ https://github.com/open-mesh-mirror/batman-adv/blob/master/net/batman-adv/log.h#L38 | batman-adv source]]| |
| | ''orig_interval'' | integer | ''1000'' | ''not specified'' | Specified in milliseconds, the interval in which batman-adv floods the network with its protocol information, '1000' as a default means a message per second which allows batman to recognize a route change up to a minute. In a static environment(nodes aren't moving, rare up/down of nodes) you might want to increase the interval value to save bandwidth, inversely, in a highly mobile environment(cars) but remember that will drastically increase traffic. \\ It's recommended to keep the default unless there are problems. | | | ''orig_interval'' | integer | ''1000'' | ''not specified'' | Specified in milliseconds, the interval in which batman-adv floods the network with its protocol information, '1000' as a default means a message per second which allows batman to recognize a route change up to a minute. In a static environment(nodes aren't moving, rare up/down of nodes) you might want to increase the interval value to save bandwidth, inversely, in a highly mobile environment(cars) but remember that will drastically increase traffic. \\ It's recommended to keep the default unless there are problems. | |
| | ''bridge_loop_avoidance'' | boolean | ''1'' | ''0'', ''1'' | In bridged LAN setups, this should be enabled in order to avoid broadcast loops that can completely flood the entire LAN(this option might need to be compiled), if you don't connect multiple batman-adv hosts to the same ethernet or don't use bridging, you can disable this option. | | | ''bridge_loop_avoidance'' | boolean | ''1'' | ''0'', ''1'' | In bridged LAN setups, this should be enabled in order to avoid broadcast loops that can completely flood the entire LAN(this option might need to be compiled), if you don't connect multiple batman-adv hosts to the same ethernet or don't use bridging, you can disable this option. | |
| | ''network_coding'' | boolean | ''1'' | ''0'', ''1'' | Combine two packets into a single transmission, which saves air-time but **requires**: \\ -- At least 3 nodes to be effective \\ -- One node must act as a relay which has this option enabled \\ -- Relay must support Promiscuous mode (both receive and send) \\ -- Support MTU value of at least 1546. | | | ''network_coding'' | boolean | ''1'' | ''0'', ''1'' | Combine two packets into a single transmission, which saves air-time but **requires**: \\ -- At least 3 nodes to be effective \\ -- One node must act as a relay which has this option enabled \\ -- Relay must support Promiscuous mode (both receive and send) \\ -- Support MTU value of at least 1546. | |
| | ''hop_penalty'' | boolean | ''30'' | ''not specified'' | Modify batman_adv's preference for multihop routes vs short routes, the value is applied to the TQ of each forwarded OGM, propagating the cost of an extra hop(packet must be received and re-transmitted), the higher it's the more unlikely other nodes will choose the current node as an intermediate hop towards any node, otherwise, a lower value will result in longer routes because re-transmissions aren't penalized. | | | ''hop_penalty'' | boolean | ''30'' | ''not specified'' | Modify batman_adv's preference for multihop routes vs short routes, the value is applied to the TQ of each forwarded OGM, propagating the cost of an extra hop(packet must be received and re-transmitted), the higher it's the more unlikely other nodes will choose the current node as an intermediate hop towards any node, otherwise, a lower value will result in longer routes because re-transmissions aren't penalized. | |
| | ''ap_isolation'' | boolean | ''1'' | ''0'', ''1'' | Standard WiFi APs support AP Isolation, which prevents clients communicating with each other, if the WiFi AP interface is bridged into batman-adv mesh network, it might be desirable to extend this isolation throughout the mesh by enabling this option. | | | ''ap_isolation'' | boolean | ''0'' | ''0'', ''1'' | Standard WiFi APs support AP Isolation, which prevents clients communicating with each other, if the WiFi AP interface is bridged into batman-adv mesh network, it might be desirable to extend this isolation throughout the mesh by enabling this option. | |
| | ''isolation_mark'' | string | ''0x00000000/0x00000000'' | ''0'', ''1'' | An extension of ''ap_isolation'', it allows the user to decide which client is classified as isolated via firewall rules, increasing the flexibility of the isolation, batman-adv extracts the fwmark the firewall attached to each packet it receives through the soft-interface and decides based on that value if the source client is isolated or not, this value is defined as a ''value/mask'', in the firewall, a simple case is to mark all the packets coming with a fwmark using ''tc'', you then set the fwmark you've set with ''tc'' in this option for it to work. | | | ''isolation_mark'' | string | ''0x00000000/0x00000000'' | ''0'', ''1'' | An extension of ''ap_isolation'', it allows the user to decide which client is classified as isolated via firewall rules, increasing the flexibility of the isolation, batman-adv extracts the fwmark the firewall attached to each packet it receives through the soft-interface and decides based on that value if the source client is isolated or not, this value is defined as a ''value/mask'', in the firewall, a simple case is to mark all the packets coming with a fwmark using ''tc'', you then set the fwmark you've set with ''tc'' in this option for it to work. | |
| |