forked from freifunk-franken/docs
Compare commits
28 Commits
Author | SHA1 | Date |
---|---|---|
Johannes Kimmel | 9f60633600 | |
Johannes Kimmel | fdda93203d | |
Johannes Kimmel | 4a2f079935 | |
Johannes Kimmel | f3e83f5fe1 | |
Johannes Kimmel | 6d9f6ade8f | |
Johannes Kimmel | 2b18b02d41 | |
Fabian Bläse | 8bcb762965 | |
Fabian Bläse | 85fd2a1389 | |
Fabian Bläse | c8707e61fc | |
Fabian Bläse | d3ed8a4e20 | |
Johannes Kimmel | 81c82d26dc | |
Fabian Bläse | 8037ed74b1 | |
Johannes Kimmel | 6b56b1a9a9 | |
Johannes Kimmel | 99380b396f | |
Johannes Kimmel | fe4dfb9fe9 | |
Fabian Bläse | 1d3f71bcc4 | |
Johannes Kimmel | b5ec56d9d4 | |
Johannes Kimmel | 56550ee12e | |
Johannes Kimmel | 3ed483cabb | |
Fabian Bläse | dfcc88ab1f | |
Johannes Kimmel | 60dcf53a0e | |
Johannes Kimmel | c0d2e6c1c9 | |
Johannes Kimmel | ae04be72fb | |
Johannes Kimmel | a74cde38db | |
Fabian Bläse | 199e1a8450 | |
Johannes Kimmel | 6c7334385c | |
Fabian Bläse | f99fe536b5 | |
Fabian Bläse | 325ca42a21 |
|
@ -4,24 +4,24 @@ clone:
|
|||
settings:
|
||||
tags: true
|
||||
|
||||
pipeline:
|
||||
steps:
|
||||
version:
|
||||
image: klakegg/hugo:0.105.0-ext-alpine-ci
|
||||
image: ghcr.io/hugomods/hugo:go-git-0.125.7
|
||||
commands:
|
||||
- hugo version
|
||||
|
||||
build:
|
||||
image: klakegg/hugo:0.105.0-ext-alpine-ci
|
||||
image: ghcr.io/hugomods/hugo:go-git-0.125.7
|
||||
commands:
|
||||
- hugo --verbose --debug --printPathWarnings
|
||||
- hugo --logLevel debug --printPathWarnings
|
||||
|
||||
list-files:
|
||||
image: klakegg/hugo:0.105.0-ext-alpine-ci
|
||||
image: ghcr.io/hugomods/hugo:go-git-0.125.7
|
||||
commands:
|
||||
- ls -Rl public
|
||||
|
||||
deploy:
|
||||
image: klakegg/hugo:0.105.0-ext-alpine-ci
|
||||
image: ghcr.io/hugomods/hugo:go-git-0.125.7
|
||||
secrets:
|
||||
- BOT_PRIVATE_KEY
|
||||
commands:
|
||||
|
@ -32,4 +32,5 @@ pipeline:
|
|||
- chmod 0600 $HOME/.ssh/id_ed25519
|
||||
- rsync -a public/ "docs@git.freifunk-franken.de:"
|
||||
|
||||
branches: [ master ]
|
||||
when:
|
||||
branch: master
|
||||
|
|
10
README.md
10
README.md
|
@ -120,6 +120,16 @@ die Änderung nur aus einem Commit besteht kann man folgendermaßen vorgehen:
|
|||
|
||||
Bei komplizierteren Änderungen über mehrere Commits wird `git rebase` benötigt.
|
||||
|
||||
#### Vorschau
|
||||
|
||||
Für Pull Requests wird automatisch eine Vorschau gerendert. Wenn die Seite
|
||||
erfolgreich generiert werden kann, erscheint hinter dem Commit und auf der
|
||||
Seite vom Pull Request ein grüner Haken. Dort werden Details zum Buildprozess
|
||||
hinterlegt und ein Link zur Vorschau:
|
||||
|
||||
![Screenshot Vorschau Commit](preview_commit.png)
|
||||
![Screenshot Vorschau Pull Request](preview_pr.png)
|
||||
|
||||
### 2. Issue erstellen
|
||||
|
||||
Änderungen können auch über ein [issue] vorgeschlagen werden, falls die Arbeit
|
||||
|
|
|
@ -0,0 +1,46 @@
|
|||
html {
|
||||
scrollbar-gutter: stable;
|
||||
}
|
||||
|
||||
.book-page {
|
||||
box-shadow: 0 0 1.5rem rgba(0, 0, 0, 0.15);
|
||||
min-height: 100vh;
|
||||
padding-left: 2rem;
|
||||
padding-right: 2rem;
|
||||
}
|
||||
|
||||
.book-menu .book-menu-content {
|
||||
padding-right: 1.5rem;
|
||||
}
|
||||
|
||||
.book-toc .book-toc-content {
|
||||
padding-left: 1.5rem;
|
||||
}
|
||||
|
||||
.markdown h1 {
|
||||
font-weight: bold;
|
||||
}
|
||||
|
||||
.markdown h2 {
|
||||
margin-top: 1.5em;
|
||||
font-weight: bold;
|
||||
font-size: 1.7em;
|
||||
}
|
||||
|
||||
.markdown h3 {
|
||||
margin-top: 1.5em;
|
||||
font-weight: bold;
|
||||
font-size: 1.25em;
|
||||
}
|
||||
|
||||
.container {
|
||||
max-width: 90rem;
|
||||
}
|
||||
|
||||
summary:focus {
|
||||
outline: none;
|
||||
}
|
||||
|
||||
.markdown table th {
|
||||
background: var(--gray-100);
|
||||
}
|
|
@ -7,5 +7,5 @@ Auf dieser Seite findet sich eine Sammlung von Wissen und Anleitungen über Frei
|
|||
|
||||
<!--more-->
|
||||
|
||||
{{< section >}}
|
||||
{{< section summary >}}
|
||||
|
||||
|
|
|
@ -8,4 +8,3 @@ Alles zum Thema Freifunk Franken Firmware
|
|||
|
||||
<!--more-->
|
||||
|
||||
[Layer 3]({{< ref "layer3_config" >}})
|
||||
|
|
|
@ -1,22 +0,0 @@
|
|||
---
|
||||
title: "20220814"
|
||||
date: 2022-08-14T00:00:00+02:00
|
||||
---
|
||||
|
||||
https://dev.freifunk-franken.de/layer3/20220814/
|
||||
https://dev.freifunk-franken.de/node/20220814/
|
||||
|
||||
## Allgemeines
|
||||
- Update auf OpenWrt 21.02.3 (#261)
|
||||
- Leaflet (Positionsauswahl) aktualisiert (#242)
|
||||
- Update-Benachrichtigung überarbeitet (#244)
|
||||
|
||||
## node-Variante
|
||||
- Portkonfiguration ohne Reboot (#243)
|
||||
- Web-UI Portkonfiguration für Geräte mit zwei getrennten Interfaces gefixt (#259)
|
||||
|
||||
## layer3-Variante
|
||||
- Fehlerhaften bird2 Filter für `router_ip` überarbeitet (#255)
|
||||
- Zurückrollen der Änderungen nach Ablauf des Timers im Test-Mode gefixt (#260)
|
||||
|
||||
<!--more-->
|
|
@ -1,18 +0,0 @@
|
|||
---
|
||||
title: "20221019"
|
||||
date: 2022-10-19T00:00:00+02:00
|
||||
---
|
||||
|
||||
https://dev.freifunk-franken.de/layer3/20221019/
|
||||
https://dev.freifunk-franken.de/node/20221019/
|
||||
|
||||
- Update auf OpenWrt 21.02.5 ([#265](https://git.freifunk-franken.de/freifunk-franken/firmware/pulls/265))
|
||||
|
||||
Dieses Release enthält Fixes für die folgenden kürzlich bekannt gewordenen Schwachstellen im Linux Wireless Code:
|
||||
- `CVE-2022-41674`: fix u8 overflow in cfg80211\_update\_notlisted\_nontrans (max 256 byte overwrite) (RCE)
|
||||
- `CVE-2022-42719`: `wifi:` `mac80211:` fix MBSSID parsing use-after-free use after free condition (RCE)
|
||||
- `CVE-2022-42720`: `wifi:` `cfg80211:` fix BSS refcounting bugs ref counting use-after-free possibilities (RCE)
|
||||
- `CVE-2022-42721`: `wifi:` `cfg80211:` avoid nontransmitted BSS list corruption list corruption (DOS)
|
||||
- `CVE-2022-42722`: `wifi:` `mac80211:` fix crash in beacon protection for P2P-device NULL ptr dereference crash (DOS)
|
||||
|
||||
<!--more-->
|
|
@ -1,7 +0,0 @@
|
|||
---
|
||||
title: "Changelogs"
|
||||
bookCollapseSection: true
|
||||
date: 2022-11-18T17:17:51+01:00
|
||||
---
|
||||
|
||||
{{< section >}}
|
|
@ -1,6 +0,0 @@
|
|||
---
|
||||
title: "layer3 config"
|
||||
date: 2022-11-17T23:07:49+01:00
|
||||
---
|
||||
|
||||
<!--more-->
|
|
@ -0,0 +1,7 @@
|
|||
---
|
||||
title: "Hardware"
|
||||
bookCollapseSection: true
|
||||
date: 2022-12-01T17:25:00+01:00
|
||||
---
|
||||
|
||||
{{< section summary >}}
|
|
@ -0,0 +1,65 @@
|
|||
---
|
||||
title: "Mikrotik RB5009"
|
||||
date: 2023-12-21T15:46:00+01:00
|
||||
---
|
||||
|
||||
<!--more-->
|
||||
|
||||
## Installation
|
||||
|
||||
Die Anleitung ist größtenteils aus dem [OpenWrt Wiki](https://openwrt.org/toh/mikrotik/rb5009ug_s_in#installation_instructions_with_modified_routerboot) übernommen.
|
||||
|
||||
### Router vorbereiten
|
||||
- BOOTP Server + TFTP Server starten
|
||||
- `ip addr add 192.168.1.10/24 dev eth0`
|
||||
- `ip link set up dev eth0`
|
||||
- [Image](https://github.com/adron-s/openwrt-rb5009/releases/download/rb5009-20220209/openwrt-mvebu-cortexa72-mikrotik_rb5009-initramfs-fit-uImage.elf) herunterladen
|
||||
- Im Ordner, in den das Image heruntergeladen wurde:
|
||||
- `dnsmasq --no-daemon --listen-address 192.168.1.10 --bind-interfaces -p0 --dhcp-authoritative --dhcp-range=192.168.1.100,192.168.1.200 --bootp-dynamic --dhcp-boot=openwrt-mvebu-cortexa72-mikrotik_rb5009-initramfs-fit-uImage.elf --log-dhcp --enable-tftp --tftp-root=$(pwd)`
|
||||
- Computer in Port 1 (2.5G) stecken
|
||||
- Router im Netinstall Modus starten
|
||||
- Router mit gedrücktem Reset-Button (fest!) booten
|
||||
- Reset-Button gedrückt halten bis dnsmasq reagiert und einen BOOTP Lease verteilt
|
||||
- Nach erfolgreichem Boot (`dnsmasq-tftp: sent xyz to 192.168.1.108`) in LAN-Port 2 umstecken
|
||||
|
||||
### Backups erstellen
|
||||
Dieser Schritt ist unbedingt nötig, und die erzeugten Backups sollten unbedingt gut gespeichert werden,
|
||||
damit es später möglich ist wieder die Herstellersoftware zu flashen.
|
||||
```sh
|
||||
# aabbccddeeff durch die tatsächliche MAC Adresse des RB5009 ersetzen!
|
||||
# Der Vorgang dauert ca. 5 Minuten, da insgesamt über 1GB vom Router gelesen wird!
|
||||
|
||||
ssh root@192.168.1.1 'cat /dev/mtd?' | zstd > mtd.bin.zst
|
||||
ssh root@192.168.1.1 'cat /proc/mtd' > procmtd.txt
|
||||
tar -cf rb5009-aabbccddeeff.tar procmtd.txt mtd.bin.zst
|
||||
rm procmtd.txt mtd.bin.zst
|
||||
```
|
||||
|
||||
### RouterBOOT Bootloader anpassen
|
||||
- `wget https://github.com/adron-s/aux-loader2/raw/main/releases/2.xx-latest/rbt-with-aux-for-mtd5.bin`
|
||||
- `scp -O rbt-with-aux-for-mtd5.bin root@192.168.1.1:/tmp/`
|
||||
- Per SSH auf dem gebooteten OpenWrt einloggen: `ssh root@192.168.1.1`
|
||||
- `mtd write /tmp/rbt-with-aux-for-mtd5.bin RouterBOOT`
|
||||
- `echo cfg > /sys/firmware/mikrotik/soft_config/boot_device`
|
||||
- `echo 1 > /sys/firmware/mikrotik/soft_config/commit`
|
||||
|
||||
### Freifunk Firmware installieren
|
||||
- Firmware ("sysupgrade") per `scp -O` auf den Router nach `/tmp` kopieren
|
||||
- `sysupgrade -n /tmp/fff-*-mikrotik_rb5009-sysupgrade.bin`
|
||||
|
||||
## Ports für Layer3 Konfiguration
|
||||
|
||||
| Geräteport | Untagged | Tagged |
|
||||
|---------------|----------|---------|
|
||||
| SFP+ | `sfp:*` | `sfp:t` |
|
||||
| POE IN / 2.5G | `p1:*` | `p1:t` |
|
||||
| 2 | `p2:*` | `p2:t` |
|
||||
| 3 | `p3:*` | `p3:t` |
|
||||
| 4 | `p4:*` | `p4:t` |
|
||||
| 5 | `p5:*` | `p5:t` |
|
||||
| 6 | `p6:*` | `p6:t` |
|
||||
| 7 | `p7:*` | `p7:t` |
|
||||
| 8 | `p8:*` | `p8:t` |
|
||||
|
||||
## Links
|
||||
- [OpenWRT Wiki](https://openwrt.org/toh/mikrotik/rb5009ug_s_in)
|
|
@ -0,0 +1,109 @@
|
|||
---
|
||||
title: "Ubiquiti ER-X / ER-X-SFP / EP-R6"
|
||||
date: 2022-12-01T17:25:00+01:00
|
||||
---
|
||||
|
||||
<!--more-->
|
||||
|
||||
## Installation
|
||||
|
||||
### OpenWrt installieren
|
||||
|
||||
{{< hint info >}}
|
||||
Für den EP-R6 muss ein ausreichend aktuellen OpenWrt verwendet werden, damit die Installation per Web-UI funktioniert.
|
||||
{{< /hint >}}
|
||||
{{< hint info >}}
|
||||
Die Installation per TFTP funktioniert nur, wenn der TFTP-Modus über die serielle Konsole aktiviert wird.
|
||||
Der mit einem aktualisierten Bootloader hinzu gekommene TFTP-Modus per Reset-Button erwartet ein signiertes Image und funktioniert daher nicht.
|
||||
{{< /hint >}}
|
||||
|
||||
{{< tabs >}}
|
||||
{{< tab "Per Web-UI" >}}
|
||||
Für die Installation über das Hersteller Web-UI kann ein spezielles initramfs Image verwendet werden.
|
||||
Leider fehlt dieses Image in den OpenWrt Downloads, da die Standardkonfiguration zu groß ist.
|
||||
|
||||
Stattdessen kann dieses Image verwendet werden, um ein OpenWrt zu installieren: https://fw.sgstbr.de/tools/edgerouter-x/
|
||||
Die für dieses Image verwendete OpenWrt Version und Konfiguration findet sich ebenfalls auf dieser Seite.
|
||||
|
||||
- Web UI öffnen und einloggen
|
||||
- **Port:** `eth0`
|
||||
- **IP-Konfiguration:** statisch, `192.168.1.2/24`
|
||||
- **IP des Routers:** `192.168.1.1`
|
||||
- **User:** ubnt
|
||||
- **Passwort:** ubnt
|
||||
- Image hochladen und installieren
|
||||
{{< / tab >}}
|
||||
|
||||
{{< tab "Per TFTP" >}}
|
||||
Zunächst muss das OpenWrt initramfs heruntergeladen werden: `*-initramfs-kernel.bin`.
|
||||
Für OpenWrt 22.03.2:
|
||||
- [EdgeRouter X](https://downloads.openwrt.org/releases/22.03.2/targets/ramips/mt7621/openwrt-22.03.2-ramips-mt7621-ubnt_edgerouter-x-initramfs-kernel.bin)
|
||||
- [Edgerouter X SFP / EdgePoint R6](https://downloads.openwrt.org/releases/22.03.2/targets/ramips/mt7621/openwrt-22.03.2-ramips-mt7621-ubnt_edgerouter-x-sfp-initramfs-kernel.bin)
|
||||
|
||||
Das heruntergeladene Image booten (vgl. [OpenWrt Wiki](https://openwrt.org/inbox/toh/ubiquiti/ubiquiti_edgerouter_x_er-x_ka#serial_installation_with_tftp)):
|
||||
- Über serielle Konsole anschließen ([pinout](https://openwrt.org/toh/ubiquiti/edgerouter_x_er-x_ka#serial))
|
||||
- Während dem Booten die Option 1 auswählen
|
||||
- Das heruntergeladene `-initramfs-kernel.bin` per TFTP bereitstellen:
|
||||
```sh
|
||||
mkdir tftp
|
||||
cp ~/Downloads/*-initramfs-kernel.bin tftp/
|
||||
cd tftp
|
||||
sudo in.tftpd -l -L -s .
|
||||
```
|
||||
- Image per TFTP über eth0 booten (den Anweisungen des Bootloaders folgen)
|
||||
|
||||
Es ist nun ein OpenWrt gebootet, mit dem nun die Freifunk Firmware installiert werden kann.
|
||||
{{< / tab >}}
|
||||
{{< / tabs >}}
|
||||
|
||||
### Freifunk Firmware installieren
|
||||
Mit dem nun laufenden OpenWrt kann die Freifunk-Firmware über SSH geflasht werden.
|
||||
|
||||
{{< hint info >}}
|
||||
OpenWrt verwendet eine andere Portkonfiguration, daher muss jetzt auf den Port `eth1` gewechselt werden.
|
||||
{{< /hint >}}
|
||||
|
||||
- Über den Port `eth1` in OpenWrt einloggen
|
||||
- **Konfiguration des Laptops:** DHCP
|
||||
- **IP des Routers:** 192.168.1.1
|
||||
- **User:** root
|
||||
- Freifunk Firmware flashen
|
||||
```sh
|
||||
scp -O ~/Downloads/fff-firmware.bin root@192.168.1.1:/tmp/
|
||||
|
||||
ssh root@192.168.1.1
|
||||
# Wichtig: -n nicht vergessen!
|
||||
sysupgrade -n /tmp/fff-firmware.bin
|
||||
```
|
||||
|
||||
{{< hint info >}}
|
||||
Die Portbelegung des Routers ändert sich abermals, dieses mal auf den von Freifunk gewohnten Standard:
|
||||
- **eth0:** WAN
|
||||
- **eth1, eth2:** BATMAN (falls node-Firmware)
|
||||
- **eth3, eth4:** CLIENT
|
||||
{{< /hint >}}
|
||||
|
||||
|
||||
## Ports für Layer3 Konfiguration
|
||||
### ER-X
|
||||
|
||||
| Geräteport | Untagged | Tagged |
|
||||
|--------------|----------|----------|
|
||||
| eth0 | `eth0:*` | `eth0:t` |
|
||||
| eth1 | `eth1:*` | `eth1:t` |
|
||||
| eth2 | `eth2:*` | `eth2:t` |
|
||||
| eth3 | `eth3:*` | `eth3:t` |
|
||||
| eth4 | `eth4:*` | `eth4:t` |
|
||||
|
||||
### ER-X-SFP / EP-R6
|
||||
| Geräteport | Untagged | Tagged |
|
||||
|--------------|----------|----------|
|
||||
| eth0 | `eth0:*` | `eth0:t` |
|
||||
| eth1 | `eth1:*` | `eth1:t` |
|
||||
| eth2 | `eth2:*` | `eth2:t` |
|
||||
| eth3 | `eth3:*` | `eth3:t` |
|
||||
| eth4 | `eth4:*` | `eth4:t` |
|
||||
| eth5/SFP | `eth5:*` | `eth5:t` |
|
||||
|
||||
## Links
|
||||
- [OpenWRT Wiki](https://openwrt.org/toh/ubiquiti/edgerouter_x_er-x_ka)
|
|
@ -0,0 +1,130 @@
|
|||
---
|
||||
title: "Xiaomi Mi Router 4A"
|
||||
date: 2022-12-01T17:25:00+01:00
|
||||
---
|
||||
|
||||
<!--more-->
|
||||
|
||||
## Hardware unterscheiden
|
||||
{{< hint danger >}}
|
||||
Es gibt verschiedene Hardware-Varianten des Xiaomi Mi 4A, die sich teilweise signifikant unterscheiden.
|
||||
|
||||
Die Variante muss bei der Installation **zwingend** berücksichtigt werden, da die Firmwares nicht zueinander kompatibel sind.
|
||||
{{< /hint >}}
|
||||
|
||||
{{< details "**Xiaomi Mi 4A Gigabit**" >}}
|
||||
| Gerät | aktuell unterstützt |
|
||||
| -- |:--:|
|
||||
| Xiaomi Mi 4A Gigabit v1 (GigaDevice SPI-Flash) | ✅ |
|
||||
| Xiaomi Mi 4A Gigabit v1 (cFeon SPI-Flash) | ✅ |
|
||||
| Xiaomi Mi 4A Gigabit v2 | ❌ |
|
||||
|
||||
Die Revision des Board-Layouts lässt sich nach Ausnutzen des Exploits über den Befehl `ls /etc/Wireless` feststellen.
|
||||
- v1: `mt7603e mt7612`
|
||||
- v2: `mt7603e mt7663`
|
||||
|
||||
```sh
|
||||
root@XiaoQiang:~# ls /etc/Wireless
|
||||
mt7603e mt7612
|
||||
```
|
||||
|
||||
Ab Firmwareversion `20221201` werden beide Varianten des v1-Layouts vom selben Image unterstützt und müssen nicht unterschieden werden.
|
||||
Das v2-Layout wird aktuell nicht unterstützt. Solltest du ein Gerät mit v2-Layout erhalten haben, nimm bitte Kontakt mit den [Firmware-Entwicklern](mailto:franken-dev@freifunk.net) oder der [Community](https://wiki.freifunk-franken.de/w/Kommunikation) auf.
|
||||
{{< /details >}}
|
||||
|
||||
{{< details "**Xiaomi Mi 4A**" >}}
|
||||
| Gerät | aktuell unterstützt |
|
||||
| -- |:--:|
|
||||
| Xiaomi Mi 4A (100m) | ✅ |
|
||||
| Xiaomi Mi 4A (100m-intl) | ✅ |
|
||||
|
||||
Die Hardware beider Varianten ist identisch, allerdings wird die internationale Version mit einem anderen Partitionslayout ausgeliefert.
|
||||
|
||||
Die Revision des Board-Layouts lässt sich nach Ausnutzen des Exploits über den Befehl `cat /proc/mtd | grep mtd6` feststellen.
|
||||
- 100m: `mtd6: 00100000 00010000 “overlay”`
|
||||
- 100m-intl: `mtd6: 00200000 00010000 “overlay”`
|
||||
|
||||
```sh
|
||||
root@XiaoQiang:~# cat /proc/mtd | grep mtd6
|
||||
mtd6: 00200000 00010000 “overlay”
|
||||
```
|
||||
{{< /details >}}
|
||||
|
||||
|
||||
## Installation
|
||||
Zum Überschreiben der Herstellerfirmware ist ein Exploit des Web-UI nötig: https://github.com/acecilia/OpenWRTInvasion
|
||||
|
||||
**Videozusammenfassung** des Exploits: https://www.youtube.com/watch?v=VxzEvdDWU_s
|
||||
Die Videoanleitung sollte nur als zusätzliche Hilfestellung, nicht aber als Referenz genutzt werden!
|
||||
|
||||
### Router vorbereiten
|
||||
- Router mit dem Internet verbinden (wichtig, da beim Installationsvorgang zusätzliche Daten vom Router aus dem Internet geladen werden müssen!)
|
||||
- entweder über den WAN-Port
|
||||
- oder per WiFi Client (Modus "WiFi Access Point", hier ändert sich allerdings die IP Adresse des Web-UI!)
|
||||
- PC mit einem der beiden LAN-Ports verbinden, IPv4 Adresse per DHCP beziehen
|
||||
- Mit **192.168.31.1** verbinden und Setup-Assistenten durchlaufen
|
||||
- Stok auslesen: Im Web UI einloggen. Die URL in der Adresszeile beinhaltet etwas wie `stok#3700b146c87e45fea51170f87f47d34c`
|
||||
|
||||
### Exploit ausnutzen
|
||||
Hierfür kann auch der [Anleitung des OpenWRTInvasion Exploits](https://github.com/acecilia/OpenWRTInvasion) gefolgt werden.
|
||||
|
||||
Für **Windows** gibt es eine Dockervariante, die in der oben verlinkten Anleitung beschrieben wird.
|
||||
(nicht getestet)
|
||||
|
||||
- Git Repository klonen:
|
||||
```sh
|
||||
git clone https://github.com/acecilia/OpenWRTInvasion.git
|
||||
```
|
||||
- `python3-pip` installieren
|
||||
- Im geklonten Repository `./remote_command_execution_vulnerability.py` ausführen:
|
||||
```sh
|
||||
cd OpenWRTInvasion
|
||||
./remote_command_execution_vulnerability.py
|
||||
```
|
||||
- IP Adresse des Routers und stok (nur den Teil nach `stok#`) eingeben
|
||||
|
||||
### Firmware flashen
|
||||
- Mit `telnet` auf dem Router einloggen (**User:** root, **Passwort:** root):
|
||||
```sh
|
||||
telnet 192.168.31.1
|
||||
```
|
||||
- Ein OpenWrt oder Freifunk sysupgrade Image nach /tmp/firmware.bin kopieren
|
||||
- `openwrt-[version]-ramips-mt7621-xiaomi_mi-router-4a-gigabit-squashfs-sysupgrade.bin`
|
||||
- `fff-[variant]-[version]-xiaomi_mi-router-4a-gigabit-sysupgrade.bin`
|
||||
```sh
|
||||
cd /tmp
|
||||
wget -O firmware.bin <firmware-url>
|
||||
```
|
||||
- Prüfsumme berechnen:
|
||||
```sh
|
||||
./busybox sha256sum firmware.bin
|
||||
```
|
||||
- Installieren:
|
||||
```sh
|
||||
mtd -e OS1 -r write firmware.bin OS1
|
||||
```
|
||||
|
||||
## Ports für Layer3 Konfiguration
|
||||
### Xiaomi Mi 4A Gigabit Edition
|
||||
|
||||
| Geräteport | Untagged | Tagged |
|
||||
|------------|----------|----------|
|
||||
| Internet | `wan:*` | `wan:t` |
|
||||
| • | `lan1:*` | `lan1:t` |
|
||||
| •• | `lan2:*` | `lan2:t` |
|
||||
|
||||
### Xiaomi Mi 4A (100m/100m-intl)
|
||||
|
||||
{{< hint danger >}}
|
||||
Der Xiaomi Mi 4A (100m/100m-intl) hat noch keine Unterstützung für `DSA` und benutzt noch `swconfig` um die Ports zu konfigurieren.
|
||||
{{< /hint >}}
|
||||
|
||||
| Geräteport | Untagged | Tagged |
|
||||
|------------|----------|--------|
|
||||
| Internet | `0` | `0t` |
|
||||
| • | `2` | `2t` |
|
||||
| •• | `4` | `4t` |
|
||||
|
||||
## Links
|
||||
- [OpenWRT Wiki (Gigabit)](https://openwrt.org/inbox/toh/xiaomi/xiaomi_mi_router_4a_gigabit_edition)
|
||||
- [OpenWRT Wiki (100m)](https://openwrt.org/toh/xiaomi/mi_router_4a_mir4a_100m)
|
|
@ -1,6 +1,7 @@
|
|||
---
|
||||
title: "Kontakt"
|
||||
weight: 4
|
||||
draft: true
|
||||
date: 2022-11-18T01:11:28+01:00
|
||||
---
|
||||
|
||||
|
|
|
@ -8,4 +8,4 @@ date: 2022-11-17T23:31:38+01:00
|
|||
|
||||
<!--more-->
|
||||
|
||||
{{< section >}}
|
||||
{{< section summary >}}
|
||||
|
|
|
@ -3,15 +3,28 @@ title: "git.freifunk-franken.de"
|
|||
date: 2022-11-18T01:24:01+01:00
|
||||
---
|
||||
|
||||
Hauptseite wo die entwicklung unsere Firmware und verwandter Themen stattfindet
|
||||
Hauptseite, in der die Entwicklung unserer Firmware und verwandter Themen stattfindet.
|
||||
|
||||
<!--more-->
|
||||
|
||||
[git.freifunk-franken.de](https://git.freifunk-franken.de)
|
||||
|
||||
[gitea](https://gitea.io)
|
||||
Aktuell verwenden wir zur Verwaltung der git Repositories [gitea](https://gitea.io).
|
||||
|
||||
## Anmeldung
|
||||
|
||||
E-Mail an?
|
||||
[Kontakt]({{% relref kontakt %}})
|
||||
Um den Betrieb gegen Spam zu schützen erfolgt die Anmeldung nur auf Nachfrage. Um einen Account zu erstellen, nutzt einfach einen der folgenden Kanäle:
|
||||
|
||||
| Kanal | Link |
|
||||
|------------------------------:|:------------------------------------------------------------------------------------|
|
||||
| Matrix | [\#freifunk-franken:libera.chat](https://matrix.to/#/#freifunk-franken:libera.chat) |
|
||||
| IRC | `libera.chat/#freifunk-franken` |
|
||||
| Freifunk Franken Mailingliste | <franken@freifunk.net> |
|
||||
|
||||
Bitte nennt auch folgende Daten zur Accounterstellung:
|
||||
|
||||
1. Benutzername
|
||||
2. E-Mail Adresse
|
||||
|
||||
Wir senden euch dann so bald wie möglich eine E-Mail mit den Logindaten zu.
|
||||
|
||||
|
|
|
@ -7,4 +7,4 @@ Sammlung an Themen rund um die Technik und Konzepte im Freifunk Franken Netz
|
|||
|
||||
<!--more-->
|
||||
|
||||
{{< section >}}
|
||||
{{< section summary >}}
|
||||
|
|
|
@ -3,10 +3,16 @@ title: "Freifunk Franken Netz"
|
|||
date: 2022-11-18T00:10:23+01:00
|
||||
---
|
||||
|
||||
Überblick über das Freifunk Franken Netz und seine Technik
|
||||
Ein Überblick über das Freifunk Franken Netz und seine Technik.
|
||||
|
||||
<!--more-->
|
||||
|
||||
## Einleitung
|
||||
|
||||
Das Freifunk Franken Netz ist mittlerweile zu einem vielseitigem Netz gewachsen. Man hat viele Ansatzpunkte sich zu beteiligen, es ist aber manchmal nicht leicht zu wissen, wo und wie das möglich ist.
|
||||
|
||||
Im Folgenden soll daher auf der einen Seite eine Intuition vermittelt werden, wie das Netz im größeren Zusammenhang funktioniert und auf der anderen Seite gerade so genug Details geliefert werden, sodass man sich bei Interesse genauer in ein Teilbereich einarbeiten kann.
|
||||
|
||||
![Übersicht des Freifunk Franken Netz](netz.svg "Übersicht des Freifunk Franken Netz")
|
||||
|
||||
## Zentrale Hoods "V2"
|
||||
|
@ -29,7 +35,7 @@ Deshalb sind Hoods [geographisch begrenzt][hoods], um die Teilnehmerzahl in eine
|
|||
|
||||
Das **Gateway** ist grob gesagt die *Fritz!Box* für eine Hood.
|
||||
Gateways stehen bei uns gut angebunden in Rechenzentren, denn durch sie wird sämtlicher Traffic geleitet, der zu anderen Geräten im restlichen Freifunknetz, oder über unsere Borderrouter ins Internet soll.
|
||||
Sie sind damit der **zentrale** Router in Hood, die darüber hinaus auch einen DHCP Server, Konfiguration für die Knoten, Monitoring und vorallem die Verbindung zu unserem **Layer 3** Backbonenetz herstellen.
|
||||
Sie sind damit der **zentrale** Router in Hood, die darüber hinaus auch einen DHCP Server, Konfiguration für die Knoten, Monitoring und vor allem die Verbindung zu unserem **Layer 3** Backbonenetz herstellen.
|
||||
|
||||
### Szenario 2: "realistisch"
|
||||
|
||||
|
@ -42,8 +48,8 @@ Zusätzlich verfügen die meisten Geräte nicht über die passende Antennentechn
|
|||
Über die Zeit ist das Freifunknetz daher etwas zu einen Hotspotnetz verkommen, um bequem die Störerhaftung zu umgehen.
|
||||
Das ist nicht notwendigerweise schlimm oder schlecht, aber man hat sich dennoch etwas vom Wunschszenario entfernt.
|
||||
|
||||
Vorallem darf keine Verbindung zwischen benachbarten Knoten aus unterschiedlichen Hoods existieren (rote Linie zwischen **1** und **2**).
|
||||
Es würden zwei sonst getrennte Netze gemischt und Knoten fehlkonfiguriert, da eine Verbindung zu mehrere Gatways mit unterschiedlicher Konfiguration besteht.
|
||||
Vor allem darf keine Verbindung zwischen benachbarten Knoten aus unterschiedlichen Hoods existieren (rote Linie zwischen **1** und **2**).
|
||||
Es würden zwei sonst getrennte Netze gemischt und Knoten fehlkonfiguriert, da eine Verbindung zu mehrere Gateways mit unterschiedlicher Konfiguration besteht.
|
||||
Die Firmware unterbindet daher solche Verbindungen.
|
||||
|
||||
![Fehlerhafte Verbindung zwischen zwei Freifunkknoten aus unterschiedlichen Hoods](hoods_fehler.svg "Fehlerhafte Verbindung zwischen zwei Freifunkknoten aus unterschiedlichen Hoods")
|
||||
|
@ -134,50 +140,37 @@ Auch die Hood als ganzes könnte durch den höheren Resourcenverbrauch beeinträ
|
|||
Dank 60GHz Hardware bedeutet das mittlerweile bezahlbare Gigabit Geschwindigkeiten.
|
||||
Mehr ist dazu auch nicht zu sagen :)
|
||||
|
||||
---
|
||||
# TODO
|
||||
## Einleitung
|
||||
## Zusammenfassung
|
||||
|
||||
- weniger Details, dafür mehr Überblick
|
||||
- eher als Sprungbrett zu einzelnen Themen gedacht
|
||||
- Entscheidungshilfe Node vs L3
|
||||
- weniger als Nachschlagewerk gedacht, dafür hoffentlich roter Faden erkennbar
|
||||
- ertragbare Länge
|
||||
### Welche Firmware ist die richtige? **Node** oder **Layer 3**?
|
||||
|
||||
## Welche Firmware?
|
||||
Beide Firmwareversionen, **Node** und **Layer 3**, haben ihre Vorteile (+) und Nachteile (-):
|
||||
|
||||
- Einfache Auswahlkriterien
|
||||
- Noch einmal **kurz** Vor- und Nachteile auflisten
|
||||
| | Node | Layer3 |
|
||||
|-----------------------------------|:----:|:------:|
|
||||
| Konfigurationsaufwand | + | - |
|
||||
| Automatisches Wifi Mesh + Roaming | + | - |
|
||||
| Performance | - | + |
|
||||
| Flexibilität Peering | - | + |
|
||||
| Flexibilität Hardware | - | + |
|
||||
| Aufwand Firmwareentwicklung | - | + |
|
||||
| Aufwand Gateways | - | + |
|
||||
|
||||
| | Node | Layer3 |
|
||||
|---|:-:|:-:|
|
||||
| Konfiguration | + | - |
|
||||
| Automatisches Wifi Mesh + Roaming | + | - |
|
||||
| Performance | - | + |
|
||||
| Flexibilität Peering | - | + |
|
||||
| Flexibilität Hardware | - | + |
|
||||
| Aufwand Firmwareentwicklung | - | + |
|
||||
| Aufwand Gateways | - | + |
|
||||
| ... | ... | ... |
|
||||
#### Node
|
||||
|
||||
## Glossar
|
||||
- Fußnoten[^Layer3]?
|
||||
- tauchen nicht in der TOC auf
|
||||
- Position nicht steuerbar
|
||||
- sollte allerdings überall gehen
|
||||
- Links zu Headern? [Beispiel](#Beispiel) zu [Fußnoten](#Fußnoten)
|
||||
- Abhängig vom Markdownprocessor
|
||||
- Hedgedoc erzeugt eventuell andere IDs als gitea oder hugo
|
||||
Der Konfigurationsaufwand bei der Node Firmware ist kleiner. Man muss sich nicht um IPs kümmern und durch das automatische Meshen ist es auch nicht nötig einen Peering Partner zu suchen.
|
||||
|
||||
### Beispiel
|
||||
Auf gleicher Hardware wird man üblicherweise kleinere Geschwindigkeiten als mit der Layer 3 Firmware erzielen.
|
||||
|
||||
### Fußnoten
|
||||
Aus technischer Sicht ist die Node Firmware deutlich komplizierter aufgebaut und benötigt außerdem mit den Gateways zusätzliche Infrastruktur. Das macht sie in der Entwicklung zeitaufwendiger und im Betrieb gelegentlich auch weniger stabil.
|
||||
|
||||
[^Layer3]: **Layer3**
|
||||
usw
|
||||
Dafür muss sich der Betreiber, abgesehen von Name, Kontaktadresse und Position, um keine weitere Konfiguration kümmern.
|
||||
|
||||
## Bemerkungen / FAQs
|
||||
- Layer 3 Technik ist unabhängig von Freifunk Franken
|
||||
#### Layer 3
|
||||
|
||||
Die Konfiguration bei der Layer 3 Firmware gestaltet sich aus unterschiedlichen Gründen etwas schwieriger als bei der Node Firmware. Es fehlt aktuell an einer einfachen Eingabemöglichkeit für alle Funktionen, sodass die Konfiguration über die Konsole mit `ssh` geschehen muss. Für die Profis kein Problem - für jemanden, der das noch nie gesehen hat, kann das eine große Hürde sein.
|
||||
|
||||
Leider kann nicht alles "wegautomatisiert" werden. Wer gezielt Richtfunk und Tunnel aufbauen möchte, muss diese Peerings der Firmware auch irgendwie mitteilen. Wer seine IPs fest vergeben möchte muss sich auch darum kümmern und eintragen. Die höhere Flexibilität bezahlt man also mit etwas mehr Handarbeit. Je nach Ansicht kann dies natürlich Vor- und Nachteil sein.
|
||||
|
||||
[batman]: https://www.open-mesh.org/projects/batman-adv/wiki "B.A.T.M.A.N Advanced"
|
||||
[fastd]: https://github.com/NeoRaider/fastd "fastd"
|
||||
|
@ -191,19 +184,3 @@ usw
|
|||
[BGP]: https://en.wikipedia.org/wiki/Border_Gateway_Protocol
|
||||
[Wireguard]: https://www.wireguard.com/
|
||||
[GRE]: https://en.wikipedia.org/wiki/Generic_Routing_Encapsulation
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
|
|
@ -7,7 +7,7 @@ Einblick in die Technik der node-firmware
|
|||
|
||||
<!--more-->
|
||||
|
||||
{{< section >}}
|
||||
{{< section summary >}}
|
||||
|
||||
|
||||
|
||||
|
|
|
@ -24,15 +24,13 @@ Es lassen sich auch sehr günstige Gateways realisieren, die mehrere Hoods perfo
|
|||
## Konzept
|
||||
|
||||
Die Daten für den VXLAN-Tunnel erhält der Router mit dem Hoodfile. Ein entsprechender `vpn` Eintrag muss vorhanden sein:
|
||||
```
|
||||
---
|
||||
```json
|
||||
"vpn": [
|
||||
{
|
||||
"protocol": "vxlan",
|
||||
"address": "gateway.url"
|
||||
}
|
||||
],
|
||||
---
|
||||
```
|
||||
|
||||
Der Router konfiguriert damit ein VXLAN Interface `vxlan0` als weiteres batman-adv Interface.
|
||||
|
@ -50,7 +48,7 @@ Auf den Gateways wird die jeweilige VXLAN Gegenstelle konfiguriert und ebenfalls
|
|||
Zum Testen `http://rl-fff1.fff.community/v2/` als keyserver eintragen. Man findet den Eintrag in der Datei
|
||||
|
||||
`/usr/lib/functions/fff/hoodfile`
|
||||
```
|
||||
```bash
|
||||
echo "Getting hoodfile from Keyserver"
|
||||
|
||||
if /bin/busybox wget -T15 -O "$file" "http://rl-fff1.fff.community/v2/?lat=$lat&long=$long"; then
|
||||
|
|
|
@ -13,11 +13,26 @@ Technik, um HTTPS Verbindungen weiterzuleiten, ohne die Verschlüsselung aufzubr
|
|||
|
||||
<https://de.wikipedia.org/wiki/Server_Name_Indication>
|
||||
|
||||
---
|
||||
## Anwendung: HTTPS Website im Freifunk hosten
|
||||
|
||||
## TLS Handshake
|
||||
Innerhalb des Freifunk Netzes war es schon immer recht simpel Websites zu hosten. Dank IPv6 und wie es im Freifunk Franken Netz umgesetzt ist, kann jeder sogar globale IPv6 Adressen nutzen. Man ist also weltweit per IPv6 erreichbar. Damit ist es einfach auch von einem kleinen Computer zuhause Services im Internet bereit zu stellen, ohne einen Server mieten zu müssen. Leider ist man gelegentlich trotzdem zusätzlich auf Erreichbarkeit via IPv4 angewiesen. Im Freifunk Franken Netz haben wir allerdings nur eine sehr begrenzte Anzahl an IPv4 Adressen und können daher nicht jedem Nutzer eine globale Adresse zur Verfügung stellen.
|
||||
|
||||
Wireshark mitschnitt beim Verbindungsaufbau nach <https://wiki.freifunk-franken.de>
|
||||
Mit dem [SNI Proxy]({{% relref "sni.fff.community.md" %}}), wie er auf [sni.fff.community][] betrieben wird, kann man seine IPv6-only Websites auch für IPv4-only Geräte verfügbar machen, indem man:
|
||||
|
||||
1. einen `AAAA` DNS Eintrag vom eigenen Webservice auf die gewünschte IPv6 Adresse setzt
|
||||
2. für den `A` DNS Eintrag die IPv4 Adresse wählt, wie sie auf der Anleitung von [sni.fff.community][] steht
|
||||
|
||||
Der Service hat eine öffentlich zugängliche IPv4 Adresse und kann dadurch IPv4 Verbindungen entgegen nehmen.
|
||||
|
||||
Der SNI Proxy inspiziert die ersten Bytes und ermittelt welcher Hostname angesprochen ist. Der Proxy baut dann eine Verbindung via IPv6 zu dem Webserver auf und leitet dann sämtliche Bytes zwischen Client und Server einfach weiter. Dabei wird keine Verschlüsselung aufgebrochen. Dadurch funktioniert insbesondere auch der Betrieb mit [Let's Encrypt Certificates](https://letsencrypt.org/) und Ende-zu-Ende Verschlüsselung bleibt erhalten.
|
||||
|
||||
## Funktionsweise im Detail
|
||||
|
||||
### TLS Handshake
|
||||
|
||||
Der Proxy macht sich zu Nutze, dass selbst bei einer verschlüsselten Verbindung via HTTPS häufig der Zielhostname in Klartext übermittelt wird (SNI: Server Name Indication).
|
||||
|
||||
Hier ein gekürzter Wireshark Mitschnitt beim Verbindungsaufbau nach <https://wiki.freifunk-franken.de>
|
||||
|
||||
```
|
||||
...
|
||||
|
@ -34,9 +49,9 @@ Transport Layer Security
|
|||
...
|
||||
```
|
||||
|
||||
Die aufgerufene Domain wird selbst bei `https://` im Klartext übertragen!
|
||||
### IPv6
|
||||
|
||||
## IPv6
|
||||
Sind Client und Server IPv6-fähig passiert der Verbindungsaufbau ganz normal direkt über IPv6 ohne extra Proxy.
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
|
@ -45,12 +60,14 @@ sequenceDiagram
|
|||
participant DNS
|
||||
|
||||
client ->>+ DNS: AAAA? example.com
|
||||
DNS -->>- client: 2001:db8::
|
||||
DNS -->>- client: 2001:db8:1::
|
||||
client ->>+ srv: https://example.com
|
||||
srv -->- client: Connection
|
||||
```
|
||||
|
||||
## IPv4
|
||||
### IPv4
|
||||
|
||||
Für einen IPv4-only Client und einem IPv6-only Server sieht es folgendermaßen aus: Der Client fragt die IPv4 Adresse vom Zielhost ab und bekommt die IPv4 Adresse vom SNI Proxy geliefert. Der Client baut sodann die Verbindung mit dem SNI Proxy auf und übermittelt dabei beim TLS Handshake das eigentliche Ziel. Der SNI Proxy fragt dann die IPv6 Adresse vom Server ab und stellt eine Verbindung her. Die bereits vom Client übertragenen Bytes werden einfach dorthin kopiert und die Antworten vom Server zurück in Verbindung zum Client gegeben.
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
|
@ -69,7 +86,11 @@ sequenceDiagram
|
|||
deactivate sni
|
||||
```
|
||||
|
||||
## NAT46 Mode
|
||||
### NAT46 Mode
|
||||
|
||||
Als Erweiterung kann der SNI Proxy noch die Adresse anpassen, mit der die Verbindungen zu den Servern aufgebaut wird. Das ist sinnvoll, damit aus der Sicht vom Server nicht alle Clients von der selben IPv6 kommen. Damit lassen sich also im Notfall auch Firewall regeln bauen, sollte aus einem bestimmten IP Bereich vermehrt Angriffe kommen. Man muss also nicht gleich sämtlichen Verkehr vom SNI Proxy sperren.
|
||||
|
||||
Dazu bettet der SNI Proxy die 4 Bytes aus der Adresse vom Client in die unteren Bytes der IPv6 Adresse mit der der SNI Proxy die Verbindung aufbaut:
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
|
@ -83,6 +104,6 @@ sequenceDiagram
|
|||
deactivate sni
|
||||
```
|
||||
|
||||
## Beispiel Hosting im Freifunk
|
||||
Im Beispiel hat der Client die IP `192.0.2.1`. Diese 4 Bytes entsprechen `c000:201` in IPv6 Hexadezimalschreibweise. Zum SNI Proxy selber wird nicht nur eine IPv6 Adresse, sondern ein ganzen `/96` Netz geroutet. Damit sind genug Adressen vorhanden, um das ganze IPv4 Internet in IPv6 Adressen einzubetten. Der SNI Proxy erzeugt die Adresse, indem er an das Prefix `2001:db8:2::/96` noch die übrigen 4 Bytes mit der Client Adresse auffüllt. Das ergibt dann die Adresse `2001:db8:2::c000:201`, die für die Verbindung benutzt wird.
|
||||
|
||||
- https://rmon.bareminimum.eu
|
||||
[sni.fff.community]: https://sni.fff.community "Anleitung für den SNI Proxy"
|
||||
|
|
2
go.mod
2
go.mod
|
@ -2,4 +2,4 @@ module git.freifunk-franken.de/freifunk-franken/docs
|
|||
|
||||
go 1.19
|
||||
|
||||
require github.com/alex-shpak/hugo-book v0.0.0-20221111100854-d5b75f4fb3aa // indirect
|
||||
require github.com/alex-shpak/hugo-book v0.0.0-20240413091959-f8a0fc4e246c // indirect
|
||||
|
|
4
go.sum
4
go.sum
|
@ -1,2 +1,2 @@
|
|||
github.com/alex-shpak/hugo-book v0.0.0-20221111100854-d5b75f4fb3aa h1:VthswmcR+7NtpamidIRuFq+8JRAz4v+s7xVJ0MmeLqM=
|
||||
github.com/alex-shpak/hugo-book v0.0.0-20221111100854-d5b75f4fb3aa/go.mod h1:L4NMyzbn15fpLIpmmtDg9ZFFyTZzw87/lk7M2bMQ7ds=
|
||||
github.com/alex-shpak/hugo-book v0.0.0-20240413091959-f8a0fc4e246c h1:NB5qoQkSUWrr70ZUXqLHpStDBQ5fA/g9yGB3eCuYfkU=
|
||||
github.com/alex-shpak/hugo-book v0.0.0-20240413091959-f8a0fc4e246c/go.mod h1:L4NMyzbn15fpLIpmmtDg9ZFFyTZzw87/lk7M2bMQ7ds=
|
||||
|
|
Binary file not shown.
After Width: | Height: | Size: 33 KiB |
Binary file not shown.
After Width: | Height: | Size: 42 KiB |
Loading…
Reference in New Issue