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

Target

Select target project
  • ffbs/ffbs-gluon
  • parabol1337/ffbs-gluon
  • darkbit/ffbs-gluon
3 results
Show changes
Hide whitespace changes
Inline Side-by-side
Showing
with 726 additions and 323 deletions
docs/features/monitoring.rst
View file @ b9a90f4f
......@@ -47,7 +47,7 @@ installed. Please note that at least one alfred daemon is required to run as
.. _alfred-json: https://github.com/ffnord/alfred-json
The following datatypes are used:
The following data types are used:
* `nodeinfo`: 158
* `statistics`: 159
......
docs/features/multidomain.rst
View file @ b9a90f4f
......@@ -21,18 +21,18 @@ Overview
Multidomain support allows to build a single firmware with multiple,
switchable domain configurations. The nomenclature is as follows:
- ``site``: an aggregate over multiple domains
- ``domain``: mesh network with connectivity parameters that prevent
accidental bridging with other domains
- ``domain code``: unique domain identifier
- ``domain name``: pretty name for a domain code
- ``site``: an aggregate over multiple domains
- ``domain``: mesh network with connectivity parameters that prevent
accidental bridging with other domains
- ``domain code``: unique domain identifier
- ``domain name``: pretty name for a domain code
By default Gluon builds firmware with a single domain embedded into
``site.conf``. To use multiple domains, enable it in ``site.mk``:
::
GLUON_MULTIDOMAIN=1
GLUON_MULTIDOMAIN=1
In the site repository, create the ``domains/`` directory, which will
hold your domain configurations. Each domain configuration file is named
......@@ -41,26 +41,26 @@ supported.
::
site/
|-- site.conf
|-- site.mk
|-- i18n/
|-- domains/
|-- alpha_centauri.conf
|-- beta_centauri.conf
|-- gamma_centauri.conf
site/
|-- site.conf
|-- site.mk
|-- i18n/
|-- domains/
|-- alpha_centauri.conf
|-- beta_centauri.conf
|-- gamma_centauri.conf
The domain configuration ``alpha_centauri.conf`` could look like this.
::
{
domain_names = {
alpha_centauri = 'Alpha Centauri'
},
{
domain_names = {
alpha_centauri = 'Alpha Centauri'
},
-- more domain specific config follows below
}
-- more domain specific config follows below
}
In this example “Alpha Centauri” is the user-visible ``domain_name`` for the
domain_code ``alpha_centauri``. Also note that the domain code
......@@ -88,18 +88,25 @@ domain of a router, if and only if one of the above conditions matches.
Switching the domain
--------------------
**via commandline**:
Via commandline
^^^^^^^^^^^^^^^
::
uci set gluon.core.domain="newdomaincode"
gluon-reconfigure
reboot
gluon-switch-domain 'newdomaincode'
**via config mode:**
When the node is not in config mode, ``gluon-switch-domain`` will automatically
reboot the node by default. This can be suppressed by passing ``--no-reboot``::
To allow switching the domain via config mode, ``config-mode-domain-select``
has to be added to GLUON_FEATURES in the site.mk.
gluon-switch-domain --no-reboot 'newdomaincode'
Switching the domain without reboot is currently **experimental**.
Via config mode
^^^^^^^^^^^^^^^
To allow switching the domain via config mode, add ``config-mode-domain-select``
to the enabled features in the image-customization.lua file.
|image0|
......@@ -116,115 +123,113 @@ site or domain context.
site.conf only variables
^^^^^^^^^^^^^^^^^^^^^^^^
- Used in as initial default values, when the firmware was just flashed
and/or the config mode is skipped, so they do not make sense in a
domain specific way:
- authorized_keys
- default_domain
- poe_passthrough
- mesh_on_wan
- mesh_on_lan
- single_as_lan
- setup_mode.skip
- autoupdater.branch
- mesh_vpn.enabled
- mesh_vpn.pubkey_privacy
- mesh_vpn.bandwidth_limit
- mesh_vpn.bandwidth_limit.enabled
- mesh_vpn.bandwidth_limit.ingress
- mesh_vpn.bandwidth_limit.egress
- Variables that influence the appearance of the config mode,
domain-independent because they are relevant before a domain was selected.
- config_mode.geo_location.show_altitude
- config_mode.hostname.optional
- config_mode.remote_login
- config_mode.remote_login.show_password_form
- config_mode.remote_login.min_password_length
- hostname_prefix
- mesh_vpn.fastd.configurable
- roles.default
- roles.list
- Specific to a firmware build itself:
- site_code
- site_name
- autoupdater.branches.*.name
- autoupdater.branches.*.good_signatures
- autoupdater.branches.*.pubkeys
- We simply do not see any reason, why these variables could be helpful
in a domain specific way:
- mesh_vpn.fastd.syslog_level
- timezone
- regdom
- Used in as initial default values, when the firmware was just flashed
and/or the config mode is skipped, so they do not make sense in a
domain specific way:
- authorized_keys
- default_domain
- poe_passthrough
- interfaces.*.default_roles
- setup_mode.skip
- autoupdater.branch
- mesh_vpn.enabled
- mesh_vpn.pubkey_privacy
- mesh_vpn.bandwidth_limit
- mesh_vpn.bandwidth_limit.enabled
- mesh_vpn.bandwidth_limit.ingress
- mesh_vpn.bandwidth_limit.egress
- Variables that influence the appearance of the config mode,
domain-independent because they are relevant before a domain was selected.
- config_mode.geo_location.show_altitude
- config_mode.hostname.optional
- config_mode.remote_login
- config_mode.remote_login.show_password_form
- config_mode.remote_login.min_password_length
- hostname_prefix
- mesh_vpn.fastd.configurable
- roles.default
- roles.list
- Specific to a firmware build itself:
- site_code
- site_name
- autoupdater.branches.*.name
- autoupdater.branches.*.good_signatures
- autoupdater.branches.*.pubkeys
- We simply do not see any reason, why these variables could be helpful
in a domain specific way:
- mesh_vpn.fastd.syslog_level
- timezone
- regdom
domain.conf only variables
^^^^^^^^^^^^^^^^^^^^^^^^^^
- Obviously:
- Obviously:
- domain_names
- domain_names
- a table of domain codes to domain names
``domain_names = { foo = 'Foo Domain', bar = 'Bar Domain', baz = 'Baz Domain' }``
- a table of domain codes to domain names
``domain_names = { foo = 'Foo Domain', bar = 'Bar Domain', baz = 'Baz Domain' }``
- hide_domain
- hide_domain
- prevents a domain name(s) from appearing in config mode, either
boolean or array of domain codes
- prevents a domain name(s) from appearing in config mode, either
boolean or array of domain codes
- ``true``, ``false``
- ``{ 'foo', 'bar' }``
- ``true``, ``false``
- ``{ 'foo', 'bar' }``
- Because each domain is considered as an own layer 2 network, these
values should be different in each domain:
- Because each domain is considered a separate layer 2 network, these
values should be different in each domain:
- next_node.ip4
- next_node.ip6
- next_node.name
- prefix6
- prefix4
- extra_prefixes6
- next_node.ip4
- next_node.ip6
- next_node.name
- prefix6
- prefix4
- extra_prefixes6
- To prevent accidental bridging of different domains, all meshing
technologies should be separated:
- To prevent accidental bridging of different domains, all meshing
technologies should be separated:
- domain_seed (wired mesh)
- domain_seed (wired mesh)
- must be a random value used to derive the vxlan id for wired meshing
- must be a random value used to derive the vxlan id for wired meshing
- wifi*.mesh.id
- mesh_vpn.fastd.groups.*.peers.remotes
- mesh_vpn.fastd.groups.*.peers.key
- mesh_vpn.tunneldigger.brokers
- wifi*.mesh.id
- mesh_vpn.fastd.groups.*.peers.remotes
- mesh_vpn.fastd.groups.*.peers.key
- mesh_vpn.tunneldigger.brokers
- Clients consider WiFi networks sharing the same ESSID as if they were
the same L2 network and try to reconfirm and reuse previous
addressing. If multiple neighbouring domains shared the same ESSID,
the roaming experience of clients would degrade.
- Clients consider WiFi networks sharing the same ESSID as if they were
the same L2 network and try to reconfirm and reuse previous
addressing. If multiple neighbouring domains shared the same ESSID,
the roaming experience of clients would degrade.
- wifi*.ap.ssid
- wifi*.ap.ssid
- Some values should be only set in legacy domains and not in new domains.
- Some values should be only set in legacy domains and not in new domains.
- mesh.vxlan
- mesh.vxlan
- By default, this value is `true`. It should be only set to `false`
for one legacy domain, since vxlan prevents accidental wired
merges of domains. For old domains this value is still available
to keep compatibility between all nodes in one domain.
- By default, this value is `true`. It should be only set to `false`
for one legacy domain, since vxlan prevents accidental wired
merges of domains. For old domains this value is still available
to keep compatibility between all nodes in one domain.
- next_node.mac
- next_node.mac
- For new domains, the default value should be used, since there is
no need for a special mac (or domain specific mac). For old domains
this value is still available to keep compatibility between all
nodes in one domain.
- For new domains, the default value should be used, since there is
no need for a special mac (or domain specific mac). For old domains
this value is still available to keep compatibility between all
nodes in one domain.
Example config
--------------
......
docs/features/private-wlan.rst
View file @ b9a90f4f
Private WLAN
============
It is possible to set up a private WLAN that bridges the WAN port and is separated from the mesh network.
Please note that you should not enable ``mesh_on_wan`` simultaneously.
It is possible to set up a private WLAN that bridges the uplink port and is separated from the mesh network.
Please note that you should not enable Wired Mesh on the uplink port at the same time.
The private WLAN is encrypted using WPA2 by default. On devices with enough flash and a supported radio,
WPA3 or WPA2/WPA3 mixed-mode can be used instead of WPA2. For this to work, the ``wireless-encryption-wpa3``
feature has to be enabled as a feature.
It is recommended to enable IEEE 802.11w management frame protection for WPA2/WPA3 networks, however this
can lead to connectivity problems for older clients. In this case, management frame protection can be
made optional or completely disabled in the advanced settings tab.
The private WLAN can be enabled through the config mode if the package ``gluon-web-private-wifi`` is installed.
You may also enable a private WLAN using the command line::
......
docs/features/vpn.rst
View file @ b9a90f4f
Mesh-VPN
Mesh VPN
========
Gluon integrates several OSI-Layer 2 tunneling protocols to
enable interconnects between local meshes and provide
internetwork access. Available protocols currently are:
Gluon integrates several layer 2 tunneling protocols to
allow connections between local meshes through the internet.
- fastd
- L2TPv3 (via tunneldigger)
Protocol handlers
^^^^^^^^^^^^^^^^^
fastd is a lightweight userspace tunneling daemon, that
There are currently three protocol handlers which can be selected
as a feature:
mesh-vpn-fastd
""""""""""""""
fastd is a lightweight userspace tunneling daemon that
implements cipher suites that are specifically designed
to work well on embedded devices. It offers encryption
and authentication. Its primary drawback are the necessary
context-switches when forwarding packets.
L2TPv3 is an in-kernel tunneling protocol that performs well,
but offers no security properties by itself.
The brokering of the tunnel happens through tunneldigger,
its primary drawback being the lack of IPv6 support.
and authentication.
The primary drawback of fastd's encrypted connection modes
is the necessary context switches when forwarding packets.
A kernel-supported L2TPv3 offloading option is available to
work around the context-switching bottleneck, but it comes
at the cost of losing the ability to protect tunnel connections
against eavesdropping or manipulation.
mesh-vpn-tunneldigger
"""""""""""""""""""""
Tunneldigger always uses L2TPv3, generally achieving the same
performance as fastd with the ``null@l2tp`` method, but offering
no security.
Tunneldigger's primary drawback is the lack of IPv6 support.
It also provides less configurability than fastd.
mesh-vpn-wireguard
""""""""""""""""""
WireGuard is an encrypted in-kernel tunneling protocol that
provides encrypted transmission and at the same time offers
high throughput.
fastd
-----
^^^^^
Configurable Cipher
^^^^^^^^^^^^^^^^^^^
.. _VPN fastd methods:
Methods
"""""""
From the site configuration fastd can be allowed to offer
toggleable encryption in the config mode with the intent to
increase throughput, although in practice the gain is minimal.
fastd offers various different connection "methods" with different
security properties that can be configured in the site configuration.
**Site configuration:**
The following methods are currently recommended:
1) Add the feature ``web-mesh-vpn-fastd`` in ``site.mk``
2) Set ``mesh_vpn.fastd.configurable = true`` in ``site.conf``
3) Optionally add ``null`` to the ``mesh_vpn.fastd.methods`` table if you want "Performance mode" as default (not recommended)
- ``salsa2012+umac``: Encrypted + authenticated
- ``null+salsa2012+umac``: Unencrypted, authenticated
- ``null@l2tp``: Unencrypted, unauthenticated
**Gateway configuration:**
Multiple methods can be listed in ``site.conf``. The first listed method
supported by both the node and its peer will be used.
1) Prepend the ``null`` cipher in fastd's method list
The use of the ``null@l2tp`` method with offloading enabled can provide a
considerable performance gain, especially on weaker embedded hardware.
For L2TP offloading, the ``mesh-vpn-fastd-l2tp`` feature needs to be enabled in
``site.mk``.
**Config Mode:**
The resulting firmware will allow users to choose between secure (encrypted) and fast (unencrypted) transport.
.. _vpn-gateway-configuration:
.. image:: fastd_mode.gif
Gateway / Supernode Configuration
"""""""""""""""""""""""""""""""""
When only using the ``null`` or ``null@l2tp`` methods without offloading,
simply add these methods to the front of the method list. ``null@l2tp``
should always appear before ``null`` in the configuration when both are enabled.
fastd v22 or newer is needed for the ``null@l2tp`` method.
It is often not necessary to enable L2TP offloading on supernodes for
performance reasons. Nodes using offloading can communicate with supernodes that
don't use offloading as long as both use the ``null@l2tp`` method.
.. _vpn-gateway-configuration-offloading:
Offloading on Gateways / Supernodes
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
To enable L2TP offloading on the supernodes, it is recommended to study the
fastd documentation section pertaining to the `offload configuration option
<https://fastd.readthedocs.io/en/stable/manual/config.html#option-offload>`_.
However, the important changes to the fastd config on your Supernode are:
- | Set ``mode multitap;``
| Every peer gets their own interface.
- | Replace ``interface "foo":`` with ``interface "peer-%k";``
| ``%k`` is substituted for a portion of the peers public key.
- | Set ``offload l2tp yes;``
| This tells fastd to use the l2tp kernel module.
**Unix socket:**
To confirm whether the correct cipher is being used, fastds unix
socket can be interrogated, after installing for example `socat`.
- | Set ``persist interface no;``
| This tells fastd to only keep interfaces around while the connection is active.
::
Note that in ``multitap`` mode, which is required when using L2TP offloading,
fastd will create one interface per peer on the supernode's. This allows
offloading the L2TP forwarding into the kernel space. But this also means added
complexity with regards to handling those interfaces.
There are two main options on how you can handle this:
- create ``on up`` and ``on down`` hooks
- to handle interface setup and destruction
- preferably using the async keyword, so hooks are not blocking fastd
- use a daemon like systemd-networkd
Examples for both options can be found in the
`Wiki <https://github.com/freifunk-gluon/gluon/wiki/fastd-l2tp-offloading-on-supernodes>`_.
Configurable Method
"""""""""""""""""""
From the site configuration, fastd can be allowed to offer
toggleable encryption in the config mode with the intent to
increase throughput.
There is also an older unprotected method ``null``. Use of the newer
``null@l2tp`` method is generally recommended over ``null``, as the
performance gains provided by the latter (compared to the encrypted
and authenticated methods) are very small.
Site configuration
~~~~~~~~~~~~~~~~~~
1)
Add the feature ``web-mesh-vpn-fastd`` in ``site.mk``
2)
Set ``mesh_vpn.fastd.configurable = true`` in ``site.conf``
3)
Optionally, add ``null@l2tp`` to the ``mesh_vpn.fastd.methods`` table if you want
"Performance mode" as default (not recommended)
Config Mode
~~~~~~~~~~~
The resulting firmware will allow users to choose between secure (encrypted) and fast (unencrypted) transport.
.. image:: fastd_mode.gif
opkg update
opkg install socat
socat - UNIX-CONNECT:/var/run/fastd.mesh_vpn.socket
To confirm whether the correct cipher is being used, the log output
of fastd can be checked using ``logread``.
WireGuard
^^^^^^^^^
In order to support WireGuard in Gluon, a few technologies are glued together.
**VXLAN:** As Gluon typically relies on batman-adv, the Mesh VPN has to provide
OSI Layer 2 transport. But WireGuard is an OSI Layer 3 tunneling protocol, so
additional technology is necessary here. For this, we use VXLAN. In short, VXLAN
is a well-known technology to encapsulate ethernet packages into IP packages.
You can think of it as kind of similar to VLAN, but on a different layer. Here,
we use VXLAN to transport batman-adv traffic over WireGuard.
**wgpeerselector**: To connect all gluon nodes to each other, it is common to
create a topology where each gluon node is connected to one of the available
gateways via Mesh VPN respectively. To achieve this, the gluon node should be
able to select a random gateway to connect to. But such "random selection of a
peer" is not implemented in WireGuard by default. WireGuard only knows static
peers. Therefore the *wgpeerselector* has been developed. It randomly selects a
gateway, tries to establish a connection, and if it fails, tries to connect
to the next gateway. This approach has several advantages, such as load
balancing VPN connection attempts and avoiding problems with offline gateways.
More information about the wgpeerselector and its algorithm can be found
`here <https://github.com/freifunk-gluon/packages/blob/master/net/wgpeerselector/README.md>`__.
On the gluon node both VXLAN and the wgpeerselector are well integrated and no
explicit configuration of those tools is necessary, once the general WireGuard
support has been configured.
Attention must by paid to time synchronization. As WireGuard
performs checks on timestamps in order to avoid replay attacks, time must
be synchronized before the Mesh VPN connection is established. This means that
the NTP servers specified in your site.conf must be publicly available (and not
only through the mesh). Be aware that if you fail this, you may not directly see
negative effects. Only when a previously connected node reboots the effect
comes into play, as the gateway still knows about the old timestamp of the gluon
node.
.. _gluon-mesh-vpn-key-translate:
gluon-mesh-vpn-key-translate
""""""""""""""""""""""""""""
Many communities already possess a collection of active fastd-keys when they
plan migrating their community to WireGuard.
These public keys known on the server-side can be derived into their WireGuard
equivalent using `gluon-mesh-vpn-key-translate <https://github.com/AiyionPrime/gluon-mesh-vpn-key-translate>`__.
The routers do the necessary reencoding of the private key seamlessly
when updating firmware from fastd to the WireGuard variant.
Gateway / Supernode Configuration
"""""""""""""""""""""""""""""""""
On the gateway side, a software called *wireguard-vxlan-glue* is necessary. It
is a small daemon that dynamically adds and removes forwarding rules for VXLAN
interfaces, so traffic is sent correctly into the WireGuard interface. Thereby
the forwarding rules are only installed if a client is connected, so
unnecessary traffic in the kernel is avoided. The source can be found
`here <https://github.com/freifunkh/wireguard-vxlan-glue/>`__.
docs/features/wired-mesh.rst
View file @ b9a90f4f
......@@ -50,38 +50,84 @@ Configuration
Both Mesh-on-WAN and Mesh-on-LAN can be configured on the "Network" page
of the *Advanced settings* (if the package ``gluon-web-network`` is installed).
It is also possible to enable Mesh-on-WAN and Mesh-on-LAN by default by
adding ``mesh_on_wan = true`` and ``mesh_on_lan = true`` to ``site.conf``.
It is also possible to enable Mesh-on-WAN and Mesh-on-LAN by default by adding
the ``mesh`` role to the ``interfaces.*.default_roles`` options in your
:ref:`site.conf<user-site-interfaces>`.
.. _wired-mesh-commandline:
Commandline
===========
Starting with release 2022.1, the wired network configuration is rebuilt from ``/etc/config/gluon``
upon each ``gluon-reconfigure``.
Therefore the network configuration is overwritten at least with every firmware upgrade.
Every interface has a list of roles assigned to it which can be ``client``, ``mesh`` or ``uplink``.
When the client role is assigned to an interface in combination with other roles
(like 'client', 'mesh' in the Mesh-on-LAN example below), the other roles take
precedence, enabling mesh but not client in the previous example.
The setup/config-mode interface is every interface with the role ``client`` which makes removing
it from interfaces not only unnecessary, but generally unrecommended.
In order to make persistent changes to the router's configuration it's necessary to:
* change the sections in ``/etc/config/gluon`` e.g. using uci (see examples below)
* call ``gluon-reconfigure`` to re-generate ``/etc/config/network``
* apply the networking changes, either through executing ``service network restart`` or by performing a ``reboot``
Enable Mesh-on-WAN::
uci set network.mesh_wan.disabled=0
uci commit network
uci add_list gluon.iface_wan.role='mesh'
uci commit gluon
Disable Mesh-on-WAN::
uci set network.mesh_wan.disabled=1
uci commit network
uci del_list gluon.iface_wan.role='mesh'
uci commit gluon
Enable Mesh-on-LAN::
uci set network.mesh_lan.disabled=0
for ifname in $(cat /lib/gluon/core/sysconfig/lan_ifname); do
uci del_list network.client.ifname=$ifname
done
uci commit network
uci add_list gluon.iface_lan.role='mesh'
uci commit gluon
Disable Mesh-on-LAN::
uci set network.mesh_lan.disabled=1
for ifname in $(cat /lib/gluon/core/sysconfig/lan_ifname); do
uci add_list network.client.ifname=$ifname
done
uci commit network
uci del_list gluon.iface_lan.role='mesh'
uci commit gluon
For devices with a single interface, instead of `iface_lan` and `iface_wan` configuration is
done with `iface_single`.
Enable Mesh-on-Single::
uci add_list gluon.iface_single.role='mesh'
uci commit gluon
Disable Mesh-on-Single::
uci del_list gluon.iface_single.role='mesh'
uci commit gluon
Furthermore it is possible to make use of 802.1Q VLAN.
The following statements would create a VLAN with id 8 on ``eth0`` and join the mesh network with it::
uci set gluon.iface_lan_vlan8=interface
uci set gluon.iface_lan_vlan8.name='eth0.8'
uci add_list gluon.iface_lan_vlan8.role='mesh'
uci commit gluon
Other VLAN-interfaces could be configured on the same parent interface in order to have
all three roles available on ``eth0`` without having them interfere with each other.
This feature comes in especially handy for the persistent configuration of virtual machines
as offloader for bigger installations.
A ``reboot`` is not sufficient to apply an altered configuration; calling ``gluon-reconfigure`` before is
mandatory in order for changes to take effect.
Please note that this configuration has changed in Gluon 2016.1. Using
the old commands on 2016.1 and later will break the corresponding options
Please note that this configuration has changed in Gluon 2022.1. Using
the old commands on 2022.1 and later will break the corresponding options
in the *Advanced settings*.
docs/features/wlan-configuration.rst
View file @ b9a90f4f
......@@ -16,9 +16,11 @@ by the user). This means that it is not possible to enable or disable an existin
configurations during upgrades.
During upgrades the wifi channel of the 2.4GHz and 5GHz radio will be restored to the channel
configured in the site.conf. If you need to preserve a user defined wifi channel during upgrades
you can configure this via the uci section ``gluon-core.wireless``::
configured in the site.conf. The channel width will be reset to Gluon's default. If you need to preserve
these settings during upgrades you can configure this via the uci section ``gluon-core.wireless``::
uci set gluon-core.@wireless[0].preserve_channels='1'
uci set gluon.wireless.preserve_channels='1'
When channels should be preserved, toggling the outdoor mode will have no effect on the channel settings.
Therefore, the Outdoor mode settings won't be displayed in config mode.
Keep in mind that nodes running wifi interfaces on custom channels can't mesh with default nodes anymore!
docs/index.rst
View file @ b9a90f4f
......@@ -6,119 +6,80 @@ Several Freifunk communities in Germany use Gluon as the foundation of their Fre
.. toctree::
:caption: User Documentation
:maxdepth: 2
:caption: User Documentation
:maxdepth: 2
user/getting_started
user/site
user/supported_devices
user/x86
user/faq
user/getting_started
user/site
user/supported_devices
user/x86
user/faq
user/mtu
.. toctree::
:caption: Features
:maxdepth: 2
features/configmode
features/autoupdater
features/wlan-configuration
features/private-wlan
features/wired-mesh
features/dns-forwarder
features/monitoring
features/multidomain
features/authorized-keys
features/roles
features/vpn
:caption: Features
:maxdepth: 2
features/configmode
features/autoupdater
features/wlan-configuration
features/private-wlan
features/wired-mesh
features/dns-cache
features/monitoring
features/multidomain
features/authorized-keys
features/roles
features/vpn
.. toctree::
:caption: Developer Documentation
:maxdepth: 2
dev/basics
dev/hardware
dev/packages
dev/upgrade
dev/wan
dev/mac_addresses
dev/site_library
:caption: Developer Documentation
:maxdepth: 2
dev/basics
dev/hardware
dev/packages
dev/upgrade
dev/uplink
dev/mac_addresses
dev/site_library
dev/build
dev/debugging
.. toctree::
:caption: gluon-web Reference
:maxdepth: 1
:caption: gluon-web Reference
:maxdepth: 1
dev/web/controller
dev/web/model
dev/web/view
dev/web/i18n
dev/web/config-mode
dev/web/controller
dev/web/model
dev/web/view
dev/web/i18n
dev/web/config-mode
.. toctree::
:caption: Packages
:maxdepth: 1
package/gluon-client-bridge
package/gluon-config-mode-domain-select
package/gluon-ebtables-filter-multicast
package/gluon-ebtables-filter-ra-dhcp
package/gluon-ebtables-limit-arp
package/gluon-ebtables-source-filter
package/gluon-hoodselector
package/gluon-mesh-batman-adv
package/gluon-radv-filterd
package/gluon-scheduled-domain-switch
package/gluon-web-admin
package/gluon-web-logging
:caption: Packages
:maxdepth: 1
package/gluon-client-bridge
package/gluon-config-mode-domain-select
package/gluon-ebtables-filter-multicast
package/gluon-ebtables-filter-ra-dhcp
package/gluon-ebtables-limit-arp
package/gluon-ebtables-source-filter
package/gluon-hoodselector
package/gluon-logging
package/gluon-mesh-batman-adv
package/gluon-mesh-wireless-sae
package/gluon-radv-filterd
package/gluon-scheduled-domain-switch
package/gluon-web-admin
package/gluon-web-logging
.. toctree::
:caption: Releases
:maxdepth: 1
releases/v2020.1.1
releases/v2020.1
releases/v2019.1.2
releases/v2019.1.1
releases/v2019.1
releases/v2018.2.4
releases/v2018.2.3
releases/v2018.2.2
releases/v2018.2.1
releases/v2018.2
releases/v2018.1.4
releases/v2018.1.3
releases/v2018.1.2
releases/v2018.1.1
releases/v2018.1
releases/v2017.1.8
releases/v2017.1.7
releases/v2017.1.6
releases/v2017.1.5
releases/v2017.1.4
releases/v2017.1.3
releases/v2017.1.2
releases/v2017.1.1
releases/v2017.1
releases/v2016.2.7
releases/v2016.2.6
releases/v2016.2.5
releases/v2016.2.4
releases/v2016.2.3
releases/v2016.2.2
releases/v2016.2.1
releases/v2016.2
releases/v2016.1.6
releases/v2016.1.5
releases/v2016.1.4
releases/v2016.1.3
releases/v2016.1.2
releases/v2016.1.1
releases/v2016.1
releases/v2015.1.2
releases/v2015.1.1
releases/v2015.1
releases/v2014.4
releases/v2014.3.1
releases/v2014.3
:caption: Releases
:maxdepth: 1
releases/index
License
-------
......
docs/multidomain-site-example/domains/alpha_centauri.conf
View file @ b9a90f4f
......@@ -22,9 +22,9 @@
},
wifi24 = {
channel = 1,
ap = {
ssid = "alpha-centauri.example.org",
channel = 1,
},
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
......@@ -32,9 +32,9 @@
},
wifi5 = {
channel = 44,
ap = {
ssid = "alpha-centauri.example.org",
channel = 44,
},
mesh = {
id = 'ueH3uXjdp',
......
docs/multidomain-site-example/image-customization.lua 0 → 100644
View file @ b9a90f4f
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 {
'iwinfo',
}
if not device_class('tiny') then
features {'wireless-encryption-wpa3'}
end
docs/multidomain-site-example/site.conf
View file @ b9a90f4f
......@@ -20,10 +20,10 @@
},
mesh_vpn = {
mtu = 1312,
fastd = {
methods = {'salsa2012+umac'},
mtu = 1312,
},
bandwidth_limit = {
......
docs/multidomain-site-example/site.mk
View file @ b9a90f4f
## gluon site.mk makefile example
## GLUON_FEATURES
# Specify Gluon features/packages to enable;
# Gluon will automatically enable a set of packages
# depending on the combination of features listed
GLUON_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
## GLUON_MULTIDOMAIN
# Build gluon with multidomain support.
GLUON_MULTIDOMAIN=1
## GLUON_SITE_PACKAGES
# Specify additional Gluon/LEDE packages to include here;
# A minus sign may be prepended to remove a packages from the
# selection that would be enabled by default or due to the
# chosen feature flags
GLUON_SITE_PACKAGES := haveged iwinfo
## DEFAULT_GLUON_RELEASE
# version string to use for images
# gluon relies on
......@@ -58,6 +32,3 @@ GLUON_REGION ?= eu
# Languages to include
GLUON_LANGS ?= en de
# Do not build images for deprecated devices
GLUON_DEPRECATED ?= 0
docs/package/gluon-ebtables-limit-arp.rst
View file @ b9a90f4f
......@@ -25,5 +25,6 @@ This package is installed by default if the selected routing
feature is *mesh-batman-adv-15*.
It can be unselected via::
GLUON_SITE_PACKAGES := \
-gluon-ebtables-limit-arp
packages {
'-gluon-ebtables-limit-arp',
}
docs/package/gluon-hoodselector.rst
View file @ b9a90f4f
......@@ -66,7 +66,7 @@ and others which contain shapes.
* **default domain**
The default domain doesn’t hold any shapes and represents the inverted area of
The default domain doesn't hold any shapes and represents the inverted area of
all other shapes held by other domains with geo coordinates. It will only be
entered if a node could not be matched to a geo domain. A suggested approach is
to define the "old" network as default domain and gradually migrate nodes from
......
docs/package/gluon-logging.rst 0 → 100644
View file @ b9a90f4f
gluon-logging
=============
The *gluon-logging* package allows to configure a remote syslog server that
will receive the systems log output that is also visible when calling ``logread``
from a terminal.
It supports both IPv4 and IPv6 endpoints over UDP and TCP.
Note: The syslog mechanism is incapable of providing a complete log as network
access is required to send out log messages and ``logd`` does not buffer and resend
older log messages even though they might be available in ``logread``.
This package conflicts with ``gluon-web-logging`` as it will overwrite the
user-given syslog server on every upgrade.
site.conf
---------
syslog.ip : required
- Destination address of the remote syslog server
syslog.port : optional
- Destination port of the remote syslog server
- Defaults to 514
syslog.proto : optional
- Protocol to transport syslog frames in, can be either ``tcp`` or ``udp``
- Defaults to UDP
Example::
syslog = {
ip = "2001:db8::1",
port = 514,
proto = "udp",
},
docs/package/gluon-mesh-batman-adv.rst
View file @ b9a90f4f
......@@ -2,7 +2,7 @@ gluon-mesh-batman-adv
=====================
.. image:: gluon-mesh-batman-adv-logo.svg
:width: 300 px
:width: 300 px
B.A.T.M.A.N. Advanced (often referenced as batman-adv) is an implementation of
the B.A.T.M.A.N. routing protocol in form of a linux kernel module operating on layer 2.
......@@ -47,7 +47,7 @@ Multicast Architecture
----------------------
.. image:: gluon-mesh-batman-adv-multicast.svg
:width: 300 px
:width: 300 px
While generally broadcast capability is a nice feature of a layer 2
mesh protocol, it quickly reaches its limit.
......
docs/package/gluon-mesh-wireless-sae.rst 0 → 100644
View file @ b9a90f4f
gluon-mesh-wireless-sae
=======================
This package adds support for SAE on 802.11s mesh connections.
Enabling this package will require all 802.11s mesh connections
to be encrypted using the SAE key agreement scheme. The security
of SAE relies upon the authentication through a shared secret.
In the context of public mesh networks a shared secret is an
obvious oxymoron. Still, this functionality may provide an improvement
over unencrypted mesh connections in that it protects against a
passive attacker who did not observe the key agreement. In addition
Management Frame Protection (802.11w) gets automatically enabled on
wireless mesh interfaces to prevent protocol-level deauthentication attacks.
If `wifi.mesh.sae` is enabled, a shared secret will automatically be
derived from the `prefix6` variable. This is as secure as it gets
for a public mesh network.
For *private* mesh networks `wifi.mesh.sae_passphrase` should be
set to your shared secret.
site.conf
---------
These settings apply to all 802.11s mesh interfaces on all radios.
wifi.mesh.sae \: optional
- ``true`` enables SAE on 802.11s mesh connections
- ``false`` disables SAE on 802.11s mesh connections
- defaults to ``false``
wifi.mesh.sae_passphrase \: optional
- sets a shared secret used to authenticate any two mesh nodes,
crucial for private mesh networks
- should not be set, if the shared secret is shared with untrusted
third parties, like in a publish mesh network
- defaults to an autogenerated value derived from ``prefix6``
Example::
wifi = {
mesh = {
sae = true,
-- sae_passphrase = "<shared secret>",
},
},
docs/package/gluon-scheduled-domain-switch.rst
View file @ b9a90f4f
......@@ -15,15 +15,15 @@ site.conf
All those settings have to be defined exclusively in the domain, not the site.
domain_switch : optional (needed for domains to switch)
target_domain :
- target domain to switch to
switch_after_offline_mins :
- amount of time without reachable gateway to switch unconditionally
switch_time :
- UNIX epoch after which domain will be switched
connection_check_targets :
- array of IPv6 addresses which are probed to determine if the node is
connected to the mesh
target_domain :
- target domain to switch to
switch_after_offline_mins :
- amount of time without reachable gateway to switch unconditionally
switch_time :
- UNIX epoch after which domain will be switched
connection_check_targets :
- array of IPv6 addresses which are probed to determine if the node is
connected to the mesh
Example::
......
docs/package/gluon-web-admin.rst
View file @ b9a90f4f
......@@ -13,7 +13,7 @@ config_mode.remote_login.show_password_form \: optional
- ``true`` the password section in config mode is shown
- ``false`` the password section in config mode is hidden
- defaults to ``false``
config_mode.remote_login.min_password_length \: optional
- sets the minimum allowed password length. Set this to ``1`` to disable the
length check.
......
docs/releases/index.rst 0 → 100644
View file @ b9a90f4f
Release Notes
=============
.. toctree::
:caption: Gluon 2023.2
:maxdepth: 2
v2023.2.4
v2023.2.3
v2023.2.2
v2023.2.1
v2023.2
.. toctree::
:caption: Gluon 2023.1
:maxdepth: 2
v2023.1.1
v2023.1
.. toctree::
:caption: Gluon 2022.1
:maxdepth: 2
v2022.1.4
v2022.1.3
v2022.1.2
v2022.1.1
v2022.1
.. toctree::
:caption: Gluon 2021.1
:maxdepth: 2
v2021.1.2
v2021.1.1
v2021.1
.. toctree::
:caption: Gluon 2020.2
:maxdepth: 2
v2020.2.3
v2020.2.2
v2020.2.1
v2020.2
.. toctree::
:caption: Gluon 2020.1
:maxdepth: 2
v2020.1.4
v2020.1.3
v2020.1.2
v2020.1.1
v2020.1
.. toctree::
:caption: Gluon 2019.1
:maxdepth: 2
v2019.1.3
v2019.1.2
v2019.1.1
v2019.1
.. toctree::
:caption: Gluon 2018.2
:maxdepth: 2
v2018.2.4
v2018.2.3
v2018.2.2
v2018.2.1
v2018.2
.. toctree::
:caption: Gluon 2018.1
:maxdepth: 2
v2018.1.4
v2018.1.3
v2018.1.2
v2018.1.1
v2018.1
.. toctree::
:caption: Gluon 2017.1
:maxdepth: 2
v2017.1.8
v2017.1.7
v2017.1.6
v2017.1.5
v2017.1.4
v2017.1.3
v2017.1.2
v2017.1.1
v2017.1
.. toctree::
:caption: Gluon 2016.2
:maxdepth: 2
v2016.2.7
v2016.2.6
v2016.2.5
v2016.2.4
v2016.2.3
v2016.2.2
v2016.2.1
v2016.2
.. toctree::
:caption: Gluon 2016.1
:maxdepth: 2
v2016.1.6
v2016.1.5
v2016.1.4
v2016.1.3
v2016.1.2
v2016.1.1
v2016.1
.. toctree::
:caption: Gluon 2015.1
:maxdepth: 2
v2015.1.2
v2015.1.1
v2015.1
.. toctree::
:caption: Gluon 2014.4
:maxdepth: 2
v2014.4
.. toctree::
:caption: Gluon 2014.3
:maxdepth: 2
v2014.3.1
v2014.3
docs/releases/v2014.4.rst
View file @ b9a90f4f
......@@ -146,7 +146,7 @@ Ignored tx-power offset on Ubiquiti AirMax devices
https://github.com/freifunk-gluon/gluon/issues/94
There is still no OpenWRT support for determining the transmission
There is still no OpenWrt support for determining the transmission
power offsets on Ubiquiti AirMax devices (Bullet M2, Picostation
M2, Nanostation (loco) M2, ...). Use Gluon with caution on these
devices! Manual adjustment may be required.