New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Keine Webabwendungen hinter KD-Router (IPv6?) #50

Closed
cyberkeiler opened this Issue Jun 8, 2015 · 8 comments

Comments

Projects
None yet
6 participants
@cyberkeiler

cyberkeiler commented Jun 8, 2015

Haben einen WDR4300 seit Ende März hinter einem Kabel Deutschland Router im Einsatz. Das parallele private Netz ist ohne Probleme zu verwenden, über das Freifunk Netz war noch nie ein Aufruf einer Website möglich, Maliservices ebenfalls nicht erreichbar. - SSH und Ping funktionieren allerdings.

Zweiter Test´knoten mit WDR3600 zeigt gleiches Ergebnis.

Hitron Technologies CVE-30360
IPv6 only (IPv4 zumindest nicht in Routerconfig angezeigt)

@LeSpocky LeSpocky added the investigate label Jun 8, 2015

@cyberkeiler

This comment has been minimized.

Show comment
Hide comment
@cyberkeiler

cyberkeiler Jun 8, 2015

Achja: /etc/config/fastd haben wir schon gemäß #46 angepasst. - Keinen Erfolg.

Beim Googeln stoße ich immer über gleiche Probleme, mit Hinweis auf MTU - mangels Fachkompetenz dürft Ihr entscheiden ob dies als Ursache in Frage kommt.
https://regensburg.freifunk.net/temporaerer-fix-fuer-kabeldeutschlandunitymedia-mtu-probleme/

http://lists.berlin.freifunk.net/pipermail/berlin/2015-January/026897.html

https://www.kunden-kabeldeutschland.de/questions/wie-kann-ich-verhindern-dass-udp-pakete-mit-einer-mtu-1370-rausgefiltert-werden?page=1#anchor_answer_232539

cyberkeiler commented Jun 8, 2015

Achja: /etc/config/fastd haben wir schon gemäß #46 angepasst. - Keinen Erfolg.

Beim Googeln stoße ich immer über gleiche Probleme, mit Hinweis auf MTU - mangels Fachkompetenz dürft Ihr entscheiden ob dies als Ursache in Frage kommt.
https://regensburg.freifunk.net/temporaerer-fix-fuer-kabeldeutschlandunitymedia-mtu-probleme/

http://lists.berlin.freifunk.net/pipermail/berlin/2015-January/026897.html

https://www.kunden-kabeldeutschland.de/questions/wie-kann-ich-verhindern-dass-udp-pakete-mit-einer-mtu-1370-rausgefiltert-werden?page=1#anchor_answer_232539

@cyberkeiler

This comment has been minimized.

Show comment
Hide comment
@cyberkeiler

cyberkeiler Jun 9, 2015

Freifunk funktioniert wenn man den KD Router im Bridge Mode betreibt.
Ein manuelles setzen der MTU auf einen niedrigeren Wert als den Standardwert brachte sowohl im Bridge als auch in normalen Mode keine Besserung:

Sind die ffmd Gateway überhaupt kompatibel für diesen Lösungsansatz mit geringerer MTU (sh. Artikel Freifunk Regensburg oben?)

cyberkeiler commented Jun 9, 2015

Freifunk funktioniert wenn man den KD Router im Bridge Mode betreibt.
Ein manuelles setzen der MTU auf einen niedrigeren Wert als den Standardwert brachte sowohl im Bridge als auch in normalen Mode keine Besserung:

Sind die ffmd Gateway überhaupt kompatibel für diesen Lösungsansatz mit geringerer MTU (sh. Artikel Freifunk Regensburg oben?)

@LeSpocky

This comment has been minimized.

Show comment
Hide comment
@LeSpocky

LeSpocky Jun 29, 2015

Member

Das Problem scheint an Kabel Deutschland Anschlüssen mit DS Lite Konfiguration zu bestehen, wo man eine öffentliche IPv6-Adresse und eine private IPv4-Adresse bekommt, öffentlicher IPv4-Verkehr dann aber von KD über v6 getunnelt wird. Ich habe mich da mal bisschen durch die Links geklickt. Neben Anpassung der MTU oder Modem im Bridge-Modus könnte es auch helfen im Config-Modus IPv4 auf dem WAN-Port zu deaktivieren. Könnt Ihr das mal probieren?

Member

LeSpocky commented Jun 29, 2015

Das Problem scheint an Kabel Deutschland Anschlüssen mit DS Lite Konfiguration zu bestehen, wo man eine öffentliche IPv6-Adresse und eine private IPv4-Adresse bekommt, öffentlicher IPv4-Verkehr dann aber von KD über v6 getunnelt wird. Ich habe mich da mal bisschen durch die Links geklickt. Neben Anpassung der MTU oder Modem im Bridge-Modus könnte es auch helfen im Config-Modus IPv4 auf dem WAN-Port zu deaktivieren. Könnt Ihr das mal probieren?

