OpenVPN-Server(Bridge) auf 7560-IPClient (Fritz-OS 7.01-Freetz15014)

[feedzapper]

Habe den Patch eben auch getestet - er funktioniert "PeterPawn" - Danke !
Die Box läuft nun durch mit OS 7.01 und OpenVPN...
Der Aufruf erfolgt über die "rc.custom"
Leider ist ein Tippfehler ganz oben im Script ...
#! /bin/sh ... statt #!/bin/sh
deshalb wurde er über die rc.custom nicht richtig ausgeführt...

https://github.com/PeterPawn/YourFritz/blob/master/patch_kernel/patch_kernel_7560_skbuff_sk_checks

 

[PeterPawn]

Leider ist ein Tippfehler ganz oben im Script ...
#! /bin/sh ... statt #!/bin/sh
deshalb wurde er über die rc.custom nicht richtig ausgeführt...

Sorry, aber das wäre etwas vollkommen Neues und auch eher kein Problem des Skripts, wenn wirklich irgendeine Implementierung an dieser Stelle KEIN Leerzeichen versteht.

Der Linux-Kernel gehört da jedenfalls nicht dazu, denn dort wird in dieser Zeile:

https://elixir.bootlin.com/linux/latest/source/fs/binfmt_script.c#L56

for (cp = bprm->buf+2; (*cp == ' ') || (*cp == '\t'); cp++);

ab der dritten Position in einer Zeile mit einem She-Bang nach dem ersten Zeichen gesucht, das kein Leerzeichen und kein Tabulator ist ... wird ein solches nicht gefunden, fehlt der Name des auszuführenden Programms (siehe der restliche Code in der verlinkten Quelldatei).

Ich weiß also nicht, wer Dir diesen Bären aufgebunden hat - aber das kann man ja auch ganz einfach selbst testen, indem man sich eine Datei mit einem She-Bang mit und ohne Leerzeichen erstellt und diese jeweils versucht aufzurufen (das Programm muß ja auch nicht "/bin/sh" sein). Solange man dabei die Rechte auch noch richtig gesetzt hat, sollte das alles kein Problem darstellen. Für die automatische Erkennung im Kernel (in der oben verlinkten binfmt-Auswertung) müssen die "executable"-Rechte vorhanden sein für den aufrufenden Benutzer - auch wenn diese sich aus den Rechten für "group" oder "others" ergeben dürfen.

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

