.titleBar { margin-bottom: 5px!important; }

FRITZ!OS7 openvpn auf 7590 => kein tun Modul

Dieses Thema im Forum "Freetz" wurde erstellt von CKone, 4 Aug. 2018.

  1. JokerGermany

    JokerGermany Mitglied

    Registriert seit:
    7 Aug. 2007
    Beiträge:
    495
    Zustimmungen:
    1
    Punkte für Erfolge:
    18
    Kurzes Feedback
    7590 mit 7.10 und stink normale OpenVPN Pakete installiert, die ich sonst auch installiere.
    Funzt! Kein Skript notwendig.
    Danke an alle, die das ermöglicht haben =)
     
  2. slashxxx

    slashxxx Neuer User

    Registriert seit:
    29 Mai 2017
    Beiträge:
    14
    Zustimmungen:
    0
    Punkte für Erfolge:
    1
    #102 slashxxx, 15 Apr. 2019
    Zuletzt von einem Moderator bearbeitet: 16 Apr. 2019
    Stimmt, super Arbeit :) vielen Dank für alle die unterstützt haben.

    Besondern Dank auch an PeterPawn
     
  3. Marthzion

    Marthzion Neuer User

    Registriert seit:
    21 Dez. 2008
    Beiträge:
    6
    Zustimmungen:
    0
    Punkte für Erfolge:
    1
    Besten Dank auch von mir!

    Schön, dass ich jetzt auf die aktuelle FW für die 7590 umsteigen konnte.

    Ich nutze die openVPN Verbindung gern um meinen Internet-Trafic über die heimische Fritzbox zu tunneln.
    Jetzt habe ich festgestellt, dass nach dem Einstellen einer Kindersicherung (Also das Zuweisen eines Zugangsprofils in der AVM-Oberfläche) für irgend ein Gerät dazu führt, dass die openVPN-Verbindung geblockt wird. Man erreicht noch die Fritzbox-Oberfläche, aber der Internetverkehr wird nicht mehr durch gelassen (So als würde die Fritzbox intern irgendwo der VPN-Verbindung das Zugansprofil "gesperrt" zuweisen).
    Mit der FW6.92 ging das noch problemlos.

    Kann das jemand bestätigen?
    Kann mir evtl. jemand einen Anhaltspunkt geben, in welcher Datei man hier was editieren kann? Die ar7.cfg scheint es nicht zu sein, denn da ändert sich m.E. nichts beim zuweisen von Zugangsprofilen.
    Nach was könnte man denn hier suchen. Bin etwas ratlos.
    Wäre dankbar für Anregungen :D

    Gruß
     
  4. Matthy

    Matthy Mitglied

    Registriert seit:
    23 Feb. 2005
    Beiträge:
    263
    Zustimmungen:
    0
    Punkte für Erfolge:
    16
    Ich kann das leider bestätigen. Hab mich schon gefragt warum es bei mir nicht mehr klappt. Es liegt tatsächlich an der Kindersicherung. :-(
     
  5. PeterPawn

    PeterPawn IPPF-Urgestein

    Registriert seit:
    10 Mai 2006
    Beiträge:
    11,899
    Zustimmungen:
    679
    Punkte für Erfolge:
    113
    Beruf:
    IT-Freelancer
    Ort:
    Berlin
    #105 PeterPawn, 18 Mai 2019 um 00:00 Uhr
    Zuletzt bearbeitet: 18 Mai 2019 um 00:11 Uhr
    Thema: Änderungen an yf_patchkernel.ko für 07.10 (bzw. Labor 07.08) auf GRX-Boxen

    So sieht es jetzt in den beiden "forward"-Funktionen aus (ermittelt anhand der 7580):
    Code:
    80abe594 27 bd ff c8                      addiu   sp,sp,-56
    80abe598 af b0 00 20                      sw   s0,32(sp)   
    80abe59c af bf 00 34                      sw   ra,52(sp)   
    80abe5a0 af b4 00 30                      sw   s4,48(sp)   
    80abe5a4 af b3 00 2c                      sw   s3,44(sp)   
    80abe5a8 af b2 00 28                      sw   s2,40(sp)   
    80abe5ac af b1 00 24                      sw   s1,36(sp)   
    80abe5b0 8c 82 00 20                      lw   v0,32(a0)     <=== das ist die zu patchende Operation in "ip_forward"
    80abe5b4 14 40 00 dc                      bnez   v0,0x80abe928
    80abe5b8 00 80 80 21                      move   s0,a0       
    80abe5bc 8c 82 00 6c                      lw   v0,108(a0)   
    80abe5c0 10 40 00 dd                      beqz   v0,0x80abe938
    80abe5c4 00 00 00 00                      nop               
    
    Code:
    80b342b8 27 bd ff 98                      addiu   sp,sp,-104 
    80b342bc af b2 00 48                      sw   s2,72(sp)       
    80b342c0 3c 12 80 e0                      lui   s2,0x80e0       
    80b342c4 26 52 47 80                      addiu   s2,s2,18304 
    80b342c8 af b0 00 40                      sw   s0,64(sp)       
    80b342cc 8e 42 02 bc                      lw   v0,700(s2)     
    80b342d0 af bf 00 64                      sw   ra,100(sp)     
    80b342d4 af be 00 60                      sw   s8,96(sp)       
    80b342d8 af b7 00 5c                      sw   s7,92(sp)       
    80b342dc af b6 00 58                      sw   s6,88(sp)       
    80b342e0 af b5 00 54                      sw   s5,84(sp)       
    80b342e4 af b4 00 50                      sw   s4,80(sp)       
    80b342e8 af b3 00 4c                      sw   s3,76(sp)       
    80b342ec af b1 00 44                      sw   s1,68(sp)       
    80b342f0 8c 91 00 60                      lw   s1,96(a0)       
    80b342f4 8c 42 00 00                      lw   v0,0(v0)       
    80b342f8 24 03 ff fe                      li   v1,-2           
    80b342fc 00 80 80 21                      move   s0,a0           
    80b34300 02 23 88 24                      and   s1,s1,v1       
    80b34304 10 40 02 d9                      beqz   v0,0x80b34e6c   
    80b34308 8c 94 01 b8                      lw   s4,440(a0)     
    80b3430c 8c 82 00 20                      lw   v0,32(a0)     <=== in "ip6_forward()" ist mehr Präambel (und mehr gesicherte Register) in der Funktion zu finden und die Instruktion steht damit weiter hinten
    80b34310 14 40 03 04                      bnez   v0,0x80b34f24   
    80b34314 00 00 00 00                      nop                 
    80b34318 8c 82 00 6c                      lw   v0,108(a0)     
    80b3431c 10 40 03 05                      beqz   v0,0x80b34f34   
    80b34320 00 00 00 00                      nop                 
    
    Ich hatte jetzt die Option, jeweils für eine FRITZ!OS-Version und ein FRITZ!Box-Modell passende Patches zu erstellen ... im Ergebnis gäbe es genauso viele unterschiedliche Quelltext-Dateien.

    Oder man packt das alles in eine Datei und läßt den tatsächlich benötigten Code durch "#define"-Statements einschließen bzw. den Rest ausschließen.

    Aber auch dazu muß das ja erst mal alles in einer Datei enthalten sein und dann kriegt man auf diesem Weg am Ende auch wieder ein LKM, welches nur genau für ein Modell und eine FRITZ!OS-Version funktioniert.

    Das widerspricht dann dem "probing"-Ansatz, den ich an anderer Stelle für dieses LKM reklamiert habe ... daher habe ich mich entschlossen, weiterhin ein einzelnes LKM zu erstellen und stattdessen lieber in diesem LKM anhand der Versionsinformationen (von AVM) die passende Patch-Liste auszuwählen.

    Das dauert dann (nicht nur im Test, sondern schon in der Implementierung) ein wenig länger ... es spart aber später Support-Aufwand ("Für welches System war dieses ko-File jetzt gleich nochmal?") und wenn mit der nächsten FRITZ!OS-Version die dritte Patch-Version einziehen sollte, sind die Strukturen schon vorhanden, um die Patches anhand der Version auszuwählen.

    Also ... noch etwas Geduld, ich bin am Thema dran. Wenn man parallel dazu noch sicher ermitteln könnte, warum es bei einigen funktioniert (sogar ohne LKM, wobei das dann wohl nur für "ipv4-only"-Installationen gilt, wenn ich das richtig verstanden habe) und bei anderen wiederum nicht, könnte ich entsprechende Erkenntnisse ggf. auch bei der Implementierung schon berücksichtigen.

    Ansonsten muß man eben warten ... wobei ich die Listen der beiden Funktionen oben nicht ganz ohne Hintergedanken eingebaut habe in diesen Beitrag ... wer es absolut nicht erwarten kann oder schon mal ohne LKM testen will, ob die Patches am Ende überhaupt helfen, der kann sich ja eines der alten Shell-Skripte (die stehen ja noch im Repo: https://github.com/PeterPawn/YourFritz/tree/master/patch_kernel) nehmen und die "devmem"-Patches auf diese zwei, oben gezeigten Stellen (da müssen dann hexadezimale Nullen rein, wie bei den ebenfalls zu sehenden "nop"-Instruktionen EDIT: das ist natürlich Bullshit, da muß das Laden von v0 mit 0 rein, also 0x24020000) ändern.

    Bei anderen Modellen könnten dann die Instruktionen aber wieder etwas anders aussehen (kann man auf der Box ja über "dd if=/dev/kmem" i.V.m. "hexdump" auslesen) und auch die Einsprungadressen sind sicherlich andere (siehe "/proc/kallsyms").

    Ob bei der 7560 am Ende der CBM von AVM verwendet wird oder nicht (theoretisch müßte der auch mit dem kleinen Chip verfügbar sein) und damit die Verschiebung beim Laden von "sk" über den Pointer nun 16 oder 32 Byte sind, habe ich auch noch nicht ermittelt - das LKM macht das dann wieder automatisch anhand der Sourcen (die es aber für die 7560, 7580 und 7590 ohnehin noch nicht gibt und gerade diese Frage "CBM oder nicht" kann man sicherlich auch nicht anhand der 7583-Quellen für die 7560 klären). Daher wird der LKM-Weg vermutlich auch erst dann für die anderen Modelle sauber funktionieren, wenn die entsprechenden Quellen von AVM bereitgestellt wurden.

    Wer es sich zutraut und auch mit IPv6 und OpenVPN unter 07.10 schon heute arbeiten will, der kann dann wenigstens mit einem der Shell-Skripte (diese zu "adaptieren", ist ja eher eine leichte Übung) schon mal testen, ob der Weg überhaupt der richtige ist. Zumindest scheint OpenVPN ja unter IPv6 bei der 07.10 nicht ohne weiteres zu funktionieren ... wobei ich da immer noch nicht richtig durchblicke, wer nun Probleme hat (nicht die Personen, sondern "mit welcher Konfiguration") und wer nicht.