docs: consistently indent .rst files with 2 spaces

2 spaces is the most common indentation width used in the docs; adjust
the rest for consistency.

Also change .editorconfig accordingly.
This commit is contained in:
Matthias Schiffer 2021-12-24 14:16:04 +01:00
parent 0e19b1a5c2
commit 854fef4e12
No known key found for this signature in database
GPG Key ID: 16EF3F64CB201D9C
21 changed files with 719 additions and 723 deletions

View File

@ -25,7 +25,7 @@ indent_size = 4
[*.rst]
indent_style = space
indent_size = 3
indent_size = 2
[*.yml]
indent_style = space

View File

@ -32,7 +32,7 @@ rerun
::
make update
make update
`make update` also applies the patches that can be found in the directories found in
`patches`; the resulting branch will be called `patched`, while the commit specified in `modules`
@ -44,7 +44,7 @@ using
::
make update-patches
make update-patches
If applying a patch fails because you have changed the base commit, the repository will be reset to the old `patched` branch
and you can try rebasing it onto the new `base` branch yourself and after that call `make update-patches` to fix the problem.
@ -54,7 +54,7 @@ commits, making `git reflog` the only way to recover them!
::
make refresh-patches
make refresh-patches
In order to refresh patches when updating feeds or the OpenWrt base, `make refresh-patches` applies and updates all of their patches without installing feed packages to the OpenWrt buildsystem.

View File

@ -32,12 +32,12 @@ The tooling is contained in the kernel source tree in the file
`decode_stacktrace.sh <https://github.com/torvalds/linux/blob/master/scripts/decode_stacktrace.sh>`__.
This file and the needed source tree are available in the directory: ::
openwrt/build_dir/target-<architecture>/linux-<architecture>/linux-<version>/
openwrt/build_dir/target-<architecture>/linux-<architecture>/linux-<version>/
.. note::
Make sure to use a kernel tree that matches the version and patches
that was used to build the kernel.
If in doubt just re-build the images for the target.
Make sure to use a kernel tree that matches the version and patches
that was used to build the kernel.
If in doubt just re-build the images for the target.
Some more information on how to use this tool can be found at
`LWN <https://lwn.net/Articles/592724/>`__.
@ -48,4 +48,4 @@ Obtaining Stacktraces
On many targets stacktraces can be read from the following
location after reboot: ::
/sys/kernel/debug/crashlog
/sys/kernel/debug/crashlog

View File

@ -9,13 +9,16 @@ Development workflow
When you are developing packages, it often happens that you iteratively want to deploy
and verify the state your development. There are two ways to verify your changes:
1) One way is to rebuild the complete firmware, flash it, configure it and verify your
development then. This usually takes at least a few minutes to get your changes
working so you can test them. Especially if you iterate a lot, this becomes tedious.
2) Another way is to rebuild only the package you are currently working on and
to deploy this package to your test system. Here not even a reboot is required.
This makes iterating relatively fast. Your test system could be real hardware or
even a qemu in most cases.
1)
One way is to rebuild the complete firmware, flash it, configure it and verify your
development then. This usually takes at least a few minutes to get your changes
working so you can test them. Especially if you iterate a lot, this becomes tedious.
2)
Another way is to rebuild only the package you are currently working on and
to deploy this package to your test system. Here not even a reboot is required.
This makes iterating relatively fast. Your test system could be real hardware or
even a qemu in most cases.
Gluon provides scripts to enhance workflow 2). Here is an example illustrating
the workflow using these scripts:

View File

@ -99,16 +99,16 @@ These commands can be used on a node:
::
# Update with some probability
autoupdater
# Update with some probability
autoupdater
::
# Force update check, even when the updater is disabled
autoupdater -f
# Force update check, even when the updater is disabled
autoupdater -f
::
# If fallback is true the updater will perform an update only if the timespan
# PRIORITY days (as defined in the manifest) and another 24h have passed
autoupdater --fallback
# If fallback is true the updater will perform an update only if the timespan
# PRIORITY days (as defined in the manifest) and another 24h have passed
autoupdater --fallback

View File

@ -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
@ -93,12 +93,12 @@ Via commandline
::
gluon-switch-domain 'newdomaincode'
gluon-switch-domain 'newdomaincode'
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``::
gluon-switch-domain --no-reboot 'newdomaincode'
gluon-switch-domain --no-reboot 'newdomaincode'
Switching the domain without reboot is currently **experimental**.
@ -123,115 +123,115 @@ 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:
- 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
- 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.
- 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
- 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:
- Specific to a firmware build itself:
- site_code
- site_name
- autoupdater.branches.*.name
- autoupdater.branches.*.good_signatures
- autoupdater.branches.*.pubkeys
- 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:
- 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
- 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 as an own 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
--------------

View File

@ -52,6 +52,6 @@ socket can be interrogated, after installing for example `socat`.
::
opkg update
opkg install socat
socat - UNIX-CONNECT:/var/run/fastd.mesh_vpn.socket
opkg update
opkg install socat
socat - UNIX-CONNECT:/var/run/fastd.mesh_vpn.socket