Aber die Skript-Dateien interessieren (mich zumindest) inzwischen ohnehin nicht mehr, weil das LKM nunmehr fertig ist - damit braucht man keine BusyBox mit "devmem"-Applet mehr und die Änderungen werden beim Entladen des LKM auch wieder rückgängig gemacht - für mich die bessere Lösung (siehe https://github.com/Freetz/freetz/pull/66).

 

[feedzapper]

Es war mein Fehler mit dem Skript Aufruf - habe es nochmals analysiert gehabt.
Aber wie Du schon geschrieben hast, dass mit dem Skript ist nun obsolete - auch bei mir.
Ich verwende nun deinen LKM von hier :

https://github.com/PeterPawn/yf_bin/blob/master/target/mips/3.10.104/yf_patchkernel.ko

Er läuft prima - keine Probleme damit
Wie habe ich ihn eingebunden ?

1. Das Modul per SCP auf die Box kopiert nach /var/tmp/flash
2. Auf der Box im Shell "modsave" um den File im flash zu speichern.
3. Im Freetz WebIF in der rc.custom eingetragen :
insmod /var/tmp/flash/yf_patchkernel.ko

das wars.
Nochmals Danke für das LKM !

PS : Es sollte ja dann auch so wie oben beschrieben auf einer 7590 laufen ?!

 

[PeterPawn]

Gern geschehen ... im Moment bin ich etwas unsicher, wie das mit Freetz weitergehen wird.

Von @er13 gab es praktisch seit Anfang Dez. 2018 keinen Commit mehr (das letzte Lebenszeichen hier im IPPF stammt auch von vor Weihnachten) und @Whoopie hat den Abschied "offiziell" verkündet.

Damit bleiben aktuelle Änderungen liegen ... neben der 6490 mit den Quellen für die 07.01 - hier der PR von @f666 - trifft das auch die Integration von yf_patchkernel.c in einen Freetz-Build und es hängt alles etwas in der Schwebe.

Wenn es wenigstens die definitive "Absage" gäbe für weiteres Engagement ... dann könnte man sich auch Gedanken machen, wer stattdessen in die Bresche springen kann. So bleibt derzeit nur, entsprechende Forks des Freetz-Repo als "Konkurrenz" zu betreiben.

Man muß sicherlich auch nicht jede Zwischenversion bei jedem Paket "mitnehmen" ... wenn man obendrein die Pakete insgesamt auf die tatsächlich (in nennenswertem Umfang) verwendeten "eindampft", hat man automatisch auch noch weniger Änderungen am Projekt vorzunehmen - allerdings müßten dann die Benutzer mit den exotischeren Paketen sich selbst um deren Aktualisierung kümmern.

Kombiniert man das dann noch mit einigen Zusatzskripten, die z.B. die jeweils aktuelle Labor-Version automatisch in die (lokale) Konfiguration einbauen, spart man sich weitere Aktivitäten, solange die AVM-Änderungen unter einer bestimmten Schwelle bleiben. Nur wäre es dann sicherlich für viele Freetz-Benutzer auch hilfreich, wenn man entsprechende Skripte (für die JUIS-Abfrage und die Änderungen an den Kconfig-Eingabedateien) schon im Freetz-Master anbietet.

 

[CaptainMorgan]

Ich bräuchte vielleicht noch etwas Hilfe bei meiner konkreten Konfiguration.

Nochmal ein Recap zu meiner Situation:
OpenVPN läuft auf einer FB7560 7.01. Diese ist aus Stabilitäts und WLAN Gründen allerdings kein Router/eigener DHCP.
Grund der Installation war das die AVM Software sich mit Shrewsoft gebissen hat, die aus anderen Gründen brauchte, und mit den neuesten AVM und Windows Updates ist auch das sehr wackelig geworden.
Aus Loadbalancing Gründen wollte ich dann für alle Android Clienten den AVM eigene Lösung im Router verwenden, und für alle Windows Clienten OpenVPN.
Die Verbindung wird auch aufgebaut, ich kann alle Geräte pingen, auf interne http-Server zugreifen und auch Sambashares funktionieren
Ping ist von meinem momentanen Standort 25ms, der Upload von leider 10 Mbit kann von der 7560 mit AES-256 voll ausgelastet werden.

Was nicht funktioniert ist RemoteDesktop.
Die beiden verwendeten Maschinen funktionierten vorgestern und lokal noch tadelos zusammen, über OpenVPN tun sie es jetzt nicht mehr.
Das Paranoide ist, dass die Passwortabfrage funktioniert. Wenn ich vorab mein Android per VPN-RDP einlogge, was tadellos funktioniert wird dieses sogar rausgeschmissen wenn ich vom Laptop eine RDP-Verbindung aufbaue.
Wenn ich über Android AVM-VPN-RDP auf der stationären Maschine versuche meinen Laptop zu "RDPen" (Inceptioin quasi), passiert genau das gleiche. Mein Laptop wird lokal ausgeloggt, und das RDP Fenster öffnet sich, bleibt aber schwarz.
Wenn ich über Android in den Laptop will, funktioniert das auch. Sowohl "auswärts lokal" als auch bei Verwendung der VPN IP. Ob es aber wirklich durch 2 VPN Tunnel funktioniert oder die Adresse vorher aufgelöst wird kann ich nicht genau sagen. Habe weder ein gerootetes Android noch hier "auswärts" Zugriff auf den Router.
Windows liefert weiter keine sinnvollen Hinweise. Entweder wird man schlichtweg abgetan mit "Es ist ein Interner Fehler" aufgetreten oder aber es wird auf eine "schlechte Netzwerkkonnektivität" hingewiesen. Fürs Testen sind beide Windows Maschinen aber über Ethenert an 50/10er Verbindungen, was nicht großartig ist aber stabil und schnell genug.

Die mir bekannt ist das RDP intern UDP verwendet, was ja aber grundsätzlich kein Problem sein sollte, wollte ich darauf umstellen. Habe sowohl die Server und Clienten configs darauf umgestellt und auch die Portfreigaben im Router, leider bekomme ich so aber gar keine Verbindung aufgebaut. TCP hatte ich ursprünglich gewählt weil ich mir bei den niedrigen Bitraten relativ sicher war das die Box den Overhead gut handeln kann, was sich ja auch im Nachhinein als richtig rausgestellt hat.

Hat irgendjemand eine Idee was heir schiefläuft?

 

[Shirocco88]

@CaptainMorgan
getreu nach dem Motto "ein Bild sagt mehr als 1000 Worte" schlage ich vor, du skizierst das gewünschte Szenario, gerne auch Netzwerk-Chart;
dann ist das Design leichter zu validieren und man kann mehr sagen.

 

[CaptainMorgan]

Naja, das Netzwerk Chart dazu ist ziemlich langweilig, bin mir nicht sicher wie das zu missverstehen war:

FB7320SL ----LAN1---- FB7560 ---- LAN 2 ----- Computer
(Modem, Router) (Switch, WLAN-AP, OpenVPNServer)


Wenn du unter Netzwerk Chart etwas anderes verstehst oder aber gerne irgendwelche Logs oder die genauen Einstellungen wissen willst kann ich die jederzeit nachiefern.

Edit:

Jetzt bin ich vollkommen verwirrt.
Durch resilentes immer wieder probieren habe ich es jetzt zweimal, gestern Abend und heute Mittag, geschafft eine Verbindung aufzubauen, die dann auch wunderbar paar Minuten funktioniert, bis das Fenster wieder schwarz wird.


Edit 2:
Was seltsam ist, die Remote Maschine taucht im Router aucht zweimal auf, mit zwei verschiedenen IP's. Ist das ein Hinweis?

 

[Shirocco88]

OpenVPN läuft auf einer FB7560 7.01. Diese ist aus Stabilitäts und WLAN Gründen allerdings kein Router/eigener DHCP.

nur um sicher zu sein, die FB7560 ist im "IP-Client-Mode" konfiguriert und in FB7320SL ist ein Port-Forwarding für die OpenVPN-Ports nach FB7560 eingerichtet ?

aber gerne irgendwelche Logs oder die genauen Einstellungen wissen willst kann ich die jederzeit nachiefern.

bitte OpenVPN-Config von FB7560 und die OpenVPN-Logfiles posten;

sowie IP-Config von FB7560:

/sbin/ifconfig -a
/sbin/route -n
/sbin/showroutes -A
/sbin/showaddrs
/usr/sbin/brctl show
/bin/netstat -naulp
/bin/netstat -natlp

Was seltsam ist, die Remote Maschine taucht im Router aucht zweimal auf, mit zwei verschiedenen IP's.

Bitte Screenshot hierzu liefern, ggf. public-IP, DynDNS-Name "aus-pixeln"..

 

[CaptainMorgan]

Ich habe auf PeterPawns Anraten jetzt dazu ein neues Fass aufgemacht, werde das ganze da beackern.. Hier ging es ja primär um das erstellen eines tun-patches auch für die 7560, und so soll es denke ich auch blieben.

Dennoch:

nur um sicher zu sein, die FB7560 ist im "IP-Client-Mode" konfiguriert und in FB7320SL ist ein Port-Forwarding für die OpenVPN-Ports nach FB7560 eingerichtet ?

Ja und ja, im Moment fürs TCP Protokoll auf Port 11194. Für ipv4 und ipv6.

bitte OpenVPN-Config von FB7560 und die OpenVPN-Logfiles posten

Ersteres ist bereits im Thread, und von zweitem weiß ich nicht genau was damit gemeint ist.

sowie IP-Config von FB7560

Liefere ich nachher nach.

sowie IP-Config von FB7560

Habe ich im neuen Thread ausführlich erklärt, benötigt eigentlich keinen Screenshot. Dieselbe Maschine taucht in der Netzwerktabelle unter zwei IP's und zwei MacAdressen auf, einmal der der Netzwerkkarte und einmal der des virtuellen Adapters.

 

[CaptainMorgan]

Hat sich für die 7560 und F!OS 7.10 etwas geändert?
Habe einen aktuellen Pull aus dem Freetz Master verwendet
Ohne Peters Patch, egal bei welcher GUI funktioniert es nicht:
Immer "daemon.err openvpn[9571]: ERROR: Cannot open TUN/TAP dev /dev/net/tun: No such file or directory (errno=2)".
Das Skript gibt es folgende Meldung:

Found supported firmware version .
Found symbol 'netif_receive_skb' at memory address 0x80A66940.
Looking for TNE instruction with max. distance of 15.
Bus error
Error reading memory content with 'devmem' applet, make sure it's available.

Starte ich OpenVPN nach Einsatz des Skriptes kommt es zur Kernel Panic.

Weiß irgendjemand was genau der Stand der Dinge ist?

Hatte in ein paar verfolgten Threads überflogen dass es wohl für die 7590 bei Wahl der gui-v2 mittlerweile "automatisch" gehen soll, und kein Patch mehr nötig sein soll. Weiß jemand ob das sich auch auf die 7560 erstreckt?

 

[feedzapper]

Hat sich für die 7560 und F!OS 7.10 etwas geändert?
Habe einen aktuellen Pull aus dem Freetz Master verwendet

Du benötigst keinen Patch mehr. Das "yf_patchkernel.ko" Modul wird automatisch in Freetz im Menueconfig mit eingebunden, wenn Du das Openvpn Paket anwählst. Lediglich das "tun" Modul ist noch per Hand unter Module im Freetz WebIF einzutragen.
Allerdings verwende ich freetz-ng. Bei freetz-devel sollte es eigentlich gleich sein.

 

[CaptainMorgan]

Lediglich das "tun" Modul ist noch per Hand unter Module im Freetz WebIF einzutragen.

Das wäre "modprobe -tun"?
Oder wie würde man das machen?
Vielleicht kannst du mir schnell einen Tipp geben...

Edit:
Wenn ich über die Rudi-Shell modprobe tun eingebe, und dann den OpenVPN daemon starte, schmiert der Großteil der Box ab. Netzwerkdurchsatz ist noch aber weder Freetz-GUI noch AVM-GUI antworten...
Edit2: Sogar auf einen ping antwortet die Box nicht mehr, andereseits mache ich gerade diesen post von einem PC für den die Box der Switch ist, also daher....
Edit 3: Das Laden des Modul's über das Freetz WebIF (hat ne Weile gedauert bis ich das gefunden habe), scheint zu funktionieren (zumindest genauso gut wie modprobe tun). Denn beim Starten von OpenVPN erlebe ich wieder den gleichen Crash.

Muss man dafür die neue GUI verwenden?

 

[feedzapper]

Einfach hier rein und gut :



So stellst du auch gleich sicher, dass es auch nach einem Neustart der Box RECHTZEITIG geladen wird.
Und zwar BEVOR openvpn startet ...
Yep, alternativ modprobe.

 

[CaptainMorgan]

Da hab ichs letzendlich auch reingemacht?
Funkioniert das bei dir bei einer 7560?
Ich bekomme da das oben beschriebene Verhalten.
Ist dafür denn zwangsweise die "neue" Gui notwendig?
Alles aus die Grundfunktionen stürzt danach bei mir ab.
Syslog hilft leider nicht weiter....

 

[PeterPawn]

Ist dafür denn zwangsweise die "neue" Gui notwendig?

Ja - denn nur in dieser neuen GUI ist das automatische Laden des Patch-LKM enthalten: https://github.com/Freetz/freetz/bl...n-v2-cgi/files/root/etc/init.d/rc.openvpn#L41

Nein - denn man kann das Laden des LKM natürlich auch in den Start mit dem anderen GUI einbauen: https://github.com/Freetz/freetz/blob/master/make/openvpn-cgi/files/root/etc/init.d/rc.openvpn

Oder man lädt das Module zum Patchen ebenfalls aus "Freetz-Modules" ...

Oder ...

Such Dir die passende Antwort aus ... aber (@All) erwartet bitte nicht, daß ich auch Support für "freetz-ng" leiste.

Außerdem wäre es nett, wenn an solche Problembeschreibungen wieder die Konfigurationsdatei angehangen wird - es macht vieles leichter und erspart so manche Rückfrage. Wenn dann jemand antworten könnte, dazu aber noch Infos aus dieser Datei zur Verifikation bräuchte und so gar keine Lust hat, das noch einmal festzuhalten und damit beim Fragesteller "nachzuhaken", vergibt man auch als Fragesteller die Chance auf entsprechende Antworten, ohne es zu merken ... nicht immer wird das nochmal jemand so deutlich hier festhalten, wie ich es gerade tue.

 

[CaptainMorgan]

Nein - denn man kann das Laden des LKM natürlich auch in den Start mit dem anderen GUI einbauen: https://github.com/Freetz/freetz/blob/master/make/openvpn-cgi/files/root/etc/init.d/rc.openvpn

"Man" kann bestimmt, warum "man" nicht tut weiß ich ich nicht. Ebenso übersteigt es meine Fähigkeiten.

Oder man lädt das Module zum Patchen ebenfalls aus "Freetz-Modules" ...

Ich habe yf_patchkernel mit ins Web-IF eingetragen, das hat nichts geändert. Oder war damit etwas anderes gemeint?
Ich versuche jetzt meine Konfiguration irgendwie zu sichern und dann probiere ich die neue GUI, auch wenn ich nicht sehe wieso diese eine Verbesserung ist

Such Dir die passende Antwort aus ... aber (@All) erwartet bitte nicht, daß ich auch Support für "freetz-ng" leiste.

Hat niemand verlangt, weder explizit noch unterschwellig. War lediglich ein disclaimer von feedzapper.

Außerdem wäre es nett, wenn an solche Problembeschreibungen wieder die Konfigurationsdatei angehangen wird - es macht vieles leichter und erspart so manche Rückfrage. Wenn dann jemand antworten könnte, dazu aber noch Infos aus dieser Datei zur Verifikation bräuchte und so gar keine Lust hat, das noch einmal festzuhalten und damit beim Fragesteller "nachzuhaken", vergibt man auch als Fragesteller die Chance auf entsprechende Antworten, ohne es zu merken ... nicht immer wird das nochmal jemand so deutlich hier festhalten, wie ich es gerade tue.

Vermerkt.

 

[PeterPawn]

Wenn Du Freetz (genuine) verwendest und trotz des Ladens von "yf_patchkernel" nach "tun" immer noch Abstürze verbuchen mußt, dann suche bitte aus der "dmesg"-Ausgabe (die kann man von Hand in der Shell ansehen oder aus den Support-Daten heraussuchen) nach den Meldungen, die vom "yf_patchkernel" ausgegeben wurden, ebenso nach dem "panic.log" (beim nächsten Start auslesbar), wenn man das OpenVPN startet und die Box abstürzt.

Das LKM patcht ja direkt die Maschinenbefehle, die an den fraglichen Stellen im AVM-Kernel durch diese "BUG_ON"-Statements erzeugt werden. Da gibt es dann mehrere Möglichkeiten (m.W. gibt es noch keine 07.10-Sources von AVM) ... es kann sich an der Reihenfolge der Befehle bei AVM etwas geändert haben (das sieht man dann in den Messages des LKM, wenn die Stelle zum Patchen nicht gefunden wird) oder AVM hat am Ende gar weitere Stellen im Kernel mit solchen Pitfalls gespickt und der Absturz erfolgt an einer dieser neuen Stellen (das sieht man dann wieder im "panic.log").

Ich habe das bisher auch noch nicht selbst für die 7580 getestet ... wenn ich nachher Zeit finde, schaue ich es mir bei diesem Modell mal an. Ob sich das dann auf die 7560 übertragen läßt, kann ich nicht sagen ... wobei man ohnehin erst mal erkunden muß, was nun tatsächlich das Problem ist. Wäre das tatsächlich eher ein generelles, hätte ich bei der 7590 (die hatte ja zuerst die 07.10) schon deutlich mehr Rückmeldungen der Art "geht nicht mehr" erwartet ... diese wären mir zumindest bisher (selbst bei "freetz-ng" ) entgangen.

EDIT:

Hat niemand verlangt, weder explizit noch unterschwellig.

Deshalb gibt es meinerseits in dem Satz auch ein "@all" - das richtete sich explizit nicht (nur) an Dich und war mehr "Werbung" für Verständnis, daß man nicht auf allen Hochzeiten gleichzeitig tanzen kann.

 

[CaptainMorgan]

Habe jetzt die neue GUI geladen, da startet OpenVPN zumindest, wenn ich die beiden Module im Web-IF eintrage.
Leider geht meine Konfiguration damit flöten, und ich muss jetzt entweder Zeit investieren dass wieder auszuknobeln,
oder:

Wenn Du Freetz (genuine) verwendest und trotz des Ladens von "yf_patchkernel" nach "tun" immer noch Abstürze verbuchen mußt, dann suche bitte aus der "dmesg"-Ausgabe (die kann man von Hand in der Shell ansehen oder aus den Support-Daten heraussuchen) nach den Meldungen, die vom "yf_patchkernel" ausgegeben wurden, ebenso nach dem "panic.log" (beim nächsten Start auslesbar), wenn man das OpenVPN startet und die Box abstürzt.

... ich versuche rauszubekommen warum die alte GUI nicht funktioniert.
Das erscheint mir zielführender, allerdings bin ich mir nicht im Klaren, ob denn "in der Theorie" diese überhaupt so, mit dem expliziten Laden der beiden Module, funktionieren sollte oder nur könnte.
Dem Zitat entnehme ich dass es eigentlich sollte, sprich dass das das zu erwartende Verhalten wäre.

Wie gesagt konnte ich die tatsächliche Funktion, im Sinne einer stabilen Verbindung noch nicht testen, aber scheinbar funktioniert ja der Patch auch bei der 7560, openvpn startet ja inklusive tun/tap device.

Wenn ich die alte GUI nochmal einspiele, werde ich mich nach panic.log, dmesg und .config umschauen.

 

[PeterPawn]

Entscheidend ist nur, daß beide LKM geladen werden ... und daß das vor dem Start von OpenVPN erfolgt. Ist eines (oder beide) bereits geladen, wenn es im Zuge des Starts in "rc.openvpn" erneut geladen werden soll, passiert nichts weiter, weil der Erfolg des Ladens nicht getestet wird: https://github.com/Freetz/freetz/bl...n-v2-cgi/files/root/etc/init.d/rc.openvpn#L41

 

[CaptainMorgan]

Beim Verusch die neue GUI ans Laufen zu bekommen, ist mir in der syslog Folgendes aufgefallen:

May 15 16:47:46 daemon.notice openvpn[6855]: SIGTERM[hard,] received, process exiting
May 15 16:47:46 kern.info kernel: [ 210.552000][0][yf_patchkernel] Initialization started
May 15 16:47:46 kern.info kernel: [ 210.552000][0][yf_patchkernel] Any preceding error messages regarding memory allocation are expected and may be ignored.
May 15 16:47:46 kern.info kernel: [ 210.572000][0][yf_patchkernel] Patching kernel function 'ip_forward' at address 0x80abe594.
May 15 16:47:46 kern.info kernel: [ 210.572000][0][yf_patchkernel] Found instruction to patch (0x8c820020) at address 0x80abe5b0, replaced it with 0x24020000.
May 15 16:47:46 kern.info kernel: [ 210.588000][0][yf_patchkernel] Patching kernel function 'netif_receive_skb' at address 0x80a66940.
May 15 16:47:46 kern.info kernel: [ 210.588000][0][yf_patchkernel] No instruction to patch found in function 'netif_receive_skb', patch skipped.
May 15 16:47:46 kern.info kernel: [ 210.604000][0][yf_patchkernel] Patching kernel function '__netif_receive_skb' at address 0x80a668c4.
May 15 16:47:46 kern.info kernel: [ 210.604000][0][yf_patchkernel] No instruction to patch found in function '__netif_receive_skb', patch skipped.
May 15 16:47:46 kern.info kernel: [ 210.604000][0][yf_patchkernel] 1 patches applied.