commits July 2023

commits@lists.open-mesh.org

1 participants
38 discussions

[linux-merge]linux integration; annotated tag, v6.1.38, created. v6.1.38
by postmaster＠open-mesh.org 10 Jul '23

10 Jul '23

The annotated tag, v6.1.38 has been created at 16f603617dbbc30cafbacaf78ef6468a081fa482 (tag) tagging 61fd484b2cf6bc8022e8e5ea6f693a9991740ac2 (commit) replaces v6.1.28 tagged by Greg Kroah-Hartman on Wed Jul 5 18:28:22 2023 +0100 - Shortlog ------------------------------------------------------------ This is the 6.1.38 stable release -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmSlqDYACgkQONu9yGCS aT6bohAA2JQgHaer+7xCnxp21yqBDFGKUXTKc0yeFx8R0uGGv0evGgsJD2/U4EeW 076gpANsR4Qks5sLzF/tjS5+wWztZkj/j1GgQ6uRSSk7qBrzCIpi8yod/IrTkXlO DHVO5BX7WJ0DKjCWAlebtn+hYgEaqH6DXiTzWLLu/4h8v3uT4yzQzZCtfEqxKF+Y UWPg+nih6Q/cwNNzQr1va+Wdqo60H8ajlJ8255Mcho4lrTLyGvBN7DV84u2R4LTv mK3SuiGwwOcxD6tSpRDqoDs/q/SrgTODmOOx0oYXRnUaadKvcHhDP/xTMJg0klHE gemmfIGvInG9NAJO/W8QvdZkMlh4o4akIPkRgSyWhGKXynJEX1b1vA5wGK+lw9er Yc1tEi1gNYo7vfenNiPjhM2SIhzxoMxCBCjfj+NnfRvK4Is/lLi9qu5x2DYGipVX FJ8H+igI/sivEgqMkB1J/hgWzH6cLneYSh83B4DXK3NjZlgR+g2QwEd3gFH0kf+/ luzQtF06MFaCgQFEchOLOT1kWest/GW/KQEgzkxP60ZxyoqfaOeuMO/qqrSCbGwp JvZXw016ff1fmJQrbfCaORG0HRMByop74uie1zQqpcGU16pVWmXgUTMuQArzXttT y/mnE1p/5bZg/6xKal/sLIL4tY1+rAi6lhpIS47NusB20+cGjKQ= =yu08 -----END PGP SIGNATURE----- Vladislav Efanov (1): batman-adv: Broken sync while rescheduling delayed work ----------------------------------------------------------------------- -- linux integration

1 0

[linux-merge]linux integration; annotated tag, v6.3.12, created. v6.3.12
by postmaster＠open-mesh.org 10 Jul '23

10 Jul '23

The annotated tag, v6.3.12 has been created at 654f713df88a109074b96a6affed1f2e851ab5eb (tag) tagging eceb0b18ae34b399856a2dd1eee8c18b2341e6f0 (commit) replaces v6.3.2 tagged by Greg Kroah-Hartman on Wed Jul 5 18:29:42 2023 +0100 - Shortlog ------------------------------------------------------------ This is the 6.3.12 stable release -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmSlqIYACgkQONu9yGCS aT5zFhAAk+85cq/4NTo7ucxwk3pD5ZA5qjKUoQ72rMLcQ9zzezLx6R2eLN4HwAUu unDnQlworSutGQrkxPTBYg0nHTOySZvcjTjAiHA5zvUo2e/bOFeiuNK49ye14RJM tKTnNhYmC07/7kQ7ZquP20bV/8InRXeTSChJB5UDQglL9hfO+2yshKqjBYdQL3LY d+AkVZi6WUyWgcWg64R2qS6U8JEqibvn0yeodUX8Y5EjSvhcWam6p31CzTQGAyjn apnhtFHfNdXGkqDLY9PbXUuoC98qZ5JmmDb8l5Oc8F8QhCb0r3tY3s9xrQD5WuX4 QlSMeoNb+3BAOziPMKodTeEXixsGAdi8ttB/H8RiyYsD/6+LCxf9TfhESfz+GYgF 6rItP3ZgX99d+ym5RR7XCE4lK2Y8mVRQTDftTtXGEbgwIh1zLNrICGjOaH7mSdom H6VzTE4ivEDzLRYOQgUbpQQMc2OzteezRmNxNKsWf12EsNXappiJPosqx+HTJdwv 0Dv8MG6wsbL3bxB94ETPxQ8hBamQOJDRkZwjfA/c4+gwGr6JJeMwzq3AC+Nug0by Ds5F0ZtTjhz30xSQ4uAhPbigPaiG3/dx481kjnxS6dAsBwtfYym/Ib/Uf418NK8V hzzSaJjBigVuy66h+GFTn9prK3kyapml25CPC1XpwcvugIMsl9k= =sx+x -----END PGP SIGNATURE----- Vladislav Efanov (1): batman-adv: Broken sync while rescheduling delayed work ----------------------------------------------------------------------- -- linux integration

