FRITZ!OS7 openvpn auf 7590 => kein tun Modul

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 =)
 
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ß
 
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.
 
Zuletzt bearbeitet:
Zu Dokumentationszwecken:

In den 7490.07.11-Kernel-Sourcen sind alle BUG_ON's / drops weiterhin enthalten. Es ist also nicht ausschließen, dass diese auch bei den anderen Boxen weiterhin enthalten sind und aus der Tatsache, dass diese bei 7583.07.10 fehlen (die BUG_ON's), rein gar nichts in Bezug auf die anderen GRX5-Boxen geschlussfolgert werden kann.
 
Das ist eine schlechte Nachricht. Ich habe mich u.a. deshalb so abwartend verhalten, weil ich nach den Berichten zur 7560 die Hoffnung hatte, daß es ab 07.1x auch wieder ohne die Patches funktionieren würde.

So langsam kommt man sich auch verarscht vor, was den Umgang von AVM mit den OpenSource-Archiven angeht. Da kriegen die Dateien mal kurzerhand alle einen neuen Zeitstempel, damit man sich beim Mirroring möglichst viele Daten lädt? Ich kann damit leben, dank Flatrate und BTRFS-Dateisystem, wo ich auch einfach mit dem letzten Snapshot vergleichen kann, ob sich die Hash-Werte alter Archive geändert haben (was sie beim neuen Packen tun würden).

Keine Ahnung, ob AVM möglichst viel Traffic auf dem "osp.avm.de" verursachen will ... aber dieses Vorgehen mit den "einheitlichen" Zeitstempeln für das gesamte Verzeichnis ist dafür schon mal ein guter Ansatz, weil ich sicherlich nicht der Einzige bin, der den Server mit "wget -m" spiegelt. Schon für die Feststellung, ob/daß AVM an älteren Dateien geändert hat, muß man die halt erst mal komplett laden.

Wenn man zuviel Bandbreite hat bei AVM, dann einfach "weiter so" ... wenn man es sinnvoll machen will und tatsächlich auf die eigene Anbindung (und teilweise auch auf die der Kunden) Rücksicht nehmen will, wäre - sofern die Aktualisierung der Zeitstempel "unumgänglich" ist, obwohl auch da beim Kopieren vermutlich ein paar passende Optionen helfen könnten - die Bereitstellung einer Textdatei mit den Hash-Werten der Archive auch noch eine Alternative (wenn man sie auch pflegt) und zusätzlich noch eine Sicherung gegen Übertragungsfehler und absichtliche Verfälschungen.

Wie auch immer ... die Quellen für die GRX5-Boxen sehe ich da leider immer noch nicht (das ist Teil der erwähnten Verarschung), wenn man mal von der 7583 absieht und deren Verwendung für ALLE GRX-Boxen habe ich ja schon am Ende von #105 mehr oder weniger deutlich in Frage gestellt.

---------------------------------------------------------------------------------------------------------------------------------------