@eriu

This comment has been minimized.

Show comment
Hide comment
@eriu

eriu Aug 9, 2015

Member

möglicherweise mit gluon 2015.1.2 gelöst
https://gluon.readthedocs.org/en/v2015.1.2/releases/v2015.1.2.html

Member

eriu commented Aug 9, 2015

möglicherweise mit gluon 2015.1.2 gelöst
https://gluon.readthedocs.org/en/v2015.1.2/releases/v2015.1.2.html

@LeSpocky

This comment has been minimized.

Show comment
Hide comment
@LeSpocky

LeSpocky Sep 1, 2015

Member

Könnte mit freifunk-gluon/gluon#397 zu tun haben, was wie gesagt in gluon 2015.1.2 gelöst wurde. Dazu bitte mal die aktuelle experimental aufspielen und testen!

Member

LeSpocky commented Sep 1, 2015

Könnte mit freifunk-gluon/gluon#397 zu tun haben, was wie gesagt in gluon 2015.1.2 gelöst wurde. Dazu bitte mal die aktuelle experimental aufspielen und testen!

@RubenKelevra

This comment has been minimized.

Show comment
Hide comment
@RubenKelevra

RubenKelevra Sep 1, 2015

Setzt die MTU einfach auf 1312 runter sowohl auf den Servern als auch auf den Nodes.

Das Problem ist, dass die Kabelmodems IPv4 wie bei IPv6 behandeln und keine Hop-Fragmentierung machen, sondern sich auf Host-Fragmentierung verlassen. Darüber hinaus schicken sie aber keine Kontrollnachricht via ICMP die für die Signalisierung der zu groß gewählten MTU bei IPv4 aber zwingend erforderlich ist.

Diese beiden Bugs zusammen sorgen für ein Blackhole das einfach die Pakete verwirft wenn diese zu groß in den Tunnel geschickt werden.

Bitte beachtet außerdem, dass Batman-adv bis (aber nicht einschließend) 2015.1 einen Bug hat, der unterschiedliche MTUs beim Forward teilweise für Probleme sorgt.

Lg aus Leverkusen

RubenKelevra commented Sep 1, 2015

Setzt die MTU einfach auf 1312 runter sowohl auf den Servern als auch auf den Nodes.

Das Problem ist, dass die Kabelmodems IPv4 wie bei IPv6 behandeln und keine Hop-Fragmentierung machen, sondern sich auf Host-Fragmentierung verlassen. Darüber hinaus schicken sie aber keine Kontrollnachricht via ICMP die für die Signalisierung der zu groß gewählten MTU bei IPv4 aber zwingend erforderlich ist.

Diese beiden Bugs zusammen sorgen für ein Blackhole das einfach die Pakete verwirft wenn diese zu groß in den Tunnel geschickt werden.

Bitte beachtet außerdem, dass Batman-adv bis (aber nicht einschließend) 2015.1 einen Bug hat, der unterschiedliche MTUs beim Forward teilweise für Probleme sorgt.

Lg aus Leverkusen

@penguineer penguineer added this to the v0.39 milestone Apr 16, 2018

@christf

This comment has been minimized.

Show comment
Hide comment
@christf

christf Aug 10, 2018

Contributor

Das ist eine Anpassung, die in Folge auf gateways und nodes stattfinden muss. Die Schrittfolge wäre:

  • Erweiterung der gateway-Konfiguration, Einführung einer zusätzlichen fastd-Instanz mit MTU 1312, deren Interface in Batman eingehängt ist
  • Wechsel der MTU in der Firmware auf 1312
  • Rollout der Firmware ins gesamte Netz
  • Deaktivierung der alten fastd-Instanzen
Contributor

christf commented Aug 10, 2018

Das ist eine Anpassung, die in Folge auf gateways und nodes stattfinden muss. Die Schrittfolge wäre:

  • Erweiterung der gateway-Konfiguration, Einführung einer zusätzlichen fastd-Instanz mit MTU 1312, deren Interface in Batman eingehängt ist
  • Wechsel der MTU in der Firmware auf 1312
  • Rollout der Firmware ins gesamte Netz
  • Deaktivierung der alten fastd-Instanzen

@christf christf self-assigned this Aug 10, 2018

@penguineer penguineer referenced this issue Aug 16, 2018

Open

MTU auf 1312 setzen #121

2 of 4 tasks complete
@penguineer

This comment has been minimized.

Show comment
Hide comment
@penguineer

penguineer Aug 16, 2018

Contributor

Weitere Bearbeitung de Tickets in #121

Contributor

penguineer commented Aug 16, 2018

Weitere Bearbeitung de Tickets in #121

@penguineer penguineer closed this Aug 16, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment