Compare commits

..

1 Commits

Author SHA1 Message Date
Martin Weinelt
934287c1e9
WIP: add QEMU test driver based on virtio-serial
Migrates the test cases to pytest.
2020-11-13 03:51:21 +01:00
491 changed files with 12112 additions and 12854 deletions

3
.ecrc
View File

@ -1,3 +0,0 @@
{
"Exclude": ["docs/_build"]
}

View File

@ -7,61 +7,10 @@ insert_final_newline = true
indent_style = tab
charset = utf-8
[Dockerfile]
indent_style = space
indent_size = 4
[/patches/**]
indent_style = unset
indent_size = unset
[*.c]
[*.css]
[*.dia]
indent_style = space
indent_size = 2
[*.h]
[*.html]
[*.js]
[*{.json,.ecrc}]
indent_style = space
indent_size = 2
[*.lua]
[{Makefile,*.mk}]
indent_style = unset
[*.md]
indent_style = space
indent_size = 4
[*.pl]
[*.py]
indent_style = space
indent_size = 4
[*.rst]
indent_style = space
indent_size = 2
[*.sh]
[*.yml]
indent_style = space
indent_size = 2
[CMakeLists.txt]
[*.py]
indent_style = space
indent_size = 2
[{docs,contrib/ci}/*site*/**/*.conf]
indent_style = space
indent_size = 2
indent_size = 4

View File

@ -6,7 +6,7 @@ label: bug
<!--
Please carefully fill out the questionnaire below to help improve the
Please carefully fill out the questionaire below to help improve the
timely triaging of issues. Walk through the questions below and use
them as an inspiration for what information you can provide.

View File

@ -1,12 +0,0 @@
# Docs: <https://docs.github.com/en/code-security/dependabot/dependabot-version-updates/customizing-dependency-updates>
version: 2
updates:
- package-ecosystem: github-actions
directory: /
schedule: {interval: monthly}
- package-ecosystem: pip
directory: /docs/
schedule: {interval: monthly}

237
.github/filters.yml vendored
View File

@ -1,237 +0,0 @@
{
"ath79-generic": [
"targets/ath79-generic",
"modules",
"Makefile",
"patches/**",
"scripts/**",
"targets/generic",
"targets/targets.mk"
],
"ath79-nand": [
"targets/ath79-nand",
"modules",
"Makefile",
"patches/**",
"scripts/**",
"targets/generic",
"targets/targets.mk"
],
"ath79-mikrotik": [
"targets/ath79-mikrotik",
"modules",
"Makefile",
"patches/**",
"scripts/**",
"targets/generic",
"targets/targets.mk",
"targets/mikrotik.inc"
],
"bcm27xx-bcm2708": [
"targets/bcm27xx-bcm2708",
"modules",
"Makefile",
"patches/**",
"scripts/**",
"targets/generic",
"targets/targets.mk",
"targets/bcm27xx.inc"
],
"bcm27xx-bcm2709": [
"targets/bcm27xx-bcm2709",
"modules",
"Makefile",
"patches/**",
"scripts/**",
"targets/generic",
"targets/targets.mk",
"targets/bcm27xx.inc"
],
"ipq40xx-generic": [
"targets/ipq40xx-generic",
"modules",
"Makefile",
"patches/**",
"scripts/**",
"targets/generic",
"targets/targets.mk"
],
"ipq40xx-mikrotik": [
"targets/ipq40xx-mikrotik",
"modules",
"Makefile",
"patches/**",
"scripts/**",
"targets/generic",
"targets/targets.mk",
"targets/mikrotik.inc"
],
"ipq806x-generic": [
"targets/ipq806x-generic",
"modules",
"Makefile",
"patches/**",
"scripts/**",
"targets/generic",
"targets/targets.mk"
],
"lantiq-xrx200": [
"targets/lantiq-xrx200",
"modules",
"Makefile",
"patches/**",
"scripts/**",
"targets/generic",
"targets/targets.mk"
],
"lantiq-xway": [
"targets/lantiq-xway",
"modules",
"Makefile",
"patches/**",
"scripts/**",
"targets/generic",
"targets/targets.mk"
],
"mediatek-mt7622": [
"targets/mediatek-mt7622",
"modules",
"Makefile",
"patches/**",
"scripts/**",
"targets/generic",
"targets/targets.mk"
],
"mpc85xx-p1010": [
"targets/mpc85xx-p1010",
"modules",
"Makefile",
"patches/**",
"scripts/**",
"targets/generic",
"targets/targets.mk"
],
"mpc85xx-p1020": [
"targets/mpc85xx-p1020",
"modules",
"Makefile",
"patches/**",
"scripts/**",
"targets/generic",
"targets/targets.mk"
],
"ramips-mt7620": [
"targets/ramips-mt7620",
"modules",
"Makefile",
"patches/**",
"scripts/**",
"targets/generic",
"targets/targets.mk"
],
"ramips-mt7621": [
"targets/ramips-mt7621",
"modules",
"Makefile",
"patches/**",
"scripts/**",
"targets/generic",
"targets/targets.mk"
],
"ramips-mt76x8": [
"targets/ramips-mt76x8",
"modules",
"Makefile",
"patches/**",
"scripts/**",
"targets/generic",
"targets/targets.mk"
],
"realtek-rtl838x": [
"targets/realtek-rtl838x",
"modules",
"Makefile",
"patches/**",
"scripts/**",
"targets/generic",
"targets/targets.mk"
],
"rockchip-armv8": [
"targets/rockchip-armv8",
"modules",
"Makefile",
"patches/**",
"scripts/**",
"targets/generic",
"targets/targets.mk"
],
"sunxi-cortexa7": [
"targets/sunxi-cortexa7",
"modules",
"Makefile",
"patches/**",
"scripts/**",
"targets/generic",
"targets/targets.mk"
],
"x86-generic": [
"targets/x86-generic",
"modules",
"Makefile",
"patches/**",
"scripts/**",
"targets/generic",
"targets/targets.mk",
"targets/x86.inc"
],
"x86-geode": [
"targets/x86-geode",
"modules",
"Makefile",
"patches/**",
"scripts/**",
"targets/generic",
"targets/targets.mk"
],
"x86-legacy": [
"targets/x86-legacy",
"modules",
"Makefile",
"patches/**",
"scripts/**",
"targets/generic",
"targets/targets.mk",
"targets/x86.inc"
],
"x86-64": [
"targets/x86-64",
"modules",
"Makefile",
"patches/**",
"scripts/**",
"targets/generic",
"targets/targets.mk",
"targets/x86.inc",
"contrib/ci/minimal-site/**",
"package/**"
],
"bcm27xx-bcm2710": [
"targets/bcm27xx-bcm2710",
"modules",
"Makefile",
"patches/**",
"scripts/**",
"targets/generic",
"targets/targets.mk",
"targets/bcm27xx.inc"
],
"mvebu-cortexa9": [
"targets/mvebu-cortexa9",
"modules",
"Makefile",
"patches/**",
"scripts/**",
"targets/generic",
"targets/targets.mk"
]
}

59
.github/labeler.yml vendored
View File

@ -1,59 +0,0 @@
---
"3. topic: babel":
- package/gluon-l3roamd/**
- package/gluon-mesh-babel/**
- package/gluon-mmfd/**
"3. topic: batman-adv":
- docs/package/gluon-mesh-batman-adv*
- package/gluon-alfred/**
- package/gluon-cient-bridge/**
- package/gluon-mesh-batman-adv/**
- package/libbatadv/**
"3. topic: build":
- Makefile
- scripts/**
"3. topic: config-mode":
- docs/dev/web/config-mode.rst
- docs/package/gluon-config-mode-*
- packge/gluon-config-mode-*/**
- package/gluon-web*/**
"3. topic: continous integration":
- .github/workflows/*
- contrib/actions/**
- contrib/ci/**
"3. topic: docs":
- docs/**
"3. topic: fastd":
- docs/features/fastd*
- package/gluon-mesh-vpn-fastd/**
"3. topic: firewall":
- package/**/*-firewall
- package/gluon-ebtables-*/**
"3. topic: hardware":
- package/gluon-core/luasrc/lib/gluon/upgrade/010-primary-mac
- package/gluon-core/luasrc/usr/lib/lua/gluon/platform.lua
- targets/*
"3. topic: multidomain":
- docs/features/multidomain*
- docs/multidomain-site-example/**
- package/gluon-config-mode-domain-select/**
- package/gluon-scheduled-domain-switch/**
"3. topic: package":
- package/**
"3. topic: respondd":
- package/**/*respondd*
- package/gluon-respondd/**
"3. topic: status-page":
- package/gluon-status-page/**
"3. topic: tests":
- tests/**
"3. topic: tunneldigger":
- package/gluon-mesh-vpn-tunneldigger/**
"3. topic: wireguard":
- package/gluon-mesh-vpn-wireguard/**
"3. topic: wireless":
- package/gluon-mesh-wireless-sae/**
- package/gluon-private-wifi/**
- package/gluon-web-private-wifi/**
- package/gluon-web-wifi-config/**
- package/gluon-wireless-encryption/**

View File

@ -1,20 +0,0 @@
name: Backport
on:
pull_request_target:
types: [closed, labeled]
permissions:
contents: write # so it can comment
pull-requests: write # so it can create pull requests
jobs:
backport:
name: Backport Pull Request
if: github.repository_owner == 'freifunk-gluon' && github.event.pull_request.merged == true && (github.event_name != 'labeled' || startsWith('backport', github.event.label.name))
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Create backport PRs
uses: korthout/backport-action@v1.2.0
with:
# Config README: https://github.com/korthout/backport-action#backport-action
pull_description: |-
Automatic backport to `${target_branch}`, triggered by a label in #${pull_number}.

View File

@ -1,29 +1,20 @@
name: Build Documentation
on:
push:
paths:
- 'docs/**'
- '.github/workflows/build-docs.yml'
pull_request:
types: [opened, synchronize, reopened]
paths:
- 'docs**/'
- '.github/workflows/build-docs.yml'
permissions:
contents: read
jobs:
build-documentation:
name: docs
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- uses: actions/checkout@v1
- name: Install Dependencies
run: sudo pip3 install sphinx-rtd-theme
- name: Build documentation
run: make -C docs html
- name: Archive build output
uses: actions/upload-artifact@v3
uses: actions/upload-artifact@v1
with:
name: docs_output
path: docs/_build/html

View File

@ -1,61 +1,519 @@
# Update this file after adding/removing/renaming a target by running
# `make list-targets BROKEN=1 | ./contrib/actions/generate-actions.py > ./.github/workflows/build-gluon.yml`
name: Build Gluon
on:
push:
branches:
- master
- next*
- next
- v20*
pull_request:
types: [opened, synchronize, reopened]
permissions:
contents: read
jobs:
changed:
permissions:
contents: read # for dorny/paths-filter to fetch a list of changed files
pull-requests: read # for dorny/paths-filter to read pull requests
runs-on: ubuntu-latest
outputs:
targets: ${{ steps.filter.outputs.changes }}
steps:
- uses: actions/checkout@v3
# Filter targets based on changed files
- uses: dorny/paths-filter@v2
id: filter
with:
filters: .github/filters.yml
build_firmware:
needs: changed
if: ${{ needs.changed.outputs.targets != '[]' && needs.changed.outputs.targets != '' }}
strategy:
fail-fast: false
matrix:
# Read back changed targets to create build matrix
target: ${{ fromJSON(needs.changed.outputs.targets) }}
ar71xx-generic:
name: ar71xx-generic
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- uses: actions/checkout@v1
- name: Install Dependencies
run: sudo contrib/actions/install-dependencies.sh
- name: Build
run: contrib/actions/run-build.sh ${{ matrix.target }}
run: contrib/actions/run-build.sh ar71xx-generic
- name: Archive build logs
if: ${{ !cancelled() }}
uses: actions/upload-artifact@v3
uses: actions/upload-artifact@v1
with:
name: ${{ matrix.target }}_logs
name: ar71xx-generic_logs
path: openwrt/logs
- name: Archive build output
uses: actions/upload-artifact@v3
uses: actions/upload-artifact@v1
with:
name: ${{ matrix.target }}_output
name: ar71xx-generic_output
path: output
ar71xx-tiny:
name: ar71xx-tiny
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v1
- name: Install Dependencies
run: sudo contrib/actions/install-dependencies.sh
- name: Build
run: contrib/actions/run-build.sh ar71xx-tiny
- name: Archive build logs
if: ${{ !cancelled() }}
uses: actions/upload-artifact@v1
with:
name: ar71xx-tiny_logs
path: openwrt/logs
- name: Archive build output
uses: actions/upload-artifact@v1
with:
name: ar71xx-tiny_output
path: output
ar71xx-nand:
name: ar71xx-nand
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v1
- name: Install Dependencies
run: sudo contrib/actions/install-dependencies.sh
- name: Build
run: contrib/actions/run-build.sh ar71xx-nand
- name: Archive build logs
if: ${{ !cancelled() }}
uses: actions/upload-artifact@v1
with:
name: ar71xx-nand_logs
path: openwrt/logs
- name: Archive build output
uses: actions/upload-artifact@v1
with:
name: ar71xx-nand_output
path: output
ath79-generic:
name: ath79-generic
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v1
- name: Install Dependencies
run: sudo contrib/actions/install-dependencies.sh
- name: Build
run: contrib/actions/run-build.sh ath79-generic
- name: Archive build logs
if: ${{ !cancelled() }}
uses: actions/upload-artifact@v1
with:
name: ath79-generic_logs
path: openwrt/logs
- name: Archive build output
uses: actions/upload-artifact@v1
with:
name: ath79-generic_output
path: output
brcm2708-bcm2708:
name: brcm2708-bcm2708
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v1
- name: Install Dependencies
run: sudo contrib/actions/install-dependencies.sh
- name: Build
run: contrib/actions/run-build.sh brcm2708-bcm2708
- name: Archive build logs
if: ${{ !cancelled() }}
uses: actions/upload-artifact@v1
with:
name: brcm2708-bcm2708_logs
path: openwrt/logs
- name: Archive build output
uses: actions/upload-artifact@v1
with:
name: brcm2708-bcm2708_output
path: output
brcm2708-bcm2709:
name: brcm2708-bcm2709
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v1
- name: Install Dependencies
run: sudo contrib/actions/install-dependencies.sh
- name: Build
run: contrib/actions/run-build.sh brcm2708-bcm2709
- name: Archive build logs
if: ${{ !cancelled() }}
uses: actions/upload-artifact@v1
with:
name: brcm2708-bcm2709_logs
path: openwrt/logs
- name: Archive build output
uses: actions/upload-artifact@v1
with:
name: brcm2708-bcm2709_output
path: output
ipq40xx-generic:
name: ipq40xx-generic
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v1
- name: Install Dependencies
run: sudo contrib/actions/install-dependencies.sh
- name: Build
run: contrib/actions/run-build.sh ipq40xx-generic
- name: Archive build logs
if: ${{ !cancelled() }}
uses: actions/upload-artifact@v1
with:
name: ipq40xx-generic_logs
path: openwrt/logs
- name: Archive build output
uses: actions/upload-artifact@v1
with:
name: ipq40xx-generic_output
path: output
ipq806x-generic:
name: ipq806x-generic
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v1
- name: Install Dependencies
run: sudo contrib/actions/install-dependencies.sh
- name: Build
run: contrib/actions/run-build.sh ipq806x-generic
- name: Archive build logs
if: ${{ !cancelled() }}
uses: actions/upload-artifact@v1
with:
name: ipq806x-generic_logs
path: openwrt/logs
- name: Archive build output
uses: actions/upload-artifact@v1
with:
name: ipq806x-generic_output
path: output
lantiq-xrx200:
name: lantiq-xrx200
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v1
- name: Install Dependencies
run: sudo contrib/actions/install-dependencies.sh
- name: Build
run: contrib/actions/run-build.sh lantiq-xrx200
- name: Archive build logs
if: ${{ !cancelled() }}
uses: actions/upload-artifact@v1
with:
name: lantiq-xrx200_logs
path: openwrt/logs
- name: Archive build output
uses: actions/upload-artifact@v1
with:
name: lantiq-xrx200_output
path: output
lantiq-xway:
name: lantiq-xway
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v1
- name: Install Dependencies
run: sudo contrib/actions/install-dependencies.sh
- name: Build
run: contrib/actions/run-build.sh lantiq-xway
- name: Archive build logs
if: ${{ !cancelled() }}
uses: actions/upload-artifact@v1
with:
name: lantiq-xway_logs
path: openwrt/logs
- name: Archive build output
uses: actions/upload-artifact@v1
with:
name: lantiq-xway_output
path: output
mpc85xx-generic:
name: mpc85xx-generic
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v1
- name: Install Dependencies
run: sudo contrib/actions/install-dependencies.sh
- name: Build
run: contrib/actions/run-build.sh mpc85xx-generic
- name: Archive build logs
if: ${{ !cancelled() }}
uses: actions/upload-artifact@v1
with:
name: mpc85xx-generic_logs
path: openwrt/logs
- name: Archive build output
uses: actions/upload-artifact@v1
with:
name: mpc85xx-generic_output
path: output
mpc85xx-p1020:
name: mpc85xx-p1020
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v1
- name: Install Dependencies
run: sudo contrib/actions/install-dependencies.sh
- name: Build
run: contrib/actions/run-build.sh mpc85xx-p1020
- name: Archive build logs
if: ${{ !cancelled() }}
uses: actions/upload-artifact@v1
with:
name: mpc85xx-p1020_logs
path: openwrt/logs
- name: Archive build output
uses: actions/upload-artifact@v1
with:
name: mpc85xx-p1020_output
path: output
ramips-mt7620:
name: ramips-mt7620
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v1
- name: Install Dependencies
run: sudo contrib/actions/install-dependencies.sh
- name: Build
run: contrib/actions/run-build.sh ramips-mt7620
- name: Archive build logs
if: ${{ !cancelled() }}
uses: actions/upload-artifact@v1
with:
name: ramips-mt7620_logs
path: openwrt/logs
- name: Archive build output
uses: actions/upload-artifact@v1
with:
name: ramips-mt7620_output
path: output
ramips-mt7621:
name: ramips-mt7621
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v1
- name: Install Dependencies
run: sudo contrib/actions/install-dependencies.sh
- name: Build
run: contrib/actions/run-build.sh ramips-mt7621
- name: Archive build logs
if: ${{ !cancelled() }}
uses: actions/upload-artifact@v1
with:
name: ramips-mt7621_logs
path: openwrt/logs
- name: Archive build output
uses: actions/upload-artifact@v1
with:
name: ramips-mt7621_output
path: output
ramips-mt76x8:
name: ramips-mt76x8
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v1
- name: Install Dependencies
run: sudo contrib/actions/install-dependencies.sh
- name: Build
run: contrib/actions/run-build.sh ramips-mt76x8
- name: Archive build logs
if: ${{ !cancelled() }}
uses: actions/upload-artifact@v1
with:
name: ramips-mt76x8_logs
path: openwrt/logs
- name: Archive build output
uses: actions/upload-artifact@v1
with:
name: ramips-mt76x8_output
path: output
ramips-rt305x:
name: ramips-rt305x
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v1
- name: Install Dependencies
run: sudo contrib/actions/install-dependencies.sh
- name: Build
run: contrib/actions/run-build.sh ramips-rt305x
- name: Archive build logs
if: ${{ !cancelled() }}
uses: actions/upload-artifact@v1
with:
name: ramips-rt305x_logs
path: openwrt/logs
- name: Archive build output
uses: actions/upload-artifact@v1
with:
name: ramips-rt305x_output
path: output
sunxi-cortexa7:
name: sunxi-cortexa7
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v1
- name: Install Dependencies
run: sudo contrib/actions/install-dependencies.sh
- name: Build
run: contrib/actions/run-build.sh sunxi-cortexa7
- name: Archive build logs
if: ${{ !cancelled() }}
uses: actions/upload-artifact@v1
with:
name: sunxi-cortexa7_logs
path: openwrt/logs
- name: Archive build output
uses: actions/upload-artifact@v1
with:
name: sunxi-cortexa7_output
path: output
x86-generic:
name: x86-generic
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v1
- name: Install Dependencies
run: sudo contrib/actions/install-dependencies.sh
- name: Build
run: contrib/actions/run-build.sh x86-generic
- name: Archive build logs
if: ${{ !cancelled() }}
uses: actions/upload-artifact@v1
with:
name: x86-generic_logs
path: openwrt/logs
- name: Archive build output
uses: actions/upload-artifact@v1
with:
name: x86-generic_output
path: output
x86-geode:
name: x86-geode
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v1
- name: Install Dependencies
run: sudo contrib/actions/install-dependencies.sh
- name: Build
run: contrib/actions/run-build.sh x86-geode
- name: Archive build logs
if: ${{ !cancelled() }}
uses: actions/upload-artifact@v1
with:
name: x86-geode_logs
path: openwrt/logs
- name: Archive build output
uses: actions/upload-artifact@v1
with:
name: x86-geode_output
path: output
x86-legacy:
name: x86-legacy
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v1
- name: Install Dependencies
run: sudo contrib/actions/install-dependencies.sh
- name: Build
run: contrib/actions/run-build.sh x86-legacy
- name: Archive build logs
if: ${{ !cancelled() }}
uses: actions/upload-artifact@v1
with:
name: x86-legacy_logs
path: openwrt/logs
- name: Archive build output
uses: actions/upload-artifact@v1
with:
name: x86-legacy_output
path: output
x86-64:
name: x86-64
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v1
- name: Install Dependencies
run: sudo contrib/actions/install-dependencies.sh
- name: Build
run: contrib/actions/run-build.sh x86-64
- name: Archive build logs
if: ${{ !cancelled() }}
uses: actions/upload-artifact@v1
with:
name: x86-64_logs
path: openwrt/logs
- name: Archive build output
uses: actions/upload-artifact@v1
with:
name: x86-64_output
path: output
ar71xx-mikrotik:
name: ar71xx-mikrotik
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v1
- name: Install Dependencies
run: sudo contrib/actions/install-dependencies.sh
- name: Build
run: contrib/actions/run-build.sh ar71xx-mikrotik
- name: Archive build logs
if: ${{ !cancelled() }}
uses: actions/upload-artifact@v1
with:
name: ar71xx-mikrotik_logs
path: openwrt/logs
- name: Archive build output
uses: actions/upload-artifact@v1
with:
name: ar71xx-mikrotik_output
path: output
brcm2708-bcm2710:
name: brcm2708-bcm2710
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v1
- name: Install Dependencies
run: sudo contrib/actions/install-dependencies.sh
- name: Build
run: contrib/actions/run-build.sh brcm2708-bcm2710
- name: Archive build logs
if: ${{ !cancelled() }}
uses: actions/upload-artifact@v1
with:
name: brcm2708-bcm2710_logs
path: openwrt/logs
- name: Archive build output
uses: actions/upload-artifact@v1
with:
name: brcm2708-bcm2710_output
path: output
mvebu-cortexa9:
name: mvebu-cortexa9
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v1
- name: Install Dependencies
run: sudo contrib/actions/install-dependencies.sh
- name: Build
run: contrib/actions/run-build.sh mvebu-cortexa9
- name: Archive build logs
if: ${{ !cancelled() }}
uses: actions/upload-artifact@v1
with:
name: mvebu-cortexa9_logs
path: openwrt/logs
- name: Archive build output
uses: actions/upload-artifact@v1
with:
name: mvebu-cortexa9_output
path: output

View File

@ -1,26 +1,14 @@
---
name: Check patches
on:
push:
paths:
- 'modules'
- 'patches/**'
- '.github/workflows/check-patches.yml'
pull_request:
types: [opened, synchronize, reopened]
paths:
- 'modules'
- 'patches/**'
- '.github/workflows/check-patches.yml'
permissions:
contents: read
jobs:
check-patches:
name: Check patches
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- uses: actions/checkout@v1
- name: Refresh patches
run: make refresh-patches GLUON_SITEDIR="contrib/ci/minimal-site"
- name: Show diff

View File

@ -1,21 +0,0 @@
name: "Label PRs"
on:
# only execute base branch actions
pull_request_target:
permissions:
contents: read
jobs:
labels:
permissions:
contents: read # for actions/labeler to determine modified files
pull-requests: write # for actions/labeler to add labels to PRs
runs-on: ubuntu-latest
if: github.repository_owner == 'freifunk-gluon'
steps:
- uses: actions/labeler@v4
with:
repo-token: ${{ secrets.GITHUB_TOKEN }}
sync-labels: true

View File

@ -3,17 +3,14 @@ on:
push:
pull_request:
types: [opened, synchronize, reopened]
permissions:
contents: read
jobs:
lua:
name: Lua
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- uses: actions/checkout@v1
- name: Install Dependencies
run: sudo apt-get -y update && sudo apt-get -y install lua-check
run: sudo apt install lua-check
- name: Install example site
run: ln -s ./docs/site-example ./site
- name: Lint Lua code
@ -23,32 +20,10 @@ jobs:
name: Shell
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- uses: actions/checkout@v1
- name: Install Dependencies
run: sudo apt-get -y update && sudo apt-get -y install shellcheck
run: sudo apt install shellcheck
- name: Install example site
run: ln -s ./docs/site-example ./site
- name: Lint shell code
run: make lint-sh
editorconfig:
name: Editorconfig
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Install Dependencies
run: sudo apt install curl tar
- name: Install editorconfig-checker
env:
VERSION: 2.7.0
OS: linux
ARCH: amd64
run: |
curl -O -L -C - https://github.com/editorconfig-checker/editorconfig-checker/releases/download/$VERSION/ec-$OS-$ARCH.tar.gz
tar xzf ec-$OS-$ARCH.tar.gz
sudo mv ./bin/ec-$OS-$ARCH /usr/bin/editorconfig-checker
sudo chmod +x /usr/bin/editorconfig-checker
- name: Install example site
run: ln -s ./docs/site-example ./site
- name: Lint editorconfig
run: make lint-editorconfig

2
.gitignore vendored
View File

@ -2,9 +2,9 @@
/openwrt
/output
/site
/tests/__pycache__
/tmp
/packages
.bash_history
.subversion
.wget-hsts
/.scmversion

View File

@ -25,11 +25,9 @@ files["package/**/check_site.lua"] = {
"extend",
"in_domain",
"in_site",
"value",
"need",
"need_alphanumeric_key",
"need_array",
"need_array_elements_exclusive",
"need_array_of",
"need_boolean",
"need_chanlist",
@ -51,7 +49,6 @@ files["package/**/check_site.lua"] = {
files["package/**/luasrc/lib/gluon/config-mode/*"] = {
globals = {
"MultiListValue",
"DynamicList",
"Flag",
"Form",
@ -65,7 +62,6 @@ files["package/**/luasrc/lib/gluon/config-mode/*"] = {
"translate",
"translatef",
"Value",
"Element",
},
}

View File

@ -1,20 +0,0 @@
# .readthedocs.yaml
# Read the Docs configuration file
# See https://docs.readthedocs.io/en/stable/config-file/v2.html for details
# Required
version: 2
# Build documentation in the docs/ directory with Sphinx
sphinx:
configuration: docs/conf.py
# Optionally set the version of Python and requirements required to build your docs
python:
install:
- requirements: docs/requirements.txt
build:
os: ubuntu-22.04
tools:
python: "3.8"

View File

@ -1,30 +0,0 @@
workspace:
base: /build
#clone:
# git:
# image: woodpeckerci/plugin-git
# settings:
# recursive: true
pipeline:
build-${TARGET}:
image: "ubuntu:latest"
pull: true
environment:
- input_version=v2022.1.4
- GLUON_SITEDIR=../site
- FORCE_UNSAFE_CONFIGURE=1
- GLUON_TARGET=${TARGET}
- GLUON_DEPRECATED=1
commands:
- echo ${TARGET}
# - git config --global init.defaultBranch main
# - sed -i 's/install/install file/' contrib/actions/install-dependencies.sh
# - sh contrib/actions/install-dependencies.sh
# - sh contrib/actions/run-build.sh ${TARGET}
matrix:
TARGET:
- ath79-generic
- x86-64

View File

@ -23,8 +23,8 @@ using other parts or why the proposed change breaks other parts of the system.
They might even refuse the idea altogether - after all, they have to sleep well
after merging the changes, too.
The preferred way to discuss is in the IRC channel ([#gluon] on irc.hackint.org)
or on the [mailing list], however, you can also open a new issue on GitHub to
The preferred way to discuss in the IRC channel ([#gluon] on irc.hackint.org)
or on the [mailing list], however, you can also open a new issue on Github to
discuss there. We maintain a [list of rejected features] and we'd like to
kindly ask you to review it first. In general, looking for duplicates may save
you some time.

View File

@ -1,7 +1,7 @@
The code of Project Gluon may be distributed under the following terms, unless
noted otherwise in individual files or subtrees.
Copyright (c) Project Gluon
Copyright (c) 2013-2018, Project Gluon
All rights reserved.
Redistribution and use in source and binary forms, with or without

View File

@ -19,15 +19,14 @@ escape = '$(subst ','\'',$(1))'
GLUON_SITEDIR ?= site
$(eval $(call mkabspath,GLUON_SITEDIR))
ifeq ($(realpath $(GLUON_SITEDIR)/site.mk),)
$(GLUON_SITEDIR)/site.mk:
$(error No site configuration was found. Please check out a site configuration to $(GLUON_SITEDIR))
endif
include $(GLUON_SITEDIR)/site.mk
GLUON_RELEASE ?= $(error GLUON_RELEASE not set. GLUON_RELEASE can be set in site.mk or on the command line)
GLUON_DEPRECATED ?= 0
GLUON_DEPRECATED ?= $(error GLUON_DEPRECATED not set. Please consult the documentation)
ifneq ($(GLUON_BRANCH),)
$(warning *** Warning: GLUON_BRANCH has been deprecated, please set GLUON_AUTOUPDATER_BRANCH and GLUON_AUTOUPDATER_ENABLED instead.)
@ -53,9 +52,6 @@ $(eval $(call mkabspath,GLUON_PACKAGEDIR))
$(eval $(call mkabspath,GLUON_TARGETSDIR))
$(eval $(call mkabspath,GLUON_PATCHESDIR))
GLUON_VERSION := $(shell scripts/getversion.sh '.')
GLUON_SITE_VERSION := $(shell scripts/getversion.sh '$(GLUON_SITEDIR)')
GLUON_MULTIDOMAIN ?= 0
GLUON_AUTOREMOVE ?= 0
GLUON_DEBUG ?= 0
@ -68,10 +64,9 @@ src-link gluon_base ../../package
endef
GLUON_VARS = \
GLUON_VERSION GLUON_SITE_VERSION \
GLUON_RELEASE GLUON_REGION GLUON_MULTIDOMAIN GLUON_AUTOREMOVE GLUON_DEBUG GLUON_MINIFY GLUON_DEPRECATED \
GLUON_DEVICES GLUON_TARGETSDIR GLUON_PATCHESDIR GLUON_TMPDIR GLUON_IMAGEDIR GLUON_PACKAGEDIR GLUON_DEBUGDIR \
GLUON_SITEDIR GLUON_AUTOUPDATER_BRANCH GLUON_AUTOUPDATER_ENABLED GLUON_LANGS GLUON_BASE_FEEDS \
GLUON_SITEDIR GLUON_RELEASE GLUON_AUTOUPDATER_BRANCH GLUON_AUTOUPDATER_ENABLED GLUON_LANGS GLUON_BASE_FEEDS \
GLUON_TARGET BOARD SUBTARGET
unexport $(GLUON_VARS)
@ -105,11 +100,6 @@ refresh-patches: FORCE
update-feeds: FORCE
@$(GLUON_ENV) scripts/feeds.sh
update-modules: FORCE
@scripts/update-modules.sh
update-ci: FORCE
@$(GLUON_ENV) scripts/update-ci.sh
GLUON_TARGETS :=
@ -151,10 +141,7 @@ list-targets: FORCE
echo "$$target"
done
lint: lint-editorconfig lint-lua lint-sh
lint-editorconfig: FORCE
@scripts/lint-editorconfig.sh
lint: lint-lua lint-sh
lint-lua: FORCE
@scripts/lint-lua.sh
@ -184,16 +171,11 @@ config: $(LUA) FORCE
$(call CheckSite,$(conf)); \
)
$(OPENWRTMAKE) prepare-tmpinfo
$(GLUON_ENV) $(LUA) scripts/target_config.lua > openwrt/.config
$(OPENWRTMAKE) defconfig
$(GLUON_ENV) $(LUA) scripts/target_config_check.lua
container: FORCE
@scripts/container.sh
all: config
+@
$(GLUON_ENV) $(LUA) scripts/clean_output.lua

View File

@ -1,21 +1,12 @@
[![Build Gluon](https://github.com/freifunk-gluon/gluon/actions/workflows/build-gluon.yml/badge.svg?branch=master)](https://github.com/freifunk-gluon/gluon/actions/workflows/build-gluon.yml)
[![License](https://img.shields.io/badge/License-BSD%202--Clause-orange.svg)](https://opensource.org/license/bsd-2-clause/)
[![GitHub release (latest SemVer)](https://img.shields.io/github/v/release/freifunk-gluon/gluon?sort=semver)](https://github.com/freifunk-gluon/gluon/releases/latest)
# Gluon
Gluon is a firmware framework to build preconfigured OpenWrt images for public mesh networks.
## Getting started
We have a huge amount of documentation over at https://gluon.readthedocs.io/.
Documentation (incomplete at this time, contribute if you can!) may be found at
https://gluon.readthedocs.io/.
If you're new to Gluon and ready to get your feet wet, have a look at the
[Getting Started Guide](https://gluon.readthedocs.io/en/latest/user/getting_started.html).
Gluon's developers frequent an IRC chatroom at [#gluon](ircs://irc.hackint.org/#gluon)
on [hackint](https://hackint.org/). There is also a [webchat](https://webirc.hackint.org/#irc://irc.hackint.org/#gluon)
that allows for uncomplicated access from within your browser. This channel is also available as a bridged Matrix Room at [#gluon:hackint.org](https://matrix.to/#/#gluon:hackint.org).
that allows for access from within your browser.
## Issues & Feature requests
@ -30,10 +21,10 @@ the future development of Gluon.
Please refrain from using the `master` branch for anything else but development purposes!
Use the most recent release instead. You can list all releases by running `git tag`
and switch to one by running `git checkout v2022.1 && make update`.
and switch to one by running `git checkout v2020.2.1 && make update`.
If you're using the autoupdater, do not autoupdate nodes with anything but releases.
If you upgrade using random master commits the nodes *might break* eventually.
If you upgrade using random master commits the nodes *will break* eventually.
## Mailinglist

31
contrib/Dockerfile Normal file
View File

@ -0,0 +1,31 @@
FROM debian:buster-slim
RUN apt update && apt install -y --no-install-recommends \
ca-certificates \
file \
git \
subversion \
python \
python3 \
python3-pytest \
build-essential \
gawk \
unzip \
libncurses5-dev \
zlib1g-dev \
libssl-dev \
libelf-dev \
wget \
time \
ecdsautils \
lua-check \
shellcheck \
qemu-system-x86 \
&& rm -rf /var/lib/apt/lists/*
RUN python3 -m pip install gluon-qemu-testlab
RUN useradd -d /gluon gluon
USER gluon
VOLUME /gluon
WORKDIR /gluon

View File

@ -0,0 +1,49 @@
#!/usr/bin/env python3
import sys
ACTIONS_HEAD = """
# Update this file after adding/removing/renaming a target by running
# `make list-targets BROKEN=1 | ./contrib/actions/generate-actions.py > ./.github/workflows/build-gluon.yml`
name: Build Gluon
on:
push:
branches:
- master
- next
- v20*
pull_request:
types: [opened, synchronize, reopened]
jobs:
"""
ACTIONS_TARGET="""
{target_name}:
name: {target_name}
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v1
- name: Install Dependencies
run: sudo contrib/actions/install-dependencies.sh
- name: Build
run: contrib/actions/run-build.sh {target_name}
- name: Archive build logs
if: ${{{{ !cancelled() }}}}
uses: actions/upload-artifact@v1
with:
name: {target_name}_logs
path: openwrt/logs
- name: Archive build output
uses: actions/upload-artifact@v1
with:
name: {target_name}_output
path: output
"""
output = ACTIONS_HEAD
for target in sys.stdin:
output += ACTIONS_TARGET.format(target_name=target.strip())
print(output)

View File

@ -1,53 +0,0 @@
#!/usr/bin/env python3
# Update target filters using
# make update-ci
import re
import os
import sys
import json
# these changes trigger rebuilds on all targets
common = [
"modules",
"Makefile",
"patches/**",
"scripts/**",
"targets/generic",
"targets/targets.mk",
]
# these changes are only built on x86-64
extra = [
"contrib/ci/minimal-site/**",
"package/**"
]
_filter = dict()
# INCLUDE_PATTERN matches:
# include '...'
# include "..."
# include("...")
# include('...')
INCLUDE_PATTERN = "^\\s*include *\\(? *[\"']([^\"']+)[\"']"
# construct filters map from stdin
for target in sys.stdin:
target = target.strip()
_filter[target] = [
f"targets/{target}"
] + common
target_file = os.path.join(os.environ['GLUON_TARGETSDIR'], target)
with open(target_file) as f:
includes = re.findall(INCLUDE_PATTERN, f.read(), re.MULTILINE)
_filter[target].extend([f"targets/{i}" for i in includes])
if target == "x86-64":
_filter[target].extend(extra)
# print filters to stdout in json format, because json is stdlib and yaml compatible.
print(json.dumps(_filter, indent=2))

View File

@ -2,7 +2,9 @@
set -e
apt-get -y update
apt-get -y install git build-essential python3 gawk unzip libncurses5-dev zlib1g-dev libssl-dev libelf-dev wget rsync time qemu-utils
apt-get -y clean
cp contrib/actions/sources.list /etc/apt/sources.list
rm -rf /etc/apt/sources.list.d
apt update
apt install git subversion build-essential python gawk unzip libncurses5-dev zlib1g-dev libssl-dev wget time
apt clean
rm -rf /var/lib/apt/lists/*

View File

@ -6,7 +6,7 @@ export BROKEN=1
export GLUON_AUTOREMOVE=1
export GLUON_DEPRECATED=1
export GLUON_SITEDIR="contrib/ci/minimal-site"
export GLUON_TARGET="$1"
export GLUON_TARGET=$1
export BUILD_LOG=1
make update

View File

@ -0,0 +1,2 @@
deb http://mirror.netcologne.de/ubuntu/ bionic main restricted
deb http://mirror.netcologne.de/ubuntu/ bionic-updates main restricted

82
contrib/ci/Jenkinsfile vendored Normal file
View File

@ -0,0 +1,82 @@
pipeline {
agent none
environment {
GLUON_SITEDIR = "contrib/ci/minimal-site"
GLUON_TARGET = "x86-64"
BUILD_LOG = "1"
}
stages {
stage('lint') {
parallel {
stage('lint-lua') {
agent { label 'gluon-docker' }
steps {
sh label: 'Identify runner', script: 'echo $SLAVE_NAME'
sh 'make lint-lua'
}
}
stage('lint-sh') {
agent { label 'gluon-docker-v1' }
steps {
sh label: 'Identify runner', script: 'echo $SLAVE_NAME'
sh 'make lint-sh'
}
}
}
}
stage('docs') {
agent { label 'gluon-docker' }
steps {
sh label: 'Identify runner', script: 'echo $SLAVE_NAME'
sh 'make -C docs html'
}
}
stage('build') {
agent { label 'gluon-docker-v2' }
steps {
sh label: 'Identify runner', script: 'echo $SLAVE_NAME'
sh 'make update'
sh 'test -d /dl_cache && ln -s /dl_cache openwrt/dl || true'
timeout(time: 2, unit: "HOURS") {
sh 'make -j$(nproc) V=s'
}
stash includes: '**/output/images/factory/*-x86-64.img.gz', name: 'gluon-x86-64-factory'
}
}
stage('test') {
agent { label 'gluon-vmx' }
steps {
sh label: 'Identify runner', script: 'echo $SLAVE_NAME'
unstash 'gluon-x86-64-factory'
sh label: 'Unpack image', script: 'gunzip -cd ./output/images/factory/*x86-64*.img.gz > ./image.img'
sh label: 'Print python environment', script: 'python3 -m pip freeze'
script {
for (f in findFiles(glob: 'tests/*.py')) {
timeout(time: 10, unit: "MINUTES") {
sh label: "Test ${f.name}", script: "python3 tests/${f.name} --use-tmp-workdir"
}
}
}
}
}
}
}
/*
api-history:
Every time the build dependencies of gluon change, the version
every container has to be rebuilt. Therefore, we use Jenkins
labels which intoduce a version number which is documented here.
As soon, as you properly rebuilt your docker container, you
can notify lemoer, that you have updated your node.
- gluon-docker-v1:
- add shellcheck binary to the build environment
- gluon-docker-v2:
- add qemu-testlab testing, requires KVM virtualization support
- require rsync dependency to be able to build the next branch
- gluon-vmx
- splits the qemu testing from the gluon-docker-v2 label to accomodate
nodes without the vmx cpu flag
*/

View File

@ -0,0 +1,33 @@
FROM gluonmesh/build:latest
USER root
# this is needed to install default-jre-headless in debian slim images
RUN mkdir -p /usr/share/man/man1
RUN apt-get update && apt-get install -y default-jre-headless curl git netcat-openbsd python3 python3-pip qemu-system-x86 iproute2 openssh-client rsync
RUN python3 -m pip install jenkins-webapi sphinx sphinx_rtd_theme gluon-qemu-testlab==0.0.5
# Get docker-compose in the agent container
RUN mkdir -p /home/jenkins
RUN mkdir -p /var/lib/jenkins
RUN mkdir -p /remoting
RUN chown gluon /home/jenkins
RUN chown gluon /var/lib/jenkins
RUN chown gluon /remoting
# Start-up script to attach the slave to the master
ADD slave.py /var/lib/jenkins/slave.py
USER gluon
WORKDIR /home/jenkins
ENV JENKINS_URL "https://build.ffh.zone/"
ENV JENKINS_SLAVE_ADDRESS ""
ENV SLAVE_EXECUTORS "1"
ENV SLAVE_LABELS "docker"
ENV SLAVE_WORING_DIR ""
ENV CLEAN_WORKING_DIR "true"
CMD [ "python3", "-u", "/var/lib/jenkins/slave.py" ]

View File

@ -0,0 +1,41 @@
# Gluon CI using Jenkins
## Requirements
- Linux system
- with docker installed
- with Hardware Virtualisation (KVM Support)
- Verify using: `lscpu | grep vmx`
- If machine is virtualized host needs to load `kvm_intel` with `nested=1` option and cpuflags need to include `vmx`
## Architecture
![Screenshot from 2019-09-24 00-20-32](https://user-images.githubusercontent.com/601153/65468827-9edf2c80-de65-11e9-9fe0-56c3487719c3.png)
## Installation
You can support the gluon CI with your infrastructure:
1. You need to query @lemoer (freifunk@irrelefant.net) for credentials.
2. He will give you a `SLAVE_NAME` and a `SLAVE_SECRET` for your host.
3. Then go to your docker host and substitute the values for `SLAVE_NAME` and a `SLAVE_SECRET` in the following statements:
``` shell
git clone https://github.com/freifunk-gluon/gluon/
cd gluon/contrib/ci/jenkins-community-slave/
docker build -t gluon-jenkins .
mkdir /var/cache/openwrt_dl_cache/
chown 1000:1000 /var/cache/openwrt_dl_cache
echo "z /dev/kvm 0666 - kvm -" > /etc/tmpfiles.d/kvm.conf
systemd-tmpfiles --create
docker run --detach --restart always \
--env "SLAVE_NAME=whoareyou" \
--env "SLAVE_SECRET=changeme" \
--device /dev/kvm:/dev/kvm \
--volume /var/cache/openwrt_dl_cache/:/dl_cache \
gluon-jenkins
```
4. Check whether the instance is running correctly:
- Your node should appear [here](https://build.ffh.zone/label/gluon-docker/).
- When clicking on it, Jenkins should state "Agent is connected." like here:
![Screenshot from 2019-09-24 01-00-52](https://user-images.githubusercontent.com/601153/65469209-dac6c180-de66-11e9-9d62-0d1c3b6b940b.png)
5. **Your docker container needs to be rebuilt, when the build dependencies of gluon change. As soon as build dependencies have changed, the build dependency api level has to be raised.** After you rebuilt your docker container, notifiy @lemoer, so he can bump the versioning number.
## Backoff
- If @lemoer is not reachable, please be patient at first if possible. Otherwise contact info@hannover.freifunk.net or join the channel `#freifunkh` on hackint.

View File

@ -0,0 +1,103 @@
from jenkins import Jenkins, JenkinsError, NodeLaunchMethod
import os
import signal
import sys
import subprocess
import shutil
import requests
import time
slave_jar = '/var/lib/jenkins/slave.jar'
slave_name = os.environ['SLAVE_NAME'] if os.environ['SLAVE_NAME'] != '' else 'docker-slave-' + os.environ['HOSTNAME']
jnlp_url = os.environ['JENKINS_URL'] + '/computer/' + slave_name + '/slave-agent.jnlp'
slave_jar_url = os.environ['JENKINS_URL'] + '/jnlpJars/slave.jar'
print(slave_jar_url)
process = None
def clean_dir(dir):
for root, dirs, files in os.walk(dir):
for f in files:
os.unlink(os.path.join(root, f))
for d in dirs:
shutil.rmtree(os.path.join(root, d))
def slave_create(node_name, working_dir, executors, labels):
j = Jenkins(os.environ['JENKINS_URL'], os.environ['JENKINS_USER'], os.environ['JENKINS_PASS'])
j.node_create(node_name, working_dir, num_executors = int(executors), labels = labels, launcher = NodeLaunchMethod.JNLP)
def slave_delete(node_name):
j = Jenkins(os.environ['JENKINS_URL'], os.environ['JENKINS_USER'], os.environ['JENKINS_PASS'])
j.node_delete(node_name)
def slave_download(target):
if os.path.isfile(slave_jar):
os.remove(slave_jar)
r = requests.get(os.environ['JENKINS_URL'] + '/jnlpJars/slave.jar')
with open('/var/lib/jenkins/slave.jar', 'wb') as f:
f.write(r.content)
def slave_run(slave_jar, jnlp_url):
params = [ 'java', '-jar', slave_jar, '-jnlpUrl', jnlp_url ]
if os.environ['JENKINS_SLAVE_ADDRESS'] != '':
params.extend([ '-connectTo', os.environ['JENKINS_SLAVE_ADDRESS' ] ])
if os.environ['SLAVE_SECRET'] == '':
params.extend([ '-jnlpCredentials', os.environ['JENKINS_USER'] + ':' + os.environ['JENKINS_PASS'] ])
else:
params.extend([ '-secret', os.environ['SLAVE_SECRET'] ])
return subprocess.Popen(params, stdout=subprocess.PIPE)
def signal_handler(sig, frame):
if process != None:
process.send_signal(signal.SIGINT)
signal.signal(signal.SIGINT, signal_handler)
signal.signal(signal.SIGTERM, signal_handler)
def h():
print("ERROR!: please specify environment variables")
print("")
print('docker run -e "SLAVE_NAME=test" -e "SLAVE_SECRET=..." jenkins')
if os.environ.get('SLAVE_NAME') is None:
h()
sys.exit(1)
if os.environ.get('SLAVE_SECRET') is None:
h()
sys.exit(1)
def master_ready(url):
try:
r = requests.head(url, timeout=None)
return r.status_code == requests.codes.ok
except:
return False
while not master_ready(slave_jar_url):
print("Master not ready yet, sleeping for 10sec!")
time.sleep(10)
slave_download(slave_jar)
print('Downloaded Jenkins slave jar.')
if os.environ['SLAVE_WORING_DIR']:
os.setcwd(os.environ['SLAVE_WORING_DIR'])
if os.environ['CLEAN_WORKING_DIR'] == 'true':
clean_dir(os.getcwd())
print("Cleaned up working directory.")
if os.environ['SLAVE_NAME'] == '':
slave_create(slave_name, os.getcwd(), os.environ['SLAVE_EXECUTORS'], os.environ['SLAVE_LABELS'])
print('Created temporary Jenkins slave.')
process = slave_run(slave_jar, jnlp_url)
print('Started Jenkins slave with name "' + slave_name + '" and labels [' + os.environ['SLAVE_LABELS'] + '].')
process.wait()
print('Jenkins slave stopped.')
if os.environ['SLAVE_NAME'] == '':
slave_delete(slave_name)
print('Removed temporary Jenkins slave.')

View File

@ -1,4 +1,4 @@
-- This is an example site configuration for Gluon v2022.1
-- This is an example site configuration for Gluon v2018.2+
--
-- Take a look at the documentation located at
-- https://gluon.readthedocs.io/ for details.
@ -10,7 +10,7 @@
-- hostname_prefix = 'freifunk-',
-- Name of the community.
site_name = 'Continuous Integration',
site_name = 'Continious Integration',
-- Shorthand of the community.
site_code = 'ci',
@ -42,14 +42,10 @@
-- Wireless channel.
channel = 1,
-- ESSIDs used for client network.
-- ESSID used for client network.
ap = {
ssid = 'gluon-ci-ssid',
-- disabled = true, -- (optional)
-- Configuration for a backward compatible OWE network below.
owe_ssid = 'owe.gluon-ci-ssid', -- (optional - SSID for OWE client network)
owe_transition_mode = true, -- (optional - enables transition-mode - requires ssid as well as owe_ssid)
},
mesh = {
@ -76,12 +72,6 @@
},
},
mesh = {
vxlan = true,
batman_adv = {
routing_algo = 'BATMAN_IV',
},
},
-- The next node feature allows clients to always reach the node it is
-- connected to using a known IP address.
@ -92,19 +82,16 @@
ip6 = 'fd::1',
},
-- Options specific to routing protocols (optional)
-- mesh = {
-- Options specific to the batman-adv routing protocol (optional)
-- batman_adv = {
-- Gateway selection class (optional)
-- The default class 20 is based on the link quality (TQ) only,
-- class 1 is calculated from both the TQ and the announced bandwidth
-- gw_sel_class = 1,
-- },
-- },
mesh = {
vxlan = true,
batman_adv = {
routing_algo = 'BATMAN_IV'
}
},
mesh_vpn = {
-- enabled = true,
mtu = 1312,
fastd = {
-- Refer to https://fastd.readthedocs.io/en/latest/ to better understand
@ -112,7 +99,6 @@
-- List of crypto-methods to use.
methods = {'salsa2012+umac'},
mtu = 1312,
-- configurable = true,
-- syslog_level = 'warn',
@ -125,18 +111,7 @@
peers = {
},
-- Optional: nested peer groups
-- groups = {
-- backbone_sub = {
-- ...
-- },
-- ...
-- },
},
-- Optional: additional peer groups, possibly with other limits
-- backbone2 = {
-- ...
-- },
},
},
@ -153,8 +128,7 @@
},
autoupdater = {
-- Default branch (optional), can be overridden by setting GLUON_AUTOUPDATER_BRANCH when building.
-- Set GLUON_AUTOUPDATER_ENABLED to enable the autoupdater by default for newly installed nodes.
-- Default branch. Don't forget to set GLUON_BRANCH when building!
branch = 'stable',
-- List of branches. You may define multiple branches.
@ -169,7 +143,7 @@
-- Have multiple maintainers sign your build and only
-- accept it when a sufficient number of them have
-- signed it.
good_signatures = 0,
good_signatures = 2,
-- List of public keys of maintainers.
pubkeys = {

View File

@ -1 +0,0 @@
../minimal-site/i18n

View File

@ -1 +0,0 @@
../minimal-site/modules

View File

@ -1,176 +0,0 @@
-- This is an example site configuration for Gluon v2022.1
--
-- Take a look at the documentation located at
-- https://gluon.readthedocs.io/ for details.
--
-- This configuration will not work as is. You're required to make
-- community specific changes to it!
{
-- Used for generated hostnames, e.g. freifunk-abcdef123456. (optional)
-- hostname_prefix = 'freifunk-',
-- Name of the community.
site_name = 'Continuous Integration',
-- Shorthand of the community.
site_code = 'ci',
-- 32 bytes of random data, encoded in hexadecimal
-- This data must be unique among all sites and domains!
-- Can be generated using: echo $(hexdump -v -n 32 -e '1/1 "%02x"' </dev/urandom)
domain_seed = 'e9608c4ff338b920992d629190e9ff11049de1dfc3f299eac07792dfbcda341c',
-- Prefixes used by clients within the mesh.
-- prefix6 is required, prefix4 can be omitted if next_node.ip4
-- is not set.
prefix6 = 'fdff:cafe:cafe:cafe::/64',
-- Prefixes used by nodes within the mesh
node_prefix6 = 'fdff:cafe:cafe:cafe::/64',
-- Timezone of your community.
-- See https://openwrt.org/docs/guide-user/base-system/system_configuration#time_zones
timezone = 'CET-1CEST,M3.5.0,M10.5.0/3',
-- List of NTP servers in your community.
-- Must be reachable using IPv6!
-- ntp_servers = {'1.ntp.services.ffxx'},
-- Wireless regulatory domain of your community.
regdom = 'DE',
-- Wireless configuration for 2.4 GHz interfaces.
wifi24 = {
-- Wireless channel.
channel = 1,
-- ESSIDs used for client network.
ap = {
ssid = 'gluon-ci-ssid',
-- disabled = true, -- (optional)
-- Configuration for a backward compatible OWE network below.
owe_ssid = 'owe.gluon-ci-ssid', -- (optional - SSID for OWE client network)
owe_transition_mode = true, -- (optional - enables transition-mode - requires ssid as well as owe_ssid)
},
mesh = {
-- Adjust these values!
id = 'ueH3uXjdp', -- usually you don't want users to connect to this mesh-SSID, so use a cryptic id that no one will accidentally mistake for the client WiFi
mcast_rate = 12000,
-- disabled = true, -- (optional)
},
},
-- Wireless configuration for 5 GHz interfaces.
-- This should be equal to the 2.4 GHz variant, except
-- for channel.
wifi5 = {
channel = 44,
outdoor_chanlist = '100-140',
ap = {
ssid = 'gluon-ci-ssid',
-- disabled = true, -- (optional)
-- Configuration for a backward compatible OWE network below.
owe_ssid = 'owe.gluon-ci-ssid', -- (optional - SSID for OWE client network)
owe_transition_mode = true, -- (optional - enables transition-mode - requires ssid as well as owe_ssid)
},
mesh = {
-- Adjust these values!
id = 'ueH3uXjdp',
mcast_rate = 12000,
},
},
-- The next node feature allows clients to always reach the node it is
-- connected to using a known IP address.
next_node = {
-- anycast IPs of all nodes
name = { 'nextnode.location.community.example.org', 'nextnode', 'nn' },
ip4 = '10.0.0.1',
ip6 = 'fd::1',
},
-- Options specific to routing protocols (optional)
mesh = {
vxlan = true,
olsrd = {},
},
mesh_vpn = {
-- enabled = true,
fastd = {
-- Refer to https://fastd.readthedocs.io/en/latest/ to better understand
-- what these options do.
-- List of crypto-methods to use.
methods = {'salsa2012+umac'},
mtu = 1312,
-- configurable = true,
-- syslog_level = 'warn',
groups = {
backbone = {
-- Limit number of connected peers to reduce bandwidth.
limit = 1,
-- List of peers.
peers = {
},
-- Optional: nested peer groups
-- groups = {
-- backbone_sub = {
-- ...
-- },
-- ...
-- },
},
-- Optional: additional peer groups, possibly with other limits
-- backbone2 = {
-- ...
-- },
},
},
bandwidth_limit = {
-- The bandwidth limit can be enabled by default here.
enabled = false,
-- Default upload limit (kbit/s).
egress = 200,
-- Default download limit (kbit/s).
ingress = 3000,
},
},
autoupdater = {
-- Default branch (optional), can be overridden by setting GLUON_AUTOUPDATER_BRANCH when building.
-- Set GLUON_AUTOUPDATER_ENABLED to enable the autoupdater by default for newly installed nodes.
branch = 'stable',
-- List of branches. You may define multiple branches.
branches = {
stable = {
name = 'stable',
-- List of mirrors to fetch images from. IPv6 required!
mirrors = {'http://1.updates.services.ffhl/stable/sysupgrade'},
-- Number of good signatures required.
-- Have multiple maintainers sign your build and only
-- accept it when a sufficient number of them have
-- signed it.
good_signatures = 0,
-- List of public keys of maintainers.
pubkeys = {
},
},
},
},
}

View File

@ -1,57 +0,0 @@
## 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-olsrd \
mesh-vpn-fastd \
respondd \
status-page \
web-advanced \
web-wizard
GLUON_FEATURES_standard := \
wireless-encryption-wpa3
## GLUON_SITE_PACKAGES
# Specify additional Gluon/OpenWrt 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 := iwinfo
## DEFAULT_GLUON_RELEASE
# version string to use for images
# gluon relies on
# opkg compare-versions "$1" '>>' "$2"
# to decide if a version is newer or not.
DEFAULT_GLUON_RELEASE := 0.6+exp$(shell date '+%Y%m%d')
# Variables set with ?= can be overwritten from the command line
## GLUON_RELEASE
# call make with custom GLUON_RELEASE flag, to use your own release version scheme.
# e.g.:
# $ make images GLUON_RELEASE=23.42+5
# would generate images named like this:
# gluon-ff%site_code%-23.42+5-%router_model%.bin
GLUON_RELEASE ?= $(DEFAULT_GLUON_RELEASE)
# Default priority for updates.
GLUON_PRIORITY ?= 0
# Region code required for some images; supported values: us eu
GLUON_REGION ?= eu
# Languages to include
GLUON_LANGS ?= en de

View File

@ -1,36 +0,0 @@
FROM debian:bullseye-slim
ARG DEBIAN_FRONTEND=noninteractive
RUN apt-get update && apt-get install -y --no-install-recommends \
ca-certificates \
file \
git \
python3 \
build-essential \
gawk \
unzip \
libncurses5-dev \
zlib1g-dev \
libssl-dev \
libelf-dev \
wget \
rsync \
time \
qemu-utils \
ecdsautils \
lua-check \
shellcheck \
&& apt-get clean \
&& rm -rf /var/lib/apt/lists/*
RUN mkdir /tmp/ec &&\
wget -O /tmp/ec/ec-linux-amd64.tar.gz https://github.com/editorconfig-checker/editorconfig-checker/releases/download/2.7.0/ec-linux-amd64.tar.gz &&\
tar -xvzf /tmp/ec/ec-linux-amd64.tar.gz &&\
mv bin/ec-linux-amd64 /usr/local/bin/editorconfig-checker &&\
rm -rf /tmp/ec
RUN useradd -d /gluon gluon
USER gluon
VOLUME /gluon
WORKDIR /gluon

View File

@ -4,7 +4,7 @@ use strict;
use warnings;
use Text::Balanced qw(extract_bracketed extract_delimited extract_tagged);
@ARGV >= 1 || die "Usage: $0 <source directory>\n";
@ARGV >= 1 || die "Usage: $0 <source direcory>\n";
my %stringtable;

View File

@ -28,7 +28,7 @@ fi
pushd "$(dirname "$0")/.." >/dev/null
find ./package packages -name Makefile | grep -v '^packages/packages/' | while read -r makefile; do
find ./package packages -name Makefile | while read -r makefile; do
dir="$(dirname "$makefile")"
pushd "$dir" >/dev/null
@ -37,12 +37,13 @@ find ./package packages -name Makefile | grep -v '^packages/packages/' | while r
dirname="$(dirname "$dir" | cut -d/ -f 3-)"
package="$(basename "$dir")"
for file in "${SUFFIX1}"/* "${SUFFIX2}"/*; do
basename="$(basename "${file}")"
suffix="$(dirname "${file}")"
printf "%s\t%s\n" "${basename}" "${BLUE}${repo}${RESET}/${dirname}${dirname:+/}${RED}${package}${RESET}/${suffix}/${GREEN}${basename}${RESET}"
for file in "${SUFFIX1}"/*; do
echo "${GREEN}$(basename "${file}")${RESET}" "(${BLUE}${repo}${RESET}/${dirname}${dirname:+/}${RED}${package}${RESET}/${SUFFIX1})"
done
for file in "${SUFFIX2}"/*; do
echo "${GREEN}$(basename "${file}")${RESET}" "(${BLUE}${repo}${RESET}/${dirname}${dirname:+/}${RED}${package}${RESET}/${SUFFIX2})"
done
popd >/dev/null
done | sort | cut -f2-
done | sort
popd >/dev/null

View File

@ -1,149 +0,0 @@
#!/bin/sh
set -e
topdir="$(realpath "$(dirname "${0}")/../openwrt")"
# defaults to qemu run script
ssh_host=localhost
build_only=0
preserve_config=1
print_help() {
echo "$0 [OPTIONS] PACAKGE_DIR [PACKAGE_DIR] ..."
echo ""
echo " -h print this help"
echo " -r HOST use a remote machine as target machine. By default if this"
echo " option is not given, push_pkg.sh will use a locally"
echo " running qemu instance started by run_qemu.sh."
echo " -p PORT use PORT as ssh port (default is 22)"
echo " -b build only, do not push"
echo " -P do not preserve /etc/config. By default, if a package"
echo " defines a config file in /etc/config, this config file"
echo " will be preserved. If you specify this flag, the package"
echo " default will be installed instead."
echo ""
echo ' To change gluon variables, run e.g. "make config GLUON_MINIFY=0"'
echo ' because then the gluon logic will be triggered, and openwrt/.config'
echo ' will be regenerated. The variables from openwrt/.config are already'
echo ' automatically used for this script.'
echo
}
while getopts "p:r:hbP" opt
do
case $opt in
P) preserve_config=0;;
p) ssh_port="${OPTARG}";;
r) ssh_host="${OPTARG}"; [ -z "$ssh_port" ] && ssh_port=22;;
b) build_only=1;;
h) print_help; exit 0;;
*) ;;
esac
done
shift $(( OPTIND - 1 ))
[ -z "$ssh_port" ] && ssh_port=2223
if [ "$build_only" -eq 0 ]; then
remote_info=$(ssh -p "${ssh_port}" "root@${ssh_host}" '
source /etc/os-release
printf "%s\\t%s\\n" "$OPENWRT_BOARD" "$OPENWRT_ARCH"
')
REMOTE_OPENWRT_BOARD="$(echo "$remote_info" | cut -f 1)"
REMOTE_OPENWRT_ARCH="$(echo "$remote_info" | cut -f 2)"
# check target
if ! grep -q "CONFIG_TARGET_ARCH_PACKAGES=\"${REMOTE_OPENWRT_ARCH}\"" "${topdir}/.config"; then
echo "Configured OpenWrt Target is not matching with the target machine!" 1>&2
echo
printf "%s" " Configured architecture: " 1>&2
grep "CONFIG_TARGET_ARCH_PACKAGES" "${topdir}/.config" 1>&2
echo "Target machine architecture: ${REMOTE_OPENWRT_ARCH}" 1>&2
echo 1>&2
echo "To switch the local with the run with the corresponding GLUON_TARGET:" 1>&2
echo " make GLUON_TARGET=... config" 1>&2
exit 1
fi
fi
if [ $# -lt 1 ]; then
echo ERROR: Please specify a PACKAGE_DIR. For example:
echo
echo " \$ $0 package/gluon-core"
exit 1
fi
while [ $# -gt 0 ]; do
pkgdir="$1"; shift
echo "Package: ${pkgdir}"
if ! [ -f "${pkgdir}/Makefile" ]; then
echo "ERROR: ${pkgdir} does not contain a Makefile"
exit 1
fi
if ! grep -q BuildPackage "${pkgdir}/Makefile"; then
echo "ERROR: ${pkgdir}/Makefile does not contain a BuildPackage command"
exit 1
fi
opkg_packages="$(make TOPDIR="${topdir}" -C "${pkgdir}" DUMP=1 | awk '/^Package: / { print $2 }')"
search_package() {
find "$2" -name "$1_*.ipk" -printf '%f\n'
}
make TOPDIR="${topdir}" -C "${pkgdir}" clean
make TOPDIR="${topdir}" -C "${pkgdir}" compile
if [ "$build_only" -eq 1 ]; then
continue
fi
# IPv6 addresses need brackets around the ${ssh_host} for scp!
if echo "${ssh_host}" | grep -q :; then
BL=[
BR=]
fi
for pkg in ${opkg_packages}; do
for feed in "${topdir}/bin/packages/${REMOTE_OPENWRT_ARCH}/"*/ "${topdir}/bin/targets/${REMOTE_OPENWRT_BOARD}/packages/"; do
printf "%s" "searching ${pkg} in ${feed}: "
filename=$(search_package "${pkg}" "${feed}")
if [ -n "${filename}" ]; then
echo found!
break
else
echo not found
fi
done
if [ "$preserve_config" -eq 0 ]; then
opkg_flags=" --force-maintainer"
fi
# shellcheck disable=SC2029
if [ -n "$filename" ]; then
scp -O -P "${ssh_port}" "$feed/$filename" "root@${BL}${ssh_host}${BR}:/tmp/${filename}"
ssh -p "${ssh_port}" "root@${ssh_host}" "
set -e
echo Running opkg:
opkg install --force-reinstall ${opkg_flags} '/tmp/${filename}'
rm '/tmp/${filename}'
gluon-reconfigure
"
else
# Some packages (e.g. procd-seccomp) seem to contain BuildPackage commands
# which do not generate *.ipk files. Till this point, I am not aware why
# this is happening. However, dropping a warning if the corresponding
# *.ipk is not found (maybe due to other reasons as well), seems to
# be more reasonable than aborting. Before this commit, the command
# has failed.
echo "Warning: ${pkg}*.ipk not found! Ignoring." 1>&2
fi
done
done

View File

@ -1,15 +0,0 @@
#!/bin/sh
# Note: You can exit the qemu instance by first pressing "CTRL + a" then "c".
# Then you enter the command mode of qemu and can exit by typing "quit".
qemu-system-x86_64 \
-d 'cpu_reset' \
-enable-kvm \
-gdb tcp::1234 \
-nographic \
-netdev user,id=wan,hostfwd=tcp::2223-10.0.2.15:22 \
-device virtio-net-pci,netdev=wan,addr=0x06,id=nic1 \
-netdev user,id=lan,hostfwd=tcp::6080-192.168.1.1:80,hostfwd=tcp::2222-192.168.1.1:22,net=192.168.1.100/24 \
-device virtio-net-pci,netdev=lan,addr=0x05,id=nic2 \
"$@"

View File

@ -29,22 +29,11 @@ lower="$(mktemp)"
trap 'rm -f "$upper" "$lower"' EXIT
awk 'BEGIN {
sep = 0
}
/^---$/ {
sep = 1;
next
}
{
if(sep == 0) {
print > "'"$upper"'"
} else {
print > "'"$lower"'"
}
}' "$manifest"
awk 'BEGIN { sep=0 }
/^---$/ { sep=1; next }
{ if(sep==0) print > "'"$upper"'";
else print > "'"$lower"'"}' \
"$manifest"
ecdsasign "$upper" < "$SECRET" >> "$lower"

View File

@ -21,22 +21,11 @@ upper="$(mktemp)"
lower="$(mktemp)"
ret=1
awk 'BEGIN {
sep = 0
}
/^---$/ {
sep = 1;
next
}
{
if(sep == 0) {
print > "'"$upper"'"
} else {
print > "'"$lower"'"
}
}' "$manifest"
awk "BEGIN { sep=0 }
/^---\$/ { sep=1; next }
{ if(sep==0) print > \"$upper\";
else print > \"$lower\"}" \
"$manifest"
while read -r line
do

View File

@ -8,3 +8,38 @@
.rst-content div[class^='highlight'] pre {
overflow: visible;
}
/*
This fixes the bottom margin of paragraphs inside lists, where margins inside
a single list item would incorrectly be displayed larger than margins between
the list items.
Upstream fix (not fixed on readthedocs.io yet):
https://github.com/readthedocs/sphinx_rtd_theme/commit/ac20ce75d426efeb40fe2af1f89ea9bad285a45b
*/
.rst-content .section ol li > p,
.rst-content .section ol li > p:last-child,
.rst-content .section ul li > p,
.rst-content .section ul li > p:last-child {
margin-bottom: 12px;
}
.rst-content .section ol li > p:only-child,
.rst-content .section ol li > p:only-child:last-child,
.rst-content .section ul li > p:only-child,
.rst-content .section ul li > p:only-child:last-child {
margin-bottom: 0rem;
}
/*
This fixes the bottom margin of nested lists
Based on upstream fix (not on readthedocs.io yet):
https://github.com/readthedocs/sphinx_rtd_theme/commit/6f0de13baff93f25204aa2cdf0308aae47d71312
*/
.rst-content .section ul li > ul,
.rst-content .section ul li > ol,
.rst-content .section ol li > ul,
.rst-content .section ol li > ol {
margin-bottom: 12px;
}

View File

@ -20,11 +20,11 @@
# -- Project information -----------------------------------------------------
project = 'Gluon'
copyright = 'Project Gluon'
copyright = '2015-2020, Project Gluon'
author = 'Project Gluon'
# The short X.Y version
version = '2022.1'
version = '2020.2+'
# The full version, including alpha/beta/rc tags
release = version
@ -58,7 +58,7 @@ master_doc = 'index'
#
# This is also used if you do content translation via gettext catalogs.
# Usually you set "language" from the command line for these cases.
language = 'en'
language = None
# List of patterns, relative to source directory, that match files and
# directories to ignore when looking for source files.
@ -71,13 +71,6 @@ pygments_style = None
# Don't highlight code blocks unless requested explicitly
highlight_language = 'none'
# Ignore links to the config mode, as well as anchors on on hackint, which are
# used to mark channel names and do not exist. Regular links are not effected.
linkcheck_ignore = [
'http://192.168.1.1',
'https://webirc.hackint.org/#'
]
# -- Options for HTML output -------------------------------------------------

View File

@ -23,7 +23,6 @@ webbrowser. You're welcome to join us!
.. _hackint: https://hackint.org/
.. _webchat: https://webirc.hackint.org/#irc://irc.hackint.org/#gluon
.. _working-with-repositories:
Working with repositories
-------------------------
@ -53,14 +52,6 @@ and you can try rebasing it onto the new `base` branch yourself and after that c
Always call `make update-patches` after making changes to a module repository as `make update` will overwrite your
commits, making `git reflog` the only way to recover them!
::
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 build system.
This command speeds up the maintenance of updating OpenWrt and feeds.
Development Guidelines
----------------------
Lua should be used instead of sh whenever sensible. The following criteria
@ -77,7 +68,7 @@ apply:
- use tabs instead of spaces
- trailing whitespaces must be eliminated
- files need to end with a final newline
- newlines need to have Unix line endings (lf)
- newlines need to have unix line endings (lf)
To that end we provide a ``.editorconfig`` configuration, which is supported by most
of the editors out there.

View File

@ -88,17 +88,3 @@ update.sh
source and installs it into *packages/* directory. It simply tries to set the *base*
branch of the cloned repo to the correct commit. If this fails it fetches the
upstream branch and tries again to set the local *base* branch.
getversion.sh
Used to determine the version numbers of the repositories of Gluon and the
site configuration, to be included in the built firmware images as
*/lib/gluon/gluon-version* and */lib/gluon/site-version*.
By default, this uses ``git describe`` to generate a version number based
on the last git tag. This can be overridden by putting a file called
*.scmversion* into the root of the respective repositories.
A command like ``rm -f .scmversion; echo "$(./scripts/getversion.sh .)" > .scmversion``
can be used before applying local patches to ensure that the reported
version numbers refer to an upstream commit ID rather than an arbitrary
local one after ``git am``.

View File

@ -1,5 +1,5 @@
Adding hardware support
=======================
Adding support for new hardware
===============================
This page will give a short overview on how to add support
for new hardware to Gluon.
@ -7,232 +7,158 @@ Hardware requirements
---------------------
Having an ath9k, ath10k or mt76 based WLAN adapter is highly recommended,
although other chipsets may also work. VAP (multiple SSID) support
with simultaneous AP + Mesh Point (802.11s) operation is required.
Device checklist
----------------
The description of pull requests adding device support must include the
`device integration checklist
<https://github.com/freifunk-gluon/gluon/wiki/Device-Integration-checklist>`_.
The checklist ensures that core functionality of Gluon is well supported on the
device.
is a requirement.
.. _device-class-definition:
Device checklist
----------------
Pull requests adding device support must have the device checklist
included in their description. The checklist assures core functionality
of Gluon is well supported on the device.
The checklist can be found in the `wiki <https://github.com/freifunk-gluon/gluon/wiki/Device-Integration-checklist>`_.
Device classes
--------------
All supported hardware is categorized into "device classes". This allows to
adjust the feature set of Gluon to the different hardware's capabilities via
``site.mk`` without having to list individual devices.
Gluon currently is aware of two device classes. Depending on the device class, different
features can be installed onto the device.
There are currently two devices classes defined: "standard" and "tiny". The
"tiny" class contains all devices that do not meet the following requirements:
The ``tiny`` device-class contains devices with the following limitations:
- At least 7 MiB of usable firmware space
- At least 64 MiB of RAM (128MiB for devices with ath10k radio)
* All devices with less than 64 MB of system memory
* All devices with less than 7 MB of usable firmware space
* Devices using a single ath10k radio and less than 128MB of system memory
Target configuration
--------------------
Gluon's hardware support is based on OpenWrt's. For each supported target,
a configuration file exists at ``targets/<target>-<subtarget>`` (or just
``target/<target>`` for targets without subtargets) that contains all
Gluon-specific settings for the target. The generic configuration
``targets/generic`` contains settings that affect all targets.
.. _hardware-adding-profiles:
All targets must be listed in ``target/targets.mk``.
Adding profiles
---------------
The vast majority of devices with ath9k WLAN is based on the ar71xx target of OpenWrt.
If the hardware you want to add support for is ar71xx, adding a new profile
is sufficient.
The target configuration language is based on Lua, so Lua's syntax for variables
and control structures can be used.
Profiles are defined in ``targets/*`` in a shell-based DSL (so common shell
command syntax like ``if`` can be used).
Device definitions
~~~~~~~~~~~~~~~~~~
To configure a device to be built for Gluon, the ``device`` function is used.
In the simplest case, only two arguments are passed, for example:
The ``device`` command is used to define an image build for a device. It takes
two or three parameters.
.. code-block:: lua
The first parameter defines the Gluon profile name, which is used to refer to the
device and is part of the generated image name. The profile name must be same as
the output of the following command (on the target device), so the autoupdater
can work::
device('tp-link-tl-wdr3600-v1', 'tplink_tl-wdr3600-v1')
lua -e 'print(require("platform_info").get_image_name())'
The first argument is the device name in Gluon, which is part of the output
image filename, and must correspond to the model string looked up by the
autoupdater. The second argument is the corresponding device profile name in
OpenWrt, as found in ``openwrt/target/linux/<target>/image/*``.
While porting Gluon to a new device, it might happen that the profile name is
unknown. Best practise is to generate an image first by using an arbitrary value
and then executing the lua command on the device and use its output from then on.
A table of additional settings can be passed as a third argument:
The second parameter defines the name of the image files generated by OpenWrt. Usually,
it is also the OpenWrt profile name; for devices that still use the old image build
code, a third parameter with the OpenWrt profile name can be passed. The profile names
can be found in the image Makefiles in ``openwrt/target/linux/<target>/image/Makefile``.
.. code-block:: lua
Examples::
device('ubiquiti-edgerouter-x', 'ubnt_edgerouter-x', {
factory = false,
packages = {'-hostapd-mini'},
manifest_aliases = {
'ubnt-erx',
},
})
The supported additional settings are described in the following sections.
device tp-link-tl-wr1043n-nd-v1 tl-wr1043nd-v1
device alfa-network-hornet-ub hornet-ub HORNETUB
Suffixes and extensions
~~~~~~~~~~~~~~~~~~~~~~~
For many targets, OpenWrt generates images with the suffixes
``-squashfs-factory.bin`` and ``-squashfs-sysupgrade.bin``. For devices with
different image names, is it possible to override the suffixes and extensions
using the settings ``factory``, ``factory_ext``, ``sysupgrade`` and
``sysupgrade_ext``, for example:
'''''''''''''''''''''''
.. code-block:: lua
By default, image files are expected to have the extension ``.bin``. In addition,
the images generated by OpenWrt have a suffix before the extension that defaults to
``-squashfs-factory`` and ``-squashfs-sysupgrade``.
{
factory = '-squashfs-combined',
factory_ext = '.img.gz',
sysupgrade = '-squashfs-combined',
sysupgrade_ext = '.img.gz',
}
This can be changed using the ``factory`` and ``sysupgrade`` commands, either at
the top of the file to set the defaults for all images, or for a single image. There
are three forms with 0 to 2 arguments (all work with ``sysupgrade`` as well)::
Only settings that differ from the defaults need to be passed. ``factory`` and
``sysupgrade`` can be set to ``false`` when no such images exist.
factory SUFFIX .EXT
factory .EXT
factory
For some device types, there are multiple factory images with different
extensions. ``factory_ext`` can be set to a table of strings to account for this
case:
When only an extension is given, the default suffix is retained. When no arguments
are given, this signals that no factory (or sysupgrade) image exists.
.. code-block:: lua
Aliases
'''''''
{
factory_ext = {'.img.gz', '.vmdk', '.vdi'},
}
Sometimes multiple models use the same OpenWrt images. In this case, the ``alias``
command can be used to create symlinks and additional entries in the autoupdater
manifest for the alternative models.
TODO: Extra images
Standalone images
'''''''''''''''''
Aliases and manifest aliases
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Sometimes multiple devices exist that use the same OpenWrt images. To make it
easier to find these images, the ``aliases`` setting can be used to define
additional device names. Gluon will create symlinks for these names in the
image output directory.
On targets without *per-device rootfs* support in OpenWrt, the commands described above
can't be used. Instead, ``factory_image`` and ``sysupgrade_image`` are used::
.. code-block:: lua
factory_image PROFILE IMAGE .EXT
sysupgrade_image PROFILE IMAGE .EXT
device('aruba-ap-303', 'aruba_ap-303', {
factory = false,
aliases = {'aruba-instant-on-ap11'},
})
Again, the profile name must match the value printed by the aforementioned Lua
command. The image name must match the part between the target name and the extension
as generated by OpenWrt and is to be omitted when no such part exists.
The aliased name will also be added to the autoupdate manifest, allowing upgrade
images to be found under the different name on targets that perform model name
detection at runtime.
Packages
''''''''
It is also possible to add alternative names to the autoupdater manifest without
creating a symlink by using ``manifest_aliases`` instead of ``aliases``, which
should be done when the alternative name does not refer to a separate device.
This is particularly useful to allow the autoupdater to work when the model name
changed between Gluon versions.
The ``packages`` command takes an arbitrary number of arguments. Each argument
defines an additional package to include in the images in addition to the default
package sets defined by OpenWrt. When a package name is prefixed by a minus sign, the
packages are excluded instead.
Package lists
~~~~~~~~~~~~~
Gluon generates lists of packages that are installed in all images based on a
default list and the features and packages specified in the site configuration.
The ``packages`` command may be used at the top of a target definition to modify
the default package list for all images, or just for a single device (when the
target supports *per-default rootfs*).
In addition, OpenWrt defines additional per-device package lists. These lists
may be modified in Gluon's device definitions, for example to include additional
drivers and firmware, or to remove unneeded software. Packages to remove are
prefixed with a ``-`` character.
For many ath10k-based devices, this is used to replace the "CT" variant of
ath10k with the mainline-based version:
Configuration
'''''''''''''
.. code-block:: lua
The ``config`` command allows to add arbitrary target-specific OpenWrt configuration
to be emitted to ``.config``.
local ATH10K_PACKAGES_QCA9880 = {
'kmod-ath10k',
'-kmod-ath10k-ct',
'-kmod-ath10k-ct-smallbuffers',
'ath10k-firmware-qca988x',
'-ath10k-firmware-qca988x-ct',
}
device('openmesh-a40', 'openmesh_a40', {
packages = ATH10K_PACKAGES_QCA9880,
factory = false,
})
Notes
'''''
This example also shows how to define a local variable, allowing the package
list to be reused for multiple devices.
On devices with multiple WLAN adapters, care must also be taken that the primary MAC address is
configured correctly. ``/lib/gluon/core/sysconfig/primary_mac`` should contain the MAC address which
can be found on a label on most hardware; if it does not, ``/lib/gluon/upgrade/010-primary-mac``
in ``gluon-core`` might need a fix. (There have also been cases in which the address was incorrect
even on devices with only one WLAN adapter, in these cases a OpenWrt bug was the cause).
Device flags
~~~~~~~~~~~~
The settings ``class``, ``deprecated`` or ``broken`` should be set according to
the device support status. The default values are as follows:
Adding support for new hardware targets
---------------------------------------
.. code-block:: lua
Adding a new target is much more complex than adding a new profile. There are two basic steps
required for adding a new target:
{
class = 'standard',
deprecated = false,
broken = false,
}
Package adjustments
'''''''''''''''''''
- Device classes are described in :ref:`device-class-definition`
- Broken devices are untested or do not meet our requirements as given by the
device checklist
- Deprecated devices are slated for removal in a future Gluon version due to
hardware constraints
One package that may need adjustments for new targets is ``libplatforminfo`` (to be found in
`packages/gluon/libs/libplatforminfo <https://github.com/freifunk-gluon/packages/tree/master/libs/libplatforminfo>`_).
If the new platform works fine with the definitions found in ``default.c``, nothing needs to be done. Otherwise,
create a definition for the added target or subtarget, either by symlinking one of the files in the ``templates``
directory, or adding a new source file.
Global settings
~~~~~~~~~~~~~~~
There is a number of directives that can be used outside of a ``device()``
definition:
On many targets, Gluon's network setup scripts (mainly in the package ``gluon-core``)
won't run correctly without some adjustments, so better double check that everything is fine there (and the files
``primary_mac``, ``lan_ifname`` and ``wan_ifname`` in ``/lib/gluon/core/sysconfig/`` contain sensible values).
- ``include('filename')``: Include another file with global settings
- ``config(key, value)``: Set a config symbol in OpenWrt's ``.config``. Value
may be a string, number, boolean, or nil. Booleans and nil are used for
tristate symbols, where nil sets the symbol to ``m``.
- ``try_config(key, value)``: Like ``config()``, but do not fail if setting
the symbol is not possible (usually because its dependencies are not met)
- ``packages { 'package1', '-package2', ... }``: Define a list of packages to
add or remove for all devices of a target. Package lists passed to multiple
calls of ``packages`` will be aggregated.
- ``defaults { key = value, ... }``: Set default values for any of the
additional settings that can be passed to ``device()``.
Build system support
''''''''''''''''''''
Helper functions
~~~~~~~~~~~~~~~~
The following helpers can be used in the target configuration:
A definition for the new target must be created under ``targets``, and it must be added
to ``targets/targets.mk``. The ``GluonTarget`` macro takes one to three arguments:
the target name, the Gluon subtarget name (if the target has subtargets), and the
OpenWrt subtarget name (if it differs from the Gluon subtarget). The third argument
can be used to define multiple Gluon targets with different configuration for the
same OpenWrt target, like it is done for the ``ar71xx-tiny`` target.
- ``env.KEY`` allows to access environment variables
- ``istrue(value)`` returns true if the passed string is a positive number
(often used with ``env``, for example ``if istrue(env.GLUON_DEBUG) then ...``)
Hardware support in packages
----------------------------
In addition to the target configuration files, some device-specific changes may
be required in packages.
gluon-core
~~~~~~~~~~
- ``/lib/gluon/upgrade/010-primary-mac``: Override primary MAC address selection
Usually, the primary (label) MAC address is defined in OpenWrt's Device Trees.
For devices or targets where this is not the case, it is possible to specify
what interface to take the primary MAC address from in ``010-primary-mac``.
- ``/lib/gluon/upgrade/020-interfaces``: Override LAN/WAN interface assignment
On PoE-powered devices, the PoE input port should be "WAN".
- ``/usr/lib/lua/gluon/platform.lua``: Contains a list of outdoor devices
gluon-setup-mode
~~~~~~~~~~~~~~~~
- ``/lib/gluon/upgrade/320-setup-ifname``: Contains a list of devices that use
the WAN port for the config mode
On PoE-powered devices, the PoE input port should be used for the config
mode. This is handled correctly by default for outdoor devices listed in
``platform.lua``.
libplatforminfo
~~~~~~~~~~~~~~~
When adding support for a new target to Gluon, it may be necessary to adjust
libplatforminfo to define how autoupdater image names are derived from the
model name.
After this, is should be sufficient to call ``make GLUON_TARGET=<target>`` to build the images for the new target.

View File

@ -3,88 +3,6 @@ Package development
Gluon packages are OpenWrt packages and follow the same rules described at https://openwrt.org/docs/guide-developer/packages.
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.
Gluon provides scripts to enhance workflow 2). Here is an example illustrating
the workflow using these scripts:
.. code-block:: shell
# start a local qemu instance
contrib/run_qemu.sh output/images/factory/[...]-x86-64.img
# apply changes to the desired package
vi package/gluon-ebtables/files/etc/init.d/gluon-ebtables
# rebuild and push the package to the qemu instance
contrib/push_pkg.sh package/gluon-ebtables/
# test your changes
...
# do more changes
...
# rebuild and push the package to the qemu instance
contrib/push_pkg.sh package/gluon-ebtables/
# test your changes
...
(and so on...)
# see help of the script for more information
contrib/push_pkg.sh -h
...
Features of ``push_pkg.sh``:
* Works with compiled and non-compiled packages.
* This means it can be used in the development of C-code, Lua-Code and mostly any other code.
* Works with native OpenWrt and Gluon packages.
* Pushes to remote machines or local qemu instances.
* Pushes multiple packages in in one call if desired.
* Performs site.conf checks.
Implementation details of ``push_pkg.sh``:
* First, the script builds an opkg package using the OpenWrt build system.
* This package is pushed to a *target machine* using scp:
* By default the *target machine* is a locally running x86 qemu started using ``run_qemu.sh``.
* The *target machine* can also be remote machine. (See the cli switch ``-r``)
* Remote machines are not limited to a specific architecture. All architectures supported by gluon can be used as remote machines.
* Finally opkg is used to install/update the packages in the target machine.
* While doing this, it will not override ``/etc/config`` with package defaults by default. (See the cli switch ``-P``).
* While doing this, opkg calls the ``check_site.lua`` from the package as post_install script to validate the ``site.conf``. This means that the ``site.conf`` of the target machine is used for this validation.
Note that:
* ``push_pkg.sh`` does neither build nor push dependencies of the packages automatically. If you want to update dependencies, you must explicitly specify them to be pushed.
* If you add new packages, you must run ``make update config GLUON_TARGET=...``.
* You can change the gluon target of the target machine via ``make config GLUON_TARGET=...``.
* If you want to update the ``site.conf`` of the target machine, use ``push_pkg.sh package/gluon-site/``.
* Sometimes when things break, you can heal them by compiling a package with its dependencies: ``cd openwrt; make package/gluon-ebtables/clean; make package/gluon-ebtables/compile; cd ..``.
* You can exit qemu by pressing ``CTRL + a`` and ``c`` afterwards.
Gluon package makefiles
=======================

View File

@ -1,5 +1,5 @@
Uplink support
==============
WAN support
===========
As the WAN port of a node will be connected to a user's private network, it
is essential that the node only uses the WAN when it is absolutely necessary.
@ -11,12 +11,11 @@ There are two cases in which the WAN port is used:
After the VPN connection has been established, the node should be able to reach
the mesh's DNS servers and use these for all other name resolution.
If a device has only a single Ethernet port (or group of ports), it will be
used as an uplink port even when it is not labelled as "WAN" by default. This
behavior can be controlled using the ``interfaces.single.default_roles``
site.conf option. It is also possible to alter the interface assignment after
installation by modifying ``/etc/config/gluon`` and running
``gluon-reconfigure``.
If the device does not feature a WAN port, the LAN port is configured as WAN port.
In case such a device has multiple LAN ports, all these can be used as WAN.
Devices, which feature a "hybrid" port (labelled as WAN/LAN), this port is used as WAN.
This behavior can be reversed using the ``single_as_lan`` site.conf option.
Routing tables
~~~~~~~~~~~~~~

View File

@ -74,7 +74,8 @@ Useful functions:
- *header* (*key*, *value*): Adds an HTTP header to the reply to be sent to
the client. Has no effect when non-header data has already been written.
- *prepare_content* (*mime*): Sets the *Content-Type* header to the given MIME
type
type, potentially setting additional headers or modifying the MIME type to
accommodate browser quirks
- *write* (*data*, ...): Sends the given data to the client. If headers have not
been sent, it will be done before the data is written.

View File

@ -30,27 +30,6 @@ in ``site.mk``, care must be taken to pass the same ``GLUON_RELEASE`` to ``make
as otherwise the generated manifest will be incomplete.
Manifest format
------------------------
The manifest starts with a short header, followed by the list of firmwares and signatures.
The header contains the following information:
.. code-block:: sh
BRANCH=stable
DATE=2020-10-07 00:00:00+02:00
PRIORITY=7
- ``BRANCH`` is the autoupdater branch name that needs to match the nodes configuration.
- ``DATE`` specifies when the time period for the update begins. Nodes will do their regular update during a random minute
between 4:00 and 4:59 am. Nodes might not always have a reliable NTP synchronization, which is why a fallback mechanism
exists, that checks for an update, and will execute if ``DATE`` is at least 24h in the past.
- ``PRIORITY`` can be configured as ``GLUON_PRIORITY`` when generating the manifest or in ``site.mk``, and defines
the number of days over which the update should be stretched out after ``DATE``. Nodes will calculate a probability
based on the time left to determine when to update.
Automated nightly builds
------------------------
@ -61,9 +40,9 @@ A fully automated nightly build could use the following commands:
git pull
# git -C site pull
make update
make clean GLUON_TARGET=ath79-generic
make clean GLUON_TARGET=ar71xx-generic
NUM_CORES_PLUS_ONE=$(expr $(nproc) + 1)
make -j$NUM_CORES_PLUS_ONE GLUON_TARGET=ath79-generic GLUON_RELEASE=$GLUON_RELEASE \
make -j$NUM_CORES_PLUS_ONE GLUON_TARGET=ar71xx-generic GLUON_RELEASE=$GLUON_RELEASE \
GLUON_AUTOUPDATER_BRANCH=experimental GLUON_AUTOUPDATER_ENABLED=1
make manifest GLUON_RELEASE=$GLUON_RELEASE GLUON_AUTOUPDATER_BRANCH=experimental
contrib/sign.sh $SECRETKEY output/images/sysupgrade/experimental.manifest

View File

@ -18,9 +18,6 @@ Config Mode by pressing and holding the RESET/WPS/DECT button for about three
seconds. The device should reboot (all LEDs will turn off briefly) and
Config Mode will be available.
If you have access to the console of the node, there is the
``gluon-enter-setup-mode`` command, which reboots a node into Config Mode.
Port Configuration
------------------

View File

@ -1,51 +0,0 @@
DNS caching
===========
User experience may be greatly improved when dns is accelerated. Also, it
seems like a good idea to keep the number of packages being exchanged
between node and gateway as small as possible. In order to do this, a
DNS cache may be used on a node. The dnsmasq instance listening on port
53 on the node will be reconfigured to answer requests, use a list of
upstream servers and a specific cache size if the options listed below are
added to site.conf. Upstream servers are the DNS servers which are normally
used by the nodes to resolve hostnames (e.g. gateways/supernodes).
There are the following settings:
servers
cacheentries
To use the node's DNS server, both options should be set. The node will cache at
most 'cacheentries' many DNS records in RAM. The 'servers' list will be used to
resolve the received DNS queries if the request cannot be answered from
cache. Gateways should announce the "next node" address via DHCP and RDNSS (if
any). Note that not setting 'servers' here will lead to DNS not working: Once
the gateways all announce the "next node" address for DNS, there is no way for
nodes to automatically determine DNS servers. They have to be baked into the
firmware.
If these settings do not exist, the cache is not initialized and RAM usage will
not increase.
When next_node.name is set, an A record and an AAAA record for the
next-node IP address are placed in the dnsmasq configuration. This means that
the content of next_node.name may be resolved even without upstream connectivity.
It is suggested to use the same name as the DNS server provides:
e.g. nextnode.location.community.example.org (This way the name also works if a
client uses static DNS Servers). Hint: If next_node.name does not contain a dot
some browsers would open the searchpage instead.
::
dns = {
cacheentries = 5000,
servers = { '2001:db8::1', },
},
next_node = {
name = { 'nextnode.location.community.example.org', 'nextnode', 'nn' },
ip6 = '2001:db8:8::1',
ip4 = '198.51.100.1',
}
Each cache entry will occupy about 90 bytes of RAM.

View File

@ -0,0 +1,26 @@
DNS forwarder
=============
A Gluon node can be configured to act as a DNS forwarder. Requests for the
next-node hostname(s) can be answered locally, without querying the upstream
resolver.
**Note:** While this reduces answer time and allows to use the next-node
hostname without upstream connectivity, this feature should not be used for
next-node hostnames that are FQDN when the zone uses DNSSEC.
One or more upstream resolvers can be configured in the *dns.servers* setting.
When *next_node.name* is set, A and/or AAAA records for the next-node IP
addresses are placed in the dnsmasq configuration.
::
dns = {
servers = { '2001:db8::1', },
},
next_node = {
name = { 'nextnode.location.community.example.org', 'nextnode', 'nn' },
ip6 = '2001:db8:8::1',
ip4 = '198.51.100.1',
}

View File

@ -130,7 +130,9 @@ site.conf only variables
- authorized_keys
- default_domain
- poe_passthrough
- interfaces.*.default_roles
- mesh_on_wan
- mesh_on_lan
- single_as_lan
- setup_mode.skip
- autoupdater.branch
- mesh_vpn.enabled
@ -186,7 +188,7 @@ domain.conf only variables
- ``true``, ``false``
- ``{ 'foo', 'bar' }``
- Because each domain is considered a separate layer 2 network, these
- Because each domain is considered as an own layer 2 network, these
values should be different in each domain:
- next_node.ip4

View File

@ -1,8 +1,8 @@
Private WLAN
============
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.
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.
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``

View File

@ -1,212 +1,57 @@
Mesh VPN
Mesh-VPN
========
Gluon integrates several layer 2 tunneling protocols to
allow connections between local meshes through the internet.
Gluon integrates several OSI-Layer 2 tunneling protocols to
enable interconnects between local meshes and provide
internetwork access. Available protocols currently are:
Protocol handlers
^^^^^^^^^^^^^^^^^
- fastd
- L2TPv3 (via tunneldigger)
There are currently three protocol handlers which can be selected
via ``GLUON_FEATURES`` in ``site.mk``:
mesh-vpn-fastd
""""""""""""""
fastd is a lightweight userspace tunneling daemon that
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.
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.
and authentication. Its primary drawback are the necessary
context-switches when forwarding packets.
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.
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.
fastd
^^^^^
-----
.. _VPN fastd methods:
Methods
"""""""
fastd offers various different connection "methods" with different
security properties that can be configured in the site configuration.
The following methods are currently recommended:
- ``salsa2012+umac``: Encrypted + authenticated
- ``null+salsa2012+umac``: Unencrypted, authenticated
- ``null@l2tp``: Unencrypted, unauthenticated
Multiple methods can be listed in ``site.conf``. The first listed method
supported by both the node and its peer will be used.
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``.
Configurable Cipher
^^^^^^^^^^^^^^^^^^^
.. _vpn-gateway-configuration:
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 supornodes, 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.
- | 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
From the site configuration fastd can be allowed to offer
toggleable encryption in the config mode with the intent to
increase throughput.
increase throughput, although in practice the gain is minimal.
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:**
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`` to the ``mesh_vpn.fastd.methods`` table if you want "Performance mode" as default (not 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@l2tp`` to the ``mesh_vpn.fastd.methods`` table if you want
"Performance mode" as default (not recommended)
**Gateway configuration:**
Config Mode
~~~~~~~~~~~
1) Prepend the ``null`` cipher in fastd's method list
**Config Mode:**
The resulting firmware will allow users to choose between secure (encrypted) and fast (unencrypted) transport.
.. image:: fastd_mode.gif
To confirm whether the correct cipher is being used, the log output
of fastd can be checked using ``logread``.
**Unix socket:**
To confirm whether the correct cipher is being used, fastd's unix
socket can be interrogated, after installing for example `socat`.
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
""""""""""""""""""""""""""""
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/>`__.
opkg update
opkg install socat
socat - UNIX-CONNECT:/var/run/fastd.mesh_vpn.socket

View File

@ -50,84 +50,38 @@ 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
the ``mesh`` role to the ``interfaces.*.default_roles`` options in your
:ref:`site.conf<user-site-interfaces>`.
.. _wired-mesh-commandline:
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``.
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 add_list gluon.iface_wan.role='mesh'
uci commit gluon
uci set network.mesh_wan.disabled=0
uci commit network
Disable Mesh-on-WAN::
uci del_list gluon.iface_wan.role='mesh'
uci commit gluon
uci set network.mesh_wan.disabled=1
uci commit network
Enable Mesh-on-LAN::
uci add_list gluon.iface_lan.role='mesh'
uci commit gluon
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
Disable Mesh-on-LAN::
uci del_list gluon.iface_lan.role='mesh'
uci commit gluon
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
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 2022.1. Using
the old commands on 2022.1 and later will break the corresponding options
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
in the *Advanced settings*.

View File

@ -16,10 +16,10 @@ 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. 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``::
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``::
uci set gluon.wireless.preserve_channels='1'
uci set gluon-core.@wireless[0].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.

View File

@ -14,7 +14,6 @@ Several Freifunk communities in Germany use Gluon as the foundation of their Fre
user/supported_devices
user/x86
user/faq
user/mtu
.. toctree::
:caption: Features
@ -25,7 +24,7 @@ Several Freifunk communities in Germany use Gluon as the foundation of their Fre
features/wlan-configuration
features/private-wlan
features/wired-mesh
features/dns-cache
features/dns-forwarder
features/monitoring
features/multidomain
features/authorized-keys
@ -40,7 +39,7 @@ Several Freifunk communities in Germany use Gluon as the foundation of their Fre
dev/hardware
dev/packages
dev/upgrade
dev/uplink
dev/wan
dev/mac_addresses
dev/site_library
dev/build
@ -79,7 +78,57 @@ Several Freifunk communities in Germany use Gluon as the foundation of their Fre
:caption: Releases
:maxdepth: 1
releases/index
releases/v2020.2.1
releases/v2020.2
releases/v2020.1.4
releases/v2020.1.3
releases/v2020.1.2
releases/v2020.1.1
releases/v2020.1
releases/v2019.1.3
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
License
-------

View File

@ -20,10 +20,10 @@
},
mesh_vpn = {
mtu = 1312,
fastd = {
methods = {'salsa2012+umac'},
mtu = 1312,
},
bandwidth_limit = {

View File

@ -58,3 +58,6 @@ GLUON_REGION ?= eu
# Languages to include
GLUON_LANGS ?= en de
# Do not build images for deprecated devices
GLUON_DEPRECATED ?= 0

View File

@ -1,129 +0,0 @@
Release Notes
=============
.. 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

View File

@ -88,8 +88,6 @@ New features
* Add support for making nodes a DNS cache for clients
(`#1000 <https://github.com/freifunk-gluon/gluon/pull/1000>`_)
See also: :doc:`../features/dns-cache`
* Add L2TP via tunneldigger as an alternative VPN system
(`#978 <https://github.com/freifunk-gluon/gluon/pull/978>`_)

View File

@ -28,7 +28,7 @@ Bugfixes
As the path to both config mode and status page were changed between versions
users could be affected by a redirect to a no more valid URL.
* batman-adv has received two bugfixes, which were `backported <https://github.com/openwrt/routing/commit/7bf62cc8b556b5046f9bbd37687376fe9ea175bb>`_ from v2018.4
* batman-adv has received two bugfixes, which were `backported <https://github.com/openwrt-routing/packages/commit/7bf62cc8b556b5046f9bbd37687376fe9ea175bb>`_ from v2018.4
Other changes
~~~~~~~~~~~~~

View File

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

@ -253,15 +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>`_)
- | 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.
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,15 +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>`_)
- | 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.
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,15 +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>`_)
- | 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.
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,15 +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>`_)
- | 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.
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

@ -206,15 +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>`_)
- | 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.
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

@ -1,42 +0,0 @@
Gluon 2020.2.2
==============
Bugfixes
--------
- Fixed unstable WiFi on some units of the TP-Link Archer C50 v4 (`#2133 <https://github.com/freifunk-gluon/gluon/pull/2133>`_)
- Fixed CVE-2020-27638 in fastd
Other changes
-------------
- Linux kernel has been updated to 4.14.206
- Backports of batman-adv bugfixes
Known issues
------------
* Upgrading EdgeRouter-X from versions before v2020.1.x may lead to a soft-bricked state due to bad blocks on the
NAND flash which the NAND driver before this release does not handle well.
(`#1937 <https://github.com/freifunk-gluon/gluon/issues/1937>`_)
* The integration of the BATMAN_V routing algorithm is incomplete.
- Mesh neighbors don't appear on the status page. (`#1726 <https://github.com/freifunk-gluon/gluon/issues/1726>`_)
Many tools have the BATMAN_IV metric hardcoded, these need to be updated to account for the new throughput
metric.
- Throughput values are not correctly acquired for different interface types.
(`#1728 <https://github.com/freifunk-gluon/gluon/issues/1728>`_)
This affects virtual interface types like bridges and VXLAN.
* Default TX power on many Ubiquiti devices is too high, correct offsets are unknown
(`#94 <https://github.com/freifunk-gluon/gluon/issues/94>`_)
Reducing the TX power in the Advanced Settings is recommended.
* In configurations not using VXLAN, the MAC address of the WAN interface is modified even when Mesh-on-WAN is disabled
(`#496 <https://github.com/freifunk-gluon/gluon/issues/496>`_)
This may lead to issues in environments where a fixed MAC address is expected (like VMware when promiscuous mode is
disallowed).

View File

@ -1,49 +0,0 @@
Gluon 2020.2.3
==============
Bugfixes
--------
- LEDs on the ASUS RT-AC51 are now fully functional.
- Netgear EX6150v1 randomly booting into failsafe mode has been fixed.
This happened dependent on the state of the mode setting switch.
- Dnsmasq has been patched against multiple security issues in its DNS response validation.
See the OpenWrt advisory at https://openwrt.org/advisory/2021-01-19-1
Other changes
-------------
- Linux kernel has been updated to 4.14.224
- batman-adv fixes were backported from its 2021.0 release
- OpenSSL has been updated to 1.1.1k
Known issues
------------
* Upgrading EdgeRouter-X from versions before v2020.1.x may lead to a soft-bricked state due to bad blocks on the
NAND flash which the NAND driver before this release does not handle well.
(`#1937 <https://github.com/freifunk-gluon/gluon/issues/1937>`_)
* The integration of the BATMAN_V routing algorithm is incomplete.
- Mesh neighbors don't appear on the status page. (`#1726 <https://github.com/freifunk-gluon/gluon/issues/1726>`_)
Many tools have the BATMAN_IV metric hardcoded, these need to be updated to account for the new throughput
metric.
- Throughput values are not correctly acquired for different interface types.
(`#1728 <https://github.com/freifunk-gluon/gluon/issues/1728>`_)
This affects virtual interface types like bridges and VXLAN.
* Default TX power on many Ubiquiti devices is too high, correct offsets are unknown
(`#94 <https://github.com/freifunk-gluon/gluon/issues/94>`_)
Reducing the TX power in the Advanced Settings is recommended.
* In configurations not using VXLAN, the MAC address of the WAN interface is modified even when Mesh-on-WAN is disabled
(`#496 <https://github.com/freifunk-gluon/gluon/issues/496>`_)
This may lead to issues in environments where a fixed MAC address is expected (like VMware when promiscuous mode is
disallowed).

View File

@ -1,63 +0,0 @@
Gluon 2021.1.1
==============
Important notes
---------------
Upgrades to v2021.1 and later releases are only supported from releases v2018.2 and later. This is due to migrations that have been removed to simplify maintenance.
Added hardware support
----------------------
ath79-generic
~~~~~~~~~~~~~
* Joy-IT
- JT-OR750i
ramips-mt76x8
~~~~~~~~~~~~~
* Xiaomi
- Mi Router 4A (100M Edition)
Bugfixes
--------
- Missing bandwidth limit settings resulted in a respondd crash for v2021.1.
- The Tunneldigger VPN provider was not registered with the Gluon VPN backend, resulting in broken Tunneldigger configurations.
- Disabling Radio interfaces in v2021.1 could lead to null pointer dereferences in the respondd airtime module, as the survey returns no data in this case.
Known issues
------------
* Upgrading EdgeRouter-X from versions before v2020.1.x may lead to a soft-bricked state due to bad blocks on the NAND flash which the NAND driver before this release does not handle well.
(`#1937 <https://github.com/freifunk-gluon/gluon/issues/1937>`_)
* The integration of the BATMAN_V routing algorithm is incomplete.
- Mesh neighbors don't appear on the status page. (`#1726 <https://github.com/freifunk-gluon/gluon/issues/1726>`_)
Many tools have the BATMAN_IV metric hardcoded, these need to be updated to account for the new throughput
metric.
- Throughput values are not correctly acquired for different interface types.
(`#1728 <https://github.com/freifunk-gluon/gluon/issues/1728>`_)
This affects virtual interface types like bridges and VXLAN.
* Default TX power on many Ubiquiti devices is too high, correct offsets are unknown
(`#94 <https://github.com/freifunk-gluon/gluon/issues/94>`_)
Reducing the TX power in the Advanced Settings is recommended.
* In configurations without VXLAN, the MAC address of the WAN interface is modified even when Mesh-on-WAN is disabled
(`#496 <https://github.com/freifunk-gluon/gluon/issues/496>`_)
This may lead to issues in environments where a fixed MAC address is expected (like VMware when promiscuous mode is disallowed).

View File

@ -1,131 +0,0 @@
Gluon 2021.1.2
==============
Important notes
---------------
This release fixes a **critical security vulnerability** in Gluon's
autoupdater.
Upgrades to v2021.1 and later releases are only supported from releases v2018.2
and later. Migration code for upgrades from older versions has been removed to
simplify maintenance.
Updates
-------
- The Linux kernel was updated to version 4.14.275
- The mac80211 wireless driver stack was updated to a version based on kernel
4.19.237
Various minor package updates are not listed here and can be found in the commit
log.
Bugfixes
--------
* **[SECURITY]** Autoupdater: Fix signature verification
A recently discovered issue (CVE-2022-24884) in the *ecdsautils* package
allows forgery of cryptographic signatures. This vulnerability can be
exploited to create a manifest accepted by the autoupdater without knowledge
of the signers' private keys. By intercepting nodes' connections to the update
server, such a manifest allows to distribute malicious firmware updates.
This is a **critical** vulnerability. All nodes with autoupdater must be
updated. Requiring multiple signatures for an update does *not* mitigate the
issue.
As a temporary workaround, the issue can be mitigated on individual nodes by
disabling the autoupdater via config mode or using the following commands::
uci set autoupdater.settings.enabled=0
uci commit autoupdater
A fixed firmware should be installed manually before enabling the autoupdater
again.
See security advisory `GHSA-qhcg-9ffp-78pw
<https://github.com/freifunk-gluon/ecdsautils/security/advisories/GHSA-qhcg-9ffp-78pw>`_
for further information on this vulnerability.
* **[SECURITY]** Config Mode: Prevent Cross-Site Request Forgery (CSRF)
The Config Mode was not validating the *Origin* header of POST requests.
This allowed arbitrary websites to modify configuration (including SSH keys)
on a Gluon node in Config Mode reachable from a user's browser by sending POST
requests with form data to 192.168.1.1.
The impact of this issue is considered low, as nodes are only vulnerable while
in Config Mode.
* Config Mode: Fix occasionally hanging page load after submitting the
configuration wizard causing the reboot message and VPN key not to be
displayed
* Config Mode (OSM): Update default OpenLayers source URL
The OSM feature of the Config Mode was broken when the default source URL was
used for OpenLayers, as the old URL has become unavailable. The default was
updated to a URL that should not become unavailable again.
* Config Mode (OSM): Fix error when using ``"`` character in attribution text
* respondd-module-airtime: Fix respondd crash on devices with disabled WLAN
interfaces
Several improvements were made to the error handling of the
*respondd-module-airtime* package. The "PHY ID" field (introduced in Gluon
2021.1) was removed again.
* ipq40xx: Fix bad WLAN performance on Plasma Cloud PA1200 and PA2200 devices
* Fix occasional build failure in "perl" package with high number of threads
(``-j32`` or higher)
Other improvements
------------------
* Several improvements were made to the status page:
- WLAN channel display does not require the *respondd-module-airtime* package
anymore
- The "gateway nexthop" label now links to the status page of the nexthop node
- The timeout to retrieve information from neighbour nodes was increased,
making the display of the name
of overloaded, slow or otherwise badly reachable nodes more likely to
succeed
Known issues
------------
* Upgrading EdgeRouter-X from versions before v2020.1.x may lead to a
soft-bricked state due to bad blocks on the NAND flash which the NAND driver
before this release does not handle well.
(`#1937 <https://github.com/freifunk-gluon/gluon/issues/1937>`_)
* The integration of the BATMAN_V routing algorithm is incomplete.
- Mesh neighbors don't appear on the status page.
(`#1726 <https://github.com/freifunk-gluon/gluon/issues/1726>`_)
Many tools have the BATMAN_IV metric hardcoded, these need to be updated to
account for the new throughput metric.
- Throughput values are not correctly acquired for different interface types.
(`#1728 <https://github.com/freifunk-gluon/gluon/issues/1728>`_)
This affects virtual interface types like bridges and VXLAN.
* Default TX power on many Ubiquiti devices is too high, correct offsets are
unknown (`#94 <https://github.com/freifunk-gluon/gluon/issues/94>`_)
Reducing the TX power in the Advanced Settings is recommended.
* In configurations without VXLAN, the MAC address of the WAN interface is
modified even when Mesh-on-WAN is disabled
(`#496 <https://github.com/freifunk-gluon/gluon/issues/496>`_)
This may lead to issues in environments where a fixed MAC address is expected
(like VMware when promiscuous mode is disallowed).

View File

@ -1,141 +0,0 @@
Gluon 2021.1
============
Important notes
---------------
Upgrades to v2021.1 and later releases are only supported from releases v2018.2 and later. This is due to migrations that have been removed to simplify maintenance.
Added hardware support
----------------------
ath79-generic
~~~~~~~~~~~~~
* Plasma Cloud
- PA300 [#outdoor]_
- PA300E [#outdoor]_
* TP-Link
- Archer C2 v3
- Archer D50 v1
ipq40xx-generic
~~~~~~~~~~~~~~~
* AVM
- FRITZ!Box 7530
* Plasma Cloud
- PA1200 [#outdoor]_
- PA2200
ramips-mt7620
~~~~~~~~~~~~~
* Netgear
- EX3700
- EX3800
.. [#outdoor]
This device is supposed to be set up outdoors and will therefore have its outdoor mode flag automatically enabled.
Major changes
-------------
Multicast optimizations (batman-adv)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In this release, we reenable the multicast optimizations, that have gone through another round of bug squashing upstream. With this feature batman-adv will distribute IPv6 link-local multicast packets via individual unicast packets instead of flooding them through the whole mesh as long as the number of subscribed nodes does not exceed 16. This reduces layer 2 overhead, especially for IPv6 Neighbor Discovery.
We also relaxed the firewall for IPv6 multicast packets: Instead of always dropping non-essential multicast packets we now allow all IPv6 link-local multicast packets to pass when the destination group has up to 16 subscribers
Status page
~~~~~~~~~~~
The status page has received much attention in this release and now exposes many more details that help to understand a node's setup remotely.
Among other things, we now expose wireless client count per radio, the mac80211 identifiers, the frequencies radios are tuned to, as well as information about the VPN provider and details on the mesh protocol stack.
gluon-switch-domain utility
~~~~~~~~~~~~~~~~~~~~~~~~~~~
The ``gluon-switch-domain`` utility has been introduced to allow for a standard way to encapsulate the steps required for safely switching between domains. Existing packages like the hoodselector and the scheduled-domain-switch have been tied in with gluon-switch-domain.
It has an experimental ``--no-reboot`` flag that requires further testing, to ensure it doesn't accidentally bridge separate domains.
Other changes
-------------
- The private WLAN interface is now assigned the interface name `wan_radioX` where X is the phy index.
- Linux kernel has been updated to 4.14.235
- The kernel's mac80211 stack has been updated to 4.19.193-test1 to mitigate the `FragAttacks <https://www.fragattacks.com/>`_ vulnerabilities
- OpenSSL has been updated to 1.1.1k, fixing CVE-2021-3449 and CVE-2021-3450
- Dropbear has been patched against mishandling of special filenames in its scp component (CVE-2020-36524)
Bugfixes
--------
- The firmware partition lookup in gluon-web-admin's firmware update page was using an old partition label and therefore failed to look up the available flash size. This resulted in misleading error messages in case the uploaded firmware file exceeds the flash size.
- Android 9 and higher do not properly wake up to renew their MLD subscriptions, therefore dropping out of the Neighbor Discovery MLD group, which leads to broken IPv6 connectivity after the device has slept for a while. A workaround has been deployed to wake these devices up in regular intervals to prevent this regression.
Internal
--------
Mesh-VPN Abstraction Layer
~~~~~~~~~~~~~~~~~~~~~~~~~~
In preparation for the introduction of new tunneling protocols, the gluon-mesh-vpn framework has been modularized. This allows for providers to use a standard interface and keep their implementation details in a dedicated package.
Continuous Integration
~~~~~~~~~~~~~~~~~~~~~~
* GitHub Actions
- GitHub actions is now enabled for the Gluon project, build-testing all available targets.
- CI jobs are now run based on which paths have been modified.
- Linters for lua and shell scripts have been integrated.
Known issues
------------
* Upgrading EdgeRouter-X from versions before v2020.1.x may lead to a soft-bricked state due to bad blocks on the NAND flash which the NAND driver before this release does not handle well.
(`#1937 <https://github.com/freifunk-gluon/gluon/issues/1937>`_)
* The integration of the BATMAN_V routing algorithm is incomplete.
- Mesh neighbors don't appear on the status page. (`#1726 <https://github.com/freifunk-gluon/gluon/issues/1726>`_)
Many tools have the BATMAN_IV metric hardcoded, these need to be updated to account for the new throughput
metric.
- Throughput values are not correctly acquired for different interface types.
(`#1728 <https://github.com/freifunk-gluon/gluon/issues/1728>`_)
This affects virtual interface types like bridges and VXLAN.
* Default TX power on many Ubiquiti devices is too high, correct offsets are unknown
(`#94 <https://github.com/freifunk-gluon/gluon/issues/94>`_)
Reducing the TX power in the Advanced Settings is recommended.
* In configurations without VXLAN, the MAC address of the WAN interface is modified even when Mesh-on-WAN is disabled
(`#496 <https://github.com/freifunk-gluon/gluon/issues/496>`_)
This may lead to issues in environments where a fixed MAC address is expected (like VMware when promiscuous mode is disallowed).

View File

@ -1,85 +0,0 @@
Gluon 2022.1.1
==============
Important notes
---------------
This release mitigates multiple flaws in the Linux wireless stack fixing RCE and DoS vulnerabilities.
Added hardware support
----------------------
ipq40xx-generic
~~~~~~~~~~~~~~~
- GL.iNet
- GL-AP1300
mpc85xx-p1010
~~~~~~~~~~~~~
- TP-Link
- TL-WDR4900 (v1)
ramips-mt7621
~~~~~~~~~~~~~
- ZyXEL
- NWA50AX
rockchip-armv8
~~~~~~~~~~~~~~
- FriendlyElec
- NanoPi R4S (4GB LPDDR4)
Bugfixes
--------
* Multiple mitigations for (`critical vulnerabilities <https://seclists.org/oss-sec/2022/q4/20>`_) in the Linux kernel WLAN stack. This only concerns Gluon v2022.1, older Gluon versions are unaffected.
* CVE-2022-41674
* CVE-2022-42719
* CVE-2022-42720
* CVE-2022-42721
* CVE-2022-42722
* Fixes `security issues in WolfSSL <https://openwrt.org/releases/22.03/notes-22.03.1#security_fixes>`_. People who have installed additional, non-Gluon packages which rely on WolfSSL's TLS 1.3 implementation might be affected. Firmwares using either gluon-mesh-wireless-sae or gluon-wireless-encryption-wpa3 are unaffected by these issues, since only WPA-Enterprise relies on the affected TLS functionality.
* CVE-2022-38152
* CVE-2022-39173
* Fixes the update path for GL-AR300M and NanoStation Loco M2/M5 (XW) devices.
Known issues
------------
* A workaround for Android devices not waking up to their MLD subscriptions was removed,
potentially breaking IPv6 connectivity for these devices after extended sleep periods.
(`#2672 <https://github.com/freifunk-gluon/gluon/issues/2672>`_)
* Upgrading EdgeRouter-X from versions before v2020.1.x may lead to a soft-bricked state due to bad blocks on the NAND flash which the NAND driver before this release does not handle well.
(`#1937 <https://github.com/freifunk-gluon/gluon/issues/1937>`_)
* The integration of the BATMAN_V routing algorithm is incomplete.
- Mesh neighbors don't appear on the status page. (`#1726 <https://github.com/freifunk-gluon/gluon/issues/1726>`_)
Many tools have the BATMAN_IV metric hardcoded, these need to be updated to account for the new throughput
metric.
- Throughput values are not correctly acquired for different interface types.
(`#1728 <https://github.com/freifunk-gluon/gluon/issues/1728>`_)
This affects virtual interface types like bridges and VXLAN.
* Default TX power on many Ubiquiti devices is too high, correct offsets are unknown
(`#94 <https://github.com/freifunk-gluon/gluon/issues/94>`_)
Reducing the TX power in the Advanced Settings is recommended.
* In configurations without VXLAN, the MAC address of the WAN interface is modified even when Mesh-on-WAN is disabled
(`#496 <https://github.com/freifunk-gluon/gluon/issues/496>`_)
This may lead to issues in environments where a fixed MAC address is expected (like VMware when promiscuous mode is disallowed).

View File

@ -1,37 +0,0 @@
Gluon 2022.1.2
==============
Bugfixes
--------
* Various build-errors which sporadically occur when building with a large thread-count have been fixed
* Android devices do not lose their IPv6 connectivity after extended idle-time
* The 802.11s mesh network is now using 802.11ax HE-modes when supported by hardware
Known issues
------------
* Upgrading EdgeRouter-X from versions before v2020.1.x may lead to a soft-bricked state due to bad blocks on the NAND flash which the NAND driver before this release does not handle well.
(`#1937 <https://github.com/freifunk-gluon/gluon/issues/1937>`_)
* The integration of the BATMAN_V routing algorithm is incomplete.
- Mesh neighbors don't appear on the status page. (`#1726 <https://github.com/freifunk-gluon/gluon/issues/1726>`_)
Many tools have the BATMAN_IV metric hardcoded, these need to be updated to account for the new throughput
metric.
- Throughput values are not correctly acquired for different interface types.
(`#1728 <https://github.com/freifunk-gluon/gluon/issues/1728>`_)
This affects virtual interface types like bridges and VXLAN.
* Default TX power on many Ubiquiti devices is too high, correct offsets are unknown
(`#94 <https://github.com/freifunk-gluon/gluon/issues/94>`_)
Reducing the TX power in the Advanced Settings is recommended.
* In configurations without VXLAN, the MAC address of the WAN interface is modified even when Mesh-on-WAN is disabled
(`#496 <https://github.com/freifunk-gluon/gluon/issues/496>`_)
This may lead to issues in environments where a fixed MAC address is expected (like VMware when promiscuous mode is disallowed).

View File

@ -1,40 +0,0 @@
Gluon 2022.1.3
==============
Bugfixes
--------
* Ipq40xx Wave2 devices temporarily use non-ct firmware again to work around 802.11s unicast package loss in ath10k-ct
(`#2692 <https://github.com/freifunk-gluon/gluon/issues/2692>`_)
* Modify kernel builds slightly to work around a boot hang on various devices based on the QCA9563 SoC - especially the Unifi AC-* devices
(`#2784 <https://github.com/freifunk-gluon/gluon/issues/2784>`_)
* Work around an issue with wifi setup timing by waiting a bit while device initialisation is ongoing
(`#2779 <https://github.com/freifunk-gluon/gluon/issues/2779>`_)
Known issues
------------
* Upgrading EdgeRouter-X from versions before v2020.1.x may lead to a soft-bricked state due to bad blocks on the NAND flash which the NAND driver before this release does not handle well.
(`#1937 <https://github.com/freifunk-gluon/gluon/issues/1937>`_)
* The integration of the BATMAN_V routing algorithm is incomplete.
- Mesh neighbors don't appear on the status page. (`#1726 <https://github.com/freifunk-gluon/gluon/issues/1726>`_)
Many tools have the BATMAN_IV metric hardcoded, these need to be updated to account for the new throughput
metric.
- Throughput values are not correctly acquired for different interface types.
(`#1728 <https://github.com/freifunk-gluon/gluon/issues/1728>`_)
This affects virtual interface types like bridges and VXLAN.
* Default TX power on many Ubiquiti devices is too high, correct offsets are unknown
(`#94 <https://github.com/freifunk-gluon/gluon/issues/94>`_)
Reducing the TX power in the Advanced Settings is recommended.
* In configurations without VXLAN, the MAC address of the WAN interface is modified even when Mesh-on-WAN is disabled
(`#496 <https://github.com/freifunk-gluon/gluon/issues/496>`_)
This may lead to issues in environments where a fixed MAC address is expected (like VMware when promiscuous mode is disallowed).

View File

@ -1,136 +0,0 @@
Gluon 2022.1.4
==============
Added hardware support
----------------------
ath79-generic
~~~~~~~~~~~~~
- LibreRouter
- LibreRouter (v1)
- Teltonika
- RUT230 (v1)
ath79-nand
~~~~~~~~~~
- Aerohive
- HiveAP 121
- NETGEAR
- WNDR4300 (v1)
lantiq-xrx200
~~~~~~~~~~~~~
- Arcadyan
- o2 Box 6431
ramips-mt7621
~~~~~~~~~~~~~
- Cudy
- X6 (v1, v2)
- D-Link
- DAP-X1860 (A1)
- GL.iNet
- GL-MT1300
- Mercusys
- MR70X (v1)
- Xiaomi
- Mi Router 3G
ramips-mt76x8
~~~~~~~~~~~~~
- TP-Link
- RE200 (v3)
realtek-rtl838x
~~~~~~~~~~~~~~~
- D-Link
- DGS-1210-10P
ipq40xx-generic
~~~~~~~~~~~~~~~
- AVM
- FRITZBox 7520
ipq40xx-mikrotik
~~~~~~~~~~~~~~~~
- Mikrotik
- hAP ac2
Bugfixes
--------
* Enterasys WS-AP3705i now uses the correct image-name for use with the autoupdater
(`#2819 <https://github.com/freifunk-gluon/gluon/issues/2819>`_)
* Reduce memory Usage for ath10k on ZyXEL WRE6606 devices
(`#2842 <https://github.com/freifunk-gluon/gluon/issues/2842>`_)
* Replace the Workaround for failed boots on ath79 with a proper fix.
(`#2784 <https://github.com/freifunk-gluon/gluon/issues/2784#issuecomment-1452126501>`_)
* AVM FRITZ!Box 7360 v2 flashed with the incorrect image for v1 will automatically update to the correct image.
* Revert OOM inducing switch of ath79 Wave2 firmware back to -ct
(`#2879 <https://github.com/freifunk-gluon/gluon/pull/2879>`_)
Known issues
------------
* Upgrading EdgeRouter-X from versions before v2020.1.x may lead to a soft-bricked state due to bad blocks on the NAND flash which the NAND driver before this release does not handle well.
(`#1937 <https://github.com/freifunk-gluon/gluon/issues/1937>`_)
* The integration of the BATMAN_V routing algorithm is incomplete.
- Mesh neighbors don't appear on the status page. (`#1726 <https://github.com/freifunk-gluon/gluon/issues/1726>`_)
Many tools have the BATMAN_IV metric hardcoded, these need to be updated to account for the new throughput
metric.
- Throughput values are not correctly acquired for different interface types.
(`#1728 <https://github.com/freifunk-gluon/gluon/issues/1728>`_)
This affects virtual interface types like bridges and VXLAN.
* Default TX power on many Ubiquiti devices is too high, correct offsets are unknown
(`#94 <https://github.com/freifunk-gluon/gluon/issues/94>`_)
Reducing the TX power in the Advanced Settings is recommended.
* In configurations without VXLAN, the MAC address of the WAN interface is modified even when Mesh-on-WAN is disabled
(`#496 <https://github.com/freifunk-gluon/gluon/issues/496>`_)
This may lead to issues in environments where a fixed MAC address is expected (like VMware when promiscuous mode is disallowed).

View File

@ -1,417 +0,0 @@
Gluon 2022.1
============
Important notes
---------------
Upgrades to v2022.1 and later releases are only supported from releases v2020.1 and later. This is due to migrations that have been removed to simplify maintenance.
Added hardware support
----------------------
ath79-generic
~~~~~~~~~~~~~
- D-Link
- DAP-2660 A1
- Enterasys
- WS-AP3705i
- Siemens
- WS-AP3610
- TP-Link
- Archer A7 v5
- CPE510 v2
- CPE510 v3
- CPE710 v1
- EAP225-Outdoor v1
- WBS210 v2
ath79-mikrotik
~~~~~~~~~~~~~~
- Mikrotik
- RB951Ui-2nD
ipq40xx-generic
~~~~~~~~~~~~~~~
- Aruba Networks
- AP-303H
- AP-365
- InstantOn AP11D
- InstantOn AP17
ipq40xx-mikrotik
~~~~~~~~~~~~~~~~
- Mikrotik
- SXTsq-5-AC
ramips-mt7620
~~~~~~~~~~~~~
- Xiaomi
- Mi Router 3G (v2)
ramips-mt7621
~~~~~~~~~~~~~
- Cudy
- WR2100
- Netgear
- R6260
- WAC104
- WAX202
- TP-Link
- RE500
- RE650 v1
- Ubiquiti
- UniFi 6 Lite
- Xiaomi
- Mi Router 4A (Gigabit Edition)
ramips-mt7622
~~~~~~~~~~~~~
- Linksys
- E8450
- Xiaomi
- AX3200
- Ubiquiti
- UniFi 6 LR
ramips-mt76x8
~~~~~~~~~~~~~
- GL.iNet
- microuter-N300
- Netgear
- R6020
- RAVPower
- RP-WD009
- TP-Link
- Archer C20 v4
- Archer C20 v5
- RE200 v2
- RE305 v1
- Xiaomi
- Mi Router 4C
- Mi Router 4A (100M Edition)
rockchip-armv8
~~~~~~~~~~~~~~
- FriendlyElec
- NanoPi R2S
mpc85xx-p1010
~~~~~~~~~~~~~
- Sophos
- RED 15w rev. 1
mpc85xx-p1020
~~~~~~~~~~~~~
- Extreme Networks
- WS-AP3825i
Removed Devices
---------------
This list contains devices which do not have enough memory or flash to
be operated with this Gluon release.
- D-Link
- DIR-615 (C1, D1, D2, D3, D4, H1)
- Linksys
- WRT160NL
- TP-Link
- TL-MR13U (v1)
- TL-MR3020 (v1)
- TL-MR3040 (v1, v2)
- TL-MR3220 (v1, v2)
- TL-MR3420 (v1, v2)
- TL-WA701N/ND (v1, v2)
- TL-WA730RE (v1)
- TL-WA750RE (v1)
- TL-WA801N/ND (v1, v2, v3)
- TL-WA830RE (v1, v2)
- TL-WA850RE (v1)
- TL-WA860RE (v1)
- TL-WA901N/ND (v1, v2, v3, v4, v5)
- TL-WA7210N (v2)
- TL-WA7510N (v1)
- TL-WR703N (v1)
- TL-WR710N (v1, v2)
- TL-WR740N (v1, v3, v4, v5)
- TL-WR741N/ND (v1, v2, v4, v5)
- TL-WR743N/ND (v1, v2)
- TL-WR840N (v2)
- TL-WR841N/ND (v3, v5, v7, v8, v9, v10, v11, v12)
- TL-WR841N/ND (v1, v2)
- TL-WR843N/ND (v1)
- TL-WR940N (v1, v2, v3, v4, v5, v6)
- TL-WR941ND (v2, v3, v4, v5, v6)
- TL-WR1043N/ND (v1)
- WDR4900
- Ubiquiti
- AirGateway
- AirGateway Pro
- AirRouter
- Bullet
- LS-SR71
- Nanostation XM
- Nanostation Loco XM
- Picostation
- Unknown
- A5-V11
- VoCore
- VoCore (8M, 16M)
Atheros target migration
------------------------
All Atheros MIPS devices built with the ``ar71xx-generic``,
``ar71xx-nand`` as well as ``ar71xx-tiny`` were deprecated upstream and
are therefore not available with Gluon anymore.
Many devices previously built with ``ar71xx-generic`` and
``ar71xx-nand`` are now available with the ``ath79-generic`` as well as
``ath79-nand`` target respectively.
Missing devices
~~~~~~~~~~~~~~~
The following devices have not yet been integrated into Gluons ath79
targets.
- 8Devices
- Carambola 2
- Aerohive
- HiveAP 121
- Allnet
- ALL0315
- Buffalo
- WZR-HP-G300NH2
- WZR-HP-G450H
- GL.iNet
- 6408A v1
- NETGEAR
- WNDR4300
- WNDRMAC
- WNDRMAC v2
- TP-Link
- WR2543
- Ubiquiti
- Rocket
- WD
- MyNet N600
- MyNet N750
- ZyXEL
- NB6616
- NB6716
Features
--------
WireGuard
~~~~~~~~~
Gluon got WireGuard support. This allows offloading **encrypted**
connections into kernel space, increasing performance by forwarding
packets without the need for context switches between user and kernel
space.
In order to reuse existing (already verified) fastd-keypairs for
WireGuard, a key derivation procedure is `currently being
developed <https://github.com/freifunk-gluon/gluon/pull/2601>`__. This
should ease migration from fastd to WireGuard in case whitelisting VPN
keys is desired.
fastd L2TP
~~~~~~~~~~
fastd can now act as a connection broker for unencrypted L2TP-based
tunneling within Gluons mesh-vpn framework. This new ``null@l2tp``
connection method allows for increased performance within existing
fastd setups.
In addition to a sufficiently
:ref:`configured fastd-based VPN server<vpn-gateway-configuration>`,
this requires further modifications to a sites :ref:`VPN fastd methods<VPN fastd methods>`.
Major changes
-------------
OpenWrt
~~~~~~~
This release is based on the newest OpenWrt 22.03 release branch.
It ships with Linux kernel 5.10 as well as wireless-backports 5.15.
Network changes (DSA / Upgrade-Behavior)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The ``ramips-mt7621`` and ``lantiq-xrx200`` targets now use the upstream DSA
subsystem instead of OpenWrt swconfig for managing ethernet switches.
Gluon detects the existing user-intent and automatically applies it over
to DSA syntax. See the section about network reconfiguration for more
details.
System reconfiguration
~~~~~~~~~~~~~~~~~~~~~~
The network and system-LED configurations are now re-generated after
each update / invocation of ``gluon-reconfigure``.
The user-intent is preserved within Gluons implemented functionality
(Wired-Mesh / Client access / WAN).
As an additional feature, Gluon now supports assigning roles to
interfaces. This behavior is explained
:ref:`here<wired-mesh-commandline>`.
Site changes
------------
VPN provider MTU
~~~~~~~~~~~~~~~~
To account for multiple VPN methods available for a site, the MTU used
for the VPN tunnel connection is now moved to the specific VPN provider
configuration. For fastd this means that ``mesh_vpn.mtu`` needs to be
moved to ``mesh_vpn.fastd.mtu``. (`#2352 <https://github.com/freifunk-gluon/gluon/pull/2352>`__)
Preconfigured Interfaces Roles
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Instead of ``mesh_on_wan`` and ``mesh_on_lan`` there is now an
``interfaces`` block to configure the default behavior of network
interfaces. Details can be found in the
:ref:`documentation<user-site-interfaces>`.
Minor changes
-------------
- The ``brcm2708-bcm2708`` ``brcm2708-bcm2709`` ``brcm2708-bcm2710``
targets were renamed to ``bcm27xx-bcm2708`` ``bcm27xx-bcm2709`` and
``bcm27xx-bcm2710``
- The GL.iNet GL-AR750S was moved to the ``ath79-nand`` subtarget
- Gluon now ships the ath10k-ct firmware derivation for
QCA9886 / QCA9888 / QCA9896 / QCA9898 / QCA9984 /
QCA9994 / IPQ4018 / IPQ4028 / IPQ4019 / IPQ4029
radios (`#2541 <https://github.com/freifunk-gluon/gluon/pull/2541>`__)
- WolfSSL instead of OpenSSL is now used when built with WPA3 support
- The option to configure the wireless-channel independent from the
site-selected channel was moved from
``gluon-core.wireless.preserve_channels`` to
``gluon.wireless.preserve_channels``
- ``gluon-info`` is a new command that provides information about the
current node
- ``GLUON_DEPRECATED`` is now set to 0 by default
- To reboot a running gluon-node into setup-mode, Gluon now offers the
``gluon-enter-setup-mode`` command
- Devices without WLAN do not show the private-wifi configuration
anymore
- The Autoupdater now uses the site default branch in case it is
configured to use a non-existent / invalid branch
Known issues
------------
* A workaround for Android devices not waking up to their MLD subscriptions was removed,
potentially breaking IPv6 connectivity for these devices after extended sleep periods.
(`#2672 <https://github.com/freifunk-gluon/gluon/issues/2672>`_)
* Upgrading EdgeRouter-X from versions before v2020.1.x may lead to a soft-bricked state due to bad blocks on the NAND flash which the NAND driver before this release does not handle well.
(`#1937 <https://github.com/freifunk-gluon/gluon/issues/1937>`_)
* The integration of the BATMAN_V routing algorithm is incomplete.
- Mesh neighbors don't appear on the status page. (`#1726 <https://github.com/freifunk-gluon/gluon/issues/1726>`_)
Many tools have the BATMAN_IV metric hardcoded, these need to be updated to account for the new throughput
metric.
- Throughput values are not correctly acquired for different interface types.
(`#1728 <https://github.com/freifunk-gluon/gluon/issues/1728>`_)
This affects virtual interface types like bridges and VXLAN.
* Default TX power on many Ubiquiti devices is too high, correct offsets are unknown
(`#94 <https://github.com/freifunk-gluon/gluon/issues/94>`_)
Reducing the TX power in the Advanced Settings is recommended.
* In configurations without VXLAN, the MAC address of the WAN interface is modified even when Mesh-on-WAN is disabled
(`#496 <https://github.com/freifunk-gluon/gluon/issues/496>`_)
This may lead to issues in environments where a fixed MAC address is expected (like VMware when promiscuous mode is disallowed).

View File

@ -1 +1 @@
sphinx-rtd-theme==1.2.0
sphinx-rtd-theme

View File

@ -45,7 +45,7 @@ msgstr ""
"selbstverständlich vertraulich behandelt und nicht weitergegeben."
"</p>"
"<div class=\"the-key\">"
"# <%= pcdata(hostname) %><br>"
"# <%= pcdata(hostname) %><br />"
"<%= pubkey %>"
"</div>"
"<p>Dein Knoten startet gerade neu und wird anschließend versuchen, sich mit "
@ -58,7 +58,7 @@ msgid "gluon-config-mode:novpn"
msgstr ""
"<p><strong>Du hast ausgewählt die Internetverbindung (Mesh-VPN) nicht zu "
"nutzen</strong>. Dein Knoten kann also nur dann eine Verbindung zum "
"Freifunk-Netz aufbauen, wenn andere Freifunk-Knoten in WLAN-Reichweite sind.</p>"
"Freifunk-Netz aufbauen, wenn andere Freifunk-Knoten in WLAN-Reichweite sind."
"<p>Bitte schicke uns eine E-Mail mit dem Namen deines Knotens "
"(<em><%= pcdata(hostname) %></em>) und ein paar Informationen an <a href="
"\"mailto:freifunk-keys@lists.in-kiel.de?"

View File

@ -41,7 +41,7 @@ msgstr ""
"\">keys@alpha-centauri.freifunk.net</a>. Of course, your e-mail address will "
"be treated confidentially and will not be passed on.</p>"
"<div class=\"the-key\">"
" # <%= pcdata(hostname) %><br>"
" # <%= pcdata(hostname) %><br />"
"<%= pubkey %>"
"</div>"
"<p>Your node <em><%= pcdata(hostname) %></em> is currently rebooting and will "

View File

@ -36,7 +36,7 @@ msgstr ""
"body=<%= urlencode('# ' .. hostname .. '\n' .. pubkey) %>\">keys@alpha-centauri.freifunk.net</a>."
"</p>"
"<div class=\"the-key\">"
" # <%= pcdata(hostname) %><br>"
" # <%= pcdata(hostname) %><br />"
"<%= pubkey %>"
"</div>"

View File

@ -12,6 +12,7 @@
# the git repository from where to clone the package feed
#PACKAGES_MY_OWN_PACKAGES_REPO=https://github.com/.../my-own-packages.git
## PACKAGES_$feedname_COMMIT
# the version/commit of the git repository to clone
#PACKAGES_MY_OWN_PACKAGES_COMMIT=123456789aabcda1a69b04278e4d38f2a3f57e49

View File

@ -1,4 +1,4 @@
-- This is an example site configuration for Gluon v2022.1
-- This is an example site configuration for Gluon v2020.2.1
--
-- Take a look at the documentation located at
-- https://gluon.readthedocs.io/ for details.
@ -105,6 +105,7 @@
mesh_vpn = {
-- enabled = true,
mtu = 1312,
fastd = {
-- Refer to https://fastd.readthedocs.io/en/latest/ to better understand
@ -112,7 +113,6 @@
-- List of crypto-methods to use.
methods = {'salsa2012+umac'},
mtu = 1312,
-- configurable = true,
-- syslog_level = 'warn',

View File

@ -17,9 +17,6 @@ GLUON_FEATURES := \
web-advanced \
web-wizard
GLUON_FEATURES_standard := \
wireless-encryption-wpa3
## GLUON_SITE_PACKAGES
# Specify additional Gluon/OpenWrt packages to include here;
# A minus sign may be prepended to remove a packages from the
@ -55,3 +52,6 @@ GLUON_REGION ?= eu
# Languages to include
GLUON_LANGS ?= en de
# Do not build images for deprecated devices
GLUON_DEPRECATED ?= 0

View File

@ -25,3 +25,84 @@ interface. This DNS server must be announced in router advertisements (using
on *batman-adv*. If your mesh does not have global IPv6 connectivity, you can setup
your *radvd* not to announce a default route by setting the *default lifetime* to 0;
in this case, the *radvd* is only used to announce the DNS server.
.. _faq-mtu:
What is a good MTU on the mesh-vpn?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Setting the MTU on the transport interface requires careful consideration, as
setting it too low will cause excessive fragmentation and setting it too high
may leave peers with a broken tunnel due to packet loss.
Consider these key values:
- Payload: Allow for the transport of IPv6 packets, by adhering to the minimum MTU
of 1280 Byte specified in RFC 2460
- and configure `MSS clamping`_ accordingly,
- and announce your link MTU via Router Advertisements and DHCP
.. _MSS clamping: https://www.tldp.org/HOWTO/Adv-Routing-HOWTO/lartc.cookbook.mtu-mss.html
- Encapsulation: Account for the overhead created by the configured mesh protocol
encapsulating the payload, which is up to 32 Byte (14 Byte Ethernet + 18 Byte
batadv).
- PMTU: What MTU does the path between your gateway and each of its peers support?
For reference, the complete MTU stack looks like this:
.. image:: mtu-diagram_v5.png
Minimum MTU
-----------
Calculate the minimum transport MTU by adding the encapsulation overhead to the
minimum payload MTU required. This is the lowest recommended value, since going
lower would cause unnecessary fragmentation for clients which respect the announced
link MTU.
Example: Our network currently uses batman-adv v15, it therefore requires up
to 32 Bytes of encapsulation overhead on top of the minimal link MTU required for
transporting IPv6.::
\ 1312 1294 1280 0
\---------+-----------------+-------------+----------------------------------+
\TAP | batadv v15 | Ethernet | Payload |
\-------+-----------------+-------------+----------------------------------+
\ ^
|
MTU_LOW = 1280 Byte + 14 Byte + 18 Byte = 1312 Byte
Maximum MTU
-----------
Calculating the maximum transport MTU is interesting, because it increases the
throughput, by allowing larger payloads to be transported, but also more difficult
as you have to take into account the tunneling overhead and each peers PMTU, which
varies between providers.
The underlying reasons are mostly PPPoE, Tunneling and IPv6 transition technologies
like DS-Lite.
Example: The peer with the smallest MTU on your network is behind DS-Lite and can
transport IPv4 packets up to 1436 Bytes in size. Your tunnel uses IPv4 (20 Byte),
UDP (8 Byte), Fastd (24 byte) and you require TAP (14 Byte) for Layer 2 (Ethernet)
Tunneling.::
1436 1416 1408 1384 1370 \
+-------------------+--------+-----------------------+-------------+------\
| IP | UDP | Fastd | TAP | bat\
+-------------------+--------+-----------------------+-------------+--------\
^ \
|
MTU_HIGH = 1436 Byte - 20 Byte - 8 Byte - 24 Byte - 14 Byte = 1370 Byte
Conclusion
----------
Determining the maximum MTU can be a tedious process, especially since the PMTU
of peers could change at any time. The general recommendation for maximized
compatibility is therefore the minimum MTU of 1312 Byte, which works well with
both IPv4 and IPv6.

View File

@ -8,7 +8,7 @@ Gluon's releases are managed using `Git tags`_. If you are just getting
started with Gluon we recommend to use the latest stable release of Gluon.
Take a look at the `list of gluon releases`_ and notice the latest release,
e.g. *v2022.1*. Always get Gluon using git and don't try to download it
e.g. *v2020.2.1*. Always get Gluon using git and don't try to download it
as a Zip archive as the archive will be missing version information.
Please keep in mind that there is no "default Gluon" build; a site configuration
@ -25,34 +25,26 @@ An example configuration can be found in the Gluon repository at *docs/site-exam
Dependencies
------------
To build Gluon, several packages need to be installed on the system. On a
freshly installed Debian Bullseye system the following packages are required:
freshly installed Debian Stretch system the following packages are required:
* `git` (to get Gluon and other dependencies)
* `python3`
* `subversion`
* `python` (Python 3 doesn't work)
* `build-essential`
* `ecdsautils` (to sign firmware, see `contrib/sign.sh`)
* `gawk`
* `unzip`
* `libncurses-dev` (actually `libncurses5-dev`)
* `libz-dev` (actually `zlib1g-dev`)
* `libssl-dev`
* `libelf-dev` (to build x86-64)
* `wget`
* `rsync`
* `time` (built-in `time` doesn't work)
* `qemu-utils`
We also provide a container environment that already tracks all these dependencies. It quickly gets you up and running, if you already have either Docker or Podman installed locally.
::
./scripts/container.sh
Building the images
-------------------
To build Gluon, first check out the repository. Replace *RELEASE* with the
version you'd like to checkout, e.g. *v2022.1*.
version you'd like to checkout, e.g. *v2020.2.1*.
::
@ -88,18 +80,18 @@ Extensive documentation about the site configuration can be found at:
site directory should always be a git repository by itself; committing site-specific files
to the Gluon main repository should be avoided, as it will make updates more complicated.
Next go back to the top-level Gluon directory and build Gluon\ [#make_update]_::
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
make GLUON_TARGET=ar71xx-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.
.. _Troubleshooting: https://github.com/freifunk-gluon/gluon/wiki/Troubleshooting
``ath79-generic`` is the most common target and will generate images for most of the supported hardware.
``ar71xx-generic`` is the most common target and will generate images for most of the supported hardware.
To see a complete list of supported targets, call ``make`` without setting ``GLUON_TARGET``.
To build all targets use a loop like this::
@ -127,22 +119,12 @@ These can be used for debugging and should be stored along with the images to
allow debugging of kernel problems on devices in the field.
See :ref:`Debugging <dev-debugging-kernel-oops>` for more information.
.. rubric:: Footnotes
.. [#make_update] ``make update`` only needs to be called again after updating the
Gluon repository (using ``git pull`` or similar) or after changing branches,
not for each build. Running it more often than necessary is undesirable, as
the update will take some time, and may undo manual modifications of the
external repositories while developing on Gluon.
See :ref:`working-with-repositories` for more information.
Cleaning the build tree
.......................
There are two levels of `make clean`::
make clean GLUON_TARGET=ath79-generic
make clean GLUON_TARGET=ar71xx-generic
will ensure all packages are rebuilt for a single target. This is usually not
necessary, but may fix certain kinds of build failures.
@ -177,14 +159,6 @@ to sign the generated package repository).
OpenWrt will handle the generation and handling of the keys itself.
When making firmware releases based on Gluon, it might make sense to store
the keypair, so updating the module repository later is possible.
In fact you should take care to reuse the same opkg keypair, so you don't pollute the key
store (see ``/etc/opkg/keys``) on the node.
The signing-key is stored at ``openwrt/key-build.pub``, ``openwrt/key-build``,
``key-build.ucert`` and ``key-build.ucert.revoke``.
The ``openwrt`` directory is the Git checkout, that gets created after calling ``make update``.
After making a fresh clone copy the key files to the aforementioned locations.
.. _getting-started-make-variables:
@ -215,7 +189,7 @@ GLUON_DEPRECATED
Usually, devices are deprecated because their flash size is insufficient to
support future Gluon versions. The recommended setting is ``0`` for new sites,
and ``upgrade`` for existing configurations (where upgrades for existing
deployments of low-flash devices are required). Defaults to ``0``.
deployments of low-flash devices are required).
GLUON_LANGS
Space-separated list of languages to include for the config mode/advanced settings. Defaults to ``en``.

View File

@ -1,223 +0,0 @@
MTU for Mesh-VPN
================
What is a good MTU on the mesh-vpn?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Setting the MTU on the transport interface requires careful consideration, as
setting it too low will cause excessive fragmentation and setting it too high
may leave peers with a broken tunnel due to packet loss.
Consider these key values:
- Payload: Allow for the transport of IPv6 packets, by adhering to the minimum MTU
of 1280 Byte specified in RFC 2460
- and configure `MSS clamping`_ accordingly,
- and announce your link MTU via Router Advertisements and DHCP
.. _MSS clamping: https://tldp.org/HOWTO/Adv-Routing-HOWTO/lartc.cookbook.mtu-mss.html
- Encapsulation: Account for the overhead created by the configured mesh protocol
encapsulating the payload, which is up to 32 Byte (14 Byte Ethernet + 18 Byte
batadv).
- PMTU: What MTU does the path between your gateway and each of its peers support?
For reference, the complete MTU stack looks like this:
.. image:: mtu-diagram_v5.png
Example for Minimum MTU
-----------------------
Calculate the minimum transport MTU by adding the encapsulation overhead to the
minimum payload MTU required. This is the lowest recommended value, since going
lower would cause unnecessary fragmentation for clients which respect the announced
link MTU.
.. editorconfig-checker-disable
Example: Our network currently uses batman-adv v15, it therefore requires up
to 32 Bytes of encapsulation overhead on top of the minimal link MTU required for
transporting IPv6.::
\ 1312 1294 1280 0
\---------+-----------------+-------------+----------------------------------+
\TAP | batadv v15 | Ethernet | Payload |
\-------+-----------------+-------------+----------------------------------+
\ ^
|
MTU_LOW = 1280 Byte + 14 Byte + 18 Byte = 1312 Byte
Example for Maximum MTU
-----------------------
Calculating the maximum transport MTU is interesting, because it increases the
throughput, by allowing larger payloads to be transported, but also more difficult
as you have to take into account the tunneling overhead and each peers PMTU, which
varies between providers.
The underlying reasons are mostly PPPoE, Tunneling and IPv6 transition technologies
like DS-Lite.
Example: The peer with the smallest MTU on your network is behind DS-Lite and can
transport IPv4 packets up to 1436 Bytes in size. Your tunnel uses IPv4 (20 Byte),
UDP (8 Byte), Fastd (24 byte) and you require TAP (14 Byte) for Layer 2 (Ethernet)
Tunneling.::
1436 1416 1408 1384 1370 \
+-------------------+--------+-----------------------+-------------+------\
| IP | UDP | Fastd | TAP | bat\
+-------------------+--------+-----------------------+-------------+--------\
^ \
|
MTU_HIGH = 1436 Byte - 20 Byte - 8 Byte - 24 Byte - 14 Byte = 1370 Byte
.. editorconfig-checker-enable
Tables for Different VPN Providers
----------------------------------
VPN Protocol Overhead (IPv4)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Overhead of the VPN protocol layers in bytes on top of an Ethernet frame.
+----------+-------+--------------+-----------+
| | fastd | Tunneldigger | Wireguard |
+==========+=======+==============+===========+
| IPv4 | 20 | 20 | 20 |
+----------+-------+--------------+-----------+
| UDP | 8 | 8 | 8 |
+----------+-------+--------------+-----------+
| Protocol | 24 | 8 | 32 |
+----------+-------+--------------+-----------+
| TAP | 14 | 14 | / |
+----------+-------+--------------+-----------+
| Sum | 66 | 50 | 60 |
+----------+-------+--------------+-----------+
Intermediate Layer Overhead
^^^^^^^^^^^^^^^^^^^^^^^^^^^
Overhead of additional layers on top of the VPN packet needed for different VPN
providers.
+------------+-------+--------------+-----------+
| | fastd | Tunneldigger | Wireguard |
+============+=======+==============+===========+
| IPv6 | / | / | 40 |
+------------+-------+--------------+-----------+
| vxlan | / | / | 16 |
+------------+-------+--------------+-----------+
| Ethernet | / | / | 14 |
+------------+-------+--------------+-----------+
| Batman v15 | 18 | 18 | 18 |
+------------+-------+--------------+-----------+
| Ethernet | 14 | 14 | 14 |
+------------+-------+--------------+-----------+
| Sum | 32 | 32 | 102 |
+------------+-------+--------------+-----------+
Minimum MTU
^^^^^^^^^^^
Calculation of different derived MTUs based on a 1280 byte payload to
avoid fragmentation.
Suggestions:
- This configuration is only suggested for fastd and Tunneldigger.
- For WireGuard, this configuration is **unsuitable**. To obtain a 1280 byte
payload with our protocol stack (see below), the Ethernet frame payload would
be 1442 bytes long (for IPv4). As we assume that the WAN network might have
a (worst case) MTU of only 1436 (with DSLite), this packet would be too long
for the WAN network.
+-------------------------------+-------+--------------+-----------+
| | fastd | Tunneldigger | Wireguard |
+===============================+=======+==============+===========+
| max unfragmented payload\* | 1280 | 1280 | 1280 |
+-------------------------------+-------+--------------+-----------+
| intermed layer overhead | 32 | 32 | 102 |
+-------------------------------+-------+--------------+-----------+
| VPN MTU\*\* | 1312 | 1312 | 1382 |
+-------------------------------+-------+--------------+-----------+
| protocol overhead (IPv4) | 66 | 50 | 60 |
+-------------------------------+-------+--------------+-----------+
| min acceptable WAN MTU (IPv4) | 1378 | 1362 | **1442** |
+-------------------------------+-------+--------------+-----------+
| min acceptable WAN MTU (IPv6) | 1398 | 1382 | 1462 |
+-------------------------------+-------+--------------+-----------+
\* Maximum size of payload going into the bat0 interface, that will not be
fragmented by batman.
\*\* This is the MTU that is set in the site.conf.
Maximum MTU
^^^^^^^^^^^
Calculation of different derived MTUs based on a maximum WAN MTU of 1436.
Suggestions:
- This configuration can be used for fastd and Tunneldigger.
- For WireGuard, this is the recommended configuration. batman-adv will
fragment larger packets transparently to avoid packet loss.
+-------------------------------+-------+--------------+-----------+
| | fastd | Tunneldigger | Wireguard |
+===============================+=======+==============+===========+
| min acceptable WAN MTU (IPv4) | 1436 | 1436 | 1436 |
+-------------------------------+-------+--------------+-----------+
| protocol overhead (IPv4) | 66 | 50 | 60 |
+-------------------------------+-------+--------------+-----------+
| VPN MTU\*\* | 1370 | 1386 | 1376 |
+-------------------------------+-------+--------------+-----------+
| intermed layer overhead | 32 | 32 | 102 |
+-------------------------------+-------+--------------+-----------+
| max unfragmented payload\* | 1338 | 1354 | 1274 |
+-------------------------------+-------+--------------+-----------+
| min acceptable WAN MTU (IPv6) | 1398 | 1382 | 1462 |
+-------------------------------+-------+--------------+-----------+
\* Maximum size of payload going into the bat0 interface, that will not be
fragmented by batman.
\*\* This is the MTU that is set in the site.conf.
Suggested MSS Values
^^^^^^^^^^^^^^^^^^^^
It is highly advised to use MSS clamping for TCP on the gateways/supernodes in
order to avoid the fragmentation mechanism of batman whenever possible.
Especially on small embedded devices, fragmentation costs performance.
As batmans fragmentation is transparent to the TCP layer, clamping the MSS
automatically to the PMTU does not work. Instead, the MSS must be specified
explicitly. In iptables, this is done via :code:`-j TCPMSS --set-mss X`,
whereby :code:`X` is the desired MSS.
Since the MSS is specified in terms of payload of a TCP packet, the MSS is
different for IPv4 and IPv6. Here are some examples for different max
unfragmented payloads:
+---------------------------------+------+------+------+------+
| max unfragmented payload | 1274 | 1280 | 1338 | 1354 |
+=================================+======+======+======+======+
| suggested MSS (IPv4, -40 bytes) | 1234 | 1240 | 1298 | 1314 |
+---------------------------------+------+------+------+------+
| suggested MSS (IPv6, -60 bytes) | 1214 | 1220 | 1278 | 1294 |
+---------------------------------+------+------+------+------+
Conclusion
^^^^^^^^^^
Determining the maximum MTU can be a tedious process, especially since the PMTU
of peers could change at any time. The general recommendation for maximized
compatibility is therefore an MTU of 1312 bytes (for fastd and tunneldigger)
and 1376 bytes (for WireGuard).

View File

@ -27,51 +27,55 @@ domain_seed
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::
The recommended way to generate a value for a new site is:
::
echo $(hexdump -v -n 32 -e '1/1 "%02x"' </dev/urandom)
prefix4 \: optional
The IPv4 Subnet of your community mesh network in CIDR notation, e.g. ::
The IPv4 Subnet of your community mesh network in CIDR notation, e.g.
::
prefix4 = '10.111.111.0/18'
Required if ``next_node.ip4`` is set.
prefix6
The IPv6 subnet of your community mesh network, e.g. ::
The IPv6 subnet of your community mesh network, e.g.
::
prefix6 = 'fdca::ffee:babe:1::/64'
node_prefix6
The ipv6 prefix from which the unique IP-addresses for nodes are selected
in babel-based networks. This may overlap with prefix6. e.g. ::
in babel-based networks. This may overlap with prefix6. e.g.
::
node_prefix6 = 'fdca::ffee:babe:2::/64'
node_client_prefix6 \: optional, deprecated
DEPRECATED: Don't specify it anymore, this prefix will then
automatically be generated from the domain_seed.
An IPv6 prefix internally used by the l3roamd protocol, used to allow
an efficient handover via unicast when a client roamed.
This is exclusively useful when running a routing mesh protocol
like babel. e.g. ::
node_client_prefix6
The ipv6 prefix from which the client-specific IP-address is calculated that
is assigned to each node by l3roamd to allow efficient communication when
roaming. This is exclusively useful when running a routing mesh protocol
like babel. e.g.
::
node_client_prefix6 = 'fdca::ffee:babe:3::/64'
timezone
The timezone of your community live in, e.g. ::
The timezone of your community live in, e.g.
::
-- Europe/Berlin
timezone = 'CET-1CEST,M3.5.0,M10.5.0/3'
ntp_servers
List of NTP servers available in your community or used by your community, e.g.::
List of NTP servers available in your community or used by your community, e.g.:
::
ntp_servers = {'1.ntp.services.ffac','2.ntp.services.ffac'}
These NTP servers must be reachable via IPv6 from the nodes. If you don't want to set an IPv6 address
This NTP servers must be reachable via IPv6 from the nodes. If you don't want to set an IPv6 address
explicitly, but use a hostname (which is recommended), see also the :ref:`FAQ <faq-dns>`.
opkg \: optional
@ -98,14 +102,15 @@ opkg \: optional
- ``%d`` is replaced by the OpenWrt distribution name ("openwrt")
- ``%v`` is replaced by the OpenWrt version number (e.g. "17.01")
- ``%S`` is replaced by the target board (e.g. "ath79/generic")
- ``%S`` is replaced by the target board (e.g. "ar71xx/generic")
- ``%A`` is replaced by the target architecture (e.g. "mips_24kc")
- ``%GS`` is replaced by the Gluon site code (as specified in ``site.conf``)
- ``%GV`` is replaced by the Gluon version
- ``%GR`` is replaced by the Gluon release (as specified in ``site.mk``)
regdom \: optional
The wireless regulatory domain responsible for your area, e.g. ::
The wireless regulatory domain responsible for your area, e.g.:
::
regdom = 'DE'
@ -118,6 +123,7 @@ wifi24 \: optional
time units (TU). A time unit is equivalent to 1024 µs.
If not set, the default value of 100 TU (=102.4 ms) is used.
There are currently two interface types available. You may choose to
configure any subset of them:
@ -152,7 +158,6 @@ wifi24 \: optional
``mesh`` also accepts an optional ``mcast_rate`` (kbit/s) parameter for
setting the multicast bitrate. Increasing the default value of 1000 to something
like 12000 is recommended.
::
wifi24 = {
@ -183,12 +188,6 @@ wifi5 \: optional
When set to ``true`` all 5 GHz radios will use outdoor channels, while on ``false``
the outdoor mode will be completely disabled. The default setting is ``'preset'``,
which will enable outdoor mode automatically on outdoor-capable devices.
It can be beneficial to look up the WLAN channels that are used by `weather radars`_
when constructing ``outdoor_chanlist`` to try and minimize the impact of DFS events.
.. _weather radars: https://homepage.univie.ac.at/albert.rafetseder/RADARs/help.html
::
wifi5 = {
@ -200,7 +199,6 @@ wifi5 \: optional
next_node \: package
Configuration of the local node feature of Gluon
::
next_node = {
@ -291,7 +289,7 @@ mesh_vpn
The `enabled` option can be set to true to enable the VPN by default. `mtu`
defines the MTU of the VPN interface, determining a proper MTU value is described
in :doc:`mtu`.
in the :ref:`FAQ <faq-mtu>`.
By default the public key of a node's VPN daemon is not added to announced respondd
data; this prevents malicious ISPs from correlating VPN sessions with specific mesh
@ -334,10 +332,10 @@ mesh_vpn
mesh_vpn = {
-- enabled = true,
mtu = 1312,
-- pubkey_privacy = true,
fastd = {
mtu = 1312,
methods = {'salsa2012+umac'},
-- configurable = true,
-- syslog_level = 'warn',
@ -387,22 +385,7 @@ mesh_vpn
},
tunneldigger = {
mtu = 1312,
brokers = {'vpn1.alpha-centauri.freifunk.net'},
},
wireguard = {
mtu = 1376,
peers = {
vpn1 = {
public_key = 'XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX=',
endpoint = 'vpn1.alpha-centauri.freifunk.net:51810',
},
vpn2 = {
public_key = 'XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX=',
endpoint = 'vpn2.alpha-centauri.freifunk.net:51810',
},
},
brokers = {'vpn1.alpha-centauri.freifunk.net'}
},
bandwidth_limit = {
@ -417,46 +400,17 @@ mesh_vpn
},
}
.. _user-site-interfaces:
interfaces \: optional
Default setup for Ethernet ports.
mesh_on_wan \: optional
Enables the mesh on the WAN port (``true`` or ``false``).
::
interfaces = {
lan = {
default_roles = { 'client', 'mesh' },
},
wan = {
default_roles = { 'uplink', 'mesh' },
},
single = {
default_roles = { 'uplink', 'mesh' },
},
},
mesh_on_wan = true,
For devices that have two distinct Ethernet ports or port groups (often
labelled WAN and LAN), the ``lan`` and ``wan`` sections are used. When there
is only one port (group), ``single`` is used instead.
mesh_on_lan \: optional
Enables the mesh on the LAN port (``true`` or ``false``).
::
Available interface roles:
- ``client``: Port allows regular clients to connect to the mesh
- ``uplink``: Port is used to establish Mesh VPN connections
- ``mesh``: Wired meshing to another Gluon or Gluon-compatible node
The ``client`` role requires exclusive control over an interface. When
the ``client`` role is assigned to an interface at the same time as other
roles (like ``'client', 'mesh'`` in the above example), the other roles take
precedence (enabling ``mesh``, but not ``client`` in the example). In that
case, the ``client`` role is removed from the config of the interface.
All interface settings are optional. If unset, the following defaults are
used:
- ``lan``: ``{ 'client' }``
- ``wan``: ``{ 'uplink' }``
- ``single``: Same as ``wan``
mesh_on_lan = true,
poe_passthrough \: optional
Enable PoE passthrough by default on hardware with such a feature.
@ -518,7 +472,7 @@ config_mode \: optional
*openlayers_url* allows to override the base URL of the
*build/ol.js* and *css/ol.css* files (the default is
``https://cdn.jsdelivr.net/gh/openlayers/openlayers.github.io@35ffe7626ce16c372143f3c903950750075e7068/en/v5.3.0``).
``https://cdn.rawgit.com/openlayers/openlayers.github.io/master/en/v5.2.0``).
It is also possible to replace the default tile layer (which is OpenStreetMap)
with a custom one using the *tile_layer* section. Only XYZ layers are supported
at this point.
@ -609,7 +563,7 @@ GLUON_DEPRECATED
Usually, devices are deprecated because their flash size is insufficient to
support future Gluon versions. The recommended setting is ``0`` for new sites,
and ``upgrade`` for existing configurations (where upgrades for existing
deployments of low-flash devices are required). Defaults to ``0``.
deployments of low-flash devices are required).
GLUON_FEATURES
Defines a list of features to include. Depending on the device, the feature list

View File

@ -1,80 +1,64 @@
Supported Devices & Architectures
=================================
ath79-generic
ar71xx-generic
--------------
* 8devices
- Carambola 2
* ALFA Network
- AP121 [#deprecated]_ [#device-class-tiny]_
- AP121F
- AP121U [#deprecated]_ [#device-class-tiny]_
* Allnet
- ALL0315N
* AVM
- FRITZ!WLAN Repeater 300E [#avmflash]_
- Fritz!WLAN Repeater 450E [#avmflash]_
- Fritz!Box 4020 [#avmflash]_
- Fritz!WLAN Repeater 300E [#avmflash]_
- Fritz!WLAN Repeater 450E [#avmflash]_
* Buffalo
- WZR-HP-AG300H / WZR-600DHP
- WZR-HP-G300NH (rtl8366s)
* devolo
- WiFi pro 1200e [#lan_as_wan]_
- WiFi pro 1200i
- WiFi pro 1750c
- WiFi pro 1750e [#lan_as_wan]_
- WiFi pro 1750i
- WiFi pro 1750x
- WZR-HP-G300NH
- WZR-HP-G300NH2
- WZR-HP-G450H
* D-Link
- DAP-1330 A1 [#lan_as_wan]_
- DAP-1365 A1 [#lan_as_wan]_
- DAP-2660 A1 [#lan_as_wan]_
- DIR-505 A1 [#lan_as_wan]_
- DIR-505 A2 [#lan_as_wan]_
- DIR-825 B1
* Enterasys
- WS-AP3705i
* Extreme Networks
- WS-AP3805i
- DAP-1330 (A1)
- DIR-505 (A1, A2)
- DIR-825 (B1)
* GL.iNet
- 6408A
- 6416A
- GL-AR150
- GL-AR300M-Lite
- GL-AR300M
- GL-AR750
- GL-USB150 (Microuter)
* Joy-IT
* Linksys
- JT-OR750i
* LibreRouter
- LibreRouter v1 [#missing_radios]_
- WRT160NL [#device-class-tiny]_
* Netgear
- WNDR3700 (v1, v2)
- WNDR3800
- WNR2200 (8M, 16M)
- WNDRMAC (v2)
* OCEDO
- Koala
- Raccoon
* Onion
- Omega [#modular_ethernet]_
* OpenMesh
@ -87,83 +71,142 @@ ath79-generic
- OM2P-HS (v1, v2, v3, v4)
- OM2P-LC
- OM5P
- OM5P-AC (v1, v2)
- OM5P-AN
* Plasma Cloud
- PA300
- PA300E
* Siemens
- WS-AP3610
* Teltonika
- RUT230 (v1)
- OM5P-AC (v1, v2)
* TP-Link
- Archer A7 (v5)
- Archer C5 (v1)
- Archer C6 (v2 EU/RU/JP)
- Archer C7 (v2, v4, v5)
- Archer C59 (v1)
- CPE210 (v1.0, v1.1, v2.0, v3.0, v3.1, v3.20)
- CPE220 (v3.0)
- CPE510 (v1.0, v1.1, v2.0, v3.0)
- CPE710 (v1.0)
- EAP225-Outdoor (v1)
- RE450 (v1)
- Archer C7 (v2, v4, v5)
- CPE210 (v1.0, v1.1, v2.0, v3.0)
- CPE220 (v1.1)
- CPE510 (v1.0, v1.1)
- CPE520 (v1.1)
- RE450 (v1) [#device-class-tiny]_
- TD-W8970 (v1) [#lan_as_wan]_
- TL-WDR3500 (v1)
- TL-WDR3600 (v1)
- TL-WDR4300 (v1)
- TL-WR710N (v1, v2.1)
- TL-WR810N (v1)
- TL-WR842N/ND (v3)
- TL-WR1043N/ND (v2, v3, v4, v5)
- WBS210 (v1.20, v2.0)
- TL-WR842N/ND (v1, v2, v3)
- TL-WR1043N/ND (v1, v2, v3, v4, v5)
- TL-WR2543N/ND (v1)
- WBS210 (v1.20)
- WBS510 (v1.20)
* Ubiquiti
- NanoBeam M5 (XW)
- NanoStation Loco M2/M5 (XW)
- NanoStation M2/M5 (XW)
- UniFi AC Lite
- UniFi AC LR
- Air Gateway [#device-class-tiny]_
- Air Gateway LR [#device-class-tiny]_
- Air Gateway PRO [#device-class-tiny]_
- Air Router [#device-class-tiny]_
- Bullet M2/M5 [#device-class-tiny]_
- Loco M2/M5 [#device-class-tiny]_
- Loco M2/M5 XW
- Nanostation M2/M5 [#device-class-tiny]_
- Nanostation M2/M5 XW
- Picostation M2 [#device-class-tiny]_
- Rocket M2
- Rocket M2 Ti
- Rocket M2 XW
- UniFi AC Mesh
- UniFi AC Mesh Pro
- UniFi AC Pro
- UniFi AP
- UniFi AP AC Lite
- UniFi AP AC LR
- UniFi AP AC Pro
- UniFi AP LR
- UniFi AP Pro
- UniFi AP Outdoor
- UniFi AP Outdoor+
- UniFi AP PRO
ath79-nand
----------
* Western Digital
- My Net N600
- My Net N750
* ZyXEL
- NBG6616
ar71xx-nand
-----------
* Aerohive
- HiveAP 121
* GL.iNet
- GL-AR300M
- GL-AR750S
- GL-XE300
* Netgear
- WNDR3700 (v4)
- WNDR4300 (v1)
ath79-mikrotik
* ZyXEL
- NBG6716
ar71xx-tiny [#deprecated]_ [#device-class-tiny]_
------------------------------------------------
* D-Link
- DIR-615 (C1)
* TP-Link
- TL-MR13U (v1)
- TL-MR3020 (v1)
- TL-MR3040 (v1, v2)
- TL-MR3220 (v1, v2)
- TL-MR3420 (v1, v2)
- TL-WA701N/ND (v1, v2)
- TL-WA730RE (v1)
- TL-WA750RE (v1)
- TL-WA801N/ND (v1, v2, v3)
- TL-WA830RE (v1, v2)
- TL-WA850RE (v1)
- TL-WA860RE (v1)
- TL-WA901N/ND (v1, v2, v3, v4, v5)
- TL-WA7210N (v2)
- TL-WA7510N (v1)
- TL-WR703N (v1)
- TL-WR710N (v2)
- TL-WR740N (v1, v3, v4, v5)
- TL-WR741N/ND (v1, v2, v4, v5)
- TL-WR743N/ND (v1, v2)
- TL-WR840N (v2)
- TL-WR841N/ND (v3, v5, v7, v8, v9, v10, v11, v12)
- TL-WR843N/ND (v1)
- TL-WR940N (v1, v2, v3, v4, v5, v6)
- TL-WR941ND (v2, v3, v4, v5, v6)
ath79-generic
--------------
* Mikrotik
* devolo
- RB951Ui-2nD (hAP)
- WiFi pro 1200e [#lan_as_wan]_
- WiFi pro 1200i
- WiFi pro 1750c
- WiFi pro 1750e [#lan_as_wan]_
- WiFi pro 1750i
- WiFi pro 1750x
* GL.iNet
- GL-AR300M-Lite
- GL-AR750S
* OCEDO
- Raccoon
* TP-Link
- Archer C6 (v2)
- CPE220 (v3.0)
brcm2708-bcm2708
----------------
@ -182,17 +225,12 @@ ipq40xx-generic
* Aruba
- AP-303
- AP-303H
- AP-365
- Instant On AP11
- Instant On AP11D
- Instant On AP17
* AVM
- FRITZ!Box 4040 [#avmflash]_
- FRITZ!Box 7520 (v1) [#eva_ramboot]_ [#lan_as_wan]_
- FRITZ!Box 7530 [#eva_ramboot]_ [#lan_as_wan]_
- FRITZ!Box 7530 [#eva_ramboot]_
- FRITZ!Repeater 1200 [#eva_ramboot]_
* EnGenius
@ -201,7 +239,6 @@ ipq40xx-generic
* GL.iNet
- GL-AP1300
- GL-B1300
* Linksys
@ -218,25 +255,11 @@ ipq40xx-generic
- A42
- A62
* Plasma Cloud
- PA1200
- PA2200
* ZyXEL
- NBG6617
- WRE6606 [#device-class-tiny]_
ipq40xx-mikrotik
----------------
* Mikrotik
- DISC Lite5 ac (RBDiscG-5acD)
- hAP ac2
- SXTsq 5 ac (RBSXTsqG-5acD)
ipq806x-generic
---------------
@ -247,10 +270,6 @@ ipq806x-generic
lantiq-xrx200
-------------
* Arcadyan
- VGV7510KW22 (o2 Box 6431)
* AVM
- FRITZ!Box 7360 (v1, v2) [#avmflash]_ [#lan_as_wan]_
@ -258,10 +277,6 @@ lantiq-xrx200
- FRITZ!Box 7362 SL [#eva_ramboot]_ [#lan_as_wan]_
- FRITZ!Box 7412 [#eva_ramboot]_
* TP-Link
- TD-W8970 (v1) [#lan_as_wan]_
lantiq-xway
-----------
@ -273,28 +288,9 @@ lantiq-xway
- DGN3500B [#lan_as_wan]_
mediatek-mt7622
mpc85xx-generic
---------------
* Linksys
- E8450
* Ubiquiti
- UniFi 6 LR
* Xiaomi
- AX3200 (RB03)
mpc85xx-p1010
-------------
* Sophos
- RED 15w Rev.1
* TP-Link
- TL-WDR4900 (v1)
@ -310,10 +306,6 @@ mpc85xx-p1020
- WS-AP3710i
* Extreme Networks
- WS-AP3825i
* OCEDO
- Panda
@ -321,10 +313,6 @@ mpc85xx-p1020
ramips-mt7620
-------------
* ASUS
- RT-AC51U
* GL.iNet
- GL-MT300A
@ -358,62 +346,25 @@ ramips-mt7621
- RT-AC57U
* Cudy
- WR1300 (v1)
- WR2100
- X6 (v1, v2)
* D-Link
- DAP-X1860 (A1)
- DIR-860L (B1)
* GL.iNet
- GL-MT1300
* Mercusys
- MR70X (v1)
* NETGEAR
- EX6150 (v1)
- R6220
- R6260
- WAC104
- WAX202
* TP-Link
- RE500 (v1)
- RE650 (v1)
* Ubiquiti
- EdgeRouter X
- EdgeRouter X-SFP
- UniFi 6 Lite
* Wavlink
- WS-WN572HP3 (4G)
* ZBT
- WG3526-16M
- WG3526-32M
* ZyXEL
- NWA50AX
* Xiaomi
- Xiaomi Mi Router 4A (Gigabit Edition)
- Xiaomi Mi Router 3G (v1, v2)
ramips-mt76x8
-------------
@ -424,24 +375,16 @@ ramips-mt76x8
* GL.iNet
- GL-MT300N (v2)
- microuter-N300
- VIXMINI
* NETGEAR
- R6020
- R6120
* RAVPower
- RP-WD009
* TP-Link
- Archer C20 (v4, v5)
- Archer C50 (v3, v4)
- RE200 (v2, v3)
- RE305 (v1) [#device-class-tiny]
- Archer C50 (v3)
- Archer C50 (v4)
- TL-MR3020 (v3)
- TL-MR3420 (v5)
- TL-WA801ND (v5)
@ -452,26 +395,18 @@ ramips-mt76x8
- VoCore2
* Xiaomi
ramips-rt305x [#deprecated]_ [#device-class-tiny]_
---------------------------------------------------
- Xiaomi Mi Router 4A (100M Edition)
- Xiaomi Mi Router 4A (100M International Edition)
- Xiaomi Mi Router 4C
realtek-rtl838x
---------------
* A5-V11
* D-Link
- DGS-1210-10P (F1)
- DIR-615 (D1, D2, D3, D4, H1)
rockchip-armv8
--------------
* VoCore
* FriendlyElec
- NanoPi R2S
- NanoPi R4S (4GB LPDDR4)
- VoCore (8M, 16M)
sunxi-cortexa7
--------------
@ -508,14 +443,18 @@ See also: :doc:`x86`
Footnotes
---------
.. [#deprecated]
The device or target is reaching its end of life soon. This means that support
in the next major release of Gluon is doubtful.
.. [#device-class-tiny]
These devices only support a subset of Gluons capabilities due to flash or memory
size constraints. Devices are classified as tiny if they provide less than 7M of usable
size constraints. Devices are classified as tiny in they provide less than 7M of usable
flash space or have a low amount of system memory. For more information, see the
developer documentation: :ref:`device-class-definition`.
.. [#avmflash]
For instructions on how to flash AVM devices, visit https://fritz-tools.readthedocs.io
For instructions on how to flash AVM devices, visit https://fritzfla.sh
.. [#eva_ramboot]
For instructions on how to flash AVM NAND devices, see the respective
@ -523,14 +462,3 @@ Footnotes
.. [#lan_as_wan]
All LAN ports on this device are used as WAN.
.. [#missing_radios]
This device contains more than two WLAN radios, which is currently
unsupported by Gluon. Only the first two radios will work.
.. [#modular_ethernet]
These devices follow a modular principle,
which means even basic functionality like ethernet is provided by an expansion-board,
that may not be bundled with the device itself.
Such expansions are recommended for the config mode, but are not strictly necessary,
as exposed serial ports may grant sufficient access as well.

View File

@ -15,7 +15,7 @@ The following targets for x86 images exist:
There are three images:
* `generic` (compressed "raw" image, can be written to a disk directly or booted with qemu)
* `generic` (compressed "raw" image, can written to a disk directly or booted with qemu)
* `virtualbox` (VDI image)
* `vmware` (VMDK image)

16
modules
View File

@ -1,16 +1,16 @@
GLUON_FEEDS='packages routing gluon'
OPENWRT_REPO=https://github.com/openwrt/openwrt.git
OPENWRT_BRANCH=openwrt-22.03
OPENWRT_COMMIT=e500494771537b9f42f78e4d907bed18b6383606
OPENWRT_BRANCH=openwrt-19.07
OPENWRT_COMMIT=29b4104d69bf91db17764dd885e9e111a373f08c
PACKAGES_PACKAGES_REPO=https://github.com/openwrt/packages.git
PACKAGES_PACKAGES_BRANCH=openwrt-22.03
PACKAGES_PACKAGES_COMMIT=55eed1761207f4dfdb8e7d79138f6f65c8849b50
PACKAGES_PACKAGES_BRANCH=openwrt-19.07
PACKAGES_PACKAGES_COMMIT=a2673dc53c4689798c1d70d7342cb3efadb0af74
PACKAGES_ROUTING_REPO=https://github.com/openwrt/routing.git
PACKAGES_ROUTING_BRANCH=openwrt-22.03
PACKAGES_ROUTING_COMMIT=1cc7676b9f32acc30ec47f15fcb70380d5d6ef01
PACKAGES_ROUTING_REPO=https://github.com/openwrt-routing/packages.git
PACKAGES_ROUTING_BRANCH=openwrt-19.07
PACKAGES_ROUTING_COMMIT=02b4dbfcb7b8f8b566940847d22d5a6f229d2e66
PACKAGES_GLUON_REPO=https://github.com/freifunk-gluon/packages.git
PACKAGES_GLUON_COMMIT=29912ec6308fd10b47763b4cf28a638d07f59973
PACKAGES_GLUON_COMMIT=12e41d0ff07ec54bbd67a31ab50d12ca04f2238c

View File

@ -16,12 +16,7 @@ when(_'web-wizard' and _'autoupdater', {
'gluon-config-mode-autoupdater',
})
when(_'web-wizard' and (
_'mesh-vpn-fastd' or
_'mesh-vpn-fastd-l2tp' or
_'mesh-vpn-tunneldigger' or
_'mesh-vpn-wireguard'
), {
when(_'web-wizard' and (_'mesh-vpn-fastd' or _'mesh-vpn-tunneldigger'), {
'gluon-config-mode-mesh-vpn',
})

View File

@ -1,6 +1,8 @@
include $(TOPDIR)/rules.mk
PKG_NAME:=gluon-alfred
PKG_VERSION:=1
PKG_RELEASE:=1
include ../gluon.mk

View File

@ -1,6 +1,7 @@
include $(TOPDIR)/rules.mk
PKG_NAME:=gluon-authorized-keys
PKG_VERSION:=2
include ../gluon.mk

Some files were not shown because too many files have changed in this diff Show More