View File

@ -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.

View File

@ -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::

View File

@ -170,16 +170,16 @@ Site changes
for example::
fastd_mesh_vpn = {
methods = {'salsa2012+umac'},
mtu = 1426,
groups = {
backbone = {
limit = 2,
peers = {
-- ...
}
}
methods = {'salsa2012+umac'},
mtu = 1426,
groups = {
backbone = {
limit = 2,
peers = {
-- ...
}
}
}
}
- ``config_mode``: The config mode messages aren't configured in ``site.conf`` anymore. Instead, they are
@ -190,11 +190,11 @@ Site changes
in the site i18n files. The ``site.conf`` section becomes::
roles = {
default = 'foo',
list = {
'foo',
'bar',
}
default = 'foo',
list = {
'foo',
'bar',
}
}
The display string use i18n message IDs like ``gluon-luci-node-role:role:foo`` and ``gluon-luci-node-role:role:bar``.

View File

@ -9,21 +9,21 @@ ar71xx-generic
* OpenMesh
- MR600 (v1, v2)
- MR900 (v1, v2)
- OM2P (v1, v2)
- OM2P-HS (v1, v2)
- OM2P-LC
- OM5P
- OM5P-AN
- MR600 (v1, v2)
- MR900 (v1, v2)
- OM2P (v1, v2)
- OM2P-HS (v1, v2)
- OM2P-LC
- OM5P
- OM5P-AN
* Ubiquiti
- Rocket M XW
- Rocket M XW
* TP-LINK
- TL-WR841N/ND v11
- TL-WR841N/ND v11
Bugfixes
~~~~~~~~

View File

@ -30,13 +30,13 @@ 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.
- | 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.
- | 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>`_)

View File

@ -26,13 +26,13 @@ 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.
- | 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.
- | 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>`_)

View File

@ -36,13 +36,13 @@ 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.
- | 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.
- | 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>`_)

View File

@ -73,8 +73,8 @@ ramips-mt7621
.. note::
The ``ipq806x`` target has been flagged as broken, as none of its devices are fully supported in this OpenWrt
release yet. You might have to update your build scripts accordingly.
The ``ipq806x`` target has been flagged as broken, as none of its devices are fully supported in this OpenWrt
release yet. You might have to update your build scripts accordingly.
@ -109,20 +109,20 @@ have outdoor mode automatically enabled during their initial setup, specifically
* Ubiquiti
- Bullet M
- Litebeam M5
- Nanostation M5
- Nanostation M5 Loco
- Rocket M5
- Rocket M5 TI
- Unifi AC Mesh
- Unifi AC Mesh Pro
- Unifi Outdoor
- Bullet M
- Litebeam M5
- Nanostation M5
- Nanostation M5 Loco
- Rocket M5
- Rocket M5 TI
- Unifi AC Mesh
- Unifi AC Mesh Pro
- Unifi Outdoor
* TP-Link
- CPE510
- WBS510
- CPE510
- WBS510
See the :ref:`wifi5 <user-site-wifi5>` section for the *site.conf* configuration of this feature.
@ -253,13 +253,13 @@ 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.
- | 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.
- | 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>`_)

View File

@ -25,13 +25,13 @@ 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.
- | 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.
- | 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>`_)

View File

@ -50,13 +50,13 @@ 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.
- | 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.
- | 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>`_)

View File