1 0

[linux-merge]linux integration; annotated tag, v6.4.2, created. v6.4.2
by postmaster＠open-mesh.org 10 Jul '23

10 Jul '23

The annotated tag, v6.4.2 has been created at c13cdc3bab939c718edd0b1f7f183131cab17c75 (tag) tagging d7defc5b8d422ba19ab762a96cf1b1eb158aa5a8 (commit) replaces v6.4 tagged by Greg Kroah-Hartman on Wed Jul 5 18:30:42 2023 +0100 - Shortlog ------------------------------------------------------------ This is the 6.4.2 stable release -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmSlqMIACgkQONu9yGCS aT5eqRAAiOumfiGZFIP/h+zQYQ8NjJcQa+xPW74H2vQ34HxhQEC7fOdpUoPo62Gq wsb89F5/iRobPlLOQAguRp6Nms+O8pr8KmCcwUc9TPglDRbK14Nym4ehgDQkGqtk obaP0zVlb7mEko+X1mkiWJMZQ0G9b1ihP7w/yx8uU5wmLkJfBmvwucUed07eFFXt M47gLSI8eJQY3rnNxTzuHWaHQ5c7wJJPSShNVQq3yKfnZvmNYW/qghtzREB8BcSN ULo48N5tJKfZrO0jw4c8DWYdzGQTtM4k05xZCjvFc5uKwYDsRFcK5XiugoxLhkXL ljKEhO++fM8nSIXUzx8AMVRVsZDLptj0knImCOtnFOZmHDMGKMHql80DdC6JGUyW AS0FN0zkiY5u/Yx2YzuwZ/SXG8vN04+zkiDpbzvLzzNvnpG+2GmEZ+mIncds8rfC JUhlEy7GisXpO0QiKjsbWZrLV4WqvgX9Vk/JrnRkQHFaYV9Kevp7PU4sA8S3cdTY Nczdpqm4D61ixA5q0xnK9rpoMEybYB3Hpommm04Rxtz44cuef4azb1BgGT3/ASsg SU2w8DO7K7CL7v87b0dNnGZtII6ZGhs2NBvwUgcqlGVHsqvQCbHfqZLl4+aqpDak xmmFyATO5elkLAz/Ek1kivx/ItWHv0IhrMHiHUwwu1Y3QWm5vw0= =qwTL -----END PGP SIGNATURE----- ----------------------------------------------------------------------- -- linux integration

1 0

[linux-merge]linux integration; annotated tag, v4.14.320, created. v4.14.320
by postmaster＠open-mesh.org 10 Jul '23

10 Jul '23

