FRITZ!OS7 openvpn auf 7590 => kein tun Modul

Hallo zusammen,
gibt es zu dem aktuellen Problem einen neuen Stand? Ich möchte von einer 7390 auf eine 7590 umziehen und benötige OpenVPN.

Otto
 
gibt es zu dem aktuellen Problem einen neuen Stand?
Kannst Du die Frage vielleicht etwas präzisieren, z.B. durch eine Beschreibung, was das aktuelle Problem ist?

Ich weiß, daß ich das LKM zum Patchen noch nicht fertig habe ... aber als "Problem" sehe ich das irgendwie nicht wirklich, denn man kann bis zu dessen Fertigstellung ja auch anders.
 
Hallo PeterPawn,
erst einmal Danke für Deine hervorragende Arbeit.

Ich habe mir über Freetz (make) ein Image für meine neue 7590 erstellt. Wenn ich versuche jetzt den VPN-Server zu starten sehe ich nachfolgende Fehlermeldung im Syslog.

upload_2019-1-7_17-46-39.png


Ich bin kein Spezialist und mache wahrscheinlich etwas falsch.
Zum Beispiel verstehe ich dieses Aussage nicht:
-freetz mit dem "devmem" Modul gebaut und auf die Box geflasht
Ist das eine Option, die ich im freetz (make menuconfig) nicht finde oder ist das ein Script?

Otto

//edit by stoney: Bild geschrumpft
 
Zuletzt bearbeitet von einem Moderator:
Hallo Shirocco88,
wo finde ich denn das "devmem"Modul?

Otto
 
Man muss das tun-Modul in die modules-Datei eintragen, damit es geladen wird.
 
Hallo zusammen,
jetzt habe ich den Faden verloren.

...tun-Modul in die modules-Datei eintragen
Was ist das tun-Modul? Wo finde ich die modules-Datei?

Otto
 
wo finde ich denn das "devmem"Modul?
nicht 'devmem' Kernel-Modul,
sondern das 'devmem' applet, welches man erhält wenn man den entsprechenden Zusatzfunktion beim Compilieren des Busybox Binaries im Freetz aktiviert;
zum Testen einfach den Befehl "busybox devmem" in der Rudi-Shell eingeben.

Was ist das tun-Modul?
das tun-Kernelmodul wird für Betrieb der tun-Schnittstelle und damit für Betrieb von OpenVPN im Tunnelmode benötigt;
den Pfad zum tun-Kernelmodul erhält man nach Eingabe folgenden Befehls: "find / -name tun.ko"
 
Zuletzt bearbeitet:
Hallo zusammen,
ich versuche immer noch OpenVPN auf meiner neuen 7590 am Laufen zu bekommen. Ich komme aber irgendwie nicht weiter.

den entsprechenden Zusatzfunktion beim Compilieren des Busybox Binaries im Freetz aktiviert;
Was muß ich hier tun? Ist das nur das?
upload_2019-1-11_20-10-23.png

Otto

//edit by stoney: Bild geschrumpft
 
Zuletzt bearbeitet von einem Moderator:
Ja, das würde reichen, damit die BusyBox mit dem "devmem"-Applet erstellt wird.

Das Kopieren des passenden Shell-Skripts in das eigene Image (inzwischen habe ich auch noch eines für die 7560 danebengelegt) und dessen Aufruf muß man aber weiterhin selbst organisieren ... das LKM verschiebt sich (noch weiter) und auch das müßte dann ja erst mal in den Build-Prozess integriert werden.
 
Guten morgen zusammen,
ich habe mir jetzt auf Basis eurer Hinweise ein neues Freetz-Image erstellt.

1. Das Tun-Modul wird meines Erachtens jetzt sauber geladen.

upload_2019-1-12_7-9-22.png

2. Test von "devmem" Applet . Ist meines Erachtens auch so OK.

sondern das 'devmem' applet, welches man erhält wenn man den entsprechenden Zusatzfunktion beim Compilieren des Busybox Binaries im Freetz aktiviert;
zum Testen einfach den Befehl "busybox devmem" in der Rudi-Shell eingeben.