@ -30,13 +30,13 @@ 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.
- | 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.
- | 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>`_)

View File

@ -11,80 +11,80 @@ Added hardware support
ath79-generic
~~~~~~~~~~~~~
- devolo WiFi pro 1200e
- devolo WiFi pro 1200i
- devolo WiFi pro 1750c
- devolo WiFi pro 1750e
- devolo WiFi pro 1750i
- devolo WiFi pro 1750x
- GL.iNet GL-AR300M-Lite
- OCEDO Raccoon
- TP-Link Archer C6 v2
- devolo WiFi pro 1200e
- devolo WiFi pro 1200i
- devolo WiFi pro 1750c
- devolo WiFi pro 1750e
- devolo WiFi pro 1750i
- devolo WiFi pro 1750x
- GL.iNet GL-AR300M-Lite
- OCEDO Raccoon
- TP-Link Archer C6 v2
ipq40xx-generic
~~~~~~~~~~~~~~~
- Aruba AP-303
- Aruba Instant On AP11
- AVM FRITZ!Repeater 1200
- Aruba AP-303
- Aruba Instant On AP11
- AVM FRITZ!Repeater 1200
ipq806x-generic
~~~~~~~~~~~~~~~
- Netgear R7800
- Netgear R7800
lantiq-xway
~~~~~~~~~~~
- AVM FRITZ!Box 7312
- AVM FRITZ!Box 7320
- AVM FRITZ!Box 7330
- AVM FRITZ!Box 7330 SL
- AVM FRITZ!Box 7312
- AVM FRITZ!Box 7320
- AVM FRITZ!Box 7330
- AVM FRITZ!Box 7330 SL
lantiq-xrx200
~~~~~~~~~~~~~
- AVM FRITZ!Box 7360 (v1, v2)
- AVM FRITZ!Box 7360 SL
- AVM FRITZ!Box 7362 SL
- AVM FRITZ!Box 7412
- AVM FRITZ!Box 7360 (v1, v2)
- AVM FRITZ!Box 7360 SL
- AVM FRITZ!Box 7362 SL
- AVM FRITZ!Box 7412
mpc85xx-p1020
~~~~~~~~~~~~~
- Enterasys WS-AP3710i
- OCEDO Panda
- Enterasys WS-AP3710i
- OCEDO Panda
ramips-mt7620
~~~~~~~~~~~~~
- TP-Link Archer C2 (v1)
- TP-Link Archer C20 (v1)
- TP-Link Archer C20i
- TP-Link Archer C50 (v1)
- Xiaomi MiWifi Mini
- TP-Link Archer C2 (v1)
- TP-Link Archer C20 (v1)
- TP-Link Archer C20i
- TP-Link Archer C50 (v1)
- Xiaomi MiWifi Mini
ramips-mt7621
~~~~~~~~~~~~~
- Netgear EX6150 (v1)
- Netgear R6220
- Netgear EX6150 (v1)
- Netgear R6220
ramips-mt76x8
~~~~~~~~~~~~~
- GL.iNet VIXMINI
- TP-Link TL-MR3020 (v3)
- TP-Link TL-WA801ND (v5)
- TP-Link TL-WR902AC (v3)
- GL.iNet VIXMINI
- TP-Link TL-MR3020 (v3)
- TP-Link TL-WA801ND (v5)
- TP-Link TL-WR902AC (v3)
Removed hardware support
------------------------
- ALFA Network Hornet-UB [#kernelpartition_too_small]_
- ALFA Network Tube2H [#kernelpartition_too_small]_
- ALFA Network N2 [#kernelpartition_too_small]_
- ALFA Network N5 [#kernelpartition_too_small]_
- ALFA Network Hornet-UB [#kernelpartition_too_small]_
- ALFA Network Tube2H [#kernelpartition_too_small]_
- ALFA Network N2 [#kernelpartition_too_small]_
- ALFA Network N5 [#kernelpartition_too_small]_
.. [#kernelpartition_too_small]
The kernel partition on this device is too small to build a working image.
@ -162,8 +162,8 @@ Site changes
site.mk
~~~~~~~
- The ``GLUON_WLAN_MESH`` variable can be dropped, as 802.11s is
the only supported wireless transport from now on.
- The ``GLUON_WLAN_MESH`` variable can be dropped, as 802.11s is
the only supported wireless transport from now on.
Internals
---------
@ -206,13 +206,13 @@ 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.
- | 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.
- | 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>`_)

View File

@ -44,7 +44,7 @@ We also provide a container environment that already tracks all these dependenci
::
./scripts/container.sh
./scripts/container.sh
Building the images
-------------------
@ -54,31 +54,31 @@ version you'd like to checkout, e.g. *v2021.1*.
::
git clone https://github.com/freifunk-gluon/gluon.git gluon -b RELEASE
git clone https://github.com/freifunk-gluon/gluon.git gluon -b RELEASE
This command will create a directory named *gluon/*.
It might also tell a scary message about being in a *detached state*.
**Don't panic!** Everything's fine.
Now, enter the freshly created directory::
cd gluon
cd gluon
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-alpha-centauri/site-ffac.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/*::
mkdir site
cd site
git init
mkdir site
cd site
git init
Copy *site.conf*, *site.mk* and *i18n* from *docs/site-example*::
cp ../docs/site-example/site.conf .
cp ../docs/site-example/site.mk .
cp -r ../docs/site-example/i18n .
cp ../docs/site-example/site.conf .
cp ../docs/site-example/site.mk .
cp -r ../docs/site-example/i18n .
Edit these files as you see fit and commit them into the site repository.
Extensive documentation about the site configuration can be found at:
@ -88,9 +88,9 @@ to the Gluon main repository should be avoided, as it will make updates more com
Next go back to the top-level Gluon directory and build Gluon::
cd ..
make update # Get other repositories used by Gluon
make GLUON_TARGET=ath79-generic # Build Gluon
cd ..
make update # Get other repositories used by Gluon
make GLUON_TARGET=ath79-generic # Build Gluon
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.
@ -102,9 +102,9 @@ To see a complete list of supported targets, call ``make`` without setting ``GLU
To build all targets use a loop like this::
for TARGET in $(make list-targets); do
make GLUON_TARGET=$TARGET
done
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`.
@ -117,7 +117,7 @@ system.
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
cp -rL output/images /var/www
The directory `output/debug` contains a compressed kernel image for each
architecture.
@ -130,14 +130,14 @@ Cleaning the build tree
There are two levels of `make clean`::
make clean GLUON_TARGET=ath79-generic
make clean GLUON_TARGET=ath79-generic
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
make dirclean
will clean the entire tree, so the toolchain will be rebuilt as well, which will take a while.

File diff suppressed because it is too large Load Diff