The annotated tag, v4.14.320 has been created at 2c91ffa55e5b48bfa9a2ea6801f772b931a754bf (tag) tagging 60a6e3043cc8b918c989707a5eba5fd6830a08a4 (commit) replaces v4.14.314 tagged by Greg Kroah-Hartman on Wed Jun 28 10:14:30 2023 +0200 - Shortlog ------------------------------------------------------------ This is the 4.14.320 stable release -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmSb6+YACgkQONu9yGCS aT6k8xAAwMV8dM19J1KpSGIZc67DMWH4nXoehnuVROhJKZjLfJvQr9Vwab7+2gIy rXeCQgQjxKpPOgmkH67qFoD11prwXYCOj/69qeAyQTyXYjwrF3jEzCds6yBePY2U dU0og8UipoisMqO5HPtLYoFT1kYyOGTB+EmFpy0xTrudYj9ctmlqIe71oAXup766 G2AvOHBggGWdvtkecuz/bbMFrdjIOhzl1Qq68X8GmxhHsFPGt+i3e+MpzcyM+DVi WmBfzYNO3phCYvAKk21hWI7rhp/3yGFNTvZVeC39pwEtLH2Xk+5gjQHYjW/HqHyR xD9Li8A03wYbjy5501Hyt1W3Se0kLAgdDUOZX//1TOrLXLuNn91mfu2N7grhfsML +EwH7asrnQsJUn9Pr+ZKcV3Rruw5JUHuIa4vCmrsrqjqi+LTjFwTpK4Y02zefjhM qLhsIdSOU1DrmAnd5AbQPIeQnqWEe29lsG/K5OWha1qr94x37CqaFB3DeKzNnxjO qJ0ByN3GIi1KbBv2ymIkpAhOLbPEni+Kakmi5+YdPGsnsPAXHzGUf0JxBi6U6Pj5 P/VXAq5b5ZN4VbGWZa+PORahRBPy2BMlNfi6VeWsYDh4YZfoCjidy4mmrE86c+iY WMJpszU7QF6ZSqf0QXVCJEjJwVVHgvObCM2Hguyzy6oGb5usJ/w= =TkTj -----END PGP SIGNATURE----- Vladislav Efanov (1): batman-adv: Broken sync while rescheduling delayed work ----------------------------------------------------------------------- -- linux integration

1 0

[linux-merge]linux integration; annotated tag, v6.5-rc1, created. v6.5-rc1
by postmaster＠open-mesh.org 09 Jul '23

09 Jul '23

The annotated tag, v6.5-rc1 has been created at a5233ebc0b27249e13f09f2e06d5c2555a367991 (tag) tagging 06c2afb862f9da8dc5efa4b6076a0e48c3fbaaa5 (commit) replaces v6.4 tagged by Linus Torvalds on Sun Jul 9 13:53:13 2023 -0700 - Shortlog ------------------------------------------------------------ Linux 6.5-rc1 -----BEGIN PGP SIGNATURE----- iQFSBAABCAA8FiEEq68RxlopcLEwq+PEeb4+QwBBGIYFAmSrHjkeHHRvcnZhbGRz QGxpbnV4LWZvdW5kYXRpb24ub3JnAAoJEHm+PkMAQRiGyoYH/0hKwgqboNdEilrv JYP60ML/53HTXdX4HEmAdhiPZf/AAtMp6AB9rcK1wjV6eBxDu3mdUAH0wt7FCsXZ M7zg8Q3raraqcP+wCF+Z6CDXkuOhct+6SYKwZRG7k5BLw/RjdoPSJSRGDR3lKWkV GkltoKc3jG7FC0oBF3srYyuaLFwnD7j8OaZugwadnrtqcBAx02ITQPgQcG6Sm1hJ G+4jjWVXCGQ0ESrECzhTjIZmESU0YoNOIA2oH1hEhEet1eDNOB9mrw437eRQMMpm QdimJ1O72cLuS7hkGSFMo4vUw55RJjNRYq0LxomFUe7yPMQ1m7AGvh1ayXWSId9O 1KXze0A= =w97t -----END PGP SIGNATURE----- ----------------------------------------------------------------------- -- linux integration

1 0

[doc] backup-redmine/2023-07-08,main: doc: batman-adv/Faq (8fbf3482)
by postmaster＠open-mesh.org 08 Jul '23

08 Jul '23

Repository : ssh://git@diktynna/doc On branches: backup-redmine/2023-07-08,main >--------------------------------------------------------------- commit 8fbf3482fc7a6727cc46870bb174682642b08639 Author: Sven Eckelmann <sven(a)narfation.org> Date: Sun Jul 2 18:51:16 2023 +0000 doc: batman-adv/Faq >--------------------------------------------------------------- 8fbf3482fc7a6727cc46870bb174682642b08639 batman-adv/Faq.textile | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/batman-adv/Faq.textile b/batman-adv/Faq.textile index 24b0e837..bce87ab0 100644 --- a/batman-adv/Faq.textile +++ b/batman-adv/Faq.textile @@ -150,8 +150,8 @@ h2. B.A.T.M.A.N. Advanced - VLAN questions h3. VLAN forwarding doesn't work -*Q*: When I have a bridge which connects an ethernet devices with bat0, VLAN frames from the ethernet interfaces are not forwarded by batman-adv. Instead a warning like "@batman_adv: bat0: adding TT local entry xx:xx:xx:xx:xx:xx to non-existent VLAN 23@" is printed periodically. How is it possible to forward these frames -*A*: batman-adv since 2014.0.0 is VLAN-aware. It is only able to forward VLAN frames when it knows about the VLAN. This can either be done by creating a VLAN device with the correct VID on top of the batadv (bat0) device: +*Q*: When I have a bridge which connects an ethernet devices with bat0, 802.1Q VLAN frames from the ethernet interfaces are not forwarded by batman-adv. Instead a warning like "@batman_adv: bat0: adding TT local entry xx:xx:xx:xx:xx:xx to non-existent VLAN 23@" is printed periodically. How is it possible to forward these frames +*A*: batman-adv since 2014.0.0 is 802.1Q VLAN-aware. It is only able to forward VLAN frames when it knows about the VLAN. This can either be done by creating a 802.1Q VLAN device with the correct VID on top of the batadv (bat0) device: <pre> ip link add link bat0 name bat0.23 type vlan id 23

1 0

[doc] backup-redmine/2023-07-08,main: doc: batman-adv/Faq (7f239b59)
by postmaster＠open-mesh.org 08 Jul '23

08 Jul '23

Repository : ssh://git@diktynna/doc On branches: backup-redmine/2023-07-08,main >--------------------------------------------------------------- commit 7f239b5971745c8c230d3a15278fe176d50cb7a9 Author: Linus Lüssing <linus.luessing(a)c0d3.blue> Date: Tue Jul 4 12:06:18 2023 +0000 doc: batman-adv/Faq >--------------------------------------------------------------- 7f239b5971745c8c230d3a15278fe176d50cb7a9 batman-adv/Faq.textile | 2 ++ 1 file changed, 2 insertions(+) diff --git a/batman-adv/Faq.textile b/batman-adv/Faq.textile index bce87ab0..e09a7d24 100644 --- a/batman-adv/Faq.textile +++ b/batman-adv/Faq.textile @@ -162,3 +162,5 @@ Or in case of a VLAN-aware bridge, it is better to add the VLANs as required to <pre> bridge vlan add vid 23 dev bat0 </pre> + +Note: Do *not* rely on VLAN packets being filtered when no VLAN is added on top of bat0. This is likely subject to change in the future. \ No newline at end of file

1 0

[doc] main: Merge branch 'backup-redmine/2023-07-08' (f3ea75b2)
by postmaster＠open-mesh.org 08 Jul '23

08 Jul '23

