Skip to content
Snippets Groups Projects

Compare revisions

Changes are shown as if the source revision was being merged into the target revision. Learn more about comparing revisions.

Source

Select target project
No results found
Select Git revision
Loading items

Target

Select target project
  • firmware/gluon
  • 0x4A6F/gluon
  • patrick/gluon
3 results
Select Git revision
Loading items
Show changes
Show whitespace changes
Inline Side-by-side
Showing
with 2764 additions and 492 deletions
docs/releases/v2023.2.3.rst 0 → 100644
View file @ ac84ddf1
Gluon 2023.2.3
==============
Added hardware support
----------------------
ath79-generic
~~~~~~~~~~~~~
- NETGEAR
- WNDRMAC v2
mpc85xx-p1020
~~~~~~~~~~~~~
- Hewlett-Packard
- MSM460
Bugfixes
--------
* Factory images for TP-Link Archer C7 v2 now contain the correct region code
(`#3260 <https://github.com/freifunk-gluon/gluon/issues/3260>`_)
* Fixed an issue where some bootloader versions of the NETGEAR EX6150 v2 failed
to boot Gluon images in rare cases
(`Upstream <https://github.com/openwrt/openwrt/commit/de59fc45402ff03e320264c8204f6928090534ad>`_)
* Fixed boot procedure becoming stuck on Enterasys WS-AP3710i devices
(`#3248 <https://github.com/freifunk-gluon/gluon/issues/3248>`_)
Known issues
------------
* Unstable wireless with certain MediaTek devices (`#3154 <https://github.com/freifunk-gluon/gluon/issues/3154>`_)
* The integration of the BATMAN_V routing algorithm is incomplete.
- Mesh neighbors don't appear on the status page. (`#1726 <https://github.com/freifunk-gluon/gluon/issues/1726>`_)
Many tools have the BATMAN_IV metric hardcoded, these need to be updated to account for the new throughput
metric.
- Throughput values are not correctly acquired for different interface types.
(`#1728 <https://github.com/freifunk-gluon/gluon/issues/1728>`_)
This affects virtual interface types like bridges and VXLAN.
* Default TX power on many Ubiquiti devices is too high, correct offsets are unknown
(`#94 <https://github.com/freifunk-gluon/gluon/issues/94>`_)
Reducing the TX power in the Advanced Settings is recommended.
* In configurations without VXLAN, the MAC address of the WAN interface is modified even when Mesh-on-WAN is disabled
(`#496 <https://github.com/freifunk-gluon/gluon/issues/496>`_)
This may lead to issues in environments where a fixed MAC address is expected (like VMware when promiscuous mode is disallowed).
docs/releases/v2023.2.4.rst 0 → 100644
View file @ ac84ddf1
Gluon 2023.2.4
==============
Added hardware support
----------------------
ramips-mt7620
~~~~~~~~~~~~~
- NETGEAR
- EX6130
ramips-mt7621
~~~~~~~~~~~~~
- Xiaomi
- Mi Router 4A (Gigabit Edition v2)
ramips-mt76x8
~~~~~~~~~~~~~
- TP-Link
- RE200 (v4)
Bugfixes
--------
* Fixed an issue where Enterasys WS-AP3710i devices regularly boot with all-zero MAC-addresses in previous releases
* Detection of `swconfig` based switch architecture has been fixed (`#3309 <https://github.com/freifunk-gluon/gluon/pull/3309>`_)
* Fixed an issue where the AVM FRITZ!Box 4040 used an incorrect primary MAC address
(`Upstream <https://github.com/openwrt/openwrt/commit/87fbb5085d7e290b0ba536ad7d0876c4224723a6>`_)
Known issues
------------
* Unstable wireless with certain MediaTek devices (`#3154 <https://github.com/freifunk-gluon/gluon/issues/3154>`_)
* The integration of the BATMAN_V routing algorithm is incomplete.
- Mesh neighbors don't appear on the status page. (`#1726 <https://github.com/freifunk-gluon/gluon/issues/1726>`_)
Many tools have the BATMAN_IV metric hardcoded, these need to be updated to account for the new throughput
metric.
- Throughput values are not correctly acquired for different interface types.
(`#1728 <https://github.com/freifunk-gluon/gluon/issues/1728>`_)
This affects virtual interface types like bridges and VXLAN.
* Default TX power on many Ubiquiti devices is too high, correct offsets are unknown
(`#94 <https://github.com/freifunk-gluon/gluon/issues/94>`_)
Reducing the TX power in the Advanced Settings is recommended.
* In configurations without VXLAN, the MAC address of the WAN interface is modified even when Mesh-on-WAN is disabled
(`#496 <https://github.com/freifunk-gluon/gluon/issues/496>`_)
This may lead to issues in environments where a fixed MAC address is expected (like VMware when promiscuous mode is disallowed).
docs/releases/v2023.2.5.rst 0 → 100644
View file @ ac84ddf1
Gluon 2023.2.5
==============
Added hardware support
----------------------
ath79-generic
~~~~~~~~~~~~~
- Sophos
- AP15C
ramips-mt7621
~~~~~~~~~~~~~
- Genexis
- Pulse EX400
Bugfixes
--------
* VXLAN encapsulated mesh traffic arriving at a client interface is now filtered and not forwarded to the mesh
* Fixed a missing import in `libgluonutil` which led to undefined behavior on 64 bit architectures
Known issues
------------
* Unstable wireless with certain MediaTek devices (`#3154 <https://github.com/freifunk-gluon/gluon/issues/3154>`_)
* The integration of the BATMAN_V routing algorithm is incomplete.
- Mesh neighbors don't appear on the status page. (`#1726 <https://github.com/freifunk-gluon/gluon/issues/1726>`_)
Many tools have the BATMAN_IV metric hardcoded, these need to be updated to account for the new throughput
metric.
- Throughput values are not correctly acquired for different interface types.
(`#1728 <https://github.com/freifunk-gluon/gluon/issues/1728>`_)
This affects virtual interface types like bridges and VXLAN.
* Default TX power on many Ubiquiti devices is too high, correct offsets are unknown
(`#94 <https://github.com/freifunk-gluon/gluon/issues/94>`_)
Reducing the TX power in the Advanced Settings is recommended.
* In configurations without VXLAN, the MAC address of the WAN interface is modified even when Mesh-on-WAN is disabled
(`#496 <https://github.com/freifunk-gluon/gluon/issues/496>`_)
This may lead to issues in environments where a fixed MAC address is expected (like VMware when promiscuous mode is disallowed).
docs/releases/v2023.2.rst 0 → 100644
View file @ ac84ddf1
Gluon 2023.2
============
Important notes
---------------
Upgrades to v2023.2 and later releases are only supported from releases v2022.1 and later.
This is due to migrations that have been removed to simplify maintenance.
Deprecation of Tunneldigger VPN
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Tunneldigger is set to be removed from the Gluon base repository in the next major Gluon release. It is recommended
to migrate to fastd or WireGuard. Tunneldigger will be moved to the
community-packages repository and can be installed from there as an alternative.
Site changes
------------
Image customization
~~~~~~~~~~~~~~~~~~~
``GLUON_FEATURES`` and ``GLUON_SITE_PACKAGES`` have been replaced by a more flexible customization framework
based on Lua. Feature and Package selection can be specified more granularly at both target and device level.
All site configs need to be updated. Configuration like the following
must be removed from ``site.mk``:
.. code-block:: make
GLUON_FEATURES := \
autoupdater \
mesh-batman-adv-15 \
mesh-vpn-fastd \
respondd \
status-page \
web-advanced \
web-wizard
GLUON_FEATURES_standard := \
wireless-encryption-wpa3
GLUON_SITE_PACKAGES := iwinfo
It is replaced by a new file ``image-customization.lua`` with content
like the following:
.. code-block:: lua
features({
'autoupdater',
'mesh-batman-adv-15',
'mesh-vpn-fastd',
'respondd',
'status-page',
'web-advanced',
'web-wizard',
})
if not device_class('tiny') then
features({
'wireless-encryption-wpa3',
})
end
packages({'iwinfo'})
Additionally, this framework also allows communities to specify which devices should or should not be built.
For more information, see the :ref:`image customization documentation <site-image-customization>`.
Added hardware support
----------------------
armsr-armv7
~~~~~~~~~~~
- Arm
- Arm SystemReady 32-bit (EFI) [#virt]_
armsr-armv8
~~~~~~~~~~~
- Arm
- Arm SystemReady 64-bit (EFI) [#virt]_
.. [#virt]
The ArmSR targets can be used for running Gluon as a Virtual Machine on
Arm systems.
ath79-generic
~~~~~~~~~~~~~
- AVM
- FRITZ!Repeater 1750E
- Sophos
- AP100
- AP100c
- AP55
- AP55c
- TP-Link
- Archer C60 (v1)
- EAP225-Outdoor v3
- TL-WR2543N/ND (v1)
ath79-mikrotik
~~~~~~~~~~~~~~
- MikroTik
- wAPR-2nD (wAP R)
ipq40xx-generic
~~~~~~~~~~~~~~~
- ZTE
- MF289F
mediatek-filogic
~~~~~~~~~~~~~~~~
- ASUS
- TUF-AX4200
- Cudy
- WR3000 (v1)
- GL.iNet
- GL-MT3000
- NETGEAR
- WAX220
- Ubiquiti
- Unifi 6 Plus
- ZyXEL
- NWA50AX Pro
mpc85xx-p1010
~~~~~~~~~~~~~
- Enterasys
- WS-AP3715i
ramips-mt7621
~~~~~~~~~~~~~
- TP-Link
- EAP615-Wall
- Wavlink
- WS-WN572HP3 4G
ramips-mt76x8
~~~~~~~~~~~~~
- ASUS
- RT-AX53U
- ZyXEL
- WSM20
Removed hardware support
------------------------
ath79-generic
~~~~~~~~~~~~~
- TP-Link
- Archer C60 (v1)
- RE355
- RE450 (v1)
- Ubiquiti
- NanoBeam 5AC 19 (XC) [#airmax]_
- NanoBeam M5 (XW) [#airmax]_
- NanoStation Loco M2/M5 (XW) [#airmax]_
- NanoStation M2/M5 (XW) [#airmax]_
.. [#airmax]
Ubiquiti airMax devices have been removed temporarily due to an unsolved issue with the flash write-protect.
They will eventually be re-added once the issue has been fixed upstream.
(`#2939 <https://github.com/freifunk-gluon/gluon/issues/2939>`_)
ramips-mt7621
~~~~~~~~~~~~~
- TP-Link
- RE305
Features
--------
TLS support
~~~~~~~~~~~
Gluon now provides HTTPS client support when the `tls` feature is included in the site
configuration, allowing nodes to establish encrypted connections to autoupdater mirrors,
opkg repositories and other HTTPS servers.
Existing site configurations that add libustream TLS packages should switch to the `tls`
feature instead, which will always include the recommended TLS implementation as well
as common CA certificates (`ca-bundle`).
EFI images
~~~~~~~~~~
Gluon x86-64 images now support systems using EFI boot. The same images are still compatible
with legacy MBR boot methods.
Support for CAKE with fastd
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Gluon now supports CAKE as a QoS mechanism with fastd. It is automatically enabled with devices
offering at least 200MB of system memory. CAKE is enabled when throughput limits are configured
for the mesh-VPN.
For more information about the technical details, see the
(`OpenWrt wiki <https://openwrt.org/docs/guide-user/network/traffic-shaping/sqm>`_).
Support can be activated by including the `mesh-vpn-sqm` feature in the site configuration.
Docker container
~~~~~~~~~~~~~~~~
The Gluon build-container is now published to the GitHub container registry.
The container contains all the tools required to build Gluon images from source.
See the (`container registry <https://github.com/freifunk-gluon/gluon/pkgs/container/gluon-build>`_) for more information.
GitHub actions
~~~~~~~~~~~~~~
Gluon build tests now run inside a Docker container built from the gluon-build Dockerfile of the same version.
Bugfixes
--------
- Fixed script failure when reconfiguring interface groups without an assigned role.
- Host tools used to be built twice on first compilation.
Major changes
-------------
This release is based on the newest OpenWrt 23.05 release branch.
It ships with Linux kernel 5.15.y, wireless-backports 6.1.24 and batman-adv 2023.1.
.. _releases-v2023.2-minor-changes:
Minor changes
-------------
- D-Link DIR-825 B1 factory images are no longer built due to size constraints.
Please use a recent OpenWrt 23.05 image for factory installation and install Gluon
using sysupgrade.
- The robots.txt now prohibits crawling the status page.
- Changed the order in which Gluon installs packages into the OpenWrt build system
to favor Gluon and site packages over upstream OpenWrt packages.
- If enough nodes are updated, the batman-adv multicast optimizations originally introduced in Gluon 2021.1 for link-local IPv6 multicast addresses
will be applied within the domain to routable IPv6 multicast addresses.
- Gluon now uses mbedtls instead of WolfSSL for hostapd and wpa-supplicant.
Known issues
------------
* The integration of the BATMAN_V routing algorithm is incomplete.
- Mesh neighbors don't appear on the status page. (`#1726 <https://github.com/freifunk-gluon/gluon/issues/1726>`_)
Many tools have the BATMAN_IV metric hardcoded, these need to be updated to account for the new throughput
metric.
- Throughput values are not correctly acquired for different interface types.
(`#1728 <https://github.com/freifunk-gluon/gluon/issues/1728>`_)
This affects virtual interface types like bridges and VXLAN.
* Default TX power on many Ubiquiti devices is too high, correct offsets are unknown
(`#94 <https://github.com/freifunk-gluon/gluon/issues/94>`_)
Reducing the TX power in the Advanced Settings is recommended.
* In configurations without VXLAN, the MAC address of the WAN interface is modified even when Mesh-on-WAN is disabled
(`#496 <https://github.com/freifunk-gluon/gluon/issues/496>`_)
This may lead to issues in environments where a fixed MAC address is expected (like VMware when promiscuous mode is disallowed).
docs/requirements.txt 0 → 100644
View file @ ac84ddf1
Sphinx==8.2.3
sphinx-rtd-theme==3.0.2
docs/site-example/i18n/de.po
View file @ ac84ddf1
......@@ -12,33 +12,97 @@ msgstr ""
msgid "gluon-config-mode:welcome"
msgstr ""
"Willkommen zum Einrichtungsassistenten für deinen neuen Entenhausener "
"Willkommen zum Einrichtungsassistenten für deinen neuen Alpha Centauri "
"Freifunk-Knoten. Fülle das folgende Formular deinen Vorstellungen "
"entsprechend aus und sende es ab."
msgid "gluon-config-mode:domain"
msgstr "Domäne"
msgid "gluon-config-mode:domain-select"
msgstr ""
"Hier hast du die Möglichkeit, die Mesh-Domäne, in der sich dein Knoten "
"befindet, auszuwählen. Bitte denke daran, dass sich dein Knoten nur mit den "
"Knoten der ausgewählten Domäne verbinden kann."
msgid "gluon-config-mode:pubkey"
msgstr ""
"<p>Dies ist der öffentliche Schlüssel deines Freifunk-Knotens. Erst nachdem "
"er auf den Servern des Entenhausener Freifunk-Projektes eingetragen wurde, "
"kann sich dein Knoten mit dem Entenhausener Mesh-VPN verbinden. Bitte "
"schicke dazu diesen Schlüssel und den Namen deines Knotens "
"(<em><%=hostname%></em>) an "
"<a href=\"mailto:keys@entenhausen.freifunk.net\">keys@entenhausen.freifunk.net</a>."
"er auf den Servern des Freifunk-Projektes auf Alpha Centauri eingetragen "
"wurde, kann sich dein Knoten mit dem Mesh-VPN dort verbinden. Bitte schicke "
"dazu diesen Schlüssel und den Namen deines Knotens "
"(<em><%=pcdata(hostname)%></em>) an "
"<a href=\"mailto:keys@alpha-centauri.freifunk.net?subject="
"<%= urlencode('Anmeldung: ' .. hostname) %>&amp;body="
"<%= urlencode('# ' .. hostname .. '\n# ' .. sysconfig.primary_mac .. '\nkey ') %>"
"%22<%= pubkey %>%22;"
"<%= urlencode('\n\nIch habe zur Kenntnis genommen, dass der im ') %>"
"<%= urlencode('Knoten von mir eingetragene Kontakt im Meshnetz ') %>"
"<%= urlencode('öffentlich abfragbar ist und von beliebigen Diensten ') %>"
"<%= urlencode('(z.B. der Freifunk-Karte) veröffentlicht werden kann.') %>"
"<%= urlencode('\n\nGruß, \n\n') %>"
"\">keys@alpha-centauri.freifunk.net</a>. Deine E-Mail Adresse wird "
"selbstverständlich vertraulich behandelt und nicht weitergegeben."
"</p>"
"<div class=\"the-key\">"
" # <%= hostname %>"
" <br/>"
"# <%= pcdata(hostname) %><br>"
"<%= pubkey %>"
"</div>"
"<p>Dein Knoten startet gerade neu und wird anschließend versuchen, sich mit "
"anderen Freifunkknoten in seiner Nähe über WLAN sowie über deine "
"Internetverbindung über das VPN-Gateway zu verbinden.</p>"
"<p>Vergiss nicht das Netzwerkkabel vom LAN Port in den WAN Port "
"umzustecken.</p>"
msgid "gluon-config-mode:novpn"
msgstr ""
"<p><strong>Du hast ausgewählt die Internetverbindung (Mesh-VPN) nicht zu "
"nutzen</strong>. Dein Knoten kann also nur dann eine Verbindung zum "
"Freifunk-Netz aufbauen, wenn andere Freifunk-Knoten in WLAN-Reichweite sind.</p>"
"<p>Bitte schicke uns eine E-Mail mit dem Namen deines Knotens "
"(<em><%= pcdata(hostname) %></em>) und ein paar Informationen an <a href="
"\"mailto:kontakt@alpha-centauri.freifunk.net?"
"subject=<%= urlencode('Anmeldung: ' .. hostname) %>&amp;"
"body=<%= urlencode('# ' .. hostname .. '\n# ' .. sysconfig.primary_mac .. '\n# kein mesh-VPN') %>"
"<%= urlencode('\n\nIch habe zur Kenntnis genommen, dass der im ') %>"
"<%= urlencode('Knoten von mir eingetragene Kontakt im Meshnetz ') %>"
"<%= urlencode('öffentlich abfragbar ist und von beliebigen Diensten ') %>"
"<%= urlencode('(z.B. der Freifunk-Karte) veröffentlicht werden kann.') %>"
"<%= urlencode('\n\nGruß, \n\n') %>"
"\">kontakt@alpha-centauri.freifunk.net</a>. Deine E-Mail Adresse wird "
"selbstverständlich vertraulich behandelt und nicht weitergegeben.</p>"
"<p>Dein Knoten <em><%= pcdata(hostname) %></em> startet gerade neu und wird "
"anschließend versuchen, sich mit anderen Freifunkknoten in seiner Nähe über "
"WLAN zu verbinden.</p>"
msgid "gluon-config-mode:reboot"
msgstr ""
"<p>Dein Knoten startet gerade neu und wird anschließend versuchen, "
"sich mit anderen Freifunkknoten in seiner Nähe zu "
"verbinden. Weitere Informationen zur "
"Entenhausener Freifunk-Community findest du auf "
"<a href=\"https://entenhausen.freifunk.net/\">unserer Webseite</a>.</p>"
"<p>Weitere Informationen zur "
"Alpha Centauri Freifunk-Community findest du auf "
"<a href=\"https://alpha-centauri.freifunk.net/\" target=\"_blank\">unserer "
"Webseite</a>.</p>"
"<p>Um zu dieser Konfigurationsseite zurückzugelangen, drücke im normalen "
"Betrieb für drei Sekunden den Reset-Button. Das Gerät wird dann im Config "
"Betrieb für ca. 10 Sekunden den Reset-Button. Das Gerät wird dann im Config "
"Mode neustarten.</p>"
"<p>Viel Spaß mit deinem Knoten und der Erkundung von Freifunk!</p>"
# Leave empty to use the default text, which can be found in:
# package/gluon-config-mode-hostname/i18n/
msgid "gluon-config-mode:hostname-help"
msgstr ""
# Leave empty to use the default text, which can be found in:
# package/gluon-config-mode-geo-location/i18n/
msgid "gluon-config-mode:geo-location-help"
msgstr ""
msgid "gluon-config-mode:altitude-label"
msgstr ""
# Leave empty to use the default text, which can be found in:
# package/gluon-config-mode-contact-info/i18n/
msgid "gluon-config-mode:contact-help"
msgstr ""
msgid "gluon-config-mode:contact-note"
msgstr ""
docs/site-example/i18n/en.po
View file @ ac84ddf1
......@@ -2,8 +2,8 @@ msgid ""
msgstr ""
"Content-Type: text/plain; charset=UTF-8\n"
"Project-Id-Version: PACKAGE VERSION\n"
"PO-Revision-Date: 2015-03-19 20:28+0100\n"
"Last-Translator: Matthias Schiffer <mschiffer@universe-factory.net>\n"
"PO-Revision-Date: 2016-02-04 14:28+0100\n"
"Last-Translator: David Lutz <kpanic@hirnduenger.de>\n"
"Language-Team: English\n"
"Language: en\n"
"MIME-Version: 1.0\n"
......@@ -12,31 +12,91 @@ msgstr ""
msgid "gluon-config-mode:welcome"
msgstr ""
"Welcome the the setup wizard of your new Freifunk Duckburg node. "
"Please fill out the following form and transmit it."
"Welcome to the setup wizard of your new Freifunk Alpha Centauri node. Please "
"fill out the following form and submit it."
msgid "gluon-config-mode:domain"
msgstr "Domain"
msgid "gluon-config-mode:domain-select"
msgstr ""
"Here you have the possibility of selecting the mesh domain in which your node "
"is placed. Please keep in mind that your router only connects with the nodes "
"of the selected domain."
msgid "gluon-config-mode:pubkey"
msgstr ""
"<p>This is your Freifunk node's public key. The node won't be able to "
"connect to the mesh VPN until the key has been registered on the Freifunk "
"Duckburg servers. "
"To register the key send it together with your node's name (<em><%=hostname%></em>) to "
"<a href=\"mailto:keys@entenhausen.freifunk.net\">keys@entenhausen.freifunk.net</a>."
"</p>"
"servers. To register, send the key together with your node's name "
"(<em><%=pcdata(hostname)%></em>) to "
"<a href=\"mailto:keys@alpha-centauri.freifunk.net?subject="
"<%= urlencode('Registration: ' .. hostname) %>&amp;body="
"<%= urlencode('# ' .. hostname .. '\n# ' .. sysconfig.primary_mac .. '\nkey ') %>"
"%22<%= pubkey %>%22;"
"<%= urlencode('\n\nI have taken note that the contact I entered in the ') %>"
"<%= urlencode('node is publicly available on the Internet and can be ') %>"
"<%= urlencode('used by any services (e.g. the meshviewer map).') %>"
"<%= urlencode('\n\nThanks, \n\n') %>"
"\">keys@alpha-centauri.freifunk.net</a>. Of course, your e-mail address will "
"be treated confidentially and will not be passed on.</p>"
"<div class=\"the-key\">"
" # <%= hostname %>"
" <br/>"
" # <%= pcdata(hostname) %><br>"
"<%= pubkey %>"
"</div>"
"<p>Your node <em><%= pcdata(hostname) %></em> is currently rebooting and will "
"try to connect to other nearby Freifunk nodes via WLAN and to a VPN-gateway "
"via your internet connection after the reboot is finished.</p>"
"<p>Don't forget to plug the network cable from the LAN port to the WAN port."
"</p>"
msgid "gluon-config-mode:novpn"
msgstr ""
"<p>You have selected <strong>not</strong> to use the mesh VPN. "
"Your node will only be able to connect to the Freifunk network if other nodes "
"in reach already have a connection.</p>"
"<p>Please send an e-mail with the name of your node "
"(<em><%=pcdata(hostname)%></em>) and some additional information to "
"<a href=\"mailto:kontakt@alpha-centauri.freifunk.net?subject="
"<%= urlencode('Registration: ' .. hostname) %>&amp;body="
"<%= urlencode('# ' .. hostname .. '\n# ' .. sysconfig.primary_mac .. '\nkey ') %>"
"%22<%= pubkey %>%22;"
"<%= urlencode('\n\nI have taken note that the contact I entered in the ') %>"
"<%= urlencode('node is publicly available on the Internet and can be ') %>"
"<%= urlencode('used by any services (e.g. the meshviewer map).') %>"
"<%= urlencode('\n\nThanks, \n\n') %>"
"\">kontakt@alpha-centauri.freifunk.net</a>. Of course, your e-mail address will "
"be treated confidentially and will not be passed on.</p>"
"<p>Your node <em><%= pcdata(hostname) %></em> is currently rebooting and will "
"try to connect to other nearby Freifunk nodes after that.</p>"
msgid "gluon-config-mode:reboot"
msgstr ""
"<p>The node is currently rebooting and will try to connect to other "
"nearby Freifunk nodes after that. "
"Your can find lots of information on the Freifunk Duckburg community on "
"<a href=\"https://entenhausen.freifunk.net/\">our homepage</a>.</p>"
"<p>For more information about the Freifunk community on Alpha Centauri, have a "
"look at <a href=\"https://alpha-centauri.freifunk.net/\" target=\"_blank\">our "
"homepage</a>.</p>"
"<p>To get back to this configuration interface, press the reset button for "
"3 seconds during normal operation. The device will then reboot into config "
"mode.</p>"
"<p>Have fun with your node and exploring the Freifunk network!</p>"
"about 10 seconds during normal operation. The device will then reboot into "
"config mode.</p>"
"<p>Have fun with your node and exploring of the Freifunk network!</p>"
# Leave empty to use the default text, which can be found in:
# package/gluon-config-mode-hostname/i18n/
msgid "gluon-config-mode:hostname-help"
msgstr ""
# Leave empty to use the default text, which can be found in:
# package/gluon-config-mode-geo-location/i18n/
msgid "gluon-config-mode:geo-location-help"
msgstr ""
msgid "gluon-config-mode:altitude-label"
msgstr ""
# Leave empty to use the default text, which can be found in:
# package/gluon-config-mode-contact-info/i18n/
msgid "gluon-config-mode:contact-help"
msgstr ""
msgid "gluon-config-mode:contact-note"
msgstr ""
docs/site-example/i18n/fr.po
View file @ ac84ddf1
......@@ -14,30 +14,67 @@ msgid "gluon-config-mode:welcome"
msgstr ""
"Bienvenue dans l'assistant de configuration pour votre nouveau nœud "
"Freifunk. Remplissez le formulaire suivant en fonction de vos besoins "
"et enregistrez le"
"et enregistrez le."
msgid "gluon-config-mode:domain"
msgstr "Domaine"
msgid "gluon-config-mode:domain-select"
msgstr "Ici, vous avez la possibilité de sélectionner le domaine dans lequel "
"se trouve votre nœud. N'oubliez pas que votre nœud ne peut se connecter "
"qu'aux nœuds du domaine sélectionné."
msgid "gluon-config-mode:pubkey"
msgstr ""
"<p>Ceci est la clé publique de votre nœud Freifunk. Seulment après que la clé soit "
"entrée sur les serveurs de votre groupe de Freifunk votre nœud pourra se connecter "
"sur les serveur Mesh-VPN de votre groupe Freifunk. Veuillez envoyer la clé avec le "
"nom de votre nœud "
"(<em><%=hostname%></em>) à "
"<a href=\"mailto:keys@entenhausen.freifunk.net\">keys@entenhausen.freifunk.net</a>."
"<p>Ceci est la clé publique de votre nœud Freifunk. Seulment après que la clé "
"soit entrée sur les serveurs de votre groupe de Freifunk votre nœud pourra se "
"connecter sur les serveur Mesh-VPN de votre groupe Freifunk. Veuillez envoyer "
"la clé avec le nom de votre nœud "
"(<em><%=pcdata(hostname)%></em>) à "
"<a href=\"mailto:keys@alpha-centauri.freifunk.net?"
"subject=<%= urlencode('Enregistrement: ' .. hostname) %>&amp;"
"body=<%= urlencode('# ' .. hostname .. '\n' .. pubkey) %>\">keys@alpha-centauri.freifunk.net</a>."
"</p>"
"<div class=\"the-key\">"
" # <%= hostname %>"
" <br/>"
" # <%= pcdata(hostname) %><br>"
"<%= pubkey %>"
"</div>"
msgid "gluon-config-mode:novpn"
msgstr ""
"<p>Vous avez choisi de <strong>ne pas utiliser</strong> "
"le réseau VPN. Votre nœud ne pourra se connecter au réseau Freifunk que si "
"d'autres nœuds à portée ont déjà une connexion.</p>"
msgid "gluon-config-mode:reboot"
msgstr ""
"<p>Votre nœud es en train de redémarrer et va ensuite éssayer de se connecter "
"avec les autres nœuds du réseau Freifunk "
"<p>Votre nœud <em><%= pcdata(hostname) %></em> es en train de redémarrer et "
"va ensuite éssayer de se connecter avec les autres nœuds du réseau Freifunk "
"Vous pourrez trouver plus d'informations sur votre groupe Freifunk sur la page "
"<a href=\"https://entenhausen.freifunk.net/\"> de ton groupe </a>.</p> "
"<a href=\"https://alpha-centauri.freifunk.net/\" target=\"_blank\"> de ton "
"groupe </a>.</p>"
"<p> Pour retrouver cette page de configuration veuillier appuyez pendant le "
"fonctionement normal pendant 3 Secondes sur le bouton reset. L'appareil va ensuite "
"redémarer en mode configuration.</p> "
"fonctionement normal pendant 3 Secondes sur le bouton reset. L'appareil va "
"ensuite redémarer en mode configuration.</p>"
"<p>Profitez votre de nœud et amusez vous à découvrir le réseau Freifunk!</p>"
# Leave empty to use the default text, which can be found in:
# package/gluon-config-mode-hostname/i18n/
msgid "gluon-config-mode:hostname-help"
msgstr ""
# Leave empty to use the default text, which can be found in:
# package/gluon-config-mode-geo-location/i18n/
msgid "gluon-config-mode:geo-location-help"
msgstr ""
msgid "gluon-config-mode:altitude-label"
msgstr ""
# Leave empty to use the default text, which can be found in:
# package/gluon-config-mode-contact-info/i18n/
msgid "gluon-config-mode:contact-help"
msgstr ""
msgid "gluon-config-mode:contact-note"
msgstr ""
docs/site-example/i18n/gluon-site.pot
View file @ ac84ddf1
......@@ -4,8 +4,32 @@ msgstr "Content-Type: text/plain; charset=UTF-8"
msgid "gluon-config-mode:welcome"
msgstr ""
msgid "gluon-config-mode:domain"
msgstr ""
msgid "gluon-config-mode:domain-select"
msgstr ""
msgid "gluon-config-mode:pubkey"
msgstr ""
msgid "gluon-config-mode:novpn"
msgstr ""
msgid "gluon-config-mode:reboot"
msgstr ""
msgid "gluon-config-mode:hostname-help"
msgstr ""
msgid "gluon-config-mode:geo-location-help"
msgstr ""
msgid "gluon-config-mode:altitude-label"
msgstr ""
msgid "gluon-config-mode:contact-help"
msgstr ""
msgid "gluon-config-mode:contact-note"
msgstr ""
docs/site-example/image-customization.lua 0 → 100644
View file @ ac84ddf1
packages {'iwinfo'}
features {
'autoupdater',
'ebtables-filter-multicast',
'ebtables-filter-ra-dhcp',
'ebtables-limit-arp',
'mesh-batman-adv-15',
'mesh-vpn-fastd',
'respondd',
'status-page',
'web-advanced',
'web-wizard',
}
if not device_class('tiny') then
features {
'wireless-encryption-wpa3',
}
end
docs/site-example/modules
View file @ ac84ddf1
......@@ -12,7 +12,6 @@
# the git repository from where to clone the package feed
#PACKAGES_MY_OWN_PACKAGES_REPO=https://github.com/.../my-own-packages.git
## PACKAGES_$feedname_COMMIT
# the version/commit of the git repository to clone
#PACKAGES_MY_OWN_PACKAGES_COMMIT=123456789aabcda1a69b04278e4d38f2a3f57e49
......
docs/site-example/site.conf
View file @ ac84ddf1
-- This is an example site configuration for Gluon v2015.1+
-- This is an example site configuration for Gluon v2023.2.5
--
-- Take a look at the documentation located at
-- http://gluon.readthedocs.org/ for details.
-- https://gluon.readthedocs.io/ for details.
--
-- This configuration will not work as it. You're required to make
-- This configuration will not work as is. You're required to make
-- community specific changes to it!
{
-- Used for generated hostnames, e.g. freifunk-abcdef123456. (optional)
-- hostname_prefix = 'freifunk-',
-- Name of the community.
site_name = 'Freifunk Entenhausen',
site_name = 'Freifunk Alpha Centauri',
-- Shorthand of the community.
site_code = 'ffxx',
-- Prefixes used within the mesh. Both are required.
-- 32 bytes of random data, encoded in hexadecimal
-- This data must be unique among all sites and domains!
-- Can be generated using: echo $(hexdump -v -n 32 -e '1/1 "%02x"' </dev/urandom)
domain_seed = 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx',
-- Prefixes used within the mesh.
-- prefix6 is required, prefix4 can be omitted if next_node.ip4
-- is not set.
prefix4 = '10.xxx.0.0/20',
prefix6 = 'fdxx:xxxx:xxxx::/64',
-- Timezone of your community.
-- See http://wiki.openwrt.org/doc/uci/system#time_zones
-- See https://openwrt.org/docs/guide-user/base-system/system_configuration#time_zones
timezone = 'CET-1CEST,M3.5.0,M10.5.0/3',
-- List of NTP servers in your community.
......@@ -35,17 +42,21 @@
-- Wireless channel.
channel = 1,
-- ESSID used for client network.
-- ESSIDs used for client network.
ap = {
ssid = 'entenhausen.freifunk.net',
-- disabled = true, (optional)
-- ssid = 'alpha-centauri.freifunk.net', (optional - SSID for open client network)
-- disabled = true, -- (optional)
-- Configuration for a backward compatible OWE network below.
-- owe_ssid = 'owe.alpha-centauri.freifunk.net', -- (optional - SSID for OWE client network)
-- owe_transition_mode = true, -- (optional - enables transition-mode - requires ssid as well as owe_ssid)
},
mesh = {
-- Adjust these values!
id = 'ffxx-mesh',
id = 'ueH3uXjdp', -- usually you don't want users to connect to this mesh-SSID, so use a cryptic id that no one will accidentally mistake for the client WiFi
mcast_rate = 12000,
-- disabled = true, (optional)
-- disabled = true, -- (optional)
},
},
......@@ -54,24 +65,31 @@
-- for channel.
wifi5 = {
channel = 44,
outdoor_chanlist = '100-140',
ap = {
ssid = 'entenhausen.freifunk.net',
ssid = 'alpha-centauri.freifunk.net',
},
mesh = {
id = 'ffxx-mesh',
-- Adjust these values!
id = 'ueH3uXjdp',
mcast_rate = 12000,
},
},
mesh = {
vxlan = true,
batman_adv = {
routing_algo = 'BATMAN_IV',
},
},
-- The next node feature allows clients to always reach the node it is
-- connected to using a known IP address.
next_node = {
-- anycast IPs of all nodes
-- name = { 'nextnode.location.community.example.org', 'nextnode', 'nn' },
ip4 = '10.xxx.0.xxx',
ip6 = 'fdxx:xxxx:xxxx::xxxx',
-- anycast MAC of all nodes
mac = 'xe:xx:xx:xx:xx:xx',
},
-- Options specific to routing protocols (optional)
......@@ -85,15 +103,19 @@
-- },
-- },
-- Refer to http://fastd.readthedocs.org/en/latest/ to better understand
mesh_vpn = {
-- enabled = true,
fastd = {
-- Refer to https://fastd.readthedocs.io/en/latest/ to better understand
-- what these options do.
fastd_mesh_vpn = {
-- List of crypto-methods to use.
methods = {'salsa2012+umac'},
-- enabled = true,
mtu = 1312,
-- configurable = true,
-- syslog_level = 'warn',
mtu = 1280,
groups = {
backbone = {
-- Limit number of connected peers to reduce bandwidth.
......@@ -127,6 +149,7 @@
-- ...
-- },
},
},
bandwidth_limit = {
-- The bandwidth limit can be enabled by default here.
......@@ -141,7 +164,8 @@
},
autoupdater = {
-- Default branch. Don't forget to set GLUON_BRANCH when building!
-- Default branch (optional), can be overridden by setting GLUON_AUTOUPDATER_BRANCH when building.
-- Set GLUON_AUTOUPDATER_ENABLED to enable the autoupdater by default for newly installed nodes.
branch = 'stable',
-- List of branches. You may define multiple branches.
......@@ -150,7 +174,15 @@
name = 'stable',
-- List of mirrors to fetch images from. IPv6 required!
mirrors = {'http://1.updates.services.ffhl/stable/sysupgrade'},
mirrors = {
'http://1.updates.example.org/stable/sysupgrade',
-- Requires the tls feature in image-customization.lua
-- 'https://2.updates.example.org/stable/sysupgrade',
-- Uses http or https depending on the tls feature in image-customization.lua
'//3.updates.example.org/stable/sysupgrade',
},
-- Number of good signatures required.
-- Have multiple maintainers sign your build and only
......@@ -167,20 +199,4 @@
},
},
},
-- Node roles
-- roles = {
-- default = 'node',
-- list = {
-- 'node',
-- 'test',
-- 'backbone',
-- 'service',
-- },
-- },
-- Skip setup mode (config mode) on first boot
-- setup_mode = {
-- skip = true,
-- },
}
docs/site-example/site.mk
View file @ ac84ddf1
## gluon site.mk makefile example
## GLUON_SITE_PACKAGES
# specify gluon/openwrt packages to include here
# The gluon-mesh-batman-adv-* package must come first because of the dependency resolution
GLUON_SITE_PACKAGES := \
gluon-mesh-batman-adv-15 \
gluon-alfred \
gluon-announced \
gluon-autoupdater \
gluon-config-mode-autoupdater \
gluon-config-mode-contact-info \
gluon-config-mode-core \
gluon-config-mode-geo-location \
gluon-config-mode-hostname \
gluon-config-mode-mesh-vpn \
gluon-ebtables-filter-multicast \
gluon-ebtables-filter-ra-dhcp \
gluon-luci-admin \
gluon-luci-autoupdater \
gluon-luci-portconfig \
gluon-luci-wifi-config \
gluon-next-node \
gluon-mesh-vpn-fastd \
gluon-radvd \
gluon-setup-mode \
gluon-status-page \
haveged \
iptables \
iwinfo
## DEFAULT_GLUON_RELEASE
# version string to use for images
# gluon relies on
......@@ -38,6 +8,7 @@ GLUON_SITE_PACKAGES := \
DEFAULT_GLUON_RELEASE := 0.6+exp$(shell date '+%Y%m%d')
# Variables set with ?= can be overwritten from the command line
## GLUON_RELEASE
# call make with custom GLUON_RELEASE flag, to use your own release version scheme.
......@@ -46,11 +17,13 @@ DEFAULT_GLUON_RELEASE := 0.6+exp$(shell date '+%Y%m%d')
# would generate images named like this:
# gluon-ff%site_code%-23.42+5-%router_model%.bin
# Allow overriding the release number from the command line
GLUON_RELEASE ?= $(DEFAULT_GLUON_RELEASE)
# Default priority for updates.
GLUON_PRIORITY ?= 0
# Region code required for some images; supported values: us eu
GLUON_REGION ?= eu
# Languages to include
GLUON_LANGS ?= en de
docs/user/faq.rst
View file @ ac84ddf1
Frequently Asked Questions
==========================
.. _faq-hardware:
What hardware is supported?
~~~~~~~~~~~~~~~~~~~~~~~~~~~
A table with hardware supported by Gluon can be found on the `OpenWrt Wiki`_.
If you want to find out if your device can potentially be supported
have a look at :doc:`../dev/hardware` for detailed hardware requirements.
.. _OpenWrt Wiki: https://openwrt.org/toh/views/toh_gluon_supported
.. _faq-dns:
Why does DNS not work on the nodes?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Gluon nodes will ignore the DNS server on the WAN port for everything except
the mesh VPN, which can lead to confusion.
All normal services on the nodes exclusively use the DNS server on the mesh
interface. This DNS server must be announced in router advertisements (using
*radvd* or a similar software) from one or more central servers in meshes based
on *batman-adv*. If your mesh does not have global IPv6 connectivity, you can setup
your *radvd* not to announce a default route by setting the *default lifetime* to 0;
in this case, the *radvd* is only used to announce the DNS server.
.. _faq-lost-settings:
Which settings are retained or migrated upon an update?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Gluon provides a :doc:`../dev/web/config-mode`, which allows the configuration via webinterface.
Under the hood it uses UCI and sets options according to the users input.
There's a recurring misconception that all UCI settings are retained and migrated across
updates unconditionally. A settings presence does not imply this on its own.
Only if a setting is either configurable via the setupmode, or explicitly referenced
in this documentation - the wiki or other inofficial places do not count - it is supposed to
survive the update process.
All other options may be overridden, might disappear or lose functionality after a firmware update or already
after calling gluon-reconfigure.
.. _faq-gluon-preserve:
How can I retain options upon updates anyway?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For settings in the sections *network* and *system*, the option *gluon_preserve* can be set to true
in order to preserve the sections. However, this is still at a high risk and may result in broken setups.
There are two conditions that must hold:
- The preserved section must not already exist after OpenWrt's and
Gluon's setup scripts ran. Modifying existing sections is currently
unsupported.
- Preserved sections must be named, so it can be detected whether a
section conflicts with a preexisting one.
Furthermore, this merely ensures the existence, not the functionality of a UCI setting after the update.
docs/user/getting_started.rst
View file @ ac84ddf1
......@@ -8,7 +8,7 @@ Gluon's releases are managed using `Git tags`_. If you are just getting
started with Gluon we recommend to use the latest stable release of Gluon.
Take a look at the `list of gluon releases`_ and notice the latest release,
e.g. *v2014.3*. Always get Gluon using git and don't try to download it
e.g. *v2023.2.5*. Always get Gluon using git and don't try to download it
as a Zip archive as the archive will be missing version information.
Please keep in mind that there is no "default Gluon" build; a site configuration
......@@ -19,30 +19,46 @@ an old site configuration to a newer release of Gluon.
An example configuration can be found in the Gluon repository at *docs/site-example/*.
.. _Git tags: http://git-scm.com/book/en/Git-Basics-Tagging
.. _Git tags: https://git-scm.com/book/en/v2/Git-Basics-Tagging
.. _list of gluon releases: https://github.com/freifunk-gluon/gluon/releases
Dependencies
------------
To build Gluon, several packages need to be installed on the system. On a
freshly installed Debian Wheezy system the following packages are required:
freshly installed Debian Bullseye system the following packages are required:
* `clang`
* `git` (to get Gluon and other dependencies)
* `subversion`
* `python` (Python 3 doesn't work)
* `python3`
* `python3-dev`
* `python3-pyelftools`
* `python3-setuptools`
* `build-essential`
* `gawk`
* `unzip`
* `libncurses-dev` (actually `libncurses5-dev`)
* `libz-dev` (actually `zlib1g-dev`)
* `libssl-dev`
* `libelf-dev` (to build x86-64)
* `llvm`
* `wget`
* `rsync`
* `time` (built-in `time` doesn't work)
* `qemu-utils`
* `ecdsautils` (to sign firmware, see `contrib/sign.sh`)
* `swig`
We also provide a container environment that already tracks all these dependencies. It quickly gets you up and running, if you already have either Docker or Podman installed locally.
::
./scripts/container.sh
Building the images
-------------------
To build Gluon, first check out the repository. Replace *RELEASE* with the
version you'd like to checkout, e.g. *v2015.1*.
version you'd like to checkout, e.g. *v2023.2.5*.
::
......@@ -58,7 +74,7 @@ Now, enter the freshly created directory::
It's time to add (or create) your site configuration. If you already
have a site repository, just clone it::
git clone https://github.com/freifunk-duckburg/site-ffdb.git site
git clone https://github.com/freifunk-alpha-centauri/site-ffac.git site
If you want to build a new site, create a new git repository *site/*::
......@@ -78,51 +94,81 @@ Extensive documentation about the site configuration can be found at:
site directory should always be a git repository by itself; committing site-specific files
to the Gluon main repository should be avoided, as it will make updates more complicated.
Next go back to the top-level Gluon directory and build Gluon::
Next go back to the top-level Gluon directory and build Gluon\ [#make_update]_::
cd ..
make update # Get other repositories used by Gluon
make GLUON_TARGET=ar71xx-generic # Build Gluon
make GLUON_TARGET=ath79-generic # Build Gluon
When calling make, the OpenWrt build environment is prepared/updated.
In case of errors read the messages carefully and try to fix the stated issues (e.g. install tools not available yet).
In case of errors read the messages carefully and try to fix the stated issues
(e.g. install missing tools not available or look for Troubleshooting_ in the wiki.
``ar71xx-generic`` is the most common target and will generate images for most of the supported hardware.
.. _Troubleshooting: https://github.com/freifunk-gluon/gluon/wiki/Troubleshooting
``ath79-generic`` is the most common target and will generate images for most of the supported hardware.
To see a complete list of supported targets, call ``make`` without setting ``GLUON_TARGET``.
The built images can be found in the directory `output/images`. Of these, the factory
To build all targets use a loop like this::
for TARGET in $(make list-targets); do
make GLUON_TARGET=$TARGET
done
You should generally reserve 5GB of disk space and additionally about 10GB for each `GLUON_TARGET`.
The built images can be found in the directory `output/images`. Of these, the `factory`
images are to be used when flashing from the original firmware a device came with,
and sysupgrade is to upgrade from other versions of Gluon or any other OpenWRT-based
and `sysupgrade` is to upgrade from other versions of Gluon or any other OpenWrt-based
system.
You should reserve about 10GB of disk space for each `GLUON_TARGET`.
**Note:** The images for some models are identical; to save disk space, symlinks are generated instead
of multiple copies of the same image. If your webserver's configuration prohibits following
symlinks, you can use the following command to resolve these links while copying the images::
cp -rL output/images /var/www
The directory `output/debug` contains a compressed kernel image for each
architecture.
These can be used for debugging and should be stored along with the images to
allow debugging of kernel problems on devices in the field.
See :ref:`Debugging <dev-debugging-kernel-oops>` for more information.
.. rubric:: Footnotes
.. [#make_update] ``make update`` only needs to be called again after updating the
Gluon repository (using ``git pull`` or similar) or after changing branches,
not for each build. Running it more often than necessary is undesirable, as
the update will take some time, and may undo manual modifications of the
external repositories while developing on Gluon.
See :ref:`working-with-repositories` for more information.
Cleaning the build tree
.......................
There are two levels of `make clean`::
make clean GLUON_TARGET=ar71xx-generic
make clean GLUON_TARGET=ath79-generic
will ensure all packages are rebuilt for a single target; this is what you normally want to do after an update.
will ensure all packages are rebuilt for a single target. This is usually not
necessary, but may fix certain kinds of build failures.
::
make dirclean
will clean the entire tree, so the toolchain will be rebuilt as well, which is
not necessary in most cases, and will take a while.
will clean the entire tree, so the toolchain will be rebuilt as well, which will take a while.
opkg repositories
-----------------
Gluon is mostly compatible with OpenWrt, so the normal OpenWrt package repositories
can be used for Gluon as well. It is advisable to setup a mirror or reverse proxy
reachable over IPv6 and add it to ``site.conf`` as http://downloads.openwrt.org/ does
not support IPv6.
can be used for Gluon as well.
This is not true for kernel modules; the Gluon kernel is incompatible with the
kernel of the default OpenWrt images. Therefore, Gluon will not only generate images,
but also an opkg repositoy containing all kernel modules provided by OpenWrt/Gluon
for the kernel of the generated images.
but also an opkg repository containing all core packages provided by OpenWrt,
including modules for the kernel of the generated images.
Signing keys
............
......@@ -130,53 +176,122 @@ Signing keys
Gluon does not support HTTPS for downloading packages; fortunately, opkg deploys
public-key cryptography to ensure package integrity.
The Gluon images will contain two public keys: the official OpenWrt signing key
The Gluon images will contain public keys from two sources: the official OpenWrt keyring
(to allow installing userspace packages) and a Gluon-specific key (which is used
to sign the generated module repository).
to sign the generated package repository).
By default, Gluon will handle the generation and handling of the keys itself.
OpenWrt will handle the generation and handling of the keys itself.
When making firmware releases based on Gluon, it might make sense to store
the keypair, so updating the module repository later is possible.
The location the keys are stored at and read from can be changed
(see :ref:`getting-started-environment-variables`). To only generate the keypair
at the configured location without doing a full build, use ``make create-key``.
.. _getting-started-environment-variables:
Environment variables
---------------------
Gluon's build process can be controlled by various environment variables.
GLUON_SITEDIR
Path to the site configuration. Defaults to ``site``.
GLUON_BUILDDIR
Working directory during build. Defaults to ``build``.
GLUON_OPKG_KEY
Path key file used to sign the module opkg repository. Defaults to ``$(GLUON_BULDDIR)/gluon-opkg-key``.
The private key will be stored as ``$(GLUON_OPKG_KEY)``, the public key as ``$(GLUON_OPKG_KEY).pub``.
GLUON_OUTPUTDIR
Path where output files will be stored. Defaults to ``output``.
In fact you should take care to reuse the same opkg keypair, so you don't pollute the key
store (see ``/etc/opkg/keys``) on the node.
The signing-key is stored at ``openwrt/key-build.pub``, ``openwrt/key-build``,
``key-build.ucert`` and ``key-build.ucert.revoke``.
The ``openwrt`` directory is the Git checkout, that gets created after calling ``make update``.
After making a fresh clone copy the key files to the aforementioned locations.
.. _getting-started-make-variables:
Make variables
--------------
Gluon's build process can be controlled by various variables. They can
usually be set on the command line or in ``site.mk``.
Common variables
................
GLUON_AUTOUPDATER_BRANCH
Overrides the default branch of the autoupdater set in ``site.conf``. For the ``make manifest`` command,
``GLUON_AUTOUPDATER_BRANCH`` defines the branch to generate a manifest for.
GLUON_AUTOUPDATER_ENABLED
Set to ``1`` to enable the autoupdater by default for newly installed nodes.
GLUON_DEPRECATED
Controls whether images for deprecated devices should be built. The following
values are supported:
- ``0``: Do not build any images for deprecated devices.
- ``upgrade``: Only build sysupgrade images for deprecated devices.
- ``full``: Build both sysupgrade and factory images for deprecated devices.
Usually, devices are deprecated because their flash size is insufficient to
support future Gluon versions. The recommended setting is ``0`` for new sites,
and ``upgrade`` for existing configurations (where upgrades for existing
deployments of low-flash devices are required). Defaults to ``0``.
GLUON_LANGS
Space-separated list of languages to include for the config mode/advanced settings. Defaults to ``en``.
``en`` should always be included, other supported languages are ``de`` and ``fr``.
GLUON_PRIORITY
Defines the priority of an automatic update in ``make manifest``. See :doc:`../features/autoupdater` for
a detailed description of this value.
GLUON_REGION
Some devices (at the moment the TP-Link Archer C7) contain a region code that restricts
firmware installations. Set GLUON_REGION to ``eu`` or ``us`` to make the resulting
images installable from the respective stock firmware.
GLUON_RELEASE
Firmware release number: This string is displayed in the config mode, announced
via respondd/alfred and used by the autoupdater to decide if a newer version
is available. The same GLUON_RELEASE has to be passed to ``make`` and ``make manifest``
to generate a correct manifest.
GLUON_SITE_VERSION
Version of the site configuration. This string is displayed in the config mode
and ``gluon-info``. If unset, Gluon generates a version string using ``git describe``
on the site folder.
GLUON_TARGET
Target architecture to build.
Special variables
.................
GLUON_AUTOREMOVE
Setting ``GLUON_AUTOREMOVE=1`` enables the ``CONFIG_AUTOREMOVE`` OpenWrt setting, which will delete package build
directories after a package build has finished to save space. This is mostly useful for CI builds from scratch. Do
not set this flag during development (or generally, when you want to reuse your build tree for subsequent builds),
as it significantly increases incremental build times.
GLUON_DEBUG
The following values are supported:
- ``0``: Remove symbol tables and debug information as well as most section and other
information not strictly necessary for execution using ``sstrip``. This saves a small amount
of flash space over the default ``strip`` command (roughly 70kiB for ath79), but makes any
kind of binary analysis much more difficult, as common tools like objdump and gdb can't
handle such files at all.
- ``1``: Remove symbol tables and debug information from binaries using the standard ``strip``
command. This is the default.
- ``2``: Include debugging symbols usable with GDB or similar tools in all binaries of the image.
Requires a device or target with at least 16 MB of flash space, e.g. ``x86-64``.
GLUON_MINIFY
Setting ``GLUON_MINIFY=0`` will omit the minification of scripts during the build process. By
default the flag is set to ``1``. Disabling the flag is handy if human readable scripts on the
devices are desired for development purposes. Be aware that this will increase the size of the
resulting images and is therefore not suitable for devices with small flash chips.
GLUON_DEVICES
List of devices to build. The list contains the Gluon profile name of a device, the profile
name is the first parameter of the ``device`` command in a target file.
e.g. ``GLUON_DEVICES="avm-fritz-box-4020 tp-link-tl-wdr4300-v1"``.
Empty by default to build all devices of a target.
GLUON_IMAGEDIR
Path where images will be stored. Defaults to ``$(GLUON_OUTPUTDIR)/images``.
GLUON_MODULEDIR
Path where the kernel module opkg repository will be stored. Defaults to ``$(GLUON_OUTPUTDIR)/modules``.
GLUON_PACKAGEDIR
Path where the opkg package repository will be stored. Defaults to ``$(GLUON_OUTPUTDIR)/packages``.
So all in all, to update and rebuild a Gluon build tree, the following commands should be used (repeat the
``make clean`` and ``make`` for all targets you want to build):
::
GLUON_OUTPUTDIR
Path where output files will be stored. Defaults to ``output``.
git pull
(cd site && git pull)
make update
make clean GLUON_TARGET=ar71xx-generic
make GLUON_TARGET=ar71xx-generic
GLUON_SITEDIR
Path to the site configuration. Defaults to ``site``.
docs/user/mtu-diagram_v5.png 0 → 100644
View file @ ac84ddf1
docs/user/mtu-diagram_v5.png

67 KiB

docs/user/mtu.rst 0 → 100644
View file @ ac84ddf1
.. _mtu:
MTU for Mesh-VPN
================
What is a good MTU on the mesh-vpn?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Setting the MTU on the transport interface requires careful consideration, as
setting it too low will cause excessive fragmentation and setting it too high
may leave peers with a broken tunnel due to packet loss.
Consider these key values:
- Payload: Allow for the transport of IPv6 packets, by adhering to the minimum MTU
of 1280 Byte specified in RFC 2460
- and configure `MSS clamping`_ accordingly,
- and announce your link MTU via Router Advertisements and DHCP
.. _MSS clamping: https://tldp.org/HOWTO/Adv-Routing-HOWTO/lartc.cookbook.mtu-mss.html
- Encapsulation: Account for the overhead created by the configured mesh protocol
encapsulating the payload, which is up to 32 Byte (14 Byte Ethernet + 18 Byte
batman-adv).
- PMTU: What MTU does the path between your gateway and each of its peers support?
For reference, the complete MTU stack looks like this:
.. image:: mtu-diagram_v5.png
Example for Minimum MTU
-----------------------
Calculate the minimum transport MTU by adding the encapsulation overhead to the
minimum payload MTU required. This is the lowest recommended value, since going
lower would cause unnecessary fragmentation for clients which respect the announced
link MTU.
.. editorconfig-checker-disable
Example: Our network currently uses batman-adv v15, it therefore requires up
to 32 Bytes of encapsulation overhead on top of the minimal link MTU required for
transporting IPv6.::
\ 1312 1294 1280 0
\---------+-----------------+-------------+----------------------------------+
\TAP | batman-adv v15 | Ethernet | Payload |
\-------+-----------------+-------------+----------------------------------+
\ ^
|
MTU_LOW = 1280 Byte + 14 Byte + 18 Byte = 1312 Byte
Example for Maximum MTU
-----------------------
Calculating the maximum transport MTU is interesting, because it increases the
throughput, by allowing larger payloads to be transported, but also more difficult
as you have to take into account the tunneling overhead and each peers PMTU, which
varies between providers.
The underlying reasons are mostly PPPoE, tunneling and IPv6 transition technologies
like DS-Lite.
Example: The peer with the smallest MTU on your network is behind DS-Lite and can
transport IPv4 packets up to 1436 Bytes in size. Your tunnel uses IPv4 (20 Byte),
UDP (8 Byte), Fastd (24 byte) and you require TAP (14 Byte) for Layer 2 (Ethernet)
tunneling.::
1436 1416 1408 1384 1370 \
+-------------------+--------+-----------------------+-------------+------\
| IP | UDP | Fastd | TAP | bat\
+-------------------+--------+-----------------------+-------------+--------\
^ \
|
MTU_HIGH = 1436 Byte - 20 Byte - 8 Byte - 24 Byte - 14 Byte = 1370 Byte
.. editorconfig-checker-enable
Tables for Different VPN Providers
----------------------------------
VPN Protocol Overhead (IPv4)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Overhead of the VPN protocol layers in bytes on top of an Ethernet frame.
+----------+-------+-----------+
| | fastd | WireGuard |
+==========+=======+===========+
| IPv4 | 20 | 20 |
+----------+-------+-----------+
| UDP | 8 | 8 |
+----------+-------+-----------+
| Protocol | 24 | 32 |
+----------+-------+-----------+
| TAP | 14 | / |
+----------+-------+-----------+
| Sum | 66 | 60 |
+----------+-------+-----------+
Intermediate Layer Overhead
^^^^^^^^^^^^^^^^^^^^^^^^^^^
Overhead of additional layers on top of the VPN packet needed for different VPN
providers.
+------------+-------+-----------+
| | fastd | WireGuard |
+============+=======+===========+
| IPv6 | / | 40 |
+------------+-------+-----------+
| vxlan | / | 16 |
+------------+-------+-----------+
| Ethernet | / | 14 |
+------------+-------+-----------+
| Batman v15 | 18 | 18 |
+------------+-------+-----------+
| Ethernet | 14 | 14 |
+------------+-------+-----------+
| Sum | 32 | 102 |
+------------+-------+-----------+
Minimum MTU
^^^^^^^^^^^
Calculation of different derived MTUs based on a 1280 byte payload to
avoid fragmentation.
Suggestions:
- This configuration is only suggested for fastd.
- For WireGuard, this configuration is **unsuitable**. To obtain a 1280 byte
payload with our protocol stack (see below), the Ethernet frame payload would
be 1442 bytes long (for IPv4). As we assume that the WAN network might have
a (worst case) MTU of only 1436 (with DSLite), this packet would be too long
for the WAN network.
+-------------------------------+-------+-----------+
| | fastd | WireGuard |
+===============================+=======+===========+
| max unfragmented payload\* | 1280 | 1280 |
+-------------------------------+-------+-----------+
| intermediate layer overhead | 32 | 102 |
+-------------------------------+-------+-----------+
| VPN MTU\*\* | 1312 | 1382 |
+-------------------------------+-------+-----------+
| protocol overhead (IPv4) | 66 | 60 |
+-------------------------------+-------+-----------+
| min acceptable WAN MTU (IPv4) | 1378 | **1442** |
+-------------------------------+-------+-----------+
| min acceptable WAN MTU (IPv6) | 1398 | 1462 |
+-------------------------------+-------+-----------+
\* Maximum size of payload going into the bat0 interface, that will not be
fragmented by batman.
\*\* This is the MTU that is set in the site.conf.
Maximum MTU
^^^^^^^^^^^
Calculation of different derived MTUs based on a maximum WAN MTU of 1436.
Suggestions:
- This configuration can be used for fastd.
- For WireGuard, this is the recommended configuration. batman-adv will
fragment larger packets transparently to avoid packet loss.
+-------------------------------+-------+-----------+
| | fastd | WireGuard |
+===============================+=======+===========+
| min acceptable WAN MTU (IPv4) | 1436 | 1436 |
+-------------------------------+-------+-----------+
| protocol overhead (IPv4) | 66 | 60 |
+-------------------------------+-------+-----------+
| VPN MTU\*\* | 1370 | 1376 |
+-------------------------------+-------+-----------+
| intermediate layer overhead | 32 | 102 |
+-------------------------------+-------+-----------+
| max unfragmented payload\* | 1338 | 1274 |
+-------------------------------+-------+-----------+
| min acceptable WAN MTU (IPv6) | 1398 | 1462 |
+-------------------------------+-------+-----------+
\* Maximum size of payload going into the bat0 interface, that will not be
fragmented by batman.
\*\* This is the MTU that is set in the site.conf.
Suggested MSS Values
^^^^^^^^^^^^^^^^^^^^
It is highly advised to use MSS clamping for TCP on the gateways/supernodes in
order to avoid the fragmentation mechanism of batman whenever possible.
Especially on small embedded devices, fragmentation costs performance.
As batmans fragmentation is transparent to the TCP layer, clamping the MSS
automatically to the PMTU does not work. Instead, the MSS must be specified
explicitly. In iptables, this is done via :code:`-j TCPMSS --set-mss X`,
whereby :code:`X` is the desired MSS.
Since the MSS is specified in terms of payload of a TCP packet, the MSS is
different for IPv4 and IPv6. Here are some examples for different max
unfragmented payloads:
+---------------------------------+------+------+------+------+
| max unfragmented payload | 1274 | 1280 | 1338 | 1354 |
+=================================+======+======+======+======+
| suggested MSS (IPv4, -40 bytes) | 1234 | 1240 | 1298 | 1314 |
+---------------------------------+------+------+------+------+
| suggested MSS (IPv6, -60 bytes) | 1214 | 1220 | 1278 | 1294 |
+---------------------------------+------+------+------+------+
Conclusion
^^^^^^^^^^
Determining the maximum MTU can be a tedious process, especially since the PMTU
of peers could change at any time. The general recommendation for maximized
compatibility is therefore an MTU of 1312 bytes for fastd
and 1376 bytes for WireGuard.
docs/user/site.rst
View file @ ac84ddf1
......@@ -21,176 +21,335 @@ site_code
The code of your community. It is good practice to use the TLD of
your community here.
prefix4
The IPv4 Subnet of your community mesh network in CIDR notation, e.g.
::
domain_seed
32 bytes of random data, encoded in hexadecimal, used to seed other random
values specific to the mesh domain. It must be the same for all nodes of one
mesh, but should be different for firmware that is not supposed to mesh with
each other.
The recommended way to generate a value for a new site is::
echo $(hexdump -v -n 32 -e '1/1 "%02x"' </dev/urandom)
prefix4 \: optional
The IPv4 Subnet of your community mesh network in CIDR notation, e.g. ::
prefix4 = '10.111.111.0/18'
Required if ``next_node.ip4`` is set.
prefix6
The IPv6 subnet of your community mesh network, e.g.
::
The IPv6 subnet of your community mesh network, e.g. ::
prefix6 = 'fdca::ffee:babe:1::/64'
node_prefix6
The ipv6 prefix from which the unique IP-addresses for nodes are selected
in olsr-based networks. This may overlap with prefix6. e.g. ::
node_prefix6 = 'fdca::ffee:babe:2::/64'
timezone
The timezone of your community live in, e.g.
::
The timezone of your community live in, e.g. ::
-- Europe/Berlin
timezone = 'CET-1CEST,M3.5.0,M10.5.0/3'
ntp_server
List of NTP servers available in your community or used by your community, e.g.:
::
ntp_servers
List of NTP servers available in your community or used by your community, e.g.::
ntp_servers = {'1.ntp.services.ffeh','2.tnp.services.ffeh'}
ntp_servers = {'1.ntp.services.ffac','2.ntp.services.ffac'}
opkg : optional
These NTP servers must be reachable via IPv6 from the nodes. If you don't want to set an IPv6 address
explicitly, but use a hostname (which is recommended), see also the :ref:`FAQ <faq-dns>`.
opkg \: optional
``opkg`` package manager configuration.
There are two optional fields in the ``opkg`` section:
- ``openwrt`` overrides the default OpenWrt repository URL
- ``openwrt`` overrides the default OpenWrt repository URL. The default URL would
correspond to ``http://downloads.openwrt.org/snapshots/packages/%A``
and usually doesn't need to be changed when nodes are expected to have IPv6
internet connectivity.
- ``extra`` specifies a table of additional repositories (with arbitrary keys)
::
opkg = {
openwrt = 'http://opkg.services.ffeh/openwrt/%n/%v/%S/packages',
openwrt = 'http://opkg.services.ffac/openwrt/snapshots/packages/%A',
extra = {
modules = 'http://opkg.services.ffeh/modules/gluon-%GS-%GR/%S',
gluon = 'http://opkg.services.ffac/modules/gluon-%GS-%GR/%S',
},
}
There are various patterns which can be used in the URLs:
- ``%n`` is replaced by the OpenWrt version codename (e.g. "chaos_calmer")
- ``%v`` is replaced by the OpenWrt version number (e.g. "15.05")
- ``%S`` is replaced by the target architecture (e.g. "ar71xx/generic")
- ``%d`` is replaced by the OpenWrt distribution name ("openwrt")
- ``%v`` is replaced by the OpenWrt version number (e.g. "17.01")
- ``%S`` is replaced by the target board (e.g. "ath79/generic")
- ``%A`` is replaced by the target architecture (e.g. "mips_24kc")
- ``%GS`` is replaced by the Gluon site code (as specified in ``site.conf``)
- ``%GV`` is replaced by the Gluon version
- ``%GR`` is replaced by the Gluon release (as specified in ``site.mk``)
regdom : optional
The wireless regulatory domain responsible for your area, e.g.:
::
regdom \: optional
The wireless regulatory domain responsible for your area, e.g. ::
regdom = 'DE'
Setting ``regdom`` in mandatory if ``wifi24`` or ``wifi5`` is defined.
Setting ``regdom`` is mandatory if ``wifi24`` or ``wifi5`` is defined.
wifi24 : optional
wifi24 \: optional
WLAN configuration for 2.4 GHz devices.
``channel`` must be set to a valid wireless channel for your radio.
``beacon_interval`` can be specified to set a custom beacon interval in
time units (TU). A time unit is equivalent to 1024 µs.
If not set, the default value of 100 TU (=102.4 ms) is used.
There are currently three interface types available. You many choose to
There are currently two interface types available. You may choose to
configure any subset of them:
- ``ap`` creates a master interface where clients may connect
- ``mesh`` creates an 802.11s mesh interface with forwarding disabled
- ``ibss`` creates an ad-hoc interface
Each interface may be disabled by setting ``disabled`` to ``true``.
This will only affect new installations.
Upgrades will not changed the disabled state.
``ap`` requires a single parameter, a string, named ``ssid`` which sets the
interface's ESSID.
``mesh`` requires a single parameter, a string, named ``id`` which sets the mesh id.
``ibss`` requires two parametersr: ``ssid`` (a string) and ``bssid`` (a MAC).
An optional parameter ``vlan`` (integer) is supported.
Upgrades will not change the disabled state.
``ap`` holds the client network configuration.
To create an unencrypted client network, a string named ``ssid`` which sets the
interface's ESSID is required. This is the wireless network clients connect to.
For an OWE secured network, the ``owe_ssid`` string has to be set. It sets the
SSID for the opportunistically encrypted wireless network, to which compatible
clients can connect to.
For OWE to work, the ``wireless-encryption-wpa3`` has to be enabled as a feature
in your site.
To utilize the OWE transition mode, ``owe_transition_mode`` has to be set to true.
When ``owe_transition_mode`` is enabled, the OWE secured SSID will be hidden.
Compatible devices will automatically connect to the OWE secured SSID when selecting
the open SSID.
Note that for the transition mode to work, both ``ssid`` as well as ``owe_ssid``
have to be enabled. Also, some devices with a broken implementation might not be able
to connect with a transition-mode enabled network.
``mesh`` requires a single parameter, a string, named ``id`` which sets the
mesh id, also visible as an open WiFi in some network managers. Usually you
don't want users to connect to this mesh-SSID, so use a cryptic id that no
one will accidentally mistake for the client WiFi.
``mesh`` also accepts an optional ``mcast_rate`` (kbit/s) parameter for
setting the multicast bitrate. Increasing the default value of 1000 to something
like 12000 is recommended.
Both ``mesh`` and ``ibss`` accept an optional ``mcast_rate`` (kbit/s) parameter for
setting the default multicast datarate.
::
wifi24 = {
channel = 11,
ap = {
ssid = 'entenhausen.freifunk.net',
ssid = 'alpha-centauri.freifunk.net',
owe_ssid = 'owe.alpha-centauri.freifunk.net',
owe_transition_mode = true,
},
mesh = {
id = 'entenhausen-mesh',
mcast_rate = 12000,
},
ibss = {
ssid = 'ff:ff:ff:ee:ba:be',
bssid = 'ff:ff:ff:ee:ba:be',
id = 'ueH3uXjdp',
mcast_rate = 12000,
},
},
wifi5 : optional
Same as `wifi24` but for the 5Ghz radio.
.. _user-site-wifi5:
wifi5 \: optional
Same as `wifi24` but for the 5 GHz radio.
Additionally a range of channels that are safe to use outsides on the 5 GHz band can
be set up through ``outdoor_chanlist``, which allows for a space-separated list of
channels and channel ranges, separated by a hyphen.
When set this offers the outdoor mode flag for 5 GHz radios in the config mode which
reconfigures the AP to select its channel from outdoor chanlist, while respecting
regulatory specifications, and disables mesh on that radio.
The ``outdoors`` option in turn allows to configure when outdoor mode will be enabled.
When set to ``true`` all 5 GHz radios will use outdoor channels, while on ``false``
the outdoor mode will be completely disabled. The default setting is ``'preset'``,
which will enable outdoor mode automatically on outdoor-capable devices.
next_node : package
It can be beneficial to look up the WLAN channels that are used by `weather radars`_
when constructing ``outdoor_chanlist`` to try and minimize the impact of DFS events.
.. _weather radars: https://homepage.univie.ac.at/albert.rafetseder/RADARs/help.html
::
wifi5 = {
channel = 44,
outdoor_chanlist = "100-140",
[...]
},
next_node \: package
Configuration of the local node feature of Gluon
::
next_node = {
name = { 'nextnode.location.community.example.org', 'nextnode', 'nn' },
ip4 = '10.23.42.1',
ip6 = 'fdca:ffee:babe:1::1',
mac = 'ca:ff:ee:ba:be:00'
mac = '16:41:95:40:f7:dc'
}
mesh : optional
Options specific to routing protocols.
At the moment, only the ``batman_adv`` routing protocol has such options:
All values of this section are optional. If the IPv4 or IPv6 address is
omitted, there will be no IPv4 or IPv6 anycast address. The MAC address
defaults to ``16:41:95:40:f7:dc``; this value usually doesn't need to be
changed, but it can be adjusted to match existing deployments that use a
different value.
When the nodes' next-node address is used as a DNS resolver by clients
(by passing it via DHCP or router advertisements), it may be useful to
allow resolving a next-node hostname without referring to an upstream DNS
server (e.g. to allow reaching the node using such a hostname via HTTP or SSH
in isolated mesh segments). This is possible by providing one or more names
in the ``name`` field.
.. _user-site-mesh:
mesh
Configuration of general mesh functionality.
To avoid inter-mesh links, Gluon can encapsulate the mesh protocol in VXLAN
for Mesh-on-LAN/WAN. It is recommended to set *mesh.vxlan* to ``true`` to
enable VXLAN in new setups. Setting it to ``false`` disables this
encapsulation to allow meshing with other nodes that don't support VXLAN
(Gluon 2017.1.x and older). In multi-domain setups, *mesh.vxlan* is optional
and defaults to ``true``.
Gluon generally segments layer-2 meshes so that each node becomes IGMP/MLD
querier for its own local clients. This is necessary for reliable multicast
snooping. The segmentation is realized by preventing IGMP/MLD queries from
passing through the mesh. See also
:ref:`gluon-mesh-batman-adv <igmp-mld-domain-segmentation>` for details.
By default, not only queries are filtered, but also membership report and
leave packets, as they add to the background noise of the mesh. As a
consequence, snooping switches outside the mesh that are connected to a
Gluon node need to be configured to forward all multicast traffic towards
the mesh; this is usually not a problem, as such setups are unusual. If
you run a special-purpose mesh that requires membership reports to be
working, this filtering can be disabled by setting the
optional *filter_membership_reports* value to ``false``.
In addition, options specific to the batman-adv routing protocol can be set
in the *batman_adv* section:
The mandatory value *routing_algo* selects the batman-adv protocol variant.
The following values are supported:
- ``BATMAN_IV``
- ``BATMAN_V``
The optional value *gw_sel_class* sets the gateway selection class, the
default is ``20`` for B.A.T.M.A.N. IV and ``5000`` kbit/s for B.A.T.M.A.N. V.
- **B.A.T.M.A.N. IV:** with the value ``20`` the gateway is selected based
on the link quality (TQ) only; with class ``1`` it is calculated from
both, the TQ and the announced bandwidth.
- **B.A.T.M.A.N. V:** with the value ``1500`` the gateway is selected if the
throughput is at least 1500 kbit/s faster than the throughput of the
currently selected gateway.
For details on determining the threshold, when to switch to a new gateway,
see `batctl manpage`_, section "gw_mode".
.. _batctl manpage: https://www.open-mesh.org/projects/batman-adv/wiki/Gateways
The optional value ``gw_sel_class`` sets the gateway selection class. The default
class 20 is based on the link quality (TQ) only, class 1 is calculated from
both the TQ and the announced bandwidth.
::
mesh = {
vxlan = true,
filter_membership_reports = false,
batman_adv = {
routing_algo = 'BATMAN_IV',
gw_sel_class = 1,
},
}
fastd_mesh_vpn
Remote server setup for the fastd-based mesh VPN.
mesh_vpn
Remote server setup for the mesh VPN.
The `enabled` option can be set to true to enable the VPN by default.
The `enabled` option can be set to true to enable the VPN by default. `mtu`
defines the MTU of the VPN interface, determining a proper MTU value is described
in :doc:`mtu`.
By default the public key of a node's VPN daemon is not added to announced respondd
data; this prevents malicious ISPs from correlating VPN sessions with specific mesh
nodes via public respondd data. If this is of no concern in your threat model,
this behaviour can be disabled (and thus announcing the public key be enabled) by
setting `pubkey_privacy` to `false`.
The `fastd` section configures settings specific to the *fastd* VPN
implementation.
If `configurable` is set to `false` or unset, the method list will be replaced on updates
with the list from the site configuration. Setting `configurable` to `true` will allow the user to
add the method ``null`` to the beginning of the method list or remove ``null`` from it,
and make this change survive updates. Setting `configurable` is necessary for the
package `gluon-luci-mesh-vpn-fastd`, which adds a UI for this configuration.
package `gluon-web-mesh-vpn-fastd`, which adds a UI for this configuration.
In any case, the ``null`` method should always be the first method in the list
if it is supported at all. You should only set `configurable` to `true` if the
configured peers support both the ``null`` method and methods with encryption.
You can set syslog_level from verbose (default) to warn to reduce syslog output.
fastd allows to configure a tree of peer groups and peers. By default, the
list of groups and peers configured in the *fastd* UCI config is completely
replaced by the list from site.conf on upgrades. To allow custom modifications
to the peer list, removal and modification of peers can be prevented by
setting the *preserve* option of a peer to ``1`` in UCI.
**Note:** It may be interesting to include the package *gluon-iptables-clamp-mss-to-pmtu*
in the build when using *gluon-mesh-olsrd* to work around ICMP black holes on the internet.
::
fastd_mesh_vpn = {
methods = {'salsa2012+umac'},
mesh_vpn = {
-- enabled = true,
-- pubkey_privacy = true,
fastd = {
mtu = 1312,
methods = {'salsa2012+umac'},
-- configurable = true,
mtu = 1280,
-- syslog_level = 'warn',
groups = {
backbone = {
-- Limit number of connected peers from this group
limit = 2,
limit = 1,
peers = {
peer1 = {
key = 'XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX',
-- Having multiple domains prevents SPOF in freifunk.net
remotes = {
'ipv4 "vpn1.entenhausen.freifunk.net" port 10000',
'ipv4 "vpn1.entenhausener-freifunk.de" port 10000',
'ipv4 "vpn1.alpha-centauri.freifunk.net" port 10000',
'ipv4 "vpn1.alpha-centauri-freifunk.de" port 10000',
},
},
peer2 = {
key = 'XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX',
-- You can also omit the ipv4 to allow both connection via ipv4 and ipv6
remotes = {'"vpn2.entenhausen.freifunk.net" port 10000'},
remotes = {'"vpn2.alpha-centauri.freifunk.net" port 10000'},
},
peer3 = {
key = 'XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX',
-- In addition to domains you can also add ip addresses, which provides
-- resilience in case of dns outages
remotes = {
'"vpn3.alpha-centauri.freifunk.net" port 10000',
'[2001:db8::3:1]:10000',
'192.0.2.3:10000',
},
},
},
-- Optional: nested peer groups
......@@ -207,6 +366,21 @@ fastd_mesh_vpn
-- peers = { ... },
-- },
},
},
wireguard = {
mtu = 1376,
peers = {
vpn1 = {
public_key = 'XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX=',
endpoint = 'vpn1.alpha-centauri.freifunk.net:51810',
},
vpn2 = {
public_key = 'XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX=',
endpoint = 'vpn2.alpha-centauri.freifunk.net:51810',
},
},
},
bandwidth_limit = {
-- The bandwidth limit can be enabled by default here.
......@@ -220,24 +394,72 @@ fastd_mesh_vpn
},
}
mesh_on_wan : optional
Enables the mesh on the WAN port (``true`` or ``false``).
.. _user-site-interfaces:
interfaces \: optional
Default setup for Ethernet ports.
::
interfaces = {
lan = {
default_roles = { 'client', 'mesh' },
},
wan = {
default_roles = { 'uplink', 'mesh' },
},
single = {
default_roles = { 'uplink', 'mesh' },
},
},
For devices that have two distinct Ethernet ports or port groups (often
labeled WAN and LAN), the ``lan`` and ``wan`` sections are used. When there
is only one port (group), ``single`` is used instead.
mesh_on_lan : optional
Enables the mesh on the LAN port (``true`` or ``false``).
Available interface roles:
autoupdater : package
- ``client``: Port allows regular clients to connect to the mesh
- ``uplink``: Port is used to establish Mesh VPN connections
- ``mesh``: Wired meshing to another Gluon or Gluon-compatible node
The ``client`` role requires exclusive control over an interface. When
the ``client`` role is assigned to an interface at the same time as other
roles (like ``'client', 'mesh'`` in the above example), the other roles take
precedence (enabling ``mesh``, but not ``client`` in the example). In that
case, the ``client`` role is removed from the config of the interface.
All interface settings are optional. If unset, the following defaults are
used:
- ``lan``: ``{ 'client' }``
- ``wan``: ``{ 'uplink' }``
- ``single``: Same as ``wan``
poe_passthrough \: optional
Enable PoE passthrough by default on hardware with such a feature.
autoupdater \: package
Configuration for the autoupdater feature of Gluon.
Specifying a default branch in *site.conf* is optional. See
:doc:`../features/autoupdater` for information how to change the behaviour
of the autoupdater during image build.
The mirrors are checked in random order until the manifest could be downloaded
successfully or all mirrors have been tried.
::
autoupdater = {
branch = 'stable',
branch = 'stable', -- optional
branches = {
stable = {
name = 'stable',
mirrors = {
'http://[fdca:ffee:babe:1::fec1]/firmware/stable/sysupgrade/',
'http://autoupdate.entenhausen.freifunk.net/firmware/stable/sysupgrade/',
-- Requires the tls feature in image-customization.lua
'https://autoupdate.alpha-centauri.freifunk.net/firmware/stable/sysupgrade/',
-- Uses http or https depending on the tls feature in image-customization.lua
'//autoupdate2.alpha-centauri.freifunk.net/firmware/stable/sysupgrade/',
},
-- Number of good signatures required
good_signatures = 2,
......@@ -249,18 +471,94 @@ autoupdater : package
}
}
roles : optional
All configured mirrors must be reachable from the nodes via IPv6. If you don't want to set an IPv6 address
explicitly, but use a hostname (which is recommended), see also the :ref:`FAQ <faq-dns>`.
HTTPS URLs can be used if the **tls** feature is enabled in **image-customization.lua**.
Use protocol-less ``//server/path`` URLs to use HTTPS if the **tls** feature is available,
but fall back to HTTP otherwise. The server **must** allow HTTPS connections and provide
a valid certificate in this case; the autoupdater will not fall back to HTTP if the **tls**
feature is enabled, but the HTTPS connection fails.
Note that the validity period of TLS certificates is checked as well, so care must be taken
to provide working NTP servers in addition to the update mirrors when using HTTPS.
.. _user-site-config_mode:
config_mode \: optional
Additional configuration for the configuration web interface. All values are
optional.
When no hostname is specified, a default hostname based on the *hostname_prefix*
and the node's primary MAC address is assigned. Manually setting a hostname
can be enforced by setting *hostname.optional* to *false*.
To not prefill the hostname-field in config-mode with the default hostname,
set *hostname.prefill* to *false*.
By default, no altitude field is shown by the *gluon-config-mode-geo-location*
package. Set *geo_location.show_altitude* to *true* if you want the altitude
field to be visible.
The *geo_location.osm* section is only relevant when the *gluon-config-mode-geo-location-osm*
package is used. The *center.lon* and *center.lat* values are mandatory in this case and
define the default center of the map when no position has been picked yet. The *zoom* level
defaults to 12 in this case.
*openlayers_url* allows to override the base URL of the
*build/ol.js* and *css/ol.css* files (the default is
``https://cdn.jsdelivr.net/gh/openlayers/openlayers.github.io@35ffe7626ce16c372143f3c903950750075e7068/en/v5.3.0``).
It is also possible to replace the default tile layer (which is OpenStreetMap)
with a custom one using the *tile_layer* section. Only XYZ layers are supported
at this point.
The remote login page only shows SSH key configuration by default. A
password form can be displayed by setting *remote_login.show_password_form*
to true; in this case, *remote_login.min_password_length* defines the
minimum password length.
::
config_mode = {
hostname = {
optional = false,
prefill = true,
},
geo_location = {
show_altitude = true,
osm = {
center = {
lat = 52.951947558,
lon = 8.744238281,
},
zoom = 13,
-- openlayers_url = 'http://ffac.example.org/openlayer',
-- tile_layer = {
-- type = 'XYZ',
-- url = 'https://{a-c}.tile.openstreetmap.org/{z}/{x}/{y}.png',
-- attributions = '&#169; <a href="https://www.openstreetmap.org/copyright" target="_blank">OpenStreetMap</a> contributors.',
-- },
},
},
remote_login = {
show_password_form = true,
min_password_length = 10,
},
},
roles \: optional
Optional role definitions. Nodes will announce their role inside the mesh.
This will allow in the backend to distinguish between normal, backbone and
service nodes or even gateways (if they advertise that role). It is up to
the community which roles to define. See the section below as an example.
``default`` takes the default role which is set initially. This value should be
part of ``list``. If you want node owners to change the role via config mode add
the package ``gluon-luci-node-role`` to ``site.mk``.
the package ``gluon-web-node-role`` to ``site.mk``.
The strings to display in the LuCI interface can be configured per language in the
The strings to display in the web interface are configured per language in the
``i18n/en.po``, ``i18n/de.po``, etc. files of the site repository using message IDs like
``gluon-luci-node-role:role:node`` and ``gluon-luci-node-role:role:backbone``.
``gluon-web-node-role:role:node`` and ``gluon-web-node-role:role:backbone``.
::
roles = {
......@@ -273,7 +571,7 @@ roles : optional
},
},
setup_mode : package
setup_mode \: package
Allows skipping setup mode (config mode) at first boot when attribute
``skip`` is set to ``true``. This is optional and may be left out.
::
......@@ -282,30 +580,26 @@ setup_mode : package
skip = true,
},
legacy : package
Configuration for the legacy upgrade path.
This is only required in communities upgrading from Lübeck's LFF-0.3.x.
::
.. _user-site-build-configuration:
legacy = {
version_files = {'/etc/.freifunk_version_keep', '/etc/.eff_version_keep'},
old_files = {'/etc/config/config_mode', '/etc/config/ffeh', '/etc/config/freifunk'},
config_mode_configs = {'config_mode', 'ffeh', 'freifunk'},
fastd_configs = {'ffeh_mesh_vpn', 'mesh_vpn'},
mesh_ifname = 'freifunk',
tc_configs = {'ffki', 'freifunk'},
wifi_names = {'wifi_freifunk', 'wifi_freifunk5', 'wifi_mesh', 'wifi_mesh5'},
}
Packages
--------
Build configuration
-------------------
The ``site.mk`` is a Makefile which should define constants
The ``site.mk`` is a Makefile which defines various values
involved in the build process of Gluon.
GLUON_SITE_PACKAGES
Defines a list of packages which should be installed additionally
to the ``gluon-core`` package.
GLUON_DEPRECATED
Controls whether images for deprecated devices should be built. The following
values are supported:
- ``0``: Do not build any images for deprecated devices.
- ``upgrade``: Only build sysupgrade images for deprecated devices.
- ``full``: Build both sysupgrade and factory images for deprecated devices.
Usually, devices are deprecated because their flash size is insufficient to
support future Gluon versions. The recommended setting is ``0`` for new sites,
and ``upgrade`` for existing configurations (where upgrades for existing
deployments of low-flash devices are required). Defaults to ``0``.
GLUON_RELEASE
The current release version Gluon should use.
......@@ -314,10 +608,225 @@ GLUON_PRIORITY
The default priority for the generated manifests (see the autoupdater documentation
for more information).
GLUON_REGION
Region code to build into images where necessary. Valid values are the empty string,
``us`` and ``eu``.
GLUON_LANGS
List of languages (as two-letter-codes) to be included in the web interface. Should always contain
``en``.
.. _user-site-feature-flags:
Feature flags
^^^^^^^^^^^^^
With the addition of more and more features that interact in complex ways, it
has become necessary to split certain packages into multiple parts, so it is
possible to install just what is needed for a specific use case. One example
is the package *gluon-status-page-mesh-batman-adv*: There are batman-adv-specific
status page components; they should only be installed when both batman-adv and
the status page are enabled, making the addition of a specific package for this
combination necessary.
With the ongoing modularization, e.g. for the purpose of supporting new
routing protocols, specifying all such split packages in *site.mk* would
soon become very cumbersome: In the future, further components like
respondd support or languages might be split off as separate packages,
leading to entangled package names like *gluon-mesh-vpn-fastd-respondd* or
*gluon-status-page-mesh-batman-adv-i18n-de*.
For this reason, we have introduced *feature flags*, which can be specified
using the ``image-customization.lua`` file. These flags allow to specify
a set of features on a higher level than individual package names.
Most Gluon packages can simply be specified as feature flags by removing the ``gluon-``
prefix: The feature flag corresponding to the package *gluon-mesh-batman-adv-15* is
*mesh-batman-adv-15*.
The file ``package/features`` in the Gluon repository (or
``features`` in site feeds) can specify additional rules for deriving package lists
from feature flags, e.g. specifying both *status-page* and *mesh-batman-adv-15*
will automatically select the additional package
*gluon-status-page-mesh-batman-adv*. In the future, selecting the flags
*mesh-vpn-fastd* and *respondd* might automatically enable the additional
package *gluon-mesh-vpn-fastd-respondd*, and enabling *status-page* and
*mesh-batman-adv-15* with ``de`` in *GLUON_LANGS* could
add the package *gluon-status-page-mesh-batman-adv-i18n-de*.
In short, it is not necessary anymore to list all the individual packages that are
relevant for a firmware; instead, the package list is derived from a list of feature
flags using a flexible ruleset defined in the Gluon repo or site package feeds.
To some extent, it will even allow us to further modularize existing Gluon packages,
without necessitating changes to existing site configurations.
It is still possible to override such automatic rules by removing them using
*packages* in the ``image-customization.lua`` file
(e.g., ``features { '-gluon-status-page-mesh-batman-adv' }`` to remove
the automatically added package *gluon-status-page-mesh-batman-adv*).
For convenience, there are two feature flags that do not directly correspond to a Gluon
package:
* web-wizard
Includes the *gluon-config-mode-...* base packages (hostname, geolocation and contact info),
as well as the *gluon-config-mode-autoupdater* (when *autoupdater* is an enabled feature),
and *gluon-config-mode-mesh-vpn* (when *mesh-vpn-fastd* or `mesh-vpn-wireguard` are
enabled features)
* web-advanced
Includes the *gluon-web-...* base packages (admin, network, WiFi config),
as well as the *gluon-web-autoupdater* (when *autoupdater* is an enabled feature),
We recommend to include packages for non-Gluon OpenWrt packages only and
completely rely on features for Gluon packages, as it is shown in the
example *site.mk*.
.. _site-image-customization:
Image customization
^^^^^^^^^^^^^^^^^^^
Gluon allows configuration of the build parameters for the images. This
configuration must always exist to configure the basic features included in a
Gluon build.
The file ``image-customization.lua`` in the root of the site configuration is
used for this purpose, making use of a Domain Specific Language based on Lua.
See the :ref:`site-examples` section for a simple example showing both basic
setup and a device-specific alteration.
The following functions are available:
device(device_name_list)
Returns true for devices listed in ``device_name_list``.
``device_name_list`` is a table of strings.
.. code-block:: lua
if device {
'openmesh-a40',
'openmesh-a60',
} then
packages {'iperf3'}
end
target(openwrt_target, openwrt_subtarget)
Returns true for devices of the specified OpenWrt target and subtarget.
The parameter ``openwrt_subtarget`` is optional. If it is not specified,
the function matches all subtargets of the given target.
.. code-block:: lua
if target('x86', '64') then
features {'wireless-encryption-wpa3'}
end
device_class(dev_class)
Returns true in case the current device is of the specified device class.
.. code-block:: lua
if not device_class('tiny') then
features {'wireless-encryption-wpa3'}
end
features(feature_table)
Includes the specified list of features in the image. ``feature_table`` is a table of strings.
These strings can be prefixed with a dash to exclude features included earlier in the file.
.. code-block:: lua
features {
'autoupdater',
'ebtables-filter-multicast',
'ebtables-filter-ra-dhcp',
'ebtables-limit-arp',
'mesh-batman-adv-15',
'mesh-vpn-fastd',
'respondd',
'status-page',
'web-advanced',
'web-wizard',
}
packages(package_table)
Includes the specified list of packages in the image. ``package_table`` is a table of strings.
These strings can be prefixed with a dash to exclude packages included earlier in the file.
.. code-block:: lua
packages {'iwinfo'}
broken(broken_state)
Overrides the broken state specified by Gluon. Can be used to mark a device as broken or
remove the pre-defined broken state.
.. code-block:: lua
if device {'meraki-mr33-access-point'} then
broken(false)
end
disable()
Disables image generation.
.. code-block:: lua
if device {'tp-link-cpe220-v3'} then
disable()
end
disable_factory()
Disables factory image generation. Sysupgrade images are still generated and stored in the image
output directory.
.. code-block:: lua
if device {'tp-link-cpe220-v3'} then
disable_factory()
end
include(path)
Includes another image customization file. Relative paths are interpreted relative to the site
repository root.
.. code-block:: lua
:caption: target-settings.lua
features {'wireless-encryption-wpa3'}
.. code-block:: lua
:caption: image-customization.lua
if target('x86', '64') then
include 'target-settings.lua'
end
Values returned from the included file become the return value of ``include``:
.. code-block:: lua
:caption: matches-device.lua
return device {
'openmesh-a40',
'openmesh-a60',
}
.. code-block:: lua
:caption: image-customization.lua
if include('matches-device.lua') then
packages {'iperf3'}
end
Technically, the image customization file is evaluated once for each device, allowing
to make use of regular Lua *if* statements for device-specific configuration as
can be seen in the examples.
.. _site-config-mode-texts:
Config mode texts
......@@ -332,6 +841,24 @@ gluon-config-mode:welcome
gluon-config-mode:pubkey
Information about the public VPN key on the reboot page.
gluon-config-mode:novpn
Information shown on the reboot page, if the mesh VPN was not selected.
gluon-config-mode:contact-help
Description for the usage of the ``contact`` field
gluon-config-mode:contact-note
Note shown (in small font) below the ``contact`` field
gluon-config-mode:hostname-help
Description for the usage of the ``hostname`` field
gluon-config-mode:geo-location-help
Description for the usage of the longitude/latitude fields (and altitude, if shown)
gluon-config-mode:altitude-label
Label for the ``altitude`` field
gluon-config-mode:reboot
General information shown on the reboot page.
......@@ -349,6 +876,42 @@ utilities are installed.
Depending on the context, you might be able to use comments like
``<!-- empty -->`` as translations to effectively hide the text.
Site modules
------------
The file ``modules`` in the site repository is completely optional and can be used
to supply additional package feeds from which packages are built. The git repositories
specified here are retrieved in addition to the default feeds when ``make update``
is called.
This file's format is very similar to the top-level ``modules`` file of the Gluon
tree, with the important different that the list of feeds must be assigned to
the variable ``GLUON_SITE_FEEDS``. Multiple feed names must be separated by spaces,
for example::
GLUON_SITE_FEEDS='foo bar'
The feed names may only contain alphanumerical characters, underscores and slashes.
For each of the feeds, the following variables are used to specify how to update
the feed:
PACKAGES_${feed}_REPO
The URL of the git repository to clone (usually ``git://`` or ``http(s)://``)
PACKAGES_${feed}_COMMIT
The commit ID of the repository to use
PACKAGES_${feed}_BRANCH
Optional: The branch of the repository the given commit ID can be found in.
Defaults to the default branch of the repository (usually ``main`` or ``master``)
These variables are always all uppercase, so for an entry ``foo`` in GLUON_SITE_FEEDS,
the corresponding configuration variables would be ``PACKAGES_FOO_REPO``,
``PACKAGES_FOO_COMMIT`` and ``PACKAGES_FOO_BRANCH``. Slashes in feed names are
replaced by underscores to get valid shell variable identifiers.
.. _site-examples:
Examples
--------
......@@ -364,6 +927,12 @@ site.conf
.. literalinclude:: ../site-example/site.conf
:language: lua
image-customization.lua
^^^^^^^^^^^^^^^^^^^^^^^
.. literalinclude:: ../site-example/image-customization.lua
:language: lua
i18n/en.po
^^^^^^^^^^
......@@ -385,25 +954,5 @@ modules
site-repos in the wild
^^^^^^^^^^^^^^^^^^^^^^
This is a non-exhaustive list of site-repos from various communities:
* `site-ffa <https://github.com/tecff/site-ffa>`_ (Altdorf, Landshut & Umgebung)
* `site-ffbs <https://github.com/ffbs/site-ffbs>`_ (Braunschweig)
* `site-ffhb <https://github.com/FreifunkBremen/gluon-site-ffhb>`_ (Bremen)
* `site-ffda <https://github.com/freifunk-darmstadt/site-ffda>`_ (Darmstadt)
* `site-ffgoe <https://github.com/freifunk-goettingen/site-ffgoe>`_ (Göttingen)
* `site-ffhh <https://github.com/freifunkhamburg/site-ffhh>`_ (Hamburg)
* `site-ffhgw <https://github.com/lorenzo-greifswald/site-ffhgw>`_ (Greifswald)
* `site-ffhl <https://github.com/freifunk-luebeck/site-ffhl>`_ (Lübeck)
* `site-ffmd <https://github.com/FreifunkMD/site-ffmd>`_ (Magdeburg)
* `site-ffmwu <https://github.com/freifunk-mwu/site-ffmwu>`_ (Mainz, Wiesbaden & Umgebung)
* `site-ffmyk <https://github.com/FreifunkMYK/site-ffmyk>`_ (Mayen-Koblenz)
* `site-ffm <https://github.com/freifunkMUC/site-ffm>`_ (München)
* `site-ffms <https://github.com/FreiFunkMuenster/site-ffms>`_ (Münsterland)
* `site-ffnw <https://git.nordwest.freifunk.net/ffnw/siteconf/tree/master>`_ (Nordwest)
* `site-ffpb <https://git.c3pb.de/freifunk-pb/site-ffpb>`_ (Paderborn)
* `site-ffka <https://github.com/ffka/site-ffka>`_ (Karlsruhe)
* `site-ffrl <https://github.com/ffrl/sites-ffrl>`_ (Rheinland)
* `site-ffrg <https://github.com/ffruhr/site-ffruhr>`_ (Ruhrgebiet)
* `site-ffs <https://github.com/freifunk-stuttgart/site-ffs>`_ (Stuttgart)
* `site-fftr <https://github.com/freifunktrier/site-fftr>`_ (Trier)
A non-exhaustive list of site-repos from various communities can be found on the
wiki: https://github.com/freifunk-gluon/gluon/wiki/Site-Configurations
docs/user/supported_devices.rst 0 → 100644
View file @ ac84ddf1
Supported Devices & Architectures
=================================
armsr-armv7
-----------
* Arm SystemReady (EFI) 32-bit
armsr-armv8
-----------
* Arm SystemReady (EFI) 64-bit
ath79-generic
--------------
* ALFA Network
- AP121F
* AVM
- FRITZ!WLAN Repeater 300E [#avmflash]_
- Fritz!WLAN Repeater 450E [#avmflash]_
- Fritz!Box 4020 [#avmflash]_
* Buffalo
- WZR-HP-AG300H / WZR-600DHP
- WZR-HP-G300NH (rtl8366s)
* devolo
- WiFi pro 1200e [#lan_as_wan]_
- WiFi pro 1200i
- WiFi pro 1750c
- WiFi pro 1750e [#lan_as_wan]_
- WiFi pro 1750i
- WiFi pro 1750x
* D-Link
- DAP-1330 A1 [#lan_as_wan]_
- DAP-1365 A1 [#lan_as_wan]_
- DAP-2660 A1 [#lan_as_wan]_
- DAP-2680 A1 [#lan_as_wan]_
- DAP-2695 A1 [#lan_as_wan]_
- DIR-505 A1 [#lan_as_wan]_
- DIR-505 A2 [#lan_as_wan]_
- DIR-825 B1
* Enterasys
- WS-AP3705i
* Extreme Networks
- WS-AP3805i
* GL.iNet
- 6416A
- GL-AR150
- GL-AR300M-Lite
- GL-AR750
- GL-USB150 (Microuter)
* Joy-IT
- JT-OR750i
* LibreRouter
- LibreRouter v1 [#missing_radios]_
* NETGEAR
- WNDR3700 (v1, v2)
- WNDR3800
- WNR2200 (8M, 16M)
- WNDRMAC (v2)
* OCEDO
- Koala
- Raccoon
* Onion
- Omega [#modular_ethernet]_
* OpenMesh
- A40
- A60
- MR600 (v1, v2)
- MR900 (v1, v2)
- MR1750 (v1, v2)
- OM2P (v1, v2, v4)
- OM2P-HS (v1, v2, v3, v4)
- OM2P-LC
- OM5P
- OM5P-AC (v1, v2)
- OM5P-AN
* Plasma Cloud
- PA300
- PA300E
* Siemens
- WS-AP3610
* Sophos
- AP15C
- AP100
- AP100c
- AP55
- AP55c
* Teltonika
- RUT230 (v1)
* TP-Link
- Archer A7 (v5)
- Archer C5 (v1)
- Archer C6 (v2 EU/RU/JP)
- Archer C7 (v2, v4, v5)
- Archer C59 (v1)
- Archer C60 (v1)
- CPE210 (v1.0, v1.1, v2.0, v3.0, v3.1, v3.20)
- CPE220 (v3.0)
- CPE510 (v1.0, v1.1, v2.0, v3.0)
- CPE710 (v1.0)
- EAP225-Outdoor (v1, v3)
- TL-WDR3500 (v1)
- TL-WDR3600 (v1)
- TL-WDR4300 (v1)
- TL-WR810N (v1)
- TL-WR842N/ND (v3)
- TL-WR1043N/ND (v2, v3, v4, v5)
- TL-WR2543N/ND (v1)
- WBS210 (v1.20, v2.0)
- WBS510 (v1.20)
* Ubiquiti
- NanoBeam 5AC 19 (XC)
- NanoBeam M5 (XW)
- NanoStation Loco M2/M5 (XW)
- NanoStation M2/M5 (XW)
- UniFi AC Lite
- UniFi AC LR
- UniFi AC Mesh
- UniFi AC Mesh Pro
- UniFi AC Pro
- UniFi AP
- UniFi AP LR
- UniFi AP Outdoor+
- UniFi AP PRO
- UniFi Swiss Army Knife Ultra
ath79-mikrotik
--------------
* Mikrotik
- RB951Ui-2nD (hAP)
- RBwAPR-2nD (wAP R)
ath79-nand
----------
* Aerohive
- HiveAP 121
* GL.iNet
- GL-AR300M
- GL-AR750S
- GL-XE300
* NETGEAR
- WNDR3700 (v4)
- WNDR4300 (v1)
* Zyxel
- NBG6716
brcm2708-bcm2708
----------------
* Raspberry Pi 1
brcm2708-bcm2709
----------------
* Raspberry Pi 2
ipq40xx-generic
---------------
* 8devices
- Jalapeno
* Aruba
- AP-303
- AP-303H
- AP-365
- Instant On AP11
- Instant On AP11D
- Instant On AP17
* AVM
- FRITZ!Box 4040 [#avmflash]_
- FRITZ!Box 7520 (v1) [#eva_ramboot]_ [#lan_as_wan]_
- FRITZ!Box 7530 [#eva_ramboot]_ [#lan_as_wan]_
- FRITZ!Repeater 1200 [#eva_ramboot]_
* Extreme Networks
- WS-AP3915i
* GL.iNet
- GL-AP1300
- GL-B1300
* Linksys
- EA6350 (v3)
* NETGEAR
- EX6100 (v2)
- EX6150 (v2)
* OpenMesh
- A42
- A62
* Plasma Cloud
- PA1200
- PA2200
* Zyxel
- NBG6617
ipq40xx-mikrotik
----------------
* Mikrotik
- DISC Lite5 ac (RBDiscG-5acD)
- hAP ac2
- SXTsq 5 ac (RBSXTsqG-5acD)
ipq806x-generic
---------------
* NETGEAR
- R7800
* Ubiquiti
- UniFi AC HD
lantiq-xrx200
-------------
* Arcadyan
- VGV7510KW22 (o2 Box 6431)
* AVM
- FRITZ!Box 7360 (v1, v2) [#avmflash]_ [#lan_as_wan]_
- FRITZ!Box 7360 SL [#avmflash]_ [#lan_as_wan]_
- FRITZ!Box 7362 SL [#eva_ramboot]_ [#lan_as_wan]_
- FRITZ!Box 7412 [#eva_ramboot]_
lantiq-xrx200_legacy
--------------------
* TP-Link
- TD-W8970 (v1) [#lan_as_wan]_
lantiq-xway
-----------
* AVM
- FRITZ!Box 7312 [#avmflash]_
* NETGEAR
- DGN3500B [#lan_as_wan]_
mediatek-filogic
----------------
* ASUS
- RT-AX52
- TUF AX4200
- TUF AX6000
* Cudy
- AP3000 Outdoor (v1)
- TR3000 (v1)
- WR3000 (v1)
* D-Link
- AQUILA PRO AI M30 A1
- AQUILA PRO AI M60 A1
* GL.iNet
- GL-MT2500
- GL-MT3000
* NETGEAR
- WAX220
* OpenWrt
- One
* Ubiquiti
- UniFi 6 Plus
* Wavlink
- WL-WN573HX3 [#lan_as_wan]_
* Zyxel
- NWA50AX Pro
mediatek-mt7622
---------------
* Linksys
- E8450
* Ubiquiti
- UniFi 6 LR (v1)
mpc85xx-p1010
-------------
* Enterasys
- WS-AP3715i
* Sophos
- RED 15w Rev.1
* TP-Link
- TL-WDR4900 (v1)
mpc85xx-p1020
---------------
* Aerohive
- HiveAP 330
* Enterasys
- WS-AP3710i
* Extreme Networks
- WS-AP3825i
* Hewlett-Packard
- MSM460
* Ocedo
- Panda
ramips-mt7620
-------------
* ASUS
- RT-AC51U
* GL.iNet
- GL-MT300A
- GL-MT300N
- GL-MT750
* NETGEAR
- EX3700
- EX3800
- EX6130
* Nexx
- WT3020AD/F/H
* TP-Link
- Archer C2 (v1)
- Archer C20 (v1)
- Archer C20i
- Archer C50 (v1)
* Xiaomi
- MiWiFi Mini
ramips-mt7621
-------------
* ASUS
- RT-AC57U (v1)
- RT-AX53U
* Cudy
- WR1300 (v1)
- WR2100
- X6 (v1, v2)
* D-Link
- COVR-X1860 (A1)
- DAP-X1860 (A1)
- DIR-860L (B1)
- DIR-878 (A1)
- DIR-882 (A1)
* Genexis
- Pulse EX400
* GL.iNet
- GL-MT1300
* MERCUSYS
- MR70X (v1)
* NETGEAR
- EX6150 (v1)
- R6220
- R6260
- WAC104
- WAX202
* TP-Link
- EAX11 (v2)
- EAX12
- EAX15 (v2)
- EAP615-Wall (v1)
- RE500 (v1)
- RE650 (v1)
* Ubiquiti
- EdgeRouter X
- EdgeRouter X-SFP
- UniFi 6 Lite
- UniFi nanoHD
* Wavlink
- WS-WN572HP3 (4G)
* Xiaomi
- Xiaomi Mi Router 3G (v1, v2)
- Xiaomi Mi Router 4A (Gigabit Edition v1, v2)
* Zbtlink
- WG3526-16M
- WG3526-32M
* Zyxel
- NWA50AX
- WSM20
ramips-mt76x8
-------------
* Cudy
- TR1200 (v1)
- WR1000 (v1)
* GL.iNet
- GL-MT300N (v2)
- microuter-N300
- VIXMINI
* NETGEAR
- R6020
- R6120
* RAVPower
- RP-WD009
* TP-Link
- Archer C20 (v4, v5)
- Archer C50 (v3, v4)
- RE200 (v2, v3, v4)
- TL-MR3020 (v3)
- TL-MR3420 (v5)
- TL-MR6400 (v5)
- TL-WA801ND (v5)
- TL-WR841N (v13)
- TL-WR902AC (v3, v4)
* VoCore
- VoCore2
* Xiaomi
- Xiaomi Mi Router 4A (100M Edition) - MIR4A
- Xiaomi Mi Router 4A (100M International Edition) - R4AC
- Xiaomi Mi Router 4A (100M International Edition v2) - R4ACv2
- Xiaomi Mi Router 4C - R4CM
rockchip-armv8
--------------
* FriendlyElec
- NanoPi R2S
- NanoPi R3S
- NanoPi R4S (4GB LPDDR4)
sunxi-cortexa7
--------------
* LeMaker
- Banana Pi M1
x86-generic
-----------
* x86-generic
* x86-virtualbox
* x86-vmware
See also: :doc:`x86`
x86-geode
---------
* x86-geode
See also: :doc:`x86`
x86-64
------
* x86-64-generic
* x86-64-virtualbox
* x86-64-vmware
See also: :doc:`x86`
Footnotes
---------
.. [#avmflash]
For instructions on how to flash AVM devices, visit https://fritz-tools.readthedocs.io
.. [#eva_ramboot]
For instructions on how to flash AVM NAND devices, see the respective
commit which added support in OpenWrt.
.. [#lan_as_wan]
All LAN ports on this device are used as WAN.
.. [#missing_radios]
This device contains more than two WLAN radios, which is currently
unsupported by Gluon. Only the first two radios will work.
.. [#modular_ethernet]
These devices follow a modular principle,
which means even basic functionality like ethernet is provided by an expansion-board,
that may not be bundled with the device itself.
Such expansions are recommended for the config mode, but are not strictly necessary,
as exposed serial ports may grant sufficient access as well.
docs/user/x86.rst
View file @ ac84ddf1
......@@ -9,28 +9,26 @@ Targets
The following targets for x86 images exist:
`x86-generic`
Generic x86 support with many different ethernet drivers; should run on
most x86 systems.
`x86-64`
Generic x86 64-bit support with many different ethernet drivers; should run on
most x86 systems with 64-bit support.
There are three images:
* `generic` (compressed "raw" image, can written to a disk directly or booted with qemu)
* `generic` (compressed "raw" image, can be written to a disk directly or booted with qemu)
* `virtualbox` (VDI image)
* `vmware` (VMDK image)
These images only differ in the image file format, the content is the same. Therefore there is
only a single `x86-generic` sysupgrade image instead of three.
These images differ in the image file format, the content is the same. Therefore
a single `x86-64` sysupgrade image is provided, only.
Please note that the `x86-generic` image doesn't include VirtIO support, so another virtual NIC
like `pcnet32` must be chosen when using VirtualBox.
`x86-generic`
32-bit version of `x86-64` for hardware not supporting 64-bit images.
Also comes with `virtualbox` and `vmware` factory installs.
`x86-kvm`
The `x86-kvm` image uses VirtIO as its harddisk and network driver.
`x86-geode`
x86 image for Geode CPUs.
`x86-xen_domu`
The `x86-xen_domu` target contains the necessary drivers for use in Xen.
`x86-legacy`
x86 image for very old PC hardware like i586.
`x86-64`
64bit version of `x86-generic`. Also has VirtIO support, so there's no need for an
`x86-64-kvm` target.

Impressum - Datenschutz