upload_2019-1-12_7-18-0.png


3. Das Script von PeterPawn nach Freetz-rc.external kopiert.
upload_2019-1-12_7-12-45.png

4. Wenn ich jetzt den OpenVPN-Dienst starte erhalte ich als direkte Reaktion ein "failed" und im Syslog finde ich dazu nachfolgenden Eintrag.

upload_2019-1-12_7-20-57.png

Was mache ich falsch??

Otto

//edit by stoney: Bilder geschrumpft
 
Zuletzt bearbeitet von einem Moderator:
Ohne jetzt weiter auf den Rest einzugehen ... das Skript ist dazu gedacht, von irgendwoanders aufgerufen zu werden und nicht zum "Einbinden" durch Kopieren in ein anderes.

Das nur für den Fall, daß es irgendein zusätzliches Problem durch dieses Vorgehen geben sollte - das ist eine "Anwendung", die mir im Traum nicht eingefallen wäre.

Ansonsten sagt doch die Fehlermeldung schon vieles bzw. alles - allerdings solltest Du an die Stelle irgendwelcher Bilder ohnehin die Ausgabe einer Shell-Session als Text setzen. Dabei kann man dann auch gleich noch die verwendete Konfigurationsdatei anzeigen lassen (mittels "cat") und auch in Protokollen sieht man "im Text" viel mehr - Dir ist sicherlich aufgefallen, daß im Screenshot oben (auch den bindet man hier normalerweise als Thumbnail (aka Vorschau) ein und nicht direkt als "Vollbild") gar nicht alles zu lesen ist.

Zusätzlich zu den gezeigten Punkten solltest Du die Ausgabe von "lsmod" und "ls -l /dev/net" noch posten ... denn das erste Bild ist kein "Beweis" dafür, daß das "tun"-Device erfolgreich geladen wurde. Die (zusätzlich zu zeigende) Konfigurationsdatei sollte die Angabe eines Gerätes (das auch den "Modus" - L2 (tap) oder L3 (tun) - bestimmt) enthalten ... es könnte auch sein (ich habe keinen Bock, der Fehlermeldung in den OpenVPN-Quellen hinterherzurennen), daß diese Fehlermeldung das Ergebnis des fehlenden "clone device" für TUN/TAP-Devices (das wäre dann das "/dev/net/tun") ist - daher die zusätzlichen Prüfungen mit den beiden Kommandos oben.

Außerdem ergibt ja auch der Aufruf des Skripts eine Ausgabe auf "STDERR" bzw. "STDOUT" - beides gehört in den "Fehlerbericht" hinein. Vielleicht wäre es ohnehin klüger, wenn man den Start und die korrekte Funktion des OpenVPN-Daemons erst einmal "von Hand" testet und ihn nicht sofort bzw. "nur" in den normalen Systemstart einbindet - zumal das hier offenbar auch noch im Rahmen von "externals" geschehen soll.

Warum man letzteres auf einer 7590 überhaupt einsetzen wollte, ist mir schon einigermaßen schleierhaft - Platzprobleme im erzeugten Image sollten hoffentlich nicht der Grund sein (iirc sind 44 MB für die Dateisystempartition reserviert), ansonsten macht man irgendetwas falsch ... denn nur in sehr begründeten Ausnahmefällen dürfte das einen Sinn ergeben (ansonsten sollte man lieber andere Files - von HTML-Seiten bis zu Bilddateien - auf anderen Speicher auslagern, von denen beim "Ausführen" keine direkten Gefahren ausgehen können, wie von ausführbaren Dateien => Binaries, Bibliotheken, Shell-Skripte).
 
Hallo PeterPawn,
es tut mir leid, dass ich die Hardcopys falsch eingebunden haben. Ich bin leider bei diesem Thema ein Greenhorn.
Aber jetzt zurück zu dem Problem.

Ich habe "lsmod" und "ls -l /dev/net" im Terminal Fenster ausgeführt.
Hier die das Ergebnis: putty_log.txt.

