Skip to content
Snippets Groups Projects
Commit 170c494f authored by bobcanthelpyou's avatar bobcanthelpyou Committed by Martin Weinelt
Browse files

docs: fix typos and common misspellings (#1668)

parent e8b37b2d
No related branches found
No related tags found
No related merge requests found
......@@ -36,7 +36,7 @@ Bugfixes
and a number of other minor issues)
The listed bugs could lead to high rates of batman-adv management traffic
(causing considerable load), trigger warnings about packet checksum failues
(causing considerable load), trigger warnings about packet checksum failures
in certain non-standard interface configurations, and possibly other issues.
......@@ -61,7 +61,7 @@ Known issues
* The MAC address of the WAN interface is modified even when Mesh-on-WAN is disabled (`#496 <https://github.com/freifunk-gluon/gluon/issues/496>`_)
This may lead to issues in environments where a fixed MAC address is expected (like VMware when promicious mode is disallowed).
This may lead to issues in environments where a fixed MAC address is expected (like VMware when promiscuous mode is disallowed).
* Inconsistent respondd API (`#522 <https://github.com/freifunk-gluon/gluon/issues/522>`_)
......
......@@ -71,7 +71,7 @@ x86-generic
^^^^^^^^^^^
The *x86-kvm* and *x86-xen_domu* targets have been removed; the *x86-generic*
images now support these usecases as well, so no separate targets are needed
images now support these use cases as well, so no separate targets are needed
anymore.
x86-geode
......@@ -225,7 +225,7 @@ Known issues
* The MAC address of the WAN interface is modified even when Mesh-on-WAN is disabled (`#496 <https://github.com/freifunk-gluon/gluon/issues/496>`_)
This may lead to issues in environments where a fixed MAC address is expected (like VMware when promicious mode is disallowed).
This may lead to issues in environments where a fixed MAC address is expected (like VMware when promiscuous mode is disallowed).
* Inconsistent respondd API (`#522 <https://github.com/freifunk-gluon/gluon/issues/522>`_)
......
......@@ -40,7 +40,7 @@ Known issues
* The MAC address of the WAN interface is modified even when Mesh-on-WAN is disabled (`#496 <https://github.com/freifunk-gluon/gluon/issues/496>`_)
This may lead to issues in environments where a fixed MAC address is expected (like VMware when promicious mode is disallowed).
This may lead to issues in environments where a fixed MAC address is expected (like VMware when promiscuous mode is disallowed).
* Inconsistent respondd API (`#522 <https://github.com/freifunk-gluon/gluon/issues/522>`_)
......
......@@ -46,7 +46,7 @@ Known issues
* The MAC address of the WAN interface is modified even when Mesh-on-WAN is disabled (`#496 <https://github.com/freifunk-gluon/gluon/issues/496>`_)
This may lead to issues in environments where a fixed MAC address is expected (like VMware when promicious mode is disallowed).
This may lead to issues in environments where a fixed MAC address is expected (like VMware when promiscuous mode is disallowed).
* Inconsistent respondd API (`#522 <https://github.com/freifunk-gluon/gluon/issues/522>`_)
......
......@@ -17,7 +17,7 @@ Known issues
* The MAC address of the WAN interface is modified even when Mesh-on-WAN is disabled (`#496 <https://github.com/freifunk-gluon/gluon/issues/496>`_)
This may lead to issues in environments where a fixed MAC address is expected (like VMware when promicious mode is disallowed).
This may lead to issues in environments where a fixed MAC address is expected (like VMware when promiscuous mode is disallowed).
* Inconsistent respondd API (`#522 <https://github.com/freifunk-gluon/gluon/issues/522>`_)
......
......@@ -18,7 +18,7 @@ Bugfixes
* Fix unintended difference between autoupdater version comparison and dpkg/opkg
Alphanumeric characters were considered less than end-of-string, when the
intended bahaviour (as implemented by dpkg and opkg) is that only ``~`` is
intended behaviour (as implemented by dpkg and opkg) is that only ``~`` is
less than end-of-string. This broke relations like the following:
* ``1.0`` < ``1.0a``
......@@ -35,7 +35,7 @@ Known issues
* The MAC address of the WAN interface is modified even when Mesh-on-WAN is disabled (`#496 <https://github.com/freifunk-gluon/gluon/issues/496>`_)
This may lead to issues in environments where a fixed MAC address is expected (like VMware when promicious mode is disallowed).
This may lead to issues in environments where a fixed MAC address is expected (like VMware when promiscuous mode is disallowed).
* Inconsistent respondd API (`#522 <https://github.com/freifunk-gluon/gluon/issues/522>`_)
......
......@@ -150,7 +150,7 @@ anymore.
Filtering IGMP/MLD queries directed towards the mesh ensures that each node becomes the multicast querier
for its own clients (unless there are other multicast-aware switches connected to the node), rather
than electing a single, basically arbitrary node in the mesh to become the querier. Overall,
this should significantly improve the reliablity of multicast in the mesh. This is especially
this should significantly improve the reliability of multicast in the mesh. This is especially
important for IPv6, as the IPv6 Neighbour Discovery Protocol (NDP) is based on local multicast.
See also the documentation of the :ref:`site.conf mesh section <user-site-mesh>`.
......@@ -176,7 +176,7 @@ Public key in respondd data (optional)
======================================
If desired, the fastd public key of a node can be included in the respondd nodeinfo data,
faciliating the correlations of VPN peers and nodes. As the VPN key is transmitted unencrypted
facilitating the correlations of VPN peers and nodes. As the VPN key is transmitted unencrypted
in the fastd handshake, this would theoretically allow an ISP to determine which nodes
are operated behind which internet line. Therefore, this feature must be enabled explicitly
by setting *mesh_vpn.pubkey_privacy* to ``false`` in *site.conf*.
......@@ -389,7 +389,7 @@ Known issues
* The MAC address of the WAN interface is modified even when Mesh-on-WAN is disabled (`#496 <https://github.com/freifunk-gluon/gluon/issues/496>`_)
This may lead to issues in environments where a fixed MAC address is expected (like VMware when promicious mode is disallowed).
This may lead to issues in environments where a fixed MAC address is expected (like VMware when promiscuous mode is disallowed).
* Inconsistent respondd API (`#522 <https://github.com/freifunk-gluon/gluon/issues/522>`_)
......
......@@ -148,7 +148,7 @@ Known issues
disabled (`#496 <https://github.com/freifunk-gluon/gluon/issues/496>`_)
This may lead to issues in environments where a fixed MAC address is expected
(like VMware when promicious mode is disallowed).
(like VMware when promiscuous mode is disallowed).
* Inconsistent respondd API
(`#522 <https://github.com/freifunk-gluon/gluon/issues/522>`_)
......
......@@ -30,7 +30,7 @@ Consider these key values:
- Payload: Allow for the transport of IPv6 packets, by adhering to the minimum MTU
of 1280 Byte specified in RFC 2460
- and configure `MSS clamping`_ accordingly,
- and announce your link MTU via Router Advertisments and DHCP
- and announce your link MTU via Router Advertisements and DHCP
.. _MSS clamping: https://www.tldp.org/HOWTO/Adv-Routing-HOWTO/lartc.cookbook.mtu-mss.html
......@@ -48,7 +48,7 @@ For reference, the complete MTU stack looks like this:
Minimum MTU
-----------
Calculcate the minimum transport MTU by adding the encapsulation overhead to the
Calculate the minimum transport MTU by adding the encapsulation overhead to the
minimum payload MTU required. This is the lowest recommended value, since going
lower would cause unnecessary fragmentation for clients which respect the announced
link MTU.
......
......@@ -172,7 +172,7 @@ GLUON_PRIORITY
GLUON_REGION
Some devices (at the moment the TP-Link Archer C7) contain a region code that restricts
firmware installations. Set GLUON_REGION to ``eu`` or ``us`` to make the resulting
images installable from the respective stock firmwares.
images installable from the respective stock firmware.
GLUON_RELEASE
Firmware release number: This string is displayed in the config mode, announced
......
......@@ -24,7 +24,7 @@ site_code
domain_seed
32 bytes of random data, encoded in hexadecimal, used to seed other random
values specific to the mesh domain. It must be the same for all nodes of one
mesh, but should be different for firmwares that are not supposed to mesh with
mesh, but should be different for firmware that is not supposed to mesh with
each other.
The recommended way to generate a value for a new site is:
......@@ -152,7 +152,7 @@ wifi24 \: optional
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.
``ibss`` requires two parametersr: ``ssid`` (a string) and ``bssid`` (a MAC).
``ibss`` requires two parameters: ``ssid`` (a string) and ``bssid`` (a MAC).
An optional parameter ``vlan`` (integer) is supported.
Both ``mesh`` and ``ibss`` accept an optional ``mcast_rate`` (kbit/s) parameter for
......@@ -247,7 +247,7 @@ mesh
throughput is at least 1500 kbit/s faster than the throughput of the
currently selected gateway.
For details on determining the threshhold, when to switch to a new gateway,
For details on determining the threshold, when to switch to a new gateway,
see `batctl manpage`_, section "gw_mode".
.. _batctl manpage: https://www.open-mesh.org/projects/batman-adv/wiki/Gateways
......@@ -546,7 +546,7 @@ Feature flags
With the addition of more and more features that interact in complex ways, it
has become necessary to split certain packages into multiple parts, so it is
possible to install just what is needed for a specific usecase. One example
possible to install just what is needed for a specific use case. One example
is the package *gluon-status-page-mesh-batman-adv*: There are batman-adv-specific
status page components; they should only be installed when both batman-adv and
the status page are enabled, making the addition of a specific package for this
......
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment