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.main
Matthias Schiffer
parent
0e19b1a5c2
commit
854fef4e12
|
|
@ -25,7 +25,7 @@ indent_size = 4
|
|||
|
||||
[*.rst]
|
||||
indent_style = space
|
||||
indent_size = 3
|
||||
indent_size = 2
|
||||
|
||||
[*.yml]
|
||||
indent_style = space
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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:
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
--------------
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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::
|
||||
|
||||
|
|
|
|||
|
|
@ -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``.
|
||||
|
|
|
|||
|
|
@ -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
|
||||
~~~~~~~~
|
||||
|
|
|
|||
|
|
@ -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>`_)
|
||||
|
|
|
|||
|
|
@ -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>`_)
|
||||
|
|
|
|||
|
|
@ -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>`_)
|
||||
|
|
|
|||
|
|
@ -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>`_)
|
||||
|
|
|
|||
|
|
@ -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>`_)
|
||||
|
|
|
|||
|
|
@ -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>`_)
|
||||
|
|
|
|||
|
|
@ -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>`_)
|
||||
|
|
|
|||
|
|
@ -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>`_)
|
||||
|
|
|
|||
|
|
@ -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
Loading…
Reference in New Issue