Ich habe jedenfalls bei den GRX5-Boxen immer noch nicht abschließend verstanden, ob die nun weiterhin die Patches brauchen oder nicht - bei @CaptainMorgan hatte sich das (wenn ich's richtig verstanden habe) auch mit IPv6 dann erledigt (auch ohne irgendeinen Patch), nachdem er die Box neu konfiguriert hatte und anstelle des "openvpn-gui" (was automatisch versucht, das "tap"-Device in die "lan"-Bridge einzubauen, wo das System sich dann bei ihm wohl aufhängt) das "openvpn-v2-gui" verwendet hat, was eben kein automatisches "brctl addif" enthält. Wie sich das am Ende auf die Funktion der OpenVPN-Tunnel auswirkt, hängt ja auch immer vom konkreten Fall ab ... lange nicht jede VPN-Verbindung muß tatsächlich L2-Pakete tunneln.

---------------------------------------------------------------------------------------------------------------------------------------

Sollten bei der 7490 die Patches weiterhin notwendig sein (ich habe selbst - außer beim betreuten Internetten und da kann/will ich nicht experimentieren - keine FRITZ!Box, auf der OpenVPN verwendet wird) und immer noch derselbe Code funktionieren, wie bei der 07.01, dann ist das wieder eine gute Nachricht. Ich kann zwar testen, ob die Patches funktionieren und die richtigen Stellen finden, aber ich kann nicht ermitteln, ob die Box ohne die Patches in Panik verfällt. Zumindest nicht ohne zusätzlichen Aufwand, den ich - derzeit - nicht brauche, weil die betreuten Boxen erst mal noch eine Weile bei 07.01 verharren werden, bis alle Fallstricke in der 07.11 geklärt sind.

Wenn sich also jemand mit einer 7490 mit 07.11 berufen fühlt, mal den Test zu machen, wie sich die Box ohne geladenes "yf_patchkernel" verhält, wäre ich dankbar - wer dazu eine "Anleitung" braucht, kann einfach das OpenVPN stoppen, mit "rmmod yf_patchkernel" das (beim automatischen Start) geladene Modul entfernen (mit "lsmod" überprüfen oder mit der Anzeige in "dmesg") und anschließend mit einem "mount -o bind" die Datei für das LKM mit irgendeiner leeren Datei ersetzen. Der Erfolg des "insmod"-Kommandos zum Laden des LKM wird nicht überprüft (https://github.com/Freetz/freetz/bl...n-v2-cgi/files/root/etc/init.d/rc.openvpn#L46) ... wenn das also wegen der leeren Datei nicht funktioniert, macht das Skript trotzdem weiter mit dem Start des OpenVPN. Allerdings riskiert man dann eben die "kernel panic" ... hat man die erwähnten Änderungen nur temporär vorgenommen (die sind ja auch nur ein "Prinzipvorschlag", wie man das auch ohne neues Images testen könnte und nicht konkret "ausgearbeitet", man sollte also die Kommandos kennen und etwas verstehen), ist ja beim nächsten Systemstart alles wieder Wölkchen und man hat obendrein noch das (Panic-)Log, in dem man schnell noch mal nachsehen kann, ob die Panik tatsächlich von einem der BUG_ON-Statements herrührte.
 
Hallo beieinander,

kurzes Feedback:
Habe für meine 7490 mit 7.11 ein Freetzimage gebaut (freetz-ng 15663) und auf die Box aufgespielt, OpenVPN läuft einwandfrei ohne Absturz, out of the box...ein externes Laden des yf_patchkernel Skripts über rc. costumer ist nicht mehr notwendig.

Danke an alle, gute Arbeit!

anbei meine .config zum Nachbauen
 

Anhänge

  • config.txt
    77.7 KB · Aufrufe: 12
Da auch in "freetz-ng" das "yf_patchkernel.ko" automatisch geladen wird (dort sogar im alten GUI für OpenVPN: http://trac.boxmatrix.info/freetz-n...nvpn-cgi/files/root/etc/init.d/rc.openvpn#L14 - ebenso im neuen: http://trac.boxmatrix.info/freetz-n...n-v2-cgi/files/root/etc/init.d/rc.openvpn#L39), sagt das leider nichts darüber aus, ob das LKM unter 113.07.11 (also für die 7490) auch wirklich notwendig ist - ohne "dmesg"-Ausgabe kann man leider nicht einmal sehen, ob die Patches alle ihr Ziel gefunden haben.

Da sich inzwischen aber die Symbole in den Konfigurationsdateien bei "freetz" und "freetz-ng" "auseinandergelebt haben", sollten Freetz-Benutzer #108 auch dahingehend sehr genau lesen, daß dort eben "freetz-ng" verwendet wurde - ich würde die Konfigurationsdateien weder mixen, noch wechselseitig verwenden ... zumindest nicht ohne weitere Vorbereitungen, die u.a. die jeweiligen Toolchain-Einstellungen anpassen könnten: https://github.com/Freetz/freetz/pull/55

Wer mit "Freetz" arbeitet, muß beim alten OpenVPN-GUI durchaus weiterhin selbst Hand anlegen, wenn es um das Laden des LKM geht ... der letzte Stand in "Freetz" ist immer noch dieser: https://github.com/Freetz/freetz/issues/93 - da das LKM bisher keine Zählung seiner Verwendung ermöglicht und beim V1-GUI mehr als eine Verbindung verwaltet werden kann, habe ich dort das Laden und Entladen der LKMs nicht geändert ... u.a. auch, um Einwänden keine Angriffsfläche zu bieten. Da im Moment mal wieder schlechte Stimmung ist, wird es von mir dort auch keine weiteren Änderungen geben.
 
Ich habe eine 7490 mit "freetz" auf 7.12 upgedatet. Hier der dmesg-Output:

Code:
[   77.010000][1][yf_patchkernel] Initialization started
[   77.010000][1][yf_patchkernel] Any preceding error messages regarding memory allocation are expected and may be ignored.
[   77.030000][1][yf_patchkernel] Patching kernel function 'ip_forward' at address 0x80530e40.
[   77.030000][1][yf_patchkernel] Found instruction to patch (0x8c820010) at address 0x80530e58, replaced it with 0x24020000.
[   77.050000][1][yf_patchkernel] Patching kernel function 'netif_receive_skb' at address 0x804da960.
[   77.050000][1][yf_patchkernel] Found instruction to patch (0x00020336) at address 0x804da974, replaced it with 0x00000000.
[   77.060000][1][yf_patchkernel] Patching kernel function '__netif_receive_skb' at address 0x804da8c0.
[   77.060000][1][yf_patchkernel] Found instruction to patch (0x00030336) at address 0x804da8c8, replaced it with 0x00000000.
[   77.060000][1][yf_patchkernel] 3 patches applied.

Und OpenVPN funktioniert, so wie es soll.
 
Zuletzt bearbeitet:
  • Like
Reaktionen: PeterPawn
Danke für die Info.
 
Hallo Ihr,

an dieser Stelle ein großes Danke.
Eine meiner 7490 (OpenVPN Client) kam nach Update auf 7.12 (von 6.x) in ein Bootloop.
Dank dieses Beitrags den insmod in die rc.custom und es läuft.
Ich verwende noch das V1 Interface und bin zu faul umzustellen :)

Auf der 7590 OpenVPN-Server-Box waren diese Anpassungen nicht notwendig. Da lief es auf Anhieb.

Besten Dank an PeterPawn
Wengi
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.