Otto
 

Anhänge

  • putty_log.txt
    4 KB · Aufrufe: 19
Vielleicht greift ja ein Mod ein und macht aus den Bildern im Text die kleineren Varianten.

Hier die das Ergebnis: putty_log.txt.
Das sieht soweit gut aus, das Module ist geladen, das Device ist vorhanden und der Patch war (letztendlich) dann auch noch erfolgreich (man braucht ja nur einen und zwar den passenden für die eigene Box).

Was jetzt fehlt, ist der Start des Daemons und - sollte es immer noch nicht funktionieren - ebenso der Blick in die verwendete Konfigurationsdatei, wie in das erzeugte Protokoll.
 
Hallo PeterPawn,

ich habe das verregnete Wochenende im Münsterland noch einmal genutzt um mich intensiv mit meinem Problem auseinander zu setzen.

Ich habe nach vielen Probieren schlussendlich den Fehler gefunden. Es lag an der Auswahl für das OpenVPN-Paket. Dort hatte ich versehentlich den neuen Web-Gui ausgewählt. Dort muss man eine Konfigurationsdatei eingeben, was ich natürlich nicht getan hatte. Damit war beim Starten des Dienstes keine Konfiguration vorhanden und der Dienst crashte.

Jetzt läuft seit gestern Abend die Box und die VPN-Clients können sich ohne Probleme einwählen.


Nochmals vielen Dank für Eure Hilfe.

Otto
 
So, nun gibt es endlich das Kernel-Module (mit dem Namen "yf_patchkernel.ko"), welches beim Laden die drei Stellen im laufenden Kernel entsprechend patchen kann.

Man muß das nur vor dem Start des Datenverkehrs entsprechend laden ... entweder mit "modprobe" - sofern die "modules.dep" vorhanden ist und den Eintrag für dieses Module enthält - oder mit "insmod", wo man den Pfad zum ko-File angeben kann. Die ausgeführten Patches werden als Kernel-Messages protokolliert. Wenn man das LKM wieder entlädt (über "rmmod yf_patchkernel"), werden die Änderungen wieder rückgängig gemacht, auch das wird protokolliert.

Apropos Protokoll ... da dieses LKM nicht in der Module-Tabelle von AVM steht (das Patchen ist ja nur erforderlich, wenn man einen originalen AVM-Kernel verwenden will - sonst kann man gleich ohne die Traps übersetzen), gibt es beim Laden ein paar Fehlermeldungen von der Speicherverwaltung für den Kernel ... das ist nicht weiter tragisch und tatsächlich für jedes zusätzlich geladene LKM so - bei den GRX-Boxen, wo der "tun"-Driver nicht im Kernel enthalten ist, kann man dieses Phänomen auch für ihn beobachten. Wenn also beim Laden eines eigenen LKM Nachrichten wie diese auftauchen:
Code:
[module-alloc-by-name] give 0x1000 bytes at 0x8a672000 to module 'yf_patchkernel' (0xb6000 total bytes left)
module_alloc_size_list_alloc: error: module 'yf_patchkernel' reserved size 0 too small for demand size 4096 - need 4096 more (module_alloc_waste=-4096)
, dann ist das nicht weiter problematisch. Geladen wird trotzdem und der Code wird auch ausgeführt - das "error" ist hier eher eine Übertreibung - zumal der Platz für ein Datensegment ja offenbar doch reserviert wird, wie man an den 4 KB in der Message oben sehen kann.

Da sich die LKM für VR9- und GRX5-Boxen schon deshalb unterscheiden, weil das "sk"-Feld in der "sk_buff"-Struktur des Kernels an einem anderen Offset steht, braucht es (mind.) für jede Architektur ein gesondertes LKM - wobei bisher wohl nur die MIPS-Modelle betroffen sind vom AVM-Patch (der vermutlich ja auch mit der speziellen Hardware zusammenhängt). Für VR9 und GRX5 habe ich jedenfalls die vorübersetzten LKM auch im "yf_bin"-Repository hinterlegt - jeweils als "yf_patchkernel.ko" (mit separater Signaturdatei) in einem Unterverzeichnis mit der passenden Kernel-Version.

