Hallo Tarek,
von wo aus soll die MTU detection (subtype 13) nachher erfolgen ?
Im fastd direkt oder als externes Tool, welches via script aufgerufen wird.
ich arbeite gerade an einer Lösung zur MTU-detection (packages, Issue #29). Meine Lösung sieht das Senden eines Pings mit "don't fragment bit" und variierender Paketgröße vor. Ich habe einen proof of concept in C unter github:
https://github.com/lethexa/mtudetect
Sollte dies eine Hilfe sein würde ich die Entwicklung und Integation gerne weiterführen.
Sehr cool!
Mein Plan ist die fastd MTU wieder auf 1426 (PPPoE optiemirt) zu setzen. Hintergrund des MTU detectior ist zu prüfen ob Destination Unreachable mit Subtyp 13 Communication administratively prohibited kommt. Das geschieht leider bei DS-Lite Anschlüssen bsp. Kabeldeutschland/Vodafone und unitymedia weil die sich nicht Standards halten. Würde der Fehler entsprechend auftreten soll eine MTU von 1312 (unsere aktuelle) gewählt werden. Evtl. kann man die MTU von 1312 auch größer wählen allerdings müsste man erst mal mit wireshark oder ähnlichen schauen wie groß die fastd Pakete samt Header sind und was maximal bei DS-lite Anschlüssen möglich ist.
Dein package sieht soweit sehr gut aus, aber es schein ein allgemeiner MTU detector zu sein den man via shell ausführt richtig ?
Gruß
Tim
Hi Tarek,
ich habe den Code soweit angepasst, dass der subtype 13 detektiert werden kann:
https://github.com/lethexa/mtudetect branch subtype13
von wo aus soll die MTU detection (subtype 13) später erfolgen ?
Soll diese im fastd direkt eingebaut werden oder als externes Tool aufgerufen werden um die fastd-config zu ändern ?
Gruß
Tim
On 03/13/16 16:17, Tim Leerhoff via Dev wrote:
Hi Tarek,
ich habe den Code soweit angepasst, dass der subtype 13 detektiert werden kann:
https://github.com/lethexa/mtudetect branch subtype13
von wo aus soll die MTU detection (subtype 13) später erfolgen ?
Auf den Routern über den WAN port.
Soll diese im fastd direkt eingebaut werden oder als externes Tool aufgerufen werden um die fastd-config zu ändern ?
ein externes tool bzw. watchdoog in der Firmware was dann entsprechend die conf von fastd anpasst und einen Restart des fastd daemon ausführt ist denke ich die einfachste und sinnvollste Lösung.
vg Tarek
Hi Tarek,
ich würde vorschlagen die MTU detection als Unix-daemon zu integrieren, sodass man Diesen relativ einfach per config ein- bzw. ausschalten könnte. Die fastd-config würde ich dann via 'uci' auslesen und setzen.
Wenn das OK ist würde ich diesen Weg weiterverfolgen.
Gruß
Tim
Am 13.03.2016 um 18:03 schrieb Jan-Tarek Butt via Dev:
On 03/13/16 16:17, Tim Leerhoff via Dev wrote:
Hi Tarek,
ich habe den Code soweit angepasst, dass der subtype 13 detektiert werden kann:
https://github.com/lethexa/mtudetect branch subtype13
von wo aus soll die MTU detection (subtype 13) später erfolgen ?
Auf den Routern über den WAN port.
Soll diese im fastd direkt eingebaut werden oder als externes Tool aufgerufen werden um die fastd-config zu ändern ?
ein externes tool bzw. watchdoog in der Firmware was dann entsprechend die conf von fastd anpasst und einen Restart des fastd daemon ausführt ist denke ich die einfachste und sinnvollste Lösung.
vg Tarek
Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
Hi,
ich würde vorschlagen die MTU detection als Unix-daemon zu integrieren, sodass man Diesen relativ einfach per config ein- bzw. ausschalten könnte. Die fastd-config würde ich dann via 'uci' auslesen und setzen.
Wenn das OK ist würde ich diesen Weg weiterverfolgen.
Das wäre der schönste weg :)
finde ich cool das du dir das vornimmst. Das kann eine großen effektiven Einfluss auf das Netz haben da sich dadurch die Pps sehr reduzieren könnte :)
vg Tarek
-
Jan-Tarek Butt -
Tim Leerhoff