Repository : ssh://git@diktynna/doc On branch : main >--------------------------------------------------------------- commit f3ea75b2e093c0b6c8927e5d3a78f7a873570a17 Merge: 63db0d74 7f239b59 Author: Sven Eckelmann <sven(a)narfation.org> Date: Sat Jul 8 11:28:42 2023 +0200 Merge branch 'backup-redmine/2023-07-08' >--------------------------------------------------------------- f3ea75b2e093c0b6c8927e5d3a78f7a873570a17 batman-adv/Faq.rst | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) diff --cc batman-adv/Faq.rst index e7c18be4,00000000..2eec4e18 mode 100644,000000..100644 --- a/batman-adv/Faq.rst +++ b/batman-adv/Faq.rst @@@ -1,328 -1,0 +1,331 @@@ +.. SPDX-License-Identifier: GPL-2.0 + +FAQ +=== + +Below you can see a list of frequently asked questions and answers. If +your question is not listed below, please contact us. You can contact us +via IRC: `#batadv +channel <https://webirc.hackint.org/#ircs://irc.hackint.org/#batadv>`__ on +hackint.org or by sending an e-mail to: b.a.t.m.a.n(a)lists.open-mesh.org +(only plain-text). + +If you got any problems? See: the :doc:`Troubleshooting <Troubleshooting>` +page. + +.. _batman-adv-faq-batman-general-questions: + +B.A.T.M.A.N. General questions +------------------------------ + +Does B.A.T.M.A.N. have simulator (NS2, Omnet, etc) support? +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +**Q:** Does B.A.T.M.A.N. have its own simulator? + +**A:** At this point no, but B.A.T.M.A.N. implementation (we know of) +supports simulators like the ones mentioned above. However, some +people experiment with B.A.T.M.A.N. using emulators (UML/Qemu/etc). If +you are looking for step-by-step instructions to install such a system +you can :doc:`read our emulation document </devtools/Emulation\_Environment>`. + +How to make my mesh network secure ? +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +**Q:** Can I make my mesh network secure? + +**A:** This depends on the security you want or need. Security is a +big field. Probably you mean encryption and authentication. + +When you only want to make the whole WLAN stuff unreadable for the +outside, you could just use WPA\_NONE or IBSS RSN. But this doesn't +resolve the problem that the key could leak and make the mesh attackable +- but that is something which could always happen. So it is probably not +a solution for WiFi community projects, but for mesh networks controlled +by a company. + +There are other ideas for traffic over batman-adv. Just forget about +encrypting your data on the WiFi layer, but instead do everything some +layers above. Some people experimented with the idea of implementing the +needed authentication and encryption over IPsec. + +And most of the encryption and authentication stuff has to be resolved +by the user and not by the network provider. This means HTTPS for +sensible data instead of HTTP, SSH instead of Telnet, pop3s instead of +pop3 and so on. + +So it really depends what you want and cannot be resolved in a "security +for everything, against any attack and for every purpose" blob. + +Why does batman need so much time to detect a "dead" node? +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +**Q:** Why can I see a node in the originator table a long time after +it died? *Or:* Does batman really need 200 seconds (PURGE\_TIMEOUT) to +switch the route? + +**A:** Batman switches the route as soon as it learns about a better +path towards a destination which can take a fraction of a second up to +several seconds very much depending on the settings and situation. + +When no more new originator messages are sent by a node (because it +died), no more routing updates regarding this node are exchanged. Batman +will not immediately delete this node from its database because the +connection could just have a temporary problem and might recover. Only +after a timeout period of (currently) 200 seconds the node is removed +entirely from batman's internal database. It does not hurt to give the +node a little extra time to recover from a connection loss as it speeds +up the resume process. All routes using this "lost" node as intermediate +hop will have changed towards another path in the meantime and are of no +concern. + +.. _batman-adv-faq-batman-advanced-questions: + +B.A.T.M.A.N. Advanced Questions +------------------------------- + +What can B.A.T.M.A.N. Advanced do? And can't do? +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +**Q:** What offers batman-adv? And what are the 'limitations'? + +**A:** The batman-adv kernel module can only be used to route the +packages within a mesh network, it only simulates OSI layer 2 (data +link layer). It does that as fast as possible and in a smart way. Just +like a switch. + +Batman has no security implemented. Also assigning IP addresses to the +node(s) is not Batman's task. +You may want to use underlying security mechanisms, like: IBSS RSN. + +Read more about :doc:`BATMAN <Wiki>`. + +Can batman-adv run on interfaces in AP / Station / etc mode ? +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +**Q:** Can BATMAN advanced run on interfaces in AP / Station mode? + +**A:** Yes, because batman-adv doesn't know anything about stuff below +the ethernet interface. So you could also use it over layer 2 ethernet +tunnels, wifi ap, wifi sta, wifi adhoc, ethernet or even write a +virtual interface which prints everything on paper and scans the paper +on the remote machine (but you should be fast or increase the ogm +interval). + +How can I connect non-mesh clients to my batman-adv network ? +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +**Q:** How can I connect non-mesh clients to batman-adv network? + +**A:** The :doc:`batman-adv quick-start-guide </batman-adv/Quick-start-guide>` explains how to bridge your standard AP / Ethernet +interfaces with bat0 which can be problematic if you only possess one +WiFi card. In these cases it might be desirable to run adhoc mode and +AP mode at the same time. Fortunately, some WiFi chips / drivers +support a so-called "multi VAP" (virtual AP) or "multi SSID" mode to +have multiple WiFi networks on the same WiFi interface. + +How big networks does batman-adv support? +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +**Q:** How big networks (maximum nodes) does batman-adv support? + +**A:** That is a good question. It is not possible to give an exact +answer, but there are several parameters limiting the number of nodes +in your network: + +#. **Capacity of the wireless network** + Usually, the performance of the wireless network renders unusable if + you add too many nodes (huge delay and low throughput). +#. **Memory footprint** + Each node in the mesh network holds information in memory about every + other node, so little memory might limit the number of nodes. +#. **Protocol overhead** + Each node sends "here-I-am" messages to the entire network at a + regular interval. These messages are aggregated when possible, to + reduce the overhead. + +How do I announce IP subnets using batman-adv? +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +**Q:** Can I setup differnt IP subnets using batman-adv? + +**A:** Batman-adv is a OSI layer 2 routing protocol and it does not +handle IP subnets at all. If you want to do IP subnetting, the +suggestion is to split the mesh network in different sub-meshes (e.g. +different ESSID/BSSID), and run a batman-adv instance in each of them. + +|image0| + +As shown in the picture, the result consists in having multiple meshes +working independently from each other. In particular the border nodes +like C, D and E will participate in more than one mesh network and will +consequently have more than one batman-adv interface (e.g. bat0 and +bat1): each of them assigned an IP belonging to a different subnet. + +At this point the border nodes can run an instance of any dynamic IP +routing protocol (e.g. OSPF or BGP, both implemented in +`Quagga <http://www.quagga.net/)>`__ which will see each of the +batman-adv mesh network like a single link towards the other (border) +nodes in that network. + +Note that also nodes connected to the Internet like A and B can be +considered border nodes (this is configuration dependant) and can +eventually run the IP routing protocol instance too. + +It is extremely important to do not run any layer3 mesh routing protocol +on top of nodes using batman-adv: this would result in wrong link +quality computation by the overlying protocol which will see the whole +batman-adv network as a single link (even if a path to a node is made up +by multiple hops). + +However the interaction of Quagga with the mesh network will be +"batman-adv-agnostic" since there is no way to exchange information +between the two. The creation of a batman-adv plugin for Quagga could +help in this direction by letting Quagga extract TQ (the metric used by +batman-adv) information to compute link qualities towards other border +nodes in the mesh network. This would avoid the IP routing protocol to +choose bad mesh nodes as next hop in the IP routing. As extracting/using +TQ in other protocols is just an idea/proposal right now, please contact +us if you want to do that. + +Logs not received via trace-cmd? +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +**Q:** The trace-cmd shows no log messages for batman-adv? + +**A:** You need to compile the batman-adv with logging support. + +* Linux tree + + - go to ``Networking support ---> Networking options ---> B.A.T.M.A.N. Advanced Meshing Protocol`` + and select ``B.A.T.M.A.N. debugging`` and + ``B.A.T.M.A.N. tracing support`` + +* external module + + - compile with make parameter ``CONFIG_BATMAN_ADV_DEBUG=y CONFIG_BATMAN_ADV_TRACING=y`` + +batctl must also be used to set the relevant loglevel + +How to setup B.A.T.M.A.N. so it automatically assign IP addresses? +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +**Q:** How to assign IP addresses automatically? + +**A:** Batman-adv is not responsible for assigning IP addresses. +However, you can use for example a DHCP server. + +What about assigning IP addresses in a decentralized way? +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +**Q:** How to assign IP addresses automatically in a decentralized +way? + +**A:** IPv6 will help you to do this easier by using `Unique local +address <https://en.wikipedia.org/wiki/Unique_local_address>`__ (ULA). + +What if I want to have a decentralized DNS solution? +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +**Q:** I like to setup a decentralized mesh network and would like to +have a DNS solution. I don't want to use the internet (WWW), but I do +want to have a human readable 'domains' names, just like DNS. What are +the options? + +**A:** Take a look at +`KadNode <https://github.com/mwarning/KadNode>`__. *Note:* This +software is still in beta. + +.. _batman-adv-faq-batman-advanced-bridge-loop-avoidance-questions: + +B.A.T.M.A.N. Advanced - Bridge Loop Avoidance questions +------------------------------------------------------- + +What is Bridge Loop Avoidance? +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +**Q:** What can you do with BLA? + +**A:** Bridge Loop Avoidance is used to detect and avoid loops due to +multiple batX interfaces. :doc:`Read more... <Bridge-loop-avoidance>` + +Why do we need BLA II if we can just use mesh on Ethernet? +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Under Discussion -> Features you say "no BATMAN packets on the +backbone". + +**Q:** Why would you want to use the mesh (which never has enough +bandwidth anyway) if you have a fast, reliable backbone link between +some of the nodes (eg. LAN)? +*Or:* Wouldn't it make more sense to get as much done through the +backbone as possible? + +**A:** You can explicitly use batman-adv on the mesh if you want to - +batman-adv allows adding Ethernet interfaces as well. This is a good +idea if you have full control over your LAN. However, there are users +who don't want to see batman-adv ethernet frames (with its special +ethertype 0x4305) on their LAN, because some firewalls recognize it as +malicious traffic. Therefore, one design goal of blaII was to keep +batman-adv packets out of the backbone LAN in the default case. + +What about two meshes interconnected by a LAN? +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +**Q:** Can I setup two meshes and connect them by LAN? *Or:* So, does +this mean that with current blaII, two meshes connected solely by +ethernet backbone (which can't overhear each other OGMs through wifi) +only know which macs are "on the other side of the ethernet backbone" so +as to keep the single broadcast domain united, but are fragmented in +terms of VIS data, gw, TT, and orig table? + +**A:** Yes, there are two separate meshes, and the only stuff which is +supposed to be shared is the users payload traffic. + +What about DHCP server for separate meshes? +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +**Q:** I would like to setup a DHCP server in separate meshes? *Or:* +How can I make two separate meshes use a single DHCP server (using +gw\_mode feature) in current blaII design? + +**A:** Each node at the edge to the wired network may announce itself +as a gateway, provided that a DHCP server is available in the LAN (or +any network behind it, e.g. a mesh). From a concept view, a gateway +(or maybe even multiple gateways) in mesh2 will not automatically +announced in mesh1 - this must be configured manually, or let batman +use Ethernet if this is explicitly required. + +B.A.T.M.A.N. Advanced - VLAN questions +-------------------------------------- + +VLAN forwarding doesn't work +~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +**Q**: When I have a bridge which connects an ethernet devices with - bat0, VLAN frames from the ethernet interfaces are not forwarded by - batman-adv. Instead a warning like ++bat0, 802.1Q VLAN frames from the ethernet interfaces are not forwarded ++by batman-adv. Instead a warning like +``batman_adv: bat0: adding TT local entry xx:xx:xx:xx:xx:xx to non-existent VLAN 23`` +is printed periodically. How is it possible to forward these frames + - **A**: batman-adv since 2014.0.0 is VLAN-aware. It is only able to ++**A**: batman-adv since 2014.0.0 is 802.1Q VLAN-aware. It is only able to +forward VLAN frames when it knows about the VLAN. This can either be - done by creating a VLAN device with the correct VID on top of the ++done by creating a 802.1Q VLAN device with the correct VID on top of the +batadv (bat0) device: + +:: + + ip link add link bat0 name bat0.23 type vlan id 23 + +Or in case of a VLAN-aware bridge, it is better to add the +VLANs as required to the specific ports: + +:: + + bridge vlan add vid 23 dev bat0 + ++Note: Do **not** rely on VLAN packets being filtered when no VLAN is added ++on top of bat0. This is likely subject to change in the future. ++ +.. |image0| image:: quagga_integration.png +

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

commits July 2023