nils/gluon
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
a modular framework for creating OpenWrt-based firmwares for wireless mesh nodes
2,730 Commits 26 Branches 63 Tags 18 MiB
C 35.8%
Lua 34.9%
Makefile 9.2%
Shell 7.5%
JavaScript 5.1%
Other 7.4%
a7a5db9f54
Go to file
Sven Eckelmann a7a5db9f54 gluon-mesh-batman-adv: Drop IPv4 anycast related packets from/to bat0 
The commit b3762fc61c ("gluon-client-bridge: move IPv4 local subnet route
to br-client (#1312)") moves the IPv4 prefix from the local-port interface
to br-client. A client requesting an IPv4 connection to the IPv4 anycast
address of the node (the device running gluon) will create following
packets:

1. ARP packet from client to get the MAC of the mac address of the anycast
   IPv4 address
2. ARP reply from node to client with the anycast MAC address for the IPv4
   anycast address
3. IPv4 packet from client which requires reply (for example ICMP echo
   request)
4. ARP request for the client MAC address for its IPv4 address in prefix4
   (done with the mac address of br-client and transmitted over br-client)
5. IPv4 packet from node (transmitted over br-client with br-client MAC
   address) as reply for the client IPv4 packet (for example ICMP echo
   reply)

The step 4 is extremely problematic here. ARP replies with the anycast IPv4
address must not be submitted or received via bat0 - expecially not when it
contains an node specific MAC address as source. When it is still done then
the wrong MAC address is stored in the batadv DAT cache and ARP packet is
maybe even forwarded to clients. This latter is especially true for ARP
requests which are broadcast and will be flooded to the complete mesh.

Clients will see these ARP packets and change their own neighbor IP
(translation) table. They will then try to submit the packets for IPv4
anycast addresses to the complete wrong device in the mesh. This will for
example break the access to the status page to the connected device or the
anycast DNS forwarder implementation. Especially the latter causes extreme
latency when clients try to connect to server using a domain name or even
breaks the connection setup process completely. Both are caused by the
unanswered DNS requests which at first glance look like packet loss.

An node must therefore take care of:

* not transmitting ARP packets related to the anycast IPv4 address over
  bat0
* drop ARP packets related to the anycast IPv4 when they are received on
  bat0 from a still broken node
* don't accept ARP packets related to the anycast IPv4 replies on local
  node when it comes from bat0

Fixes: b3762fc61c ("gluon-client-bridge: move IPv4 local subnet route to br-client (#1312)")
2018-07-22 16:43:00 +02:00
contrib contrib: update i18n-scan.pl script 2018-02-23 13:39:56 +01:00
docs docs: releases/v2018.1: extend explanation of status page rewrite 2018-07-14 21:19:44 +02:00
overlay overlay/opkg.mk: add explanatory comment 2017-03-02 22:53:40 +01:00
package gluon-mesh-batman-adv: Drop IPv4 anycast related packets from/to bat0 2018-07-22 16:43:00 +02:00
patches modules: update LEDE 2018-07-12 19:09:54 +02:00
scripts cripts/check_site.lua: print paths separated by '.' rather than '/' 2018-06-29 20:47:59 +02:00
targets ar71xx: Add support for TP-Link CPE210 v2 (#1445) 2018-06-26 01:19:55 +02:00
.gitignore Use LEDE as base for Gluon 2017-01-18 17:21:43 +01:00
CONTRIBUTING.md Remove squashing from contribution guidelines (#865) 2016-09-02 19:16:28 +02:00
LICENSE Use LEDE as base for Gluon 2017-01-18 17:21:43 +01:00
Makefile gluon-site: disable multidomain support by default 2018-01-26 12:32:46 +01:00
modules modules: update LEDE 2018-07-12 19:09:54 +02:00
README.md docs, README: Gluon v2018.1 2018-07-08 20:59:57 +02:00

README.md

Documentation (incomplete at this time, contribute if you can!) may be found at https://gluon.readthedocs.org/.

If you're new to Gluon and ready to get your feet wet, have a look at the Getting Started Guide.

Gluon IRC channel: #gluon in hackint

Issues & Feature requests

Before opening an issue, make sure to check whether any existing issues (open or closed) match. If you're suggesting a new feature, drop by on IRC or our mailinglist to discuss it first.

We maintain a Roadmap for the future development of Gluon.

Use a release!

Please refrain from using the master branch for anything else but development purposes! Use the most recent release instead. You can list all releases by running git tag and switch to one by running git checkout v2018.1 && make update.

If you're using the autoupdater, do not autoupdate nodes with anything but releases. If you upgrade using random master commits the nodes will break eventually.

Mailinglist

To subscribe to the list, send a message to:

gluon+subscribe@luebeck.freifunk.net

To remove your address from the list, just send a message to the address in the List-Unsubscribe header of any list message. If you haven't changed addresses since subscribing, you can also send a message to:

gluon+unsubscribe@luebeck.freifunk.net