Edit sagt:
/usr/local/emhttp/plugins/openvpnserver/scripts/rc.openvpnserver stop | logger
interface tap0 does not exist!
/usr/local/emhttp/plugins/openvpnserver/scripts/rc.openvpnserver start | logger
nohup: redirecting stderr to stdout (das ist wohl ok), und der Server startet auch, allerdings noch ohne die o.g. Buttons und die festgelegte DHCP Range wird ignoriert.
Edit2: auch ein Update auf die neue Version 2022.10.11.01-tap hat nicht geholfen.
Moinsen, bist du in diesem Zeitraum von 6.9 auf >6.10 ?
Ich hatte aus Kompatibilitäts Gründen für Unraid >=6.10 eh am Plugin größere Arbeiten durchführen müssen, da gab es daneben dann viele weitere Änderungen / Features.
Ggf hilft es einmal das Plugin zu löschen, auch den Configordner zusätzöich händisch.
/boot/config/openvpnserver und /boot/config/plugins/openvpnserver.
Danach nochmal alles auf auf 0
Hah, Kommando zurück, ich kann dein Verhalten reproduzieren, ich schau spätestens Montag nach ner Lösung 
Moinsen,
2022.10.16.01-tap ist online, fehler ist behoben ![[bf]](https://www.kodinerds.net/wcf/images/smilies/smiley69.gif "bf"){kind=small}
Merci, nach Einspielen des Updates geht alles wieder.
Hmm, kann es sein, das die Telekom VPN drosselt? Folgendes Szenario: Bei einer Bekannten habe ich per Kodi-Addon OpenVPN-Manager installiert, damit sie auf meinen Datenbestand auf einem unRaid zugreifen kann. Vorhanden ist ein Telekom-Anschluẞ mit 60/10 MBit/s, meiner einer hat 100/40 (1&1). Trotzdem werden bei ihr max. nur 14 Mbit/s abgerufen, auch der Fritzbox Online Monitor zeigt genügend Luft nach oben. Bei mir liegen ebenfalls 100/40 an, ein VPN-Upload zu meinem Arbeitgeber lastet den Upload mit knapp 40MBits/s entsprechend voll aus - der ja bei funktionierenden VPN als Download bei der Bekannten zur Verfügung stehen sollte...
Die Prozessorauslastung ist bei beiden Systemen (LibreElec, J5005; unRaid, J3455) im unkritischen Bereich von 20%-30%.
An welchen Schrauben kann man da drehen?
Du könntest die Verschlüsselung von 265 auf 128 abändern, das hätte zur Folge das die Zertifikate u. die Client Files neu gebaut werden müssten.
Vorher aber vllt mal checken ob der VPN Manager (Kodi) ein redirect default gw drinne hat, das kannst du rausnehmen (kenne das Addon nicht), andernfalls würde der komplette internet traffic der Kodibox über dein Unraid geroutet werden, willst du ja nicht, magst ja nur lokale Ressourcen verfügbar machen.
Das redirect Verhalten kannst du u.A überprüfen wenn du auf der Kodibox die ausgehende wan ip überprüfst, ist die gleich deines Unraids, gehts darüber. z.b wieistmeineip.de
Die Prozessorauslastung ist bei beiden Systemen (LibreElec, J5005; unRaid, J3455) im unkritischen Bereich von 20%-30%.
Da könnten 20% - 30% schon kritisch sein (wenn sie sie sich auf die CPU und nicht auf einen Core beziehen). J5005 hat 4 Kerne, bei einer Aufgabe, die sich nicht auf mehrere Threads verteilt (und das kann bei VPN gut der Fall sein) ist bei 25% Schluss. Kann natürlich gut sein, dass du dir das schon angesehen hast ... Wenn da kein Prozess mit sagen wir 15% oder mehr Last ist, wird es nicht an der CPU-Auslastung liegen.
Ich kann die Kerne der CPUs sehen, die dümpeln alle bei 20-30%. wieistmeineip.de wird nicht gehen, da weder unraid noch libreelec einen Webbrowser haben.
Du könntest die Verschlüsselung von 265 auf 128 abändern, das hätte zur Folge das die Zertifikate u. die Client Files neu gebaut werden müssten.
Hat nichts gebracht, die Downloadrate bleibt unten. Anbei mal ein Screenshot. Das VPN-Log muss ich noch nachreichen.
Das ist strange, muss aber aus Verständnis nochmal nachfragen, eine vpn verbindung zu deinem Arbeitsplatz funktioniert performant? Also von Unraid zu Office ?
VPN zur Uni geht über den Uni-VPN-Server. Hier zuhause wird unter Windows 10 der Shrewsoft Manager verwendet. Welche Hardware sich hinter dem VPN-Server der Uni verbirgt, entzieht sich meiner Kenntnis, der Client hier ist jedenfalls ein i7 und entsprechend potent. Die 100/40 wird auch ausgelastet.
Ein OVPN Client müsste ich erstmal auf dem Arbeitsplatzrechner installieren, bin aber z.Zt. noch arbeitsunfähig und habe daher auf Arbeit nichts zu suchen 
.
meistens hängt es am overhead oder eben der Verschlüsselung, obwohl die meisten modernen cpus aes-ni als instruction mit an board haben.
Ich kann mir nicht vorstellen das die telekom blockt 
Du könntest ja mal spaßeshalber von der uni mit deinem vpn zuhause verbinden, wenn du das "darfst", ggf mit eigenem Gerät.
Bezüglich redirect Gateway im vpn manager, falls vorhanden ? die öffentliche ip lässt sich auch in einer Bash mit installiertem curl herausfinden, Exemplarisch mal für ipv4
curl http://ipinfo.io/ip
curl ipinfo.io/ipEin Redirect gibt es (als Einstellung) nicht im Kodi VPN-Manager. Ich werde aber mal auf meinem Win-Notebook einen OVPN-Client installieren und testen.
Moin, nach viel Try and Error bezüglich verblüffend langsamer Dateiübertragungsgeschwindigkeiten über openvpn bin ich mit @PvD letztendlich darauf gestoßen, dass der Integrierte SMB Client von Kodi einfach langsamer ist als wenn das remote Share direkt über mount.cifs eingehongen wird.
Ist es ein Libreelec Spezifisches Verhalten ?
Ist das bekannt ?
kann @DaVu seitens Kodi dazu etwas sagen ? / Gibt es Optimierungsoptionen ?
Konkret geht es in diesem Test um Libreelec 10.3 auf einem Intel System.
Geschwindigkeiten über VPN Tunnel
Kodi SMB : 1,3MB/s
Mount.CIFS : 4,3MB/s
Eingehängt direkt über CIFS ist die Geschwindigkeit nahezu identisch mit der auf dem Server zu Verfügung stehenden Bandbreite im Upload, also alles chiq.
Puh....da kann ich nichts zu sagen.
Grundlegend wird es aber sehr oft empfohlen das Betriebssystem den Mount machen zu lassen und diese Aufgabe nicht Kodi zu übergeben. Es ist vielleicht auch noch die Frage, was der Kernel mit dem Filesystem-Cache noch macht, was vielleicht Kodi mit seinem SMB-Client nicht tut.
Das geht aber alles über mein Wissen hinaus.
Ich denke eher es liegt an der Aufteilung der Threads. Wenn man die Belastung des Systems beobachtet per ssh / top sieht man bei einem Netzwerkzugriff von Kodi aus nur einen Thread in die höhe schnellen.
Der Cifs Dienst geht über alle Kerne.
Ich denke eher es liegt an der Aufteilung der Threads. Wenn man die Belastung des Systems beobachtet per ssh / top sieht man bei einem Netzwerkzugriff von Kodi aus nur einen Thread in die höhe schnellen.
Der Cifs Dienst geht über alle Kerne.
Da ist definitiv was dran, aber auch hier auf meinem core I7 "Testsystem" Langweilt sich dieser Thread / Cpu Cores. ....
Ich kann dazu erst heute abend was sagen, wenn ich wieder im "anderen" Netz unterwegs bin. Da es aber primär nicht um Geschwindigkeit beim Kopieren von Daten geht, sondern um Echtzeit-Streaming, werde ich mal den CIFS-Mointpoint clientseitig als Medienquelle einbinden. Dann wird sich zeigen, ob das Limit von 1.3 MB/s noch steht oder die physisch vorhandene Bandbreite ausgenutzt wird.
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!