Ansonsten muß man ein paar Vorbereitungen treffen, wenn man sein eigenes LKM zusammen mit dem Freetz-Image erstellen will ... die notwendigen Patches habe ich in einem Branch "yf_patchkernel" meines Freetz-Klons zusammengestellt, den werde ich als Pull-Request für den Freetz-Master "annoncieren". Ob, wie und wann der dann im Freetz-Master landet, kann ich nicht beeinflussen.

============================================================

@er13: Meine Integration ist ein Vorschlag ... wenn Du das LKM anders integrieren möchtest, tu Dir keinen Zwang an. Sorge aber bitte dafür, daß als Ausgangsbasis für die C-Quelle des LKM dann die Datei aus dem YourFritz-Repo (im Unterverzeichnis "patch_kernel") verwendet wird und leicht aktualisiert werden kann - deshalb ist das bei mir eine getrennte Patch-Datei und auch ein solcher "patch" anstelle eines simplen "cp", weil ich keine anderen "Vorbereitungskommandos" für die Kernel-Sourcen kenne, die in Freetz verfügbar sein könnten.

Sollten weitere Patches notwendig werden, wäre diese Datei meine Ausgangsbasis und es liegt durchaus im Rahmen des Möglichen, daß ich da auch ansonsten noch ein paar Modifikationen (etwas mehr Dokumentation, ausführlicherer Header, ggf. sogar ein "proc"-Interface zur Abfrage der gepatchten Stellen und zur (De-)Aktivierung über ein Control-File auch ohne Entladen) vornehmen werde. Wenn Du Änderungen am Inhalt der C-Quellen möchtest, erstelle sie bitte Deinerseits als PR und nicht unbedingt als Patch bzw. als Änderung an der "900-patchkernel_source".

============================================================

Wer schon vorher die Änderungen in seinem Build berücksichtigen möchte (ich habe auch noch einen (ungetesteten) Patch des "rc.openvpn"-Files für das V2-CGI hinzugefügt, mit dem sowohl das "tun.ko" als auch "yf_patchkernel.ko" automatisch ge- und entladen werden beim Starten bzw. Stoppen von OpenVPN - zumindest solange die "ko"-Dateien unterhalb von "/lib/modules/$(uname -r)" zu finden sind beim Laden), der kann entweder den Branch "yf_patchkernel" meines "freetz"-Repos zum Checkout des Freetz-Masters hinzumischen oder er kann auch gleich den kompletten Checkout mit diesem Branch aus meinem Freetz-Repo machen. Dort nimmt man aber besser den richtigen Branch, denn der Standard dort ist der "YourFritz"-Branch und der enthält einige Änderungen, die ein Freetz-Benutzer eher nicht haben möchte (zumindest nicht so).

