Hi,
auf der Website [1] steht eine Liste an freizugebenden Ports. Diese Liste ist aber fuer uns nicht ausreichend. Die zu kleine Anzahl freigegebener Ports wird uns Probleme machen wenn wir das Netz aufsplitten bzw. alternative Tunnel- Methoden probieren. Zwar stimmt es schon, dass udp/10000–10003 momentan hauptsaetzlich genutzt wird, aber vorgesehen ist:
* udp/10000–10099 fuer fastd * udp/11000-11099 fuer tunneldigger/L2TPv3
Ich weiss, dass die Angaben jetzt erstmal nach viel klingen, aber die 4 Ports auf der Website reichen nicht aus. Definitiv geplant sind ~40 verschiedene Ports pro VPN-Server+Tunnel-Methode und der Rest ist erstmal fuer moegliche Erweiterungen enthalten. Weitere Aenderung an den benoetigten Ports behalten wir uns vor.
Auf Knoten, die sich selber als "Uplink" in der nodes.json eingetragen hatten, wurde eine UDP Verbindung Richtung VPN04 Port 10099 getestet. Die Ergebnisse lauten wie folgt:
Uplink-Knoten welche zu stark gefiltert werden: ===============================================
* https://vogtland.freifunk.net/map/#!v:m;n:60e327c73940 PL-Breitscheid81-Balkon * https://vogtland.freifunk.net/map/#!v:m;n:00e04c6801b8 PL-Nobel5-Matsch * https://vogtland.freifunk.net/map/#!v:m;n:00199967a208 PL-Raedel7-Offloader * https://vogtland.freifunk.net/map/#!v:m;n:f09fc2e41ce8 RC-Bahnhof23A-DG * https://vogtland.freifunk.net/map/#!v:m;n:687251687401 RC-Markt * https://vogtland.freifunk.net/map/#!v:m;n:f4f26ddd6d2a RC-Markt1 * https://vogtland.freifunk.net/map/#!v:m;n:18a6f76e1556 RC-Markt7 * https://vogtland.freifunk.net/map/#!v:m;n:6872516a24ac RC-Rossplatz13-Stadtwerke * https://vogtland.freifunk.net/map/#!v:m;n:6872516a267d RC-Rossplatz13-Stadtwerke2 * https://vogtland.freifunk.net/map/#!v:m;n:ac8674001040 TR-NeueG7
Nach aktuellen Stand wuerden diese Knoten sich nicht mehr direkt mit dem Server verbinden, wenn das Netz fuer den Split vorbereitet wird (und danach).
Ungetestet (da nicht erreichbar bzw. Zugang gesperrt bei PL-Kleist): ====================================================================
* https://vogtland.freifunk.net/map/#!v:m;n:f4f26d68369e AE-Altmarkt4-Glueckscafe * https://vogtland.freifunk.net/map/#!v:m;n:50c7bf20a45c FST-RosaLuxemburg10-HavannaBar * https://vogtland.freifunk.net/map/#!v:m;n:10feede608b2 LE-Irfersgrüner13-Landhandel * https://vogtland.freifunk.net/map/#!v:m;n:6872516432fe MKN-Wirtsgrundweg19a-01 * https://vogtland.freifunk.net/map/#!v:m;n:a42bb0c7b0c6 MTL-Kirchberg8-Dornroeschenturm * https://vogtland.freifunk.net/map/#!v:m;n:a42bb0c7b366 MTL-Kirchberg8-Rapunzelturm * https://vogtland.freifunk.net/map/#!v:m;n:18d6c786fbbc N-Brockauer28 * https://vogtland.freifunk.net/map/#!v:m;n:f4f26dc1f7c8 NE-AmBuehl4-Sporrer * https://vogtland.freifunk.net/map/#!v:m;n:f4f26dc1f9a2 PL-Gneisenau31 * https://vogtland.freifunk.net/map/#!v:m;n:647002ded076 PL-Hans-Sachs-49-AlteKaffeeroesterei * https://vogtland.freifunk.net/map/#!v:m;n:ec086bb82652 PL-Kleist * https://vogtland.freifunk.net/map/#!v:m;n:14cc203b1952 PL-Kleist-Test * https://vogtland.freifunk.net/map/#!v:m;n:98ded08887de POE-Bahnhof21 * https://vogtland.freifunk.net/map/#!v:m;n:18d6c753ccb0 POE-Haupt50-BistroAnkerplatz * https://vogtland.freifunk.net/map/#!v:m;n:f4f26d6836c0 TR-Auerbacher3-Curry31 * https://vogtland.freifunk.net/map/#!v:m;n:18d6c753cf53 TR-Goldene-Hoehe-3-Saal * https://vogtland.freifunk.net/map/#!v:m;n:a0f3c15b4376 TR-Mobil * https://vogtland.freifunk.net/map/#!v:m;n:ec086bb532ac TR-Pfarr19-AK
Die komplette Liste der der bisher betrachten Knoten ist angehangen.
Gruesse, Sven
[1] https://vogtland.freifunk.net/firewall-port-freigaben-und-ziel-adressen/
Hi,
auf der Website [1] steht eine Liste an freizugebenden Ports. [1] https://vogtland.freifunk.net/firewall-port-freigaben-und-ziel-adressen/
da steht auch (wohl als Fallback?), fast eine IPv6-Adresse da, die müsste allerdings statt 2003:49:a051:9000:42 richtigerweise 2003:49:a051:9000::42 lauten (mit zwei Doppelpunkten hintereinander)
Carsten
Hi,
On Sonntag, 10. Juni 2018 14:53:04 CEST Sven Eckelmann via Freifunk_info wrote:
auf der Website [1] steht eine Liste an freizugebenden Ports. Diese Liste ist aber fuer uns nicht ausreichend. Die zu kleine Anzahl freigegebener Ports wird uns Probleme machen wenn wir das Netz aufsplitten bzw. alternative Tunnel- Methoden probieren. Zwar stimmt es schon, dass udp/10000–10003 momentan hauptsaetzlich genutzt wird, aber vorgesehen ist:
- udp/10000–10099 fuer fastd
- udp/11000-11099 fuer tunneldigger/L2TPv3
koennten die Aenderung der genutzten Ports bitte auf der Website angepasst werden:
* https://vogtland.freifunk.net/freifunk-router-an-fritzbox-per-gaeste-lan/ * https://vogtland.freifunk.net/firewall-port-freigaben-und-ziel-adressen/
Auch die korrekte Angabe der Firmware-IPv6-Adresse (wie Carsten meinte) waere gut.
[...]
Ungetestet (da nicht erreichbar bzw. Zugang gesperrt bei PL-Kleist):
[...]
Von den nicht erreichten Knoten konnte bisher geklaert werden, dass folgende den UDP-Port 10099 nicht filtern:
* https://vogtland.freifunk.net/map/#!v:m;n:f4f26d68369e AE-Altmarkt4-Glueckscafe * https://vogtland.freifunk.net/map/#!v:m;n:50c7bf20a45c FST-RosaLuxemburg10-HavannaBar * https://vogtland.freifunk.net/map/#!v:m;n:10feede608b2 LE-Irfersgrüner13-Landhandel * https://vogtland.freifunk.net/map/#!v:m;n:a42bb0c7b0c6 MTL-Kirchberg8-Dornroeschenturm * https://vogtland.freifunk.net/map/#!v:m;n:a42bb0c7b366 MTL-Kirchberg8-Rapunzelturm * https://vogtland.freifunk.net/map/#!v:m;n:f4f26dc1f9a2 PL-Gneisenau31 * https://vogtland.freifunk.net/map/#!v:m;n:647002ded076 PL-Hans-Sachs-49-AlteKaffeeroesterei * https://vogtland.freifunk.net/map/#!v:m;n:18d6c753ccb0 POE-Haupt50-BistroAnkerplatz * https://vogtland.freifunk.net/map/#!v:m;n:f4f26d6836c0 TR-Auerbacher3-Curry31 * https://vogtland.freifunk.net/map/#!v:m;n:18d6c753cf53 TR-Goldene-Hoehe-3-Saal * https://vogtland.freifunk.net/map/#!v:m;n:ec086bb532ac TR-Pfarr19-AK
Damit sind folgende weiterhin ungeklaert:
* https://vogtland.freifunk.net/map/#!v:m;n:6872516432fe MKN-Wirtsgrundweg19a-01 * https://vogtland.freifunk.net/map/#!v:m;n:18d6c786fbbc N-Brockauer28 * https://vogtland.freifunk.net/map/#!v:m;n:f4f26dc1f7c8 NE-AmBuehl4-Sporrer * https://vogtland.freifunk.net/map/#!v:m;n:ec086bb82652 PL-Kleist * https://vogtland.freifunk.net/map/#!v:m;n:14cc203b1952 PL-Kleist-Test * https://vogtland.freifunk.net/map/#!v:m;n:98ded08887de POE-Bahnhof21 * https://vogtland.freifunk.net/map/#!v:m;n:a0f3c15b4376 TR-Mobil
Port Filter behoben ===================
* https://vogtland.freifunk.net/map/#!v:m;n:ac8674001040 TR-NeueG7
Damit gilt weiterhin
Uplink-Knoten welche zu stark gefiltert werden: ===============================================
* https://vogtland.freifunk.net/map/#!v:m;n:60e327c73940 PL-Breitscheid81-Balkon * https://vogtland.freifunk.net/map/#!v:m;n:00e04c6801b8 PL-Nobel5-Matsch * https://vogtland.freifunk.net/map/#!v:m;n:00199967a208 PL-Raedel7-Offloader * https://vogtland.freifunk.net/map/#!v:m;n:f09fc2e41ce8 RC-Bahnhof23A-DG * https://vogtland.freifunk.net/map/#!v:m;n:687251687401 RC-Markt * https://vogtland.freifunk.net/map/#!v:m;n:f4f26ddd6d2a RC-Markt1 * https://vogtland.freifunk.net/map/#!v:m;n:18a6f76e1556 RC-Markt7 * https://vogtland.freifunk.net/map/#!v:m;n:6872516a24ac RC-Rossplatz13-Stadtwerke * https://vogtland.freifunk.net/map/#!v:m;n:6872516a267d RC-Rossplatz13-Stadtwerke2
Nach aktuellen Stand wuerden diese Knoten sich nicht mehr direkt mit dem Server verbinden, wenn das Netz fuer den Split vorbereitet wird (und danach).
Gruesse, Sven
Hallo Sven,
Ja, Webseite aktualisiere ich noch. Hab es nur noch nicht geschafft.
Meine Portfreigabe auch (PL-Raedel..).
Danke!
André
Outlook for Android herunterladen
On Fri, Jun 15, 2018 at 10:21 PM +0200, "Sven Eckelmann via Freifunk_info" freifunk_info@freifunk-vogtland.net wrote:
Hi,
On Sonntag, 10. Juni 2018 14:53:04 CEST Sven Eckelmann via Freifunk_info wrote:
auf der Website [1] steht eine Liste an freizugebenden Ports. Diese Liste ist aber fuer uns nicht ausreichend. Die zu kleine Anzahl freigegebener Ports wird uns Probleme machen wenn wir das Netz aufsplitten bzw. alternative Tunnel- Methoden probieren. Zwar stimmt es schon, dass udp/10000–10003 momentan hauptsaetzlich genutzt wird, aber vorgesehen ist:
- udp/10000–10099 fuer fastd
- udp/11000-11099 fuer tunneldigger/L2TPv3
koennten die Aenderung der genutzten Ports bitte auf der Website angepasst werden:
* https://vogtland.freifunk.net/freifunk-router-an-fritzbox-per-gaeste-lan/ * https://vogtland.freifunk.net/firewall-port-freigaben-und-ziel-adressen/
Auch die korrekte Angabe der Firmware-IPv6-Adresse (wie Carsten meinte) waere gut.
[...]
Ungetestet (da nicht erreichbar bzw. Zugang gesperrt bei PL-Kleist):
[...]
Von den nicht erreichten Knoten konnte bisher geklaert werden, dass folgende den UDP-Port 10099 nicht filtern:
* https://vogtland.freifunk.net/map/#!v:m;n:f4f26d68369e AE-Altmarkt4-Glueckscafe * https://vogtland.freifunk.net/map/#!v:m;n:50c7bf20a45c FST-RosaLuxemburg10-HavannaBar * https://vogtland.freifunk.net/map/#!v:m;n:10feede608b2 LE-Irfersgrüner13-Landhandel * https://vogtland.freifunk.net/map/#!v:m;n:a42bb0c7b0c6 MTL-Kirchberg8-Dornroeschenturm * https://vogtland.freifunk.net/map/#!v:m;n:a42bb0c7b366 MTL-Kirchberg8-Rapunzelturm * https://vogtland.freifunk.net/map/#!v:m;n:f4f26dc1f9a2 PL-Gneisenau31 * https://vogtland.freifunk.net/map/#!v:m;n:647002ded076 PL-Hans-Sachs-49-AlteKaffeeroesterei * https://vogtland.freifunk.net/map/#!v:m;n:18d6c753ccb0 POE-Haupt50-BistroAnkerplatz * https://vogtland.freifunk.net/map/#!v:m;n:f4f26d6836c0 TR-Auerbacher3-Curry31 * https://vogtland.freifunk.net/map/#!v:m;n:18d6c753cf53 TR-Goldene-Hoehe-3-Saal * https://vogtland.freifunk.net/map/#!v:m;n:ec086bb532ac TR-Pfarr19-AK
Damit sind folgende weiterhin ungeklaert:
* https://vogtland.freifunk.net/map/#!v:m;n:6872516432fe MKN-Wirtsgrundweg19a-01 * https://vogtland.freifunk.net/map/#!v:m;n:18d6c786fbbc N-Brockauer28 * https://vogtland.freifunk.net/map/#!v:m;n:f4f26dc1f7c8 NE-AmBuehl4-Sporrer * https://vogtland.freifunk.net/map/#!v:m;n:ec086bb82652 PL-Kleist * https://vogtland.freifunk.net/map/#!v:m;n:14cc203b1952 PL-Kleist-Test * https://vogtland.freifunk.net/map/#!v:m;n:98ded08887de POE-Bahnhof21 * https://vogtland.freifunk.net/map/#!v:m;n:a0f3c15b4376 TR-Mobil
Port Filter behoben ===================
* https://vogtland.freifunk.net/map/#!v:m;n:ac8674001040 TR-NeueG7
Damit gilt weiterhin
Uplink-Knoten welche zu stark gefiltert werden: ===============================================
* https://vogtland.freifunk.net/map/#!v:m;n:60e327c73940 PL-Breitscheid81-Balkon * https://vogtland.freifunk.net/map/#!v:m;n:00e04c6801b8 PL-Nobel5-Matsch * https://vogtland.freifunk.net/map/#!v:m;n:00199967a208 PL-Raedel7-Offloader * https://vogtland.freifunk.net/map/#!v:m;n:f09fc2e41ce8 RC-Bahnhof23A-DG * https://vogtland.freifunk.net/map/#!v:m;n:687251687401 RC-Markt * https://vogtland.freifunk.net/map/#!v:m;n:f4f26ddd6d2a RC-Markt1 * https://vogtland.freifunk.net/map/#!v:m;n:18a6f76e1556 RC-Markt7 * https://vogtland.freifunk.net/map/#!v:m;n:6872516a24ac RC-Rossplatz13-Stadtwerke * https://vogtland.freifunk.net/map/#!v:m;n:6872516a267d RC-Rossplatz13-Stadtwerke2
Nach aktuellen Stand wuerden diese Knoten sich nicht mehr direkt mit dem Server verbinden, wenn das Netz fuer den Split vorbereitet wird (und danach).
Gruesse, Sven
Upps
Hier sind ja ein paar Knoten dabei wonach aktiv werden muss.
Um die hier kümmere ich mich:
* map/#!v:m;n:f09fc2e41ce8 https://vogtland.freifunk.net/map/#!v:m;n:f09fc2e41ce8 RC-Bahnhof23A-DG * https://vogtland.freifunk.net/map/#!v:m;n:687251687401 RC-Markt * https://vogtland.freifunk.net/map/#!v:m;n:f4f26ddd6d2a RC-Markt1 * https://vogtland.freifunk.net/map/#!v:m;n:18a6f76e1556 RC-Markt
Für die stadtwerke-Knoten in RC kann ich an die richtigen Leute mal eine E-Mail schreiben oder mal anrufen.
Es grüßt der Jo
andre.fiedler--- via Freifunk_info freifunk_info@freifunk-vogtland.net schrieb am Fr. 15. Juni 2018 um 23:11:
Hallo Sven,
Ja, Webseite aktualisiere ich noch. Hab es nur noch nicht geschafft.
Meine Portfreigabe auch (PL-Raedel..).
Danke! André
Outlook for Android https://aka.ms/ghei36 herunterladen
On Fri, Jun 15, 2018 at 10:21 PM +0200, "Sven Eckelmann via Freifunk_info" freifunk_info@freifunk-vogtland.net wrote:
Hi,
On Sonntag, 10. Juni 2018 14:53:04 CEST Sven Eckelmann via Freifunk_info wrote:
auf der Website [1] steht eine Liste an freizugebenden Ports. Diese Liste ist aber fuer uns nicht ausreichend. Die zu kleine Anzahl freigegebener Ports wird uns Probleme machen wenn wir das Netz aufsplitten bzw. alternative Tunnel- Methoden probieren. Zwar stimmt es schon, dass udp/10000–10003 momentan hauptsaetzlich genutzt wird, aber vorgesehen ist:
- udp/10000–10099 fuer fastd
- udp/11000-11099 fuer tunneldigger/L2TPv3
koennten die Aenderung der genutzten Ports bitte auf der Website angepasst werden:
- https://vogtland.freifunk.net/freifunk-router-an-fritzbox-per-gaeste-lan/
- https://vogtland.freifunk.net/firewall-port-freigaben-und-ziel-adressen/
Auch die korrekte Angabe der Firmware-IPv6-Adresse (wie Carsten meinte) waere gut.
[...]
Ungetestet (da nicht erreichbar bzw. Zugang gesperrt bei PL-Kleist):
[...]
Von den nicht erreichten Knoten konnte bisher geklaert werden, dass folgende den UDP-Port 10099 nicht filtern:
- https://vogtland.freifunk.net/map/#!v:m;n:f4f26d68369e AE-Altmarkt4-Glueckscafe
- https://vogtland.freifunk.net/map/#!v:m;n:50c7bf20a45c FST-RosaLuxemburg10-HavannaBar
- https://vogtland.freifunk.net/map/#!v:m;n:10feede608b2 LE-Irfersgrüner13-Landhandel
- https://vogtland.freifunk.net/map/#!v:m;n:a42bb0c7b0c6 MTL-Kirchberg8-Dornroeschenturm
- https://vogtland.freifunk.net/map/#!v:m;n:a42bb0c7b366 MTL-Kirchberg8-Rapunzelturm
- https://vogtland.freifunk.net/map/#!v:m;n:f4f26dc1f9a2 PL-Gneisenau31
- https://vogtland.freifunk.net/map/#!v:m;n:647002ded076 PL-Hans-Sachs-49-AlteKaffeeroesterei
- https://vogtland.freifunk.net/map/#!v:m;n:18d6c753ccb0 POE-Haupt50-BistroAnkerplatz
- https://vogtland.freifunk.net/map/#!v:m;n:f4f26d6836c0 TR-Auerbacher3-Curry31
- https://vogtland.freifunk.net/map/#!v:m;n:18d6c753cf53 TR-Goldene-Hoehe-3-Saal
- https://vogtland.freifunk.net/map/#!v:m;n:ec086bb532ac TR-Pfarr19-AK
Damit sind folgende weiterhin ungeklaert:
- https://vogtland.freifunk.net/map/#!v:m;n:6872516432fe MKN-Wirtsgrundweg19a-01
- https://vogtland.freifunk.net/map/#!v:m;n:18d6c786fbbc N-Brockauer28
- https://vogtland.freifunk.net/map/#!v:m;n:f4f26dc1f7c8 NE-AmBuehl4-Sporrer
- https://vogtland.freifunk.net/map/#!v:m;n:ec086bb82652 PL-Kleist
- https://vogtland.freifunk.net/map/#!v:m;n:14cc203b1952 PL-Kleist-Test
- https://vogtland.freifunk.net/map/#!v:m;n:98ded08887de POE-Bahnhof21
- https://vogtland.freifunk.net/map/#!v:m;n:a0f3c15b4376 TR-Mobil
Port Filter behoben
Damit gilt weiterhin
Uplink-Knoten welche zu stark gefiltert werden:
- https://vogtland.freifunk.net/map/#!v:m;n:60e327c73940 PL-Breitscheid81-Balkon
- https://vogtland.freifunk.net/map/#!v:m;n:00e04c6801b8 PL-Nobel5-Matsch
- https://vogtland.freifunk.net/map/#!v:m;n:00199967a208 PL-Raedel7-Offloader
- https://vogtland.freifunk.net/map/#!v:m;n:f09fc2e41ce8 RC-Bahnhof23A-DG
- https://vogtland.freifunk.net/map/#!v:m;n:687251687401 RC-Markt
- https://vogtland.freifunk.net/map/#!v:m;n:f4f26ddd6d2a RC-Markt1
- https://vogtland.freifunk.net/map/#!v:m;n:18a6f76e1556 RC-Markt7
- https://vogtland.freifunk.net/map/#!v:m;n:6872516a24ac RC-Rossplatz13-Stadtwerke
- https://vogtland.freifunk.net/map/#!v:m;n:6872516a267d RC-Rossplatz13-Stadtwerke2
Nach aktuellen Stand wuerden diese Knoten sich nicht mehr direkt mit dem Server verbinden, wenn das Netz fuer den Split vorbereitet wird (und danach).
Gruesse, Sven
Freifunk_info mailing list Freifunk_info@freifunk-vogtland.net https://mx.hateotu.de/mailman/listinfo/freifunk_info
Hi Sven,
* udp/10000–10099 fuer fastd * udp/11000-11099 fuer tunneldigger/L2TPv3
koennten die Aenderung der genutzten Ports bitte auf der Website angepasst werden:
* https://vogtland.freifunk.net/freifunk-router-an-fritzbox-per-gaeste-lan/ * https://vogtland.freifunk.net/firewall-port-freigaben-und-ziel-adressen/
Auch die korrekte Angabe der Firmware-IPv6-Adresse (wie Carsten meinte) waere gut. Wurde aktualisiert.
Uplink-Knoten welche zu stark gefiltert werden: ===============================================
* https://vogtland.freifunk.net/map/#!v:m;n:00199967a208%C2%A0PL-Raedel7-Offlo...
Wurde ebenfalls aktualisiert.
VG, André
Am 15. Juni 2018 um 22:21 schrieb Sven Eckelmann via Freifunk_info freifunk_info@freifunk-vogtland.net:
Hi,
On Sonntag, 10. Juni 2018 14:53:04 CEST Sven Eckelmann via Freifunk_info wrote: auf der Website [1] steht eine Liste an freizugebenden Ports. Diese Liste ist aber fuer uns nicht ausreichend. Die zu kleine Anzahl freigegebener Ports wird uns Probleme machen wenn wir das Netz aufsplitten bzw. alternative Tunnel- Methoden probieren. Zwar stimmt es schon, dass udp/10000–10003 momentan hauptsaetzlich genutzt wird, aber vorgesehen ist:
* udp/10000–10099 fuer fastd * udp/11000-11099 fuer tunneldigger/L2TPv3
koennten die Aenderung der genutzten Ports bitte auf der Website angepasst werden:
* https://vogtland.freifunk.net/freifunk-router-an-fritzbox-per-gaeste-lan/ * https://vogtland.freifunk.net/firewall-port-freigaben-und-ziel-adressen/
Auch die korrekte Angabe der Firmware-IPv6-Adresse (wie Carsten meinte) waere gut.
[...] Ungetestet (da nicht erreichbar bzw. Zugang gesperrt bei PL-Kleist): ==================================================================== [...]
Von den nicht erreichten Knoten konnte bisher geklaert werden, dass folgende den UDP-Port 10099 nicht filtern:
* https://vogtland.freifunk.net/map/#!v:m;n:f4f26d68369e AE-Altmarkt4-Glueckscafe * https://vogtland.freifunk.net/map/#!v:m;n:50c7bf20a45c FST-RosaLuxemburg10-HavannaBar * https://vogtland.freifunk.net/map/#!v:m;n:10feede608b2 LE-Irfersgrüner13-Landhandel * https://vogtland.freifunk.net/map/#!v:m;n:a42bb0c7b0c6 MTL-Kirchberg8-Dornroeschenturm * https://vogtland.freifunk.net/map/#!v:m;n:a42bb0c7b366 MTL-Kirchberg8-Rapunzelturm * https://vogtland.freifunk.net/map/#!v:m;n:f4f26dc1f9a2 PL-Gneisenau31 * https://vogtland.freifunk.net/map/#!v:m;n:647002ded076 PL-Hans-Sachs-49-AlteKaffeeroesterei * https://vogtland.freifunk.net/map/#!v:m;n:18d6c753ccb0 POE-Haupt50-BistroAnkerplatz * https://vogtland.freifunk.net/map/#!v:m;n:f4f26d6836c0 TR-Auerbacher3-Curry31 * https://vogtland.freifunk.net/map/#!v:m;n:18d6c753cf53 TR-Goldene-Hoehe-3-Saal * https://vogtland.freifunk.net/map/#!v:m;n:ec086bb532ac TR-Pfarr19-AK
Damit sind folgende weiterhin ungeklaert:
* https://vogtland.freifunk.net/map/#!v:m;n:6872516432fe MKN-Wirtsgrundweg19a-01 * https://vogtland.freifunk.net/map/#!v:m;n:18d6c786fbbc N-Brockauer28 * https://vogtland.freifunk.net/map/#!v:m;n:f4f26dc1f7c8 NE-AmBuehl4-Sporrer * https://vogtland.freifunk.net/map/#!v:m;n:ec086bb82652 PL-Kleist * https://vogtland.freifunk.net/map/#!v:m;n:14cc203b1952 PL-Kleist-Test * https://vogtland.freifunk.net/map/#!v:m;n:98ded08887de POE-Bahnhof21 * https://vogtland.freifunk.net/map/#!v:m;n:a0f3c15b4376 TR-Mobil
Port Filter behoben ===================
* https://vogtland.freifunk.net/map/#!v:m;n:ac8674001040 TR-NeueG7
Damit gilt weiterhin
Uplink-Knoten welche zu stark gefiltert werden: ===============================================
* https://vogtland.freifunk.net/map/#!v:m;n:60e327c73940 PL-Breitscheid81-Balkon * https://vogtland.freifunk.net/map/#!v:m;n:00e04c6801b8 PL-Nobel5-Matsch * https://vogtland.freifunk.net/map/#!v:m;n:00199967a208 PL-Raedel7-Offloader * https://vogtland.freifunk.net/map/#!v:m;n:f09fc2e41ce8 RC-Bahnhof23A-DG * https://vogtland.freifunk.net/map/#!v:m;n:687251687401 RC-Markt * https://vogtland.freifunk.net/map/#!v:m;n:f4f26ddd6d2a RC-Markt1 * https://vogtland.freifunk.net/map/#!v:m;n:18a6f76e1556 RC-Markt7 * https://vogtland.freifunk.net/map/#!v:m;n:6872516a24ac RC-Rossplatz13-Stadtwerke * https://vogtland.freifunk.net/map/#!v:m;n:6872516a267d RC-Rossplatz13-Stadtwerke2
Nach aktuellen Stand wuerden diese Knoten sich nicht mehr direkt mit dem Server verbinden, wenn das Netz fuer den Split vorbereitet wird (und danach).
Gruesse, Sven _______________________________________________ Freifunk_info mailing list Freifunk_info@freifunk-vogtland.net https://mx.hateotu.de/mailman/listinfo/freifunk_info
On Sonntag, 17. Juni 2018 00:26:45 CEST André Fiedler via Freifunk_info wrote:
- udp/10000–10099 fuer fastd
- udp/11000-11099 fuer tunneldigger/L2TPv3
koennten die Aenderung der genutzten Ports bitte auf der Website angepasst werden:
- https://vogtland.freifunk.net/freifunk-router-an-fritzbox-per-gaeste-lan/
- https://vogtland.freifunk.net/firewall-port-freigaben-und-ziel-adressen/
Auch die korrekte Angabe der Firmware-IPv6-Adresse (wie Carsten meinte) waere gut.
Wurde aktualisiert.
Danke.
Gruesse, Sven
Hi,
Am Sat, 16 Jun 2018 22:26:45 +0000 (GMT) schrieb André Fiedler via Freifunk_info freifunk_info@freifunk-vogtland.net:
Wurde aktualisiert.
Danke, habe es nochmal angeschaut, und auch etwas unglücklich, denn gleichzeitig zu weit und zu eng, ist die Angabe für DNS: "* udp/53"
Zu weit ist der Stern, denn nötig ist nur eine Firewallregel zu demjenigen DNS-Server, der per DHCP mitgeteilt wurde. Wie man das massenkompatibel formuliert, weiß ich nicht, ist aber vermutlich auch nicht nötig, denn wer sich auf diese Seite verirrt und wirklich alles einschränkt, weiß vermutlich, was er tut.
Zu eng ist es deswegen, weil DNS auch über TCP gehen kann, nämlich wenn die Antworten so groß sind, dass ein UDP-Paket nicht mehr ausreicht. Das wird mittelfristig ein Blocker, u.a. wenn sich Signaturen im DNS mehr verbreiten.
Carsten
Hi Carsten,
ich habe bei mir UDP 1-9999 freigegeben, das sollte doch reichen, oder? Ich kann den Artikel noch aktualisieren.
VG und Danke! André
Am 17. Juni 2018 um 23:29 schrieb Carsten Weber via Freifunk_info freifunk_info@freifunk-vogtland.net:
Hi,
Am Sat, 16 Jun 2018 22:26:45 +0000 (GMT) schrieb André Fiedler via Freifunk_info freifunk_info@freifunk-vogtland.net:
Wurde aktualisiert.
Danke, habe es nochmal angeschaut, und auch etwas unglücklich, denn gleichzeitig zu weit und zu eng, ist die Angabe für DNS: "* udp/53"
Zu weit ist der Stern, denn nötig ist nur eine Firewallregel zu demjenigen DNS-Server, der per DHCP mitgeteilt wurde. Wie man das massenkompatibel formuliert, weiß ich nicht, ist aber vermutlich auch nicht nötig, denn wer sich auf diese Seite verirrt und wirklich alles einschränkt, weiß vermutlich, was er tut.
Zu eng ist es deswegen, weil DNS auch über TCP gehen kann, nämlich wenn die Antworten so groß sind, dass ein UDP-Paket nicht mehr ausreicht. Das wird mittelfristig ein Blocker, u.a. wenn sich Signaturen im DNS mehr verbreiten.
Carsten _______________________________________________ Freifunk_info mailing list Freifunk_info@freifunk-vogtland.net https://mx.hateotu.de/mailman/listinfo/freifunk_info
In der Zwischenzeit verschwunden ================================
* https://vogtland.freifunk.net/map/#!v:m;n:6872516432fe MKN-Wirtsgrundweg19a-01 * https://vogtland.freifunk.net/map/#!v:m;n:18d6c786fbbc N-Brockauer28 * https://vogtland.freifunk.net/map/#!v:m;n:f4f26dc1f7c8 NE-AmBuehl4-Sporrer * https://vogtland.freifunk.net/map/#!v:m;n:14cc203b1952 PL-Kleist-Test
kein Uplink mehr Vorhanden ==========================
* https://vogtland.freifunk.net/map/#!v:m;n:a0f3c15b4376 TR-Pfarr1 * https://vogtland.freifunk.net/map/#!v:m;n:00199967a208 PL-Raedel7-Offloader
Folgende sind weiterhin ungeklaert ==================================
* https://vogtland.freifunk.net/map/#!v:m;n:ec086bb82652 PL-Kleist * https://vogtland.freifunk.net/map/#!v:m;n:98ded08887de POE-Bahnhof21
Uplink-Knoten welche zu stark gefiltert werden: ===============================================
* https://vogtland.freifunk.net/map/#!v:m;n:60e327c73940 PL-Breitscheid81-Balkon (kein Test da gerade offline) * https://vogtland.freifunk.net/map/#!v:m;n:00e04c6801b8 PL-Nobel5-Matsch (kein Test da gerade offline) * https://vogtland.freifunk.net/map/#!v:m;n:f09fc2e41ce8 RC-Bahnhof23A-DG * https://vogtland.freifunk.net/map/#!v:m;n:687251687401 RC-Markt * https://vogtland.freifunk.net/map/#!v:m;n:f4f26ddd6d2a RC-Markt1 * https://vogtland.freifunk.net/map/#!v:m;n:18a6f76e1556 RC-Markt7 * https://vogtland.freifunk.net/map/#!v:m;n:6872516a24ac RC-Rossplatz13-Stadtwerke * https://vogtland.freifunk.net/map/#!v:m;n:6872516a267d RC-Rossplatz13-Stadtwerke2
Nach aktuellen Stand wuerden diese Knoten sich nicht mehr direkt mit dem Server verbinden, wenn die Firmware-Einstellung fuer die entsprechende Domain gesetzt werden.
Gruesse, Sven
Hallo,
* https://vogtland.freifunk.net/map/#!v:m;n:687251687401 RC-Markt * https://vogtland.freifunk.net/map/#!v:m;n:f4f26ddd6d2a RC-Markt1 * https://vogtland.freifunk.net/map/#!v:m;n:18a6f76e1556 RC-Markt7
Habe ich erledigt
Die Knoten für die Stadtwerke da habe ich den Admin angeschrieben.
Der jo
Sven Eckelmann via Freifunk_info freifunk_info@freifunk-vogtland.net schrieb am Mi. 4. Juli 2018 um 19:00:
In der Zwischenzeit verschwunden
MKN-Wirtsgrundweg19a-01
- https://vogtland.freifunk.net/map/#!v:m;n:18d6c786fbbc N-Brockauer28
- https://vogtland.freifunk.net/map/#!v:m;n:f4f26dc1f7c8
NE-AmBuehl4-Sporrer
- https://vogtland.freifunk.net/map/#!v:m;n:14cc203b1952 PL-Kleist-Test
kein Uplink mehr Vorhanden
- https://vogtland.freifunk.net/map/#!v:m;n:a0f3c15b4376 TR-Pfarr1
- https://vogtland.freifunk.net/map/#!v:m;n:00199967a208
PL-Raedel7-Offloader
Folgende sind weiterhin ungeklaert
- https://vogtland.freifunk.net/map/#!v:m;n:ec086bb82652 PL-Kleist
- https://vogtland.freifunk.net/map/#!v:m;n:98ded08887de POE-Bahnhof21
Uplink-Knoten welche zu stark gefiltert werden:
PL-Breitscheid81-Balkon (kein Test da gerade offline)
- https://vogtland.freifunk.net/map/#!v:m;n:00e04c6801b8 PL-Nobel5-Matsch (kein Test da gerade offline)
- https://vogtland.freifunk.net/map/#!v:m;n:f09fc2e41ce8 RC-Bahnhof23A-DG
- https://vogtland.freifunk.net/map/#!v:m;n:687251687401 RC-Markt
- https://vogtland.freifunk.net/map/#!v:m;n:f4f26ddd6d2a RC-Markt1
- https://vogtland.freifunk.net/map/#!v:m;n:18a6f76e1556 RC-Markt7
- https://vogtland.freifunk.net/map/#!v:m;n:6872516a24ac
RC-Rossplatz13-Stadtwerke
RC-Rossplatz13-Stadtwerke2
Nach aktuellen Stand wuerden diese Knoten sich nicht mehr direkt mit dem Server verbinden, wenn die Firmware-Einstellung fuer die entsprechende Domain gesetzt werden.
Gruesse, Sven
Freifunk_info mailing list Freifunk_info@freifunk-vogtland.net https://mx.hateotu.de/mailman/listinfo/freifunk_info
* https://vogtland.freifunk.net/map/#!v:m;n:f09fc2e41ce8 RC-Bahnhof23A-DG
Sollte auch erledigt sein.
Der Jo
Dunkelschunkel dunkelschunkel@googlemail.com schrieb am Mo. 9. Juli 2018 um 15:30:
Hallo,
- https://vogtland.freifunk.net/map/#!v:m;n:687251687401 RC-Markt
- https://vogtland.freifunk.net/map/#!v:m;n:f4f26ddd6d2a RC-Markt1
- https://vogtland.freifunk.net/map/#!v:m;n:18a6f76e1556 RC-Markt7
Habe ich erledigt
Die Knoten für die Stadtwerke da habe ich den Admin angeschrieben.
Der jo
Sven Eckelmann via Freifunk_info freifunk_info@freifunk-vogtland.net schrieb am Mi. 4. Juli 2018 um 19:00:
In der Zwischenzeit verschwunden
MKN-Wirtsgrundweg19a-01
- https://vogtland.freifunk.net/map/#!v:m;n:18d6c786fbbc N-Brockauer28
- https://vogtland.freifunk.net/map/#!v:m;n:f4f26dc1f7c8
NE-AmBuehl4-Sporrer
- https://vogtland.freifunk.net/map/#!v:m;n:14cc203b1952 PL-Kleist-Test
kein Uplink mehr Vorhanden
- https://vogtland.freifunk.net/map/#!v:m;n:a0f3c15b4376 TR-Pfarr1
- https://vogtland.freifunk.net/map/#!v:m;n:00199967a208
PL-Raedel7-Offloader
Folgende sind weiterhin ungeklaert
- https://vogtland.freifunk.net/map/#!v:m;n:ec086bb82652 PL-Kleist
- https://vogtland.freifunk.net/map/#!v:m;n:98ded08887de POE-Bahnhof21
Uplink-Knoten welche zu stark gefiltert werden:
PL-Breitscheid81-Balkon (kein Test da gerade offline)
PL-Nobel5-Matsch (kein Test da gerade offline)
RC-Bahnhof23A-DG
- https://vogtland.freifunk.net/map/#!v:m;n:687251687401 RC-Markt
- https://vogtland.freifunk.net/map/#!v:m;n:f4f26ddd6d2a RC-Markt1
- https://vogtland.freifunk.net/map/#!v:m;n:18a6f76e1556 RC-Markt7
- https://vogtland.freifunk.net/map/#!v:m;n:6872516a24ac
RC-Rossplatz13-Stadtwerke
RC-Rossplatz13-Stadtwerke2
Nach aktuellen Stand wuerden diese Knoten sich nicht mehr direkt mit dem Server verbinden, wenn die Firmware-Einstellung fuer die entsprechende Domain gesetzt werden.
Gruesse, Sven
Freifunk_info mailing list Freifunk_info@freifunk-vogtland.net https://mx.hateotu.de/mailman/listinfo/freifunk_info
On Montag, 9. Juli 2018 21:02:00 CEST Dunkelschunkel via Freifunk_info wrote:
- https://vogtland.freifunk.net/map/#!v:m;n:f09fc2e41ce8 RC-Bahnhof23A-DG
Sollte auch erledigt sein.
Danke fuer die Hilfe
geklaert ========
* https://vogtland.freifunk.net/map/#!v:m;n:18a6f76e1556 RC-Markt7 * https://vogtland.freifunk.net/map/#!v:m;n:00199967a208 PL-Raedel7-Offloader * https://vogtland.freifunk.net/map/#!v:m;n:687251687401 RC-Markt * https://vogtland.freifunk.net/map/#!v:m;n:98ded08887de POE-Bahnhof21 * https://vogtland.freifunk.net/map/#!v:m;n:f09fc2e41ce8 RC-Bahnhof23A-DG * https://vogtland.freifunk.net/map/#!v:m;n:f4f26ddd6d2a RC-Markt1
Folgende sind weiterhin ungeklaert ==================================
* https://vogtland.freifunk.net/map/#!v:m;n:ec086bb82652 PL-Kleist
Uplink-Knoten welche zu stark gefiltert werden: ===============================================
* https://vogtland.freifunk.net/map/#!v:m;n:60e327c73940 PL-Breitscheid81-Balkon (kein Test da gerade offline) * https://vogtland.freifunk.net/map/#!v:m;n:00e04c6801b8 PL-Nobel5-Matsch * https://vogtland.freifunk.net/map/#!v:m;n:6872516a24ac RC-Rossplatz13-Stadtwerke * https://vogtland.freifunk.net/map/#!v:m;n:6872516a267d RC-Rossplatz13-Stadtwerke2
Nach aktuellen Stand wuerden diese Knoten sich nicht mehr direkt mit dem Server verbinden, wenn die Firmware-Einstellung fuer die entsprechende Domain gesetzt werden.
Gruesse, Sven
Hallo alle,
ich muss einmal fragen. In RC gibt es einen Karteneintrag, von einem Router, der dort nicht existiert.
RC-Markt https://vogtland.freifunk.net/map/#!v:m;n:687251687401
Das Gerät mesht nicht mit irgendeinem anderen, obwohl es ganz in der Nähe mehrere gibt, man sieht gelegentlich Nutzer, aber an der Stelle, an der es erscheint, ist es definitiv nicht.
Nun gehe ich langsam davon aus, dass es ein ehemaliges Testgerät ist, das sich inzwischen an einem anderen Ort befindet, aber noch die alten Geodaten hat (und den alten Namen).
Kann sich jemand(tm) erinnern, in RC am Markt mal einen Router platziert zu haben? Und wenn ja, könnte der mal bitte richtig neu zugeordnet werden?
Danke schön.
Beste Grüße, Steffen.
Guten Morgen Steffen,
Als Reichenbacher kennst du sicher den grauen Infoterminal mit Bildschirm. Da drin Ist die Pico Station. Der Knoten Markt 7 ist im Bürgerbüro und mesht eher nach hinten.
Alles In Ordnung.
Nick via Freifunk_info freifunk_info@freifunk-vogtland.net schrieb am Do. 12. Juli 2018 um 08:41:
Hallo alle,
ich muss einmal fragen. In RC gibt es einen Karteneintrag, von einem Router, der dort nicht existiert.
RC-Markt https://vogtland.freifunk.net/map/#!v:m;n:687251687401
Das Gerät mesht nicht mit irgendeinem anderen, obwohl es ganz in der Nähe mehrere gibt, man sieht gelegentlich Nutzer, aber an der Stelle, an der es erscheint, ist es definitiv nicht.
Nun gehe ich langsam davon aus, dass es ein ehemaliges Testgerät ist, das sich inzwischen an einem anderen Ort befindet, aber noch die alten Geodaten hat (und den alten Namen).
Kann sich jemand(tm) erinnern, in RC am Markt mal einen Router platziert zu haben? Und wenn ja, könnte der mal bitte richtig neu zugeordnet werden?
Danke schön.
Beste Grüße, Steffen. _______________________________________________ Freifunk_info mailing list Freifunk_info@freifunk-vogtland.net https://mx.hateotu.de/mailman/listinfo/freifunk_info
Sehr geehrte Damen und Herren, seit einigen Tagen ergibt sich folgendes Bild. Die AP sind ständig rot.
MfG
Stephan Hösl
Mit freundlichen Grüßen
Stephan Hösl
Privat
Rosa-Luxemburg-Straße 7
08468 Reichenbach
Telefon (03765) 327713-0
Telefax (03765) 327713-169
E-Mail: mailto:privat@stephan-hoesl.com privat@stephan-hoesl.com
Web: http://www.stephan-hoesl.com/ www.stephan-hoesl.com
GEHEIMHALTUNGSPFLICHT:
Diese E-Mail und etwaige Anhänge können vertrauliche und/oder rechtlich geschützte Informationen enthalten. Falls Sie nicht der
angegebene Empfänger sind oder falls diese E-Mail irrtümlich an Sie adressiert wurde, benachrichtigen Sie uns bitte sofort durch
eine Antwort-E-Mail und löschen Sie diese E-Mail nebst etwaigen Anlagen von Ihrem System. Ebenso dürfen Sie dann diese E-Mail
oder ihre Anlagen nicht kopieren oder an Dritte weitergeben.
Vielen Dank.
Von: Freifunk_info freifunk_info-bounces@freifunk-vogtland.net Im Auftrag von Dunkelschunkel via Freifunk_info Gesendet: Donnerstag, 12. Juli 2018 08:52 An: info@freifunk-vogtland.net Cc: Dunkelschunkel dunkelschunkel@googlemail.com; freifunk_info@freifunk-vogtland.net Betreff: Re: [Freifunk_info] Seltsamer Router ...
Guten Morgen Steffen,
Als Reichenbacher kennst du sicher den grauen Infoterminal mit Bildschirm. Da drin Ist die Pico Station.
Der Knoten Markt 7 ist im Bürgerbüro und mesht eher nach hinten.
Alles In Ordnung.
Nick via Freifunk_info <freifunk_info@freifunk-vogtland.net mailto:freifunk_info@freifunk-vogtland.net > schrieb am Do. 12. Juli 2018 um 08:41:
Hallo alle,
ich muss einmal fragen. In RC gibt es einen Karteneintrag, von einem Router, der dort nicht existiert.
RC-Markt https://vogtland.freifunk.net/map/#!v:m;n:687251687401
Das Gerät mesht nicht mit irgendeinem anderen, obwohl es ganz in der Nähe mehrere gibt, man sieht gelegentlich Nutzer, aber an der Stelle, an der es erscheint, ist es definitiv nicht.
Nun gehe ich langsam davon aus, dass es ein ehemaliges Testgerät ist, das sich inzwischen an einem anderen Ort befindet, aber noch die alten Geodaten hat (und den alten Namen).
Kann sich jemand(tm) erinnern, in RC am Markt mal einen Router platziert zu haben? Und wenn ja, könnte der mal bitte richtig neu zugeordnet werden?
Danke schön.
Beste Grüße, Steffen. _______________________________________________ Freifunk_info mailing list Freifunk_info@freifunk-vogtland.net mailto:Freifunk_info@freifunk-vogtland.net https://mx.hateotu.de/mailman/listinfo/freifunk_info
Hallo,
wegen der Art eine neues Thema auf der Mailingliste zu "starten", habe ich ihnen schon privat geschrieben.
On Donnerstag, 12. Juli 2018 15:30:27 CEST Stephan Hösl via Freifunk_info wrote:
Sehr geehrte Damen und Herren, seit einigen Tagen ergibt sich folgendes Bild. Die AP sind ständig rot.
Scheinbar gibt es ein Problem mit ihrem Anschluss bzw. auf dem Weg von den Geraeten zu ihrem Internet-Anschluss. Kleinere UDP Pakete kann dieser ohne Probleme verschicken. Daher erkennen die VPN-Server ihn als waere eine Verbindung vorhanden. Nun fragt der Server regelmaessig auch Statusinformationen ab - und diese koennen auch groesser werden und werden in (mehrere) grossere Pakete verpackt.
Was nun passiert ist, dass die Geraete so ein groesseres UDP Paket versuchen zu schicken und bei ihrer Internetverbindung werden diese Daten einfach verworfen.
Daher:
* andere Geraete sehen das Geraet -> zeichnen lustige, bunte Verbindungslinien * VPN-Server koennen Daten nicht abfragen -> markieren den Knoten als offline (rot)
Dies sieht man zum Beispiel wenn man sich auf den Knoten einwaehlt und eine groessere Textausgabe startet (`dmesg`). Die Verbindung scheint dann einfach zu haengen. Bei kleineren Ausgaben (`ip link show dev mesh-vpn`) tritt dies nicht auf.
Wenn ich die Paketgroesse auf dem Geraet *temporaer* fuer den VPN-Prozess (fastd) von 1426 auf 1280 und dem VXLAN (zwischen Mesh-on-WAN/LAN-Geraeten) reduziere, tritt das Problem nicht mehr beim Senden vom Geraet Richtung VPN- Server auf. Empfangen ist aber eine ganz andere Sache. Und es beeintraechtigt natuerlich auch die Verbindungen anderer Leute ueber ihre Geraete.
Vielleicht koennen sie mit ihrem Internetanbieter klaeren wie sie das Problem am Besten beheben. Vielleicht gibt es auch noch andere Probleme, die ich nicht direkt erkannt habe.
Gruesse, Sven
[1] https://vpn01.freifunk-vogtland.net/meshviewer-ffrgb/#/en/map/6872515ec540 [2] https://vpn01.freifunk-vogtland.net/meshviewer-ffrgb/#/en/map/6872514c0a8b [3] https://vpn01.freifunk-vogtland.net/meshviewer-ffrgb/#/en/map/6872513aaef5 [4] https://vpn01.freifunk-vogtland.net/meshviewer-ffrgb/#/en/map/6872513ab0fe
Hallo,
Ich würde sowohl an die Knoten als auch an den Internetzugang für die beiden Geräte im Park rann kommen.
Wie es aussieht geht es wieder?
[3] https://vpn01.freifunk-vogtland.net/meshviewer-ffrgb/#/en/map/6872513aaef5 [4] https://vpn01.freifunk-vogtland.net/meshviewer-ffrgb/#/en/map/6872513ab0fe
Wir können das Meshen über Kabel auch aus schalten. Das wäre kein Problem. Wenn die Geräte dadurch etwas entlastet werden.
Sven du darfst das gerne raus nehmen, ich habe die Berechtigung das zu genehmigen.
Der Jo
Sven Eckelmann via Freifunk_info freifunk_info@freifunk-vogtland.net schrieb am Do. 12. Juli 2018 um 16:53:
Hallo,
wegen der Art eine neues Thema auf der Mailingliste zu "starten", habe ich ihnen schon privat geschrieben.
On Donnerstag, 12. Juli 2018 15:30:27 CEST Stephan Hösl via Freifunk_info wrote:
Sehr geehrte Damen und Herren, seit einigen Tagen ergibt sich folgendes Bild. Die AP sind ständig rot.
Scheinbar gibt es ein Problem mit ihrem Anschluss bzw. auf dem Weg von den Geraeten zu ihrem Internet-Anschluss. Kleinere UDP Pakete kann dieser ohne Probleme verschicken. Daher erkennen die VPN-Server ihn als waere eine Verbindung vorhanden. Nun fragt der Server regelmaessig auch Statusinformationen ab - und diese koennen auch groesser werden und werden in (mehrere) grossere Pakete verpackt.
Was nun passiert ist, dass die Geraete so ein groesseres UDP Paket versuchen zu schicken und bei ihrer Internetverbindung werden diese Daten einfach verworfen.
Daher:
- andere Geraete sehen das Geraet -> zeichnen lustige, bunte Verbindungslinien
- VPN-Server koennen Daten nicht abfragen -> markieren den Knoten als
offline (rot)
Dies sieht man zum Beispiel wenn man sich auf den Knoten einwaehlt und eine groessere Textausgabe startet (`dmesg`). Die Verbindung scheint dann einfach zu haengen. Bei kleineren Ausgaben (`ip link show dev mesh-vpn`) tritt dies nicht auf.
Wenn ich die Paketgroesse auf dem Geraet *temporaer* fuer den VPN-Prozess (fastd) von 1426 auf 1280 und dem VXLAN (zwischen Mesh-on-WAN/LAN-Geraeten) reduziere, tritt das Problem nicht mehr beim Senden vom Geraet Richtung VPN- Server auf. Empfangen ist aber eine ganz andere Sache. Und es beeintraechtigt natuerlich auch die Verbindungen anderer Leute ueber ihre Geraete.
Vielleicht koennen sie mit ihrem Internetanbieter klaeren wie sie das Problem am Besten beheben. Vielleicht gibt es auch noch andere Probleme, die ich nicht direkt erkannt habe.
Gruesse, Sven
[1] https://vpn01.freifunk-vogtland.net/meshviewer-ffrgb/#/en/map/6872515ec540 [2] https://vpn01.freifunk-vogtland.net/meshviewer-ffrgb/#/en/map/6872514c0a8b [3] https://vpn01.freifunk-vogtland.net/meshviewer-ffrgb/#/en/map/6872513aaef5 [4] https://vpn01.freifunk-vogtland.net/meshviewer-ffrgb/#/en/map/6872513ab0fe _______________________________________________ Freifunk_info mailing list Freifunk_info@freifunk-vogtland.net https://mx.hateotu.de/mailman/listinfo/freifunk_info
On Donnerstag, 12. Juli 2018 17:15:28 CEST Dunkelschunkel wrote:
Ich würde sowohl an die Knoten als auch an den Internetzugang für die beiden Geräte im Park rann kommen.
Das koennte hilfreich sein wenn du schaust was genau die MTU-Probleme hervorruft.
Wie es aussieht geht es wieder?
Hab wie gesagt Die MTU *temporaer* von 1426 auf 1280 runtergesetzt. Das ist aber keine langfristige Loesung und erlauben wir eigentlich beim Server auch nicht. Wenn es erst seit ein paar Tagen auftritt, gab es entweder vorher eine andere Loesung oder es hat sich irgendwas im Netzwerk bzw. bei der Internetverbindung geaendert - irgendwas was die MTU staerker als erwartet einschraenkt.
Haengen die eigentlich alle 3 (der vierte im Hotel mesht nur per WLAN) am selben Internetzugang?
[...]
Wir können das Meshen über Kabel auch aus schalten. Das wäre kein Problem. Wenn die Geräte dadurch etwas entlastet werden.
Sven du darfst das gerne raus nehmen, ich habe die Berechtigung das zu genehmigen.
Na ja, betrifft halt auch Meshing zum Server (Mesh-VPN oder wie das im Config- Modus hiess). Daher ausschalten des Mesh-on-LAN/WAN erscheint mir noch nicht die perfekte Loesung.
Wenn ich das auch noch ausschalten wurde, muessten alle Daten ueber RC- Trinitatisgasse6 und Co gehen. Da habt ihr aber die WiFi Coverage Class auch noch falsch auf allen Knoten eingestellt - daher wird da der Sendeslot bzw. Ack-Timeout fuer die Verbindung zwischen diesen Geraeten falsch berechnet.
Gruesse, Sven
On Donnerstag, 12. Juli 2018 17:25:07 CEST Sven Eckelmann via Freifunk_info wrote:
Hab wie gesagt Die MTU *temporaer* von 1426 auf 1280 runtergesetzt. Das ist aber keine langfristige Loesung und erlauben wir eigentlich beim Server auch nicht. Wenn es erst seit ein paar Tagen auftritt, gab es entweder vorher eine andere Loesung oder es hat sich irgendwas im Netzwerk bzw. bei der Internetverbindung geaendert - irgendwas was die MTU staerker als erwartet einschraenkt.
Haengen die eigentlich alle 3 (der vierte im Hotel mesht nur per WLAN) am selben Internetzugang?
Wollte es gerade nochmal testen und jetzt kriege ich Pakete mit der vollen VPN-Link-MTU (1426) ueber den VPN Link zum Server. Vielleicht gibt es da nur immer mal wieder temporaere Probleme beim ISP/lokalen Netz?
18:23:14.852766 IP6 fe80::12:7bff:fe00:603 > fe80::642c:13ff:fece:e87f: ICMP6, echo reply, seq 2, length 1386 18:23:15.772561 IP6 fe80::642c:13ff:fece:e87f > ff02::1: ICMP6, echo request, seq 3, length 1386
Gruesse, Sven
bitte mal schauen ob alles in Ordnung ist. Wenn ja sag ich mal was es gewesen sein könnte
Sven Eckelmann sven@narfation.org schrieb am Do. 12. Juli 2018 um 18:29:
On Donnerstag, 12. Juli 2018 17:25:07 CEST Sven Eckelmann via Freifunk_info wrote:
Hab wie gesagt Die MTU *temporaer* von 1426 auf 1280 runtergesetzt. Das
ist
aber keine langfristige Loesung und erlauben wir eigentlich beim Server
auch
nicht. Wenn es erst seit ein paar Tagen auftritt, gab es entweder vorher
eine
andere Loesung oder es hat sich irgendwas im Netzwerk bzw. bei der Internetverbindung geaendert - irgendwas was die MTU staerker als
erwartet
einschraenkt.
Haengen die eigentlich alle 3 (der vierte im Hotel mesht nur per WLAN)
am
selben Internetzugang?
Wollte es gerade nochmal testen und jetzt kriege ich Pakete mit der vollen VPN-Link-MTU (1426) ueber den VPN Link zum Server. Vielleicht gibt es da nur immer mal wieder temporaere Probleme beim ISP/lokalen Netz?
18:23:14.852766 IP6 fe80::12:7bff:fe00:603 >fe80::642c:13ff:fece:e87f: ICMP6, echo reply, seq 2, length 1386 18:23:15.772561 IP6 fe80::642c:13ff:fece:e87f > ff02::1: ICMP6, echo request, seq 3, length 1386
Gruesse, Sven
On Freitag, 13. Juli 2018 10:10:52 CEST Dunkelschunkel wrote:
bitte mal schauen ob alles in Ordnung ist. Wenn ja sag ich mal was es gewesen sein könnte
Da waere ich gespannt. Gerade sieht es auf jedenfall so aus wie auch gestern Abend. Also es geht auch mit hoher MTU auf Mesh-VPN bei RC-RosaLuxemburg7-Hoesl-MdL-ParkderGenerationen-1 und RC-ParkderGenerationen-Schaudepot1. Aber nicht auf RC-ParkderGenerationen-Schaudepot2 (welche auch ueber mesh-vpn angebunden ist.
Hier kriegt er nur eine Antwort von sich selbst:
root@RC-ParkderGenerationen-Schaudepot2:~# batctl n [B.A.T.M.A.N. adv 2018.1, MainIF/MAC: primary0/da:b0:ac:54:74:83 (bat0/68:72:51:3a:b0:fe BATMAN_IV)] IF Neighbor last-seen mesh0 9a:db:9f:fb:e5:b9 4.340s mesh0 76:40:1c:31:21:41 0.520s mesh0 4a:73:21:05:ac:d9 0.970s mesh0 4a:5a:f7:e3:00:21 1.870s mesh0 66:2c:13:ce:e8:79 2.380s mesh-vpn 02:12:7b:00:04:03 0.450s root@RC-ParkderGenerationen-Schaudepot2:~# ping -s 1378 ff02::1%mesh-vpn PING ff02::1%mesh-vpn (ff02::1%mesh-vpn): 1378 data bytes 1386 bytes from fe80::d8b0:acff:fe54:7487: seq=0 ttl=64 time=1.082 ms 1386 bytes from fe80::d8b0:acff:fe54:7487: seq=1 ttl=64 time=0.646 ms
Hier auch vom Remote (fe80::12:7bff:fe00:403):
root@RC-ParkderGenerationen-Schaudepot1:~# batctl n [B.A.T.M.A.N. adv 2018.1, MainIF/MAC: primary0/4a:73:21:05:ac:db (bat0/68:72:51:3a:ae:f5 BATMAN_IV)] IF Neighbor last-seen mesh0 be:3c:69:e7:41:b1 4.460s mesh0 da:b0:ac:54:74:81 1.420s mesh0 9a:db:9f:fb:e5:b9 1.390s mesh0 4a:5a:f7:e3:00:21 3.970s mesh0 66:2c:13:ce:e8:79 4.510s mesh0 76:40:1c:31:21:41 2.630s mesh-vpn 02:12:7b:00:04:03 2.340s root@RC-ParkderGenerationen-Schaudepot1:~# ping -s 1378 ff02::1%mesh-vpn PING ff02::1%mesh-vpn (ff02::1%mesh-vpn): 1378 data bytes 1386 bytes from fe80::4873:21ff:fe05:acdf: seq=0 ttl=64 time=1.909 ms 1386 bytes from fe80::12:7bff:fe00:403: seq=0 ttl=64 time=58.895 ms (DUP!) 1386 bytes from fe80::4873:21ff:fe05:acdf: seq=1 ttl=64 time=0.596 ms 1386 bytes from fe80::12:7bff:fe00:403: seq=1 ttl=64 time=31.333 ms (DUP!)
Details habe ich mir jetzt aus Zeitgruenden nicht angeschaut.
Gruesse, Sven
Seltsam, als ich den Schauplatz verließ hatten beide Uplink auf VPN Server sowie diese als gewähltes Gateway
Sven Eckelmann sven@narfation.org schrieb am Fr. 13. Juli 2018 um 10:24:
On Freitag, 13. Juli 2018 10:10:52 CEST Dunkelschunkel wrote:
bitte mal schauen ob alles in Ordnung ist. Wenn ja sag ich mal was es gewesen sein könnte
Da waere ich gespannt. Gerade sieht es auf jedenfall so aus wie auch gestern Abend. Also es geht auch mit hoher MTU auf Mesh-VPN bei RC-RosaLuxemburg7-Hoesl-MdL-ParkderGenerationen-1 und RC-ParkderGenerationen-Schaudepot1. Aber nicht auf RC-ParkderGenerationen-Schaudepot2 (welche auch ueber mesh-vpn angebunden ist.
Hier kriegt er nur eine Antwort von sich selbst:
root@RC-ParkderGenerationen-Schaudepot2:~# batctl n [B.A.T.M.A.N. adv 2018.1, MainIF/MAC: primary0/da:b0:ac:54:74:83(bat0/68:72:51:3a:b0:fe BATMAN_IV)] IF Neighbor last-seen mesh0 9a:db:9f:fb:e5:b9 4.340s mesh0 76:40:1c:31:21:41 0.520s mesh0 4a:73:21:05:ac:d9 0.970s mesh0 4a:5a:f7:e3:00:21 1.870s mesh0 66:2c:13:ce:e8:79 2.380s mesh-vpn 02:12:7b:00:04:03 0.450s root@RC-ParkderGenerationen-Schaudepot2:~# ping -s 1378 ff02::1%mesh-vpn PING ff02::1%mesh-vpn (ff02::1%mesh-vpn): 1378 data bytes 1386 bytes from fe80::d8b0:acff:fe54:7487: seq=0 ttl=64 time=1.082 ms 1386 bytes from fe80::d8b0:acff:fe54:7487: seq=1 ttl=64 time=0.646 ms
Hier auch vom Remote (fe80::12:7bff:fe00:403):
root@RC-ParkderGenerationen-Schaudepot1:~# batctl n [B.A.T.M.A.N. adv 2018.1, MainIF/MAC: primary0/4a:73:21:05:ac:db(bat0/68:72:51:3a:ae:f5 BATMAN_IV)] IF Neighbor last-seen mesh0 be:3c:69:e7:41:b1 4.460s mesh0 da:b0:ac:54:74:81 1.420s mesh0 9a:db:9f:fb:e5:b9 1.390s mesh0 4a:5a:f7:e3:00:21 3.970s mesh0 66:2c:13:ce:e8:79 4.510s mesh0 76:40:1c:31:21:41 2.630s mesh-vpn 02:12:7b:00:04:03 2.340s root@RC-ParkderGenerationen-Schaudepot1:~# ping -s 1378 ff02::1%mesh-vpn PING ff02::1%mesh-vpn (ff02::1%mesh-vpn): 1378 data bytes 1386 bytes from fe80::4873:21ff:fe05:acdf: seq=0 ttl=64 time=1.909 ms 1386 bytes from fe80::12:7bff:fe00:403: seq=0 ttl=64 time=58.895 ms (DUP!) 1386 bytes from fe80::4873:21ff:fe05:acdf: seq=1 ttl=64 time=0.596 ms 1386 bytes from fe80::12:7bff:fe00:403: seq=1 ttl=64 time=31.333 ms (DUP!)
Details habe ich mir jetzt aus Zeitgruenden nicht angeschaut.
Gruesse, Sven
On Freitag, 13. Juli 2018 10:31:50 CEST Dunkelschunkel wrote:
Seltsam, als ich den Schauplatz verließ hatten beide Uplink auf VPN Server sowie diese als gewähltes Gateway
Haben sie auch jetzt - nur gehen da halt keine groesseren Pakete durch. Meine Vermutung (muesste man mal genauer anschauen) waeren, dass es beim ISP- Probleme(tm) gibt sobald die Daten per IPv6 versendet werden. Die zwei funktionierenden Geraete haben die Verbindung zum VPN-Server ueber IPv4 augebaut - nur das Geraet mit Problemen ueber IPv6.
Das sind uebrigens die einzigen Geraete die das Problem mit IPv6 haben. Mir ist auf jedenfall kein anderes bekannt und meine (non-L2TP) Testgeraete nutzten auch gerne IPv6 zum verbinden mit dem VPN-Server. Kann dir jetzt aber aus dem Stehgreif nicht sagen welche das noch tun (wir haben auf jedenfall ein paar).
Gruesse, Sven
On Freitag, 13. Juli 2018 10:48:58 CEST Sven Eckelmann via Freifunk_info wrote: [...]
Meine Vermutung (muesste man mal genauer anschauen) waeren, dass es beim ISP- Probleme(tm) gibt sobald die Daten per IPv6 versendet werden. Die zwei funktionierenden Geraete haben die Verbindung zum VPN-Server ueber IPv4 augebaut - nur das Geraet mit Problemen ueber IPv6.
Also auf dem betroffenem Geraet geht:
ping -s 1169 ff02::1%mesh-vpn
Aber nicht:
ping -s 1170 ff02::1%mesh-vpn
Ein Dump von br-wan (2018-07-13_br-wan_RC-ParkderGenerationen-Schaudepot2- IPv6-Fragmentation-Problem.pcap.gz) ist angehangen. Dort siehst du, dass das Geraet bei 1294 (MTU 1280) anfaengt das Paket zu fragmentieren (wahrscheinlich PMTU hier).
Ich habe auch noch einen Vergleichsdump von Sicht Server vs. Client angehangen. Die sind ca. zu selben Zeit aufgenommen. Aber wirklich nur circa. Beim groben Blick darauf, scheint der Server das Kleinere der zwei Fragmente nicht zu bekommen. Die minimale Ethernetpaket-Groesse von 68 Bytes wird aber zumindestens eingehalten (sind 71) und eine MTU von 1280 ist auch die minimal erlaubte fuer IPv6 (RFC 2460).
Gruesse, Sven
On Freitag, 13. Juli 2018 11:28:44 CEST Sven Eckelmann via Freifunk_info wrote: [...]
Ich habe auch noch einen Vergleichsdump von Sicht Server vs. Client angehangen. Die sind ca. zu selben Zeit aufgenommen. Aber wirklich nur circa. Beim groben Blick darauf, scheint der Server das Kleinere der zwei Fragmente nicht zu bekommen. Die minimale Ethernetpaket-Groesse von 68 Bytes wird aber zumindestens eingehalten (sind 71) und eine MTU von 1280 ist auch die minimal erlaubte fuer IPv6 (RFC 2460).
Ach ja, wenn du das lokal Testen moechtest um es den Telekom(?)-Technikern zu demonstieren, dann empfehle ich (br-wan ist hier mein Outgoing Interface und war jetzt nur fuer die Router wichtig):
# geht: ping -s 1000 -I br-wan 2a01:4f8:10a:2f8f::2
# geht nicht mehr, da es fragmentiert: ping -s 1300 -I br-wan 2a01:4f8:10a:2f8f::2
Von anderen Anschluessen aus geht das ohne Probleme.
Gruesse, Sven
-
andre.fiedler＠me.com -
André Fiedler
-
Carsten Weber -
Dunkelschunkel -
Enrico Meinel -
Nick -
privat＠stephan-hoesl.com -
Sven Eckelmann