- Dec 02, 2018
-
-
Jan Luebbe authored
For parker we need DHCP on the client interface. Ths rule prevents us from doing so. In addition: make sure old rules will be deleted on upgrade.
-
- Sep 16, 2018
-
-
Jan Luebbe authored
-
Jan Luebbe authored
-
Jan Luebbe authored
Signed-off-by:
Jan Luebbe <jlu@pengutronix.de>
-
- Sep 15, 2018
-
-
Jan Luebbe authored
-
- Sep 05, 2018
-
-
chrissi^ authored
Contact Info is no longer added on FFBS nodes since our gluon release of v2017.1.8. On nodes that have been running before this release this field is set to "Intentionally left blank". This Info should not be shown on the statuspage. Signed-off-by:
Chrissi^ <chris@tinyhost.de>
-
chrissi^ authored
Well, we don't actually need this. But let's try some patriotism.
-
Tata authored
this activates the package by default when using the batman feature while still allowing to explicitly remove it like this: GLUON_SITE_PACKAGES := \ -gluon-ebtables-limit-arp
-
- Sep 01, 2018
-
-
Matthias Schiffer authored
gluon-config-mode-geo-location-osm extends the gluon-config-mode-geo-location with a location picker based on OpenStreetMaps. Based-on-patch-by:
Jan-Tarek Butt <tarek@ring0.de>
-
Matthias Schiffer authored
The new code is shorter and uses more readable variable names. It does not depend on specifically named input fields anymore (allowing to use multiple maps on the same page), and only uses well-defined interfaces to trigger revalidation of input fields. The Map model class allows to add OSM maps to gluon-web forms.
-
Matthias Schiffer authored
-
Matthias Schiffer authored
-
Matthias Schiffer authored
-
Matthias Schiffer authored
-
Matthias Schiffer authored
Can be used for inserting Lua values into inline JS code.
-
Matthias Schiffer authored
At least the ifindex and the flags fields can be larger than 0xff. Fixes #1523
-
- Aug 24, 2018
-
-
David Bauer authored
Let gluon-respondd expose "MemAvailable" from /proc/meminfo to allow for a more realistic memory-usage estimation. Information on MemAvailable can be found here: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/ commit/?id=34e431b0ae398fc54ea69ff85ec700722c9da773
-
David Bauer authored
-
Tata authored
-
- Aug 23, 2018
-
-
Matthias Schiffer authored
-
- Aug 19, 2018
-
-
Matthias Schiffer authored
As already done with other config mode texts, the altitude field now has default texts that are used when they are not set in the site i18n files. The altitude-help text has been removed from site i18n; instead, the geo-location-help text now overrides the whole section description including the part that mentions the altitude.
-
Matthias Schiffer authored
Do not show by default, delete old altitude value when a form without altitude shown is saved. Fixes #1493
-
- Aug 06, 2018
-
-
Ruben Barkow authored
-
- Aug 03, 2018
-
-
Andreas Ziegler authored
Revert "gluon-core: make sure dns traffic leaves the correct interface when there is ipv6 wan uplink" This reverts commit b3d70111. with this change, DNS in batman-adv based networks is broken. although the revert breaks babel based networks, this is not as big of a problem.
-
- Aug 01, 2018
-
-
Christof Schulze authored
-
Christof Schulze authored
-
Christof Schulze authored
-
Christof Schulze authored
-
Christof Schulze authored
-
- Jul 29, 2018
-
-
Tata authored
Signed-off-by:
Jan-Tarek Butt <tarek@ring0.de>
-
- Jul 25, 2018
-
-
Felix Kaechele authored
Signed-off-by:
Felix Kaechele <felix@kaechele.ca>
-
Ruben Barkow authored
-
Ruben Barkow authored
-
Sven Eckelmann authored
This device is a dual 5GHz device. It is recommended to manually change the radio of the first device to the lower 5GHz channels and the second radio to the upper 5GHz channels.
-
Sven Eckelmann authored
-
- Jul 22, 2018
-
-
Sven Eckelmann authored
The commit b3762fc6 ("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 and 5 are problematic here because packets use the node specific MAC addresses from br-client instead of the anycast MAC address. The client will receive the ARP packet with the node specific MAC address and change their own neighbor IP (translation) table. This will for example break the access to the status page to the connected device or the anycast DNS forwarder implementation when the client roams to a different node. This reverts commit b3762fc6 and adds an upgrade code to remove local_node_route on on existing installations.
-
Sven Eckelmann authored
The commit b3762fc6 ("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: b3762fc6 ("gluon-client-bridge: move IPv4 local subnet route to br-client (#1312)")
-
- Jul 19, 2018
-
-
Adorfer authored
-
- Jul 17, 2018
-
-
Matthias Schiffer authored
-
Matthias Schiffer authored
-