Getestet habe ich (das Patchen, nicht die Funktion mit OpenVPN) auf einer 7490 und einer 7580 - die Ausgaben sehen dabei dann zur Zeit in etwa so aus:
(7490)
Code:
root@FB7490:~ $ insmod /var/media/ftp/yf_patchkernel.ko
root@FB7490:~ $ dmesg -c
[  812.200000][1][module-alloc-by-name] give 0x1000 bytes at 0x81845000 to module 'yf_patchkernel' (0xcd000 total bytes left)
[  812.200000][1]module_alloc_size_list_alloc: error: module 'yf_patchkernel' reserved size 0 too small for demand size 4096 - need 4096 more (module_alloc_waste=-4096)
[  812.210000][1][yf_patchkernel] Initialization started
[  812.210000][1][yf_patchkernel] Any preceding error messages regarding memory allocation are expected and may be ignored.
[  812.220000][1][yf_patchkernel] Patching kernel function 'ip_forward' at address 0x805468e0.
[  812.220000][1][yf_patchkernel] Found instruction to patch (0x8c820010) at address 0x805468f8, replaced it with 0x24020000.
[  812.240000][1][yf_patchkernel] Patching kernel function 'netif_receive_skb' at address 0x804efa20.
[  812.240000][1][yf_patchkernel] Found instruction to patch (0x00020336) at address 0x804efa34, replaced it with 0x00000000.
[  812.250000][1][yf_patchkernel] Patching kernel function '__netif_receive_skb' at address 0x804ef980.
[  812.250000][1][yf_patchkernel] Found instruction to patch (0x00030336) at address 0x804ef988, replaced it with 0x00000000.
[  812.250000][1][yf_patchkernel] 3 patches applied.
root@FB7490:~ $ rmmod yf_patchkernel
root@FB7490:~ $ dmesg -c
[  829.840000][0][yf_patchkernel] Deinitialization started
[  829.840000][0][yf_patchkernel] Reversed patch in 'ip_forward' at address 0x805468f8 to original value 0x8c820010.
[  829.840000][0][yf_patchkernel] Reversed patch in 'netif_receive_skb' at address 0x804efa34 to original value 0x00020336.
[  829.840000][0][yf_patchkernel] Reversed patch in '__netif_receive_skb' at address 0x804ef988 to original value 0x00030336.
[  829.840000][0][yf_patchkernel] All applied patches have been reversed.
[  829.840000][0]release_bug_debug_table: warning: 'yf_patchkernel' not found! (driver maybe bugfree)
root@FB7490:~ $
(7580)
Code:
# insmod /var/media/ftp/yf_patchkernel.ko
# dmesg -c
[  193.152000] [yf_patchkernel] Initialization started
[  193.152000] [yf_patchkernel] Any preceding error messages regarding memory allocation are expected and may be ignored.
[  193.212000] [yf_patchkernel] Patching kernel function 'ip_forward' at address 0x80ab97a4.
[  193.212000] [yf_patchkernel] Found instruction to patch (0x8c820020) at address 0x80ab97c0, replaced it with 0x24020000.
[  193.268000] [yf_patchkernel] Patching kernel function 'netif_receive_skb' at address 0x80a62474.
[  193.268000] [yf_patchkernel] Found instruction to patch (0x00020336) at address 0x80a62498, replaced it with 0x00000000.
[  193.320000] [yf_patchkernel] Patching kernel function '__netif_receive_skb' at address 0x80a623f0.
[  193.320000] [yf_patchkernel] Found instruction to patch (0x00030336) at address 0x80a623f8, replaced it with 0x00000000.
[  193.320000] [yf_patchkernel] 3 patches applied.
# rmmod yf_patchkernel
# dmesg -c
[  205.012000] [yf_patchkernel] Module will be removed now.
[  205.012000] [yf_patchkernel] Reversed patch in 'ip_forward' at address 0x80ab97c0 to original value 0x8c820020.
[  205.012000] [yf_patchkernel] Reversed patch in 'netif_receive_skb' at address 0x80a62498 to original value 0x00020336.
[  205.012000] [yf_patchkernel] Reversed patch in '__netif_receive_skb' at address 0x80a623f8 to original value 0x00030336.
[  205.012000] [yf_patchkernel] All applied patches have been reversed.
[  205.012000] release_bug_debug_table: warning: 'yf_patchkernel' not found! (driver maybe bugfree)
#

Sofern es jetzt keine gravierenden Probleme mit der Funktion des LKM gibt, ist das Thema für mich erst einmal gegessen ... bis es mich mit dem "proc"-Interface vielleicht noch einmal packt. Da man nach längerer Laufzeit in den Kernel-Messages die Nachrichten vom Laden nicht mehr finden wird und auch die Tatsache, daß das LKM dann in der Ausgabe von "lsmod" erscheint, nicht unbedingt etwas über den Erfolg der einzelnen Patches aussagt (es sind ja drei unabhängige Stellen), kann man nach einiger Zeit nicht mehr ohne weiteres feststellen, ob das Patchen erfolgreich war oder nicht ... und genau dafür würde dann ein "procfs"-Interface noch Sinn ergeben, über das man den Status im Nachhinein noch abfragen kann.

