221 lines
18 KiB
Markdown
221 lines
18 KiB
Markdown
# Call-Quality-Diagnose & Handoff — Christoph ↔ Geli Video-Calls
|
||
|
||
> **Zweck:** Self-contained Übergabe an eine separate Session. Enthält Symptom, **was bereits
|
||
> ausgeschlossen ist (mit Messdaten + zwei natürlichen Kontrollexperimenten)**, die leitende
|
||
> Hypothese und den Ausführungsplan.
|
||
> Stand: 2026-06-16 (**revidiert** nach Anamnese mit Christoph). Ursprünglich im Rahmen von „TP6"
|
||
> entstanden, das sich als **Nicht-QoS-Problem** entpuppt hat.
|
||
|
||
---
|
||
|
||
## TL;DR
|
||
**Video-Calls zwischen Christoph und Geli** (Telegram u.a.) ruckeln/droppen, **andere Calls nicht**.
|
||
Die zuerst vermutete **WLAN-Roaming-These ist auf Nebenfaktor herabgestuft.** Zwei natürliche
|
||
Kontrollexperimente verschieben den Verdacht klar auf die **Geli-seitige ISP-Strecke**:
|
||
- Christophs **nationale** Videocalls (vor Geli) liefen sauber → seine lokale Seite ist *nicht* die Wurzel.
|
||
- Geli wechselte **Cable/DSL → Fiber** (jetzt FB 5530 Fiber) → Problem **bleibt** → ihre Last-Mile-Bandbreite ist *nicht* die Wurzel.
|
||
|
||
→ **Leitende Hypothese:** Hochbitratiges Echtzeit-Video über die **AT↔Geli-Strecke** (kleiner Dorf-ISP
|
||
`on-isp.net` / AS202245 Geroldsgrün, **CGNAT**, vermutlich dünnes/abends überlastetes Auslands-Peering)
|
||
kippt unter schwer komprimierbarem Bild (**Gegenlicht/Dunkel → Bitraten-Spike**) in Loss/Jitter und
|
||
lässt die **Congestion-Control kollabieren**. Roaming/Handover ist additiver Nebenfaktor.
|
||
|
||
---
|
||
|
||
## Symptom (vollständig)
|
||
- Betroffen: **Christoph ↔ Geli**, **mehrere Messenger** (Telegram u.a.) → **nicht app-spezifisch**.
|
||
- **Geli-Calls = 99 % Video.** Christophs **nationale Videocalls vor Geli liefen problemlos** (gleicher
|
||
Upload, gleiches WLAN, gleiche Kamera). → starkes Kontrollexperiment für „nicht Christophs Seite".
|
||
- **Asymmetrie (Schlüssel):** Christoph ↔ andere = gut; Christoph ↔ Geli = schlecht. (Geli ↔ ihre
|
||
deutschen Freunde laut früherer Aussage ebenfalls gut.)
|
||
- **Licht-Abhängigkeit (Schlüssel):** Gehäuft bei **Dunkelheit**; **Gegenlicht bei Geli** (helles
|
||
Fenster, dunkler Rest) erzeugt sichtbare **Artefakte** auch tagsüber. → zeigt auf **Video-Bitrate**
|
||
(Sensorrauschen/Kontrast schwer komprimierbar), nicht auf Bewegung.
|
||
- **Bewegung** verschlechtert zusätzlich; **still sitzen = etwas besser, aber weiter mies**.
|
||
- **Congestion-Signatur:** **Neuer Call = schlagartig besser, dann „nächster Abbruch vorprogrammiert"**;
|
||
**Kamera aus/ein hilft**, solange es „noch nicht zu arg" ist. → klassisch **bandbreiten-/ratengebunden**
|
||
mit kollabierendem Bitraten-Schätzer, **nicht** sauberer Pfad mit zufälligem Paketverlust.
|
||
- **Jitter-/Burst-Signatur (neu, Schlüssel):** Stille **und/oder Standbild**, **verzerrter Ton („wie E-Gitarre")**,
|
||
danach **Turbo-Aufholen der letzten Gesprächsfetzen**. → Pakete werden **nicht nur verloren, sondern in
|
||
einem Buffer verzögert und stoßweise nachgeliefert** (Jitter/Queuing/Bufferbloat auf der Strecke).
|
||
E-Gitarre = Packet-Loss-Concealment des Codecs; Turbo-Catch-up = verspätet im Pulk angekommene Pakete.
|
||
- **Richtung GEKLÄRT (neu):** **Christoph hört/sieht Geli deutlich schlechter; Geli hat es mit Christoph seltener.**
|
||
→ dominanter Engpass = **Geli→Christoph**, also **Gelis Senderichtung (Upload)**.
|
||
- **WLAN-Korrelat bei Geli (neu):** schlechter mit **Distanz zum AP** und an **schlecht ausgeleuchteten Ecken** —
|
||
konkret **draußen auf der Bank an der dicken Hausmauer** (weit/abgeschirmt + dunkel = WLAN-Uplink *und* Bitrate gestresst).
|
||
- **WLAN-Architektur ist NICHT das Problem (neu, wichtig gegen Fehlfix):** Coverage gut, **keine Nachbar-WLANs**,
|
||
TX 100 %, Dual-Band. Der Engpass ist **nicht Design/Abdeckung**, sondern **Timing auf dem Uplink**:
|
||
(a) **Halb-Duplex/Airtime-Contention** (nur einer funkt zugleich; fallweise durch andere aktive Geräte, PS meist aus) → Jitter;
|
||
(b) **Retransmits** bei Distanz/Mauer/Bewegung → verspätet-im-Pulk = Jitter (Durchsatz sieht „ok" aus);
|
||
(c) **TX 100 % hilft nur Downstream** (AP→Handy) — der **Handy-Uplink** (Gelis ausgehendes Video) bleibt schwach,
|
||
v. a. hinter der dicken Mauer; (d) abgelesene **RSSI = Momentaufnahme**, verdeckt kurze **Spikes/Einbrüche**.
|
||
- **„Seit Fiber generell schlechter" (Geli, subjektiv) — Confound (neu):** mit dem Fiber-Umbau zog der Router um.
|
||
Die **PlayStation** (per WLAN, **aber regulär ausgeschaltet** → kein laufender Call-Contention-Faktor) hat **beim
|
||
Gaming Aussetzer** → bleibt als **Indiz für WLAN-Schwachstellen** an ihrem Standort, nicht als Dauer-Ursache.
|
||
„Fiber schlechter" = der **Umbau/Router-Standort**, nicht die Leitung.
|
||
- **Geräte-unabhängig (neu):** Geli Galaxy Note 10+ (test: A35), Christoph früher S22 → jetzt iPhone 16 Pro —
|
||
Problem über alle Wechsel hinweg → **nicht gerätespezifisch**.
|
||
- **„Nie das Bandbreitenlimit gesehen" (Christoph) — Mess-Caveat (neu):** FB-Charts zeigen **gemittelte (Mean-)Werte**;
|
||
die tödlichen **Sub-Sekunden-Microbursts** (Video-Spikes, WLAN-Retransmits) tauchen darin **nie** auf →
|
||
**kein Freispruch** für transiente Sättigung.
|
||
|
||
### Hardware-Timeline (beide Seiten, identische WLAN-Idee)
|
||
- **Christoph:** FB 6660 + 1 Repeater (OG, LAN-„Mesh") → **2× Cudy (2×2)**. ISP = Liwest (DOCSIS), Upload ~10 Mbit.
|
||
- **Geli:** FB 6660 + FRITZ-Repeater → Cudy → *(Glasfaser-Umstellung)* → **FB 5530 Fiber + Cudy**.
|
||
**APs = Cudy WR3600E** (Wi-Fi 6, Dual-Band 2.4+5 GHz), **TX 100 %**. ISP über alle Epochen konstant =
|
||
**`on-isp.net` / AS202245 Geroldsgrün**.
|
||
- **Gelis Anschluss (FB-5530-Settings, 2026-06-16):** **2.5↓ / 1.3↑ Gbit** (Bandbreite endgültig kein Faktor).
|
||
**IPv4 = CGNAT bestätigt:** WAN-IP `100.72.62.31` ∈ **100.64.0.0/10** (RFC 6598), außen `94.154.138.11`.
|
||
**IPv6 = nativ öffentlich:** Prefix `2a0e:7a02:31c:3000::/56`, **kein CGNAT auf v6** (Prefix rotiert ~30 h → DDNS nötig).
|
||
DNS = Quad9 (`2620:fe::fe:11`) + ISP-EDNS0 (`37.60.7.2`).
|
||
- **Christophs IPv6-Stand (Stand 2026-06-16, korrigiert):** **Liwest bietet KEIN natives IPv6** (techn. Support bestätigt).
|
||
Die **FritzBox macht 6to4** und annonciert ein **2002::-Prefix per RA ins VLAN1** → der **FB-nahe VLAN1-Host** hat damit
|
||
**(flatterhaftes) 6to4-v6**: `curl -6` zu ifconfig.co klappt (`2002:5638:c211:…`, eingeb. v4 86.56.194.17), aber
|
||
**`ping6` Google v6 = 100 % Loss** (Google-6to4-Relays abgeschaltet) = klassische 6to4-Teilerreichbarkeit.
|
||
**Intern NICHT durchgereicht:** Mac mini (VLAN20 hinter **ap1**) hat **kein v6** — ap1 macht **kein RA/DHCPv6-PD** auf den
|
||
VLANs (TP4 v4-only), **Branch-Switch (Omada) nicht v6-konfiguriert**, **Core-Switch (ALLNET) v6-Fähigkeit unklar**.
|
||
⚠️ **6to4 relay-abhängig/flatterhaft (empirisch: Google-ping scheitert) → KEINE Basis für Echtzeit-Medien.**
|
||
Saubere Alternative bei Bedarf: **6in4-Tunnelbroker** (Hurricane Electric, geroutetes /48). Details: Memory `project-ipv6-state`.
|
||
|
||
---
|
||
|
||
## Zwei natürliche Kontrollexperimente (das Rückgrat der Diagnose)
|
||
1. **Christophs nationale Videocalls = gut.** Damit sind bei *gleichem* Upload / WLAN / Kamera/Low-Light
|
||
ausgeschlossen: sein Upload, sein Roaming, seine Kamera-Bitrate **als Alleinursache**.
|
||
2. **Geli Cable/DSL → Fiber, Problem bleibt.** Damit ist Gelis **Last-Mile-Bandbreite** als Wurzel raus.
|
||
Was auf ihrer Seite konstant blieb: **derselbe Mini-ISP + CGNAT + die internationale Strecke** und die Cudy-WLAN.
|
||
|
||
→ Schnittmenge beider Experimente = die **Geli-seitige ISP-/Peering-/CGNAT-Strecke** als gemeinsamer Nenner.
|
||
|
||
---
|
||
|
||
## Was bereits AUSGESCHLOSSEN / herabgestuft ist
|
||
Messungen vom **Mac mini (Kabel, en0, VLAN20/INFRA, GW 10.40.20.1)**, 2026-06-16, **tagsüber im gesunden
|
||
Zustand** (deshalb sauber — der Mehrwert liegt im Mitschnitt **WÄHREND eines miesen Abend-Calls**).
|
||
|
||
| Hypothese | Befund | Urteil |
|
||
|---|---|---|
|
||
| Heim-Bufferbloat Christoph (Upload) | 3 Flows = 10.3 Mbit gesättigt → idle 12 ms, Vollast avg 17 / max 26 ms = A/A+ | ❌ kein Problem |
|
||
| Generischer AT→DE-Pfad | heise.de: 20.7 ms / Jitter 1.6 ms / 0 % Loss (40) | ❌ Pfad (tagsüber) top |
|
||
| Christoph → nächstes Telegram-DC | 149.154.167.50 (NL): 27 ms / Jitter 1.3 ms | ❌ Pfad (tagsüber) top |
|
||
| CAKE / QoS | kein Bufferbloat-Spielraum | ❌ **nicht deployt** (wäre marginal) |
|
||
| WARP / internat. Pfad | AT→DE tagsüber bereits 20 ms | ❌ **nicht deployt** |
|
||
| S2S-VPN-Tunnel (BF-FB ↔ Geli-FB WG) | Messenger = Cloud-Relay, nicht im Tunnel | ❌ **nicht im Call-Pfad** |
|
||
| Christophs lokale Seite (Upload/WLAN/Kamera) | **nationale Videocalls = gut** (Kontrollexp. 1) | ❌ keine Alleinursache |
|
||
| Gelis Last-Mile-**Bandbreite** | **Cable/DSL→Fiber, Problem bleibt** (Kontrollexp. 2) | ❌ nicht die Wurzel |
|
||
| **WLAN-Roaming/Handover** (ehem. Lead) | Cudy half *etwas*; still sitzen *etwas* besser, aber weiter mies; Hauptkorrelat ist **Licht**, nicht Bewegung | ⚠️ **Nebenfaktor**, nicht Wurzel |
|
||
| ~~Gelis CGNAT/Dorf-ISP durch Asymmetrie entlastet~~ | **VOID.** Gilt nur, wenn der Flaschenhals ihr *Access-Link* wäre. Sitzt er im **internat. Peering**, laufen Gelis *innerdeutsche* Calls nicht drüber → Asymmetrie bleibt erklärt | ⚠️ **wieder im Spiel** |
|
||
| Telegram-App-Bug/Codec | mehrere Messenger betroffen | ❌ entlastet |
|
||
| ~~Christoph WLAN -76 dBm auf `install-10`~~ | `install-10` = Testnetz, nicht produktiv | ⚠️ Fehlmessung, ignorieren |
|
||
|
||
---
|
||
|
||
## Leitende Hypothese: ratengebundenes Video über die Geli-Strecke
|
||
**Mechanik:** Echtzeit-Video-Congestion-Control (WebRTC/Telegram-artig) sucht die maximale Bitrate.
|
||
Schwer komprimierbares Bild (Gegenlicht/Dunkel → Sensorrauschen + Kontrast) treibt die **geforderte
|
||
Bitrate hoch**. Trifft das auf einen **engen/variablen Punkt der Geli-Strecke** (CGNAT-Session-Limit,
|
||
abends überlastetes Auslands-Peering eines Mini-AS), entstehen **Loss/Jitter**; der Bitraten-Schätzer
|
||
kollabiert und erholt sich nicht → genau das beobachtete „neuer Call kurz gut, dann Abbruch".
|
||
|
||
**Warum das alle Beobachtungen erklärt:**
|
||
| Beobachtung | Erklärung |
|
||
|---|---|
|
||
| Gegenlicht/Dunkel → Artefakte (auch tagsüber) | hohe Entropie → Bitraten-Spike → über den Engpass |
|
||
| „dunkel" gehäuft | Sensorrauschen **+** Abend-Peak-Last (dieselbe Richtung) |
|
||
| neuer Call kurz gut, dann Abbruch | Congestion-Control rampt in die Ratenwand, kollabiert, Reset hilft kurz |
|
||
| Kamera aus/ein hilft | senkt Bitrate → entlastet Engpass = bandbreitengebunden |
|
||
| nur mit Geli | nur dieser Pfad hat Mini-ISP + CGNAT + Auslands-Strecke; nationale Calls nicht |
|
||
| Roaming nur Nebenfaktor | „still = etwas besser, aber mies"; „Cudy half *etwas*" |
|
||
|
||
**Lokalisierung GEKLÄRT:** Christoph leidet stärker (hört/sieht Geli schlechter), Geli seltener →
|
||
Engpass sitzt dominant auf **Geli→Christoph = Gelis Senderichtung**. Innerhalb dieser Richtung ist die
|
||
Kette: **(1) Gelis WLAN-Uplink** (schwach an dicker Hausmauer/Distanz; Airtime nur fallweise, PS meist aus)
|
||
→ **(2) hohe Video-Bitrate** (Gegenlicht/Dunkel) → **(3) CGNAT/Auslands-Peering**
|
||
(abends). Die **Jitter-/Burst-Signatur** (verzögert-dann-stoßweise) zeigt: es ist primär **Queuing/Bufferbloat
|
||
auf dieser Senderichtung**, nicht reiner Random-Loss.
|
||
|
||
---
|
||
|
||
## Ausführungsplan (für die separate Session)
|
||
**Reihenfolge: erst beweisen, dann fixen.** Constraint: **passiv messen** während echter Calls
|
||
(„cave: verändert den Datenstrom"); **kein iperf/Sättigen** während eines laufenden Calls.
|
||
|
||
1. **Billige Sofort-Tests (heute Abend, ~0 €):**
|
||
- **Bitrate/Auflösung im Messenger deckeln** (z. B. Telegram-Datensparmodus) → wird's spürbar stabiler? = Mechanismus bestätigt.
|
||
- **Gelis Gegenlicht eliminieren** (Lampe von vorn, nicht Fenster im Rücken) → Artefakte weg/weniger?
|
||
- **Richtungstest:** beide notieren, wer wessen Aussetzer sieht (s. Lokalisierung oben).
|
||
|
||
2. **Messen — was lokalisiert wirklich? (wichtig: Sniffer-Grenze)**
|
||
- **Ein Call-Sniffer NUR auf Christophs Seite lokalisiert NICHT.** Was bei dir ankommt, hat Funk + ISP +
|
||
Transit bereits vermischt → zeigt nur das **Symptom** (eingehender Stream ruckelt/verliert, mit
|
||
Zeitstempel + Relay-IP), nicht **wo**. Verbleibende Unsicherheit = **Gelis Funk-Uplink vs. Gelis
|
||
ISP-Pfad** (≠ Fix!). Dafür braucht es einen Messpunkt **auf Gelis Seite**.
|
||
- **Remote machbar & aussagekräftig:** MTR/Ping-Log **Mac mini → Geli-FB `94.154.138.11`**, **abends
|
||
unter echter Call-Last vs. Tageswert** (22.2 ms / 0.88 ms / 0 % Loss). Degradiert der Pfad abends →
|
||
**ISP/Peering** schuld. Bleibt er sauber, Call trotzdem mies → Engpass liegt **in Gelis Funk/Relay**,
|
||
nicht im Transit. (Misst nur bis zur CGNAT-Grenze, nicht in ihr LAN.)
|
||
- **Auf Gelis Seite ohne Infra, nur per Handy:** **Bufferbloat-Test** (z. B. waveform.com/tools/bufferbloat)
|
||
auf **Gelis Handy abends** → zeigt direkt, ob **ihr Uplink unter Last aufbläht** (Latenz steigt) =
|
||
Anschluss/Funk. Einmalig, kein Setup.
|
||
- **A/B-Verhaltenstest (Handout) schlägt passives Sniffen:** ändert kontrolliert **eine** Variable
|
||
(nah am AP / gutes Licht / Audio-only / tags vs. abends) → lokalisiert besser, weil es Ursache *isoliert*.
|
||
- **Roaming nur sekundär:** Cudy-Stationen (RSSI/TX-RX/Retries/Assoc-Events) bei bewegtem Call —
|
||
Cudy ≠ MikroTik → kein MikroMCP; Cudy SSH+`iw station dump` rein lesend, falls möglich.
|
||
|
||
3. **Fix-Pfade (nach Lokalisierung) — Geli-Tal: nur dieser ISP oder schlechter Mobilfunk:**
|
||
- **(sofort, ISP-unabhängig)** Bitrate-Deckel (Telegram „weniger Daten") + **Ausleuchtung/kein Gegenlicht**
|
||
+ **Position nah am AP** + Calls eher **tagsüber** (Peak meiden) + **Audio-only** bei Bewegung.
|
||
- **(WLAN)** Zusätzlicher AP/nähere Funkstation an Gelis üblichem Call-Platz → stärkerer **Uplink** dort;
|
||
Band/Position so, dass das Handy nicht am fernen AP „klebt". TP3/CAPsMAN-802.11r adressiert den Roaming-Nebenfaktor.
|
||
- **(App/Codec)** **A/B mit anderem Dienst** (WhatsApp/Signal) abends — andere Congestion-Control kann auf
|
||
schlechtem Link robuster sein. Billiger Test, evtl. echter Gewinn. (FaceTime fällt aus: Geli = Android.)
|
||
- **(IPv6 — billigster Hebel, braucht NUR Gelis v6):** **Korrektur:** Telegram **unterstützt IPv6** (DCs dual-stack,
|
||
früher expliziter „Use IPv6"-Schalter); frühere Annahme „kann kein v6" war falsch. Die **schlechte Richtung
|
||
ist Geli→Christoph** (ihr Upload), erster Sprung = **Gelis Handy → Telegram-Reflector**. Geht *dieser* Leg über
|
||
v6, ist **Gelis CGNAT auf genau der kaputten Richtung umgangen** — das braucht **nur Gelis v6 (vorhanden),
|
||
NICHT Christophs**. Da ihre FB das LAN bereits mit v6 versorgt, **läuft das evtl. schon / ist 1 Schalter entfernt.**
|
||
**Verify (kein Ausbau):** auf Gelis Handy `test-ipv6.com` (Score) + Telegram-Daten-Einstellungen auf v6-Option prüfen.
|
||
**Offen/zu verifizieren:** ob aktuelle Clients den **VoIP-Reflector** über v6 ansprechen (Messaging-zu-DC = ja, Call-Reflector = wahrscheinlich).
|
||
**Caveat:** v6 umgeht nur die **CGNAT-Box**, NICHT das **Transit-Rohr** — bei Abend-Peering-Stau hilft v6 nicht.
|
||
- **(ISP-Intervention, falls Transit/Peering der Stau ist):** kleiner Lokal-ISP = eher erreichbar; Abend-Congestion
|
||
+ Peering nach AT schildern. CGNAT-Opt-out/öffentliche v4 nur nötig, falls v6-Weg nicht tragfähig.
|
||
- **(strukturell, TP10 — NUR Notnagel, kein Default):** eigener Medienpfad (WG-über-v6 FB↔ap1, dann self-hosted
|
||
Jitsi/SIP) **erst erwägen, wenn die Messung „Transit-Rohr" sagt** — also wenn auch v6 staut und der ISP nicht
|
||
hilft. Für den CGNAT-Fall **nicht nötig** (Gelis vorhandenes v6 reicht). ⚠️ **Christoph-seitig v6 blockiert**
|
||
(Liwest kein v6; 6to4 untauglich für RT-Medien) → bräuchte erst **6in4-Tunnelbroker (HE)** + DDNS für Gelis rotierendes /56.
|
||
|
||
---
|
||
|
||
## Benötigte Infos / Zugänge (von Christoph)
|
||
- **Richtung der Artefakte** (wer sieht wessen Aussetzer) — der wichtigste offene Fakt.
|
||
- **Cudy-Modell** + Zugangsweg (SSH/Web-UI/App, Creds) — für den sekundären Roaming-Check, beide Seiten.
|
||
- **Anruf-Gerät** (Handy/Modell) — Client-seitige Korrelation, Kamera/Codec-Verhalten bei Low-Light.
|
||
- Gelis **Fiber-Tarif** (Up/Down) + Bestätigung **weiterhin CGNAT** (`on-isp.net`).
|
||
|
||
## Constraints / Caveats
|
||
- **Passiv only** während echter Calls.
|
||
- **MikroMCP** verwaltet die **Cudys nicht**.
|
||
- **ap1 ist unverändert** — keine QoS-/Firewall-/Queue-Änderung appliziert (Details unten).
|
||
- Tagesmessungen waren sauber, **weil im gesunden Zustand** — nicht als Entlastung des Abend-Pfads werten.
|
||
|
||
## Zustand ap1 (zur Sicherheit dokumentiert — NICHTS wurde geändert)
|
||
- Keine Queues, kein CAKE. **Fasttrack `*8` weiter aktiv.** Keine neuen Mangle-Regeln.
|
||
- WAN-Egress aktuell = `bridge` → FB (10.40.41.254); masquerade `out-interface=bridge` (TP4).
|
||
- ether1-Direkt-WAN bleibt vorkonfiguriert/down (gated auf TP10).
|
||
|
||
## Querverweise
|
||
- **TP10** (VPN/CGNAT) — jetzt **aufgewertet**: Gelis FB `94.154.138.11:52727` (Fiber, CGNAT), AS202245
|
||
Geroldsgrün; Hub-Spoke auf ap1 (Geli wählt ausgehend ein, PersistentKeepalive ~25 s). Memory:
|
||
`project_ap_vpn_bridge_blocker.md`.
|
||
- **TP3** (WLAN/CAPsMAN, 802.11r/k/v) — Fix für den **Roaming-Nebenfaktor**, nicht die Wurzel.
|
||
- `docs/research/routeros-capabilities.md` — Fast-Roaming-Konzept.
|
||
|
||
## Messdaten-Anhang (Rohwerte 2026-06-16, Tageslicht/gesund)
|
||
- Upload-Sättigung Christoph: 3 Flows × ~430 KB/s = 1.28 MB/s = **10.3 Mbit** (sustained).
|
||
- Bufferbloat Christoph: idle 12 ms; Vollast avg 17.5 / max 26 ms (24 Pings).
|
||
- AT→heise.de: min 19.3 / avg 20.7 / max 27.6 / stddev 1.6 ms, 0 % Loss (40).
|
||
- AT→Telegram 149.154.167.50: avg 26.9 ms / stddev 1.3 ms (29/30); 91.108.56.130 = 173 ms (fernes DC, irrelevant).
|
||
- BF→Geli-FB 94.154.138.11: avg 22.2 / stddev 0.88 ms, 0 % Loss (30); rDNS `nat-3.aigbng02.bng.on-isp.net` = CGNAT.
|
||
⚠️ **Tageswert** — Referenz für den Abend-Vergleich, kein Freispruch.
|
||
- Testnetz-Client (VOID): `install-10`, 5 GHz, WPA3-PSK, -76 dBm — nicht das produktive Netz.
|