Aber das ist "Zukunftsmusik" und funktionieren sollte es auch im derzeitigen Zustand. Solange AVM keine weiteren Änderungen vornimmt, sollte das auch so bleiben. Die Tatsache, daß das LKM einfach so in eine Code-Seite im Speicher schreiben kann (selbst wenn es die Rechte dazu nur hat, weil es als Bestandteil des Kernels läuft, könnten bzw. sollten die Code-Seiten im Speicher natürlich gegen Schreibzugriffe geschützt sein und erst freigeschaltet werden müssen), zeigt auch ein klein wenig "Schlamperei" bei der Speicherverwaltung - aber das soll bei anderen MIPS-Geräten ja auch nicht besser aussehen: https://www.heise.de/security/meldu...ablierten-Sicherheitsmechanismen-4268046.html (Kurzlink: https://heise.de/-4268046). Trotzdem könnte das natürlich für AVM auch ein Anlaß sein, den Speicherschutz für Kernel-Code irgendwann mal zu aktivieren ... es ist sicherlich leichter, wildes Schreiben per Exploit auszulösen als ein geordnetes Aufheben eines Schreibschutzes. Für einen Teil des I/O-Memory versucht das AVM ja offenbar schon, wenn ich die Absichten richtig verstehe in der "arch/mips/avm_enh/avm_writeprotect.c" bei den GRX-Modellen.
 
Die Dateien liegen als Modules im Repository "yf_bin" - oben ebenfalls verlinkt. Das für die 7490 aktualisiere ich gleich noch einmal mit einem "Zwischenstand" auf dem Weg zu einer neuen Version, weil mir da eine ältere aus der Entwicklung untergekommen ist und die Nachrichten im Kernel-Log dabei andere waren (s. #76).

EDIT: Der in "YourFritz" als "bin"-Submodule verlinkte Stand ist nicht der aktuelle aus "yf_bin" - da ohnehin in nicht allzu weiter Ferne noch weitere Änderungen am C-Source-Code anstehen, lohnt sich da das Update im Moment nicht. Also bitte die beiden Kernel-Module (es gibt sie bisher von mir nur für 3.10.104 (GRX5) und 3.10.107 (VR9) vorkompiliert) direkt aus "yf_bin" verwenden, wenn man sie nicht selbst übersetzen will.

Ansonsten "heißt" der erste Link weiter oben zwar "yf_patchkernel.ko", der führt aber absichtlich nur zur Quell-Datei. Vielleicht hätte ich da auch den "Text" besser "yf_patchkernel.c" genannt, aber m.E. sollte das aus dem weiteren Text auch hervorgehen, wo man die Binärdateien findet.
 
Zuletzt bearbeitet:
Hallo zusammen!

könnte jemand höflicher weise an einem kurzen HOWTO (2-3 Sätze reicht auch), erläutern wie DAUs (wie ICH ;D)
das Kernel-Module (yf_patchkernel.ko) zum laufen bekommen.

klappt es auch bei den Betas (7.08?) und der 7590?

Vielen Dank und Grüße
 
Das kommt darauf an, bei welchem Stand von "Freetz" man beginnt - der erste Unterschied liegt schon darin, ob man bereits ein eigenes Freetz-Image erstellt hat (und damit eine Build-Umgebung hat, die auf "Freetz/freetz" (auf GitHub) basiert) oder ob man die erst neu erstellen will/muß und dafür gleich "PeterPawn/freetz" (Branch "yf_patchkernel") als Basis für das Klonen verwendet. Daher wäre es schön, wenn die "Voraussetzungen" (sprich: die bereits vorhandene Umgebung und vorhandene Kenntnisse) für so eine Beschreibung etwas konkreter gefaßt wären - das erspart (schon im ersten Punkt) mind. die Hälfte der Schreibarbeit (denn in den weiteren wird das nur wenig anders).
 
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.