FRITZ!OS7 openvpn auf 7590 => kein tun Modul
- Ersteller CKone
- Erstellt am
PeterPawn
IPPF-Urgestein
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,275
- Punkte für Reaktionen
- 1,751
- Punkte
- 113
Dann mußt Du auch nichts weiter machen, als die URL beim Klonen abzuändern auf den Branch in meinem Repository:
(ungetestet, nur eingetippt)
Die URL zum Klonen eines Repos kann man sich auch im GitHub-GUI anzeigen und in die Zwischenablage kopieren lassen:
- den richtigen Branch (die linke Markierung) muß man allerdings selbst angeben.
Wenn ich keinen Fehler gemacht habe, sollte bei einem "make oldconfig" sowohl das "tun"-Module als auch "yf_patchkernel" als Module automatisch ausgewählt werden und beim Build auch im eigenen Freetz-Image landen (das habe ich allerdings nicht selbst getestet, weil ich kein Freetz-Image verwende), sowie man das OpenVPN-Paket auswählt. Für das OpenVPN-GUI V2 habe ich auch versucht, das Laden und Entladen beim Starten und Stoppen des OpenVPN-Daemons direkt einzubauen ... allerdings ist auch das (steht aber weiter vorne in diesem Thread deutlich erklärt) ungetestet.
Dieser Branch basiert auf dem letzten Stand des "originalen" Freetz-Repos und enthält zusätzlich die Änderungen für das LKM und das automatische Laden beim OpenVPN-Start.
(ungetestet, nur eingetippt)
Code:
git clone -b yf_patchkernel https://github.com/PeterPawn/freetz.gitDie URL zum Klonen eines Repos kann man sich auch im GitHub-GUI anzeigen und in die Zwischenablage kopieren lassen:
- den richtigen Branch (die linke Markierung) muß man allerdings selbst angeben.
Wenn ich keinen Fehler gemacht habe, sollte bei einem "make oldconfig" sowohl das "tun"-Module als auch "yf_patchkernel" als Module automatisch ausgewählt werden und beim Build auch im eigenen Freetz-Image landen (das habe ich allerdings nicht selbst getestet, weil ich kein Freetz-Image verwende), sowie man das OpenVPN-Paket auswählt. Für das OpenVPN-GUI V2 habe ich auch versucht, das Laden und Entladen beim Starten und Stoppen des OpenVPN-Daemons direkt einzubauen ... allerdings ist auch das (steht aber weiter vorne in diesem Thread deutlich erklärt) ungetestet.
Dieser Branch basiert auf dem letzten Stand des "originalen" Freetz-Repos und enthält zusätzlich die Änderungen für das LKM und das automatische Laden beim OpenVPN-Start.
Wow danke für die Infos. Ist doch einfacher wie gedacht 
Werde wohl noch die finale Version 7.08 abwarten und dann berichten.
Top Forum.
Werde wohl noch die finale Version 7.08 abwarten und dann berichten.
Top Forum.
Hallo PeterPawn,
ich habe analog deines Beitrags folgendes versucht:
git clone -b yf_patchkernel https://github.com/fritz-ng/freetz-ng.git
...dan bekomme ich diese Fehlermeldung. Was mache ich falsch?
Otto
ich habe analog deines Beitrags folgendes versucht:
git clone -b yf_patchkernel https://github.com/fritz-ng/freetz-ng.git
...dan bekomme ich diese Fehlermeldung. Was mache ich falsch?
Otto
PeterPawn
IPPF-Urgestein
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,275
- Punkte für Reaktionen
- 1,751
- Punkte
- 113
Du gehst fälschlicherweise davon aus, daß @cuma mit "freetz-ng" es den Freetz-Benutzern tatsächlich irgendwie ermöglichen will, ohne größere Komplikationen selbst - und aus freien Stücken - entscheiden zu können, welche Änderungen aus welchem Fork sie benutzen wollen und welche nicht.
Seit 3 Stunden gibt es den "freetz-ng"-Klon auf github.com gar nicht mehr - jedenfalls nicht in einer Form, die beim durchschnittlichen "git"-Benutzer irgendeinen Nutzen entfalten könnte:
[Kleiner Tipp am Rande: Es gibt auch ein "git prune"-Kommando (oder "git worktree"), denn wie man an den übertragenen Objekten sieht, ist der "main working tree" nicht leer. Man könnte also noch rekonstruieren, was da vor dem letzten Commit enthalten war. Das "alte" Freetz-Repo war es vermutlich nicht, aber am Ende interessiert mich das auch nicht wirklich - es fiel nur (mal wieder) auf bei der "Bestandsaufnahme".]
Ich kann (und will) niemandem "Vorschriften" machen, auf wen er sich künftig bei seinem Freetz verlassen möchte und auf wen nicht.
Aber ich kann meinen eigenen Eindruck festhalten und da erinnert mich das immer mehr an den Dreijährigen im Sandkasten, der in einem Wutanfall zuerst über alles, was da "gebaut" wurde, marschiert - und zwar auch ohne Rücksicht auf Verluste bei den eigenen "Bauwerken" und mit bemerkenswerter Gründlichkeit (EDIT: für sein Alter) - und danach noch akribisch mit seinem Schippchen den Sandkasten planiert, damit die anderen Kinder ja nur keinen Spaß mehr haben und noch irgendetwas davon sehen können, was sie oder er da vorher gebaut hatten. Anschließend setzt er sich mit dem Rücken zu den anderen und versucht - als "Bulle", der er ist mit seinen ~30 cm Schulterbreite - den anderen den Blick auf das zu verwehren, was er jetzt neu baut ... nicht ohne sich alle 10 Sekunden umzusehen und beim geringsten Verdacht, irgendjemand würde da doch an ihm vorbeilinsen, einen neuen Wutausbruch: "DU SOLLST DOCH NICHT GUCKEN!" zu kriegen.
Letztlich muß jeder selbst einschätzen, was er von einem OpenSource-Projekt und denjenigen, die dafür die Maintainer-Rolle übernehmen wollen, erwartet ... in meinen Augen ist das hier mehr Ego-Pflege als alles andere und das, was die "Macher" hier offenbar im Auge haben (ob Singular oder Plural korrekt ist, weiß man gar nicht genau - sowohl bei den Machern als auch bei den Augen), ist garantiert nicht primär der Freetz-Benutzer. Der kommt vielleicht auch irgendwann mal, aber wohl eher nicht an erster Stelle und vermutlich nicht mal an zweiter - deutlicher, als es die Entwicklungen der vergangenen Tage zeigen, geht es m.E. nicht mehr.
Schon das (indirekte) Ultimatum an die Freetz-Benutzer, sie müßten von jetzt an unbedingt ausschließlich den Fork benutzen, wenn sie von irgendeiner der von @cuma eingebrachten Neuerungen profitieren wollten (denn er hat ja explizit darum "gebeten", daß bloß niemand etwas aus seinem Fork in das "Original" übernehmen möge), wäre zumindest etwas, was mich persönlich sofort davon abhalten würde, auf diesen Fork zu setzen.
Die "Selbstkontrolle" ist mir hier bei den handelnden Personen deutlich zu wenig entwickelt und so, wie wir hier schon zweimal einen "Amoklauf" im IPPF erleben mußten, was das Löschen von Beiträgen angeht (wobei ich keinen Beweis erbringen kann, daß @cuma und @opto dieselbe Person waren, aber ich stehe mit dieser Vermutung zumindest nicht alleine, wie man sich in ein paar Beiträgen von @er13 auch ansehen kann) und jetzt das Planieren im GitHub stattgefunden hat - selbstverständlich alles ausschließlich im Interesse der Freetz-Benutzer -, würde es mich auch nicht allzu sehr überraschen, wenn nach dem nächsten "Wutausbruch" (die "Gänsefüßchen" sind Absicht, weil ich das nicht für eine Kurzschlußreaktion, sondern für Kalkül halte) auch das Subversion-Repository auf boxmatrix.info wieder verschwunden sein wird - zumindest das für "freetz-ng", denn das dortige Angebot fürs Mirroring (von Repos) soll ja für jeden Freetz-Fork gelten, was die Zukunft dann irgendwann zeigen wird (https://boxmatrix.info/wiki/SVN-Server).
Aber was ich sagen kann - und das bezieht sich jetzt hier dann auch explizit auf die Frage von @ottohahn - ist, daß ich auch nicht länger bereit bin, diese Spielchen mitzumachen und auch dann die Hilfe "verweigern" werde, wenn es tatsächlich irgendeiner meiner alten Beiträge zum Freetz-Projekt sein sollte, mit dem ein "freetz-ng"-User Probleme hat. Die Macher von "freetz-ng" haben deutlich genug gemacht, daß sie mit denjenigen, die sich weiterhin um den originalen Zweig kümmern wollen, nichts zu tun haben möchten und daß die Freetz-Benutzer gefälligst auch "ihre Seite" wählen sollen in einem vollkommen unnötigen "Konflikt".
Von einer "Zusammenarbeit" sehe ich da nichts ... und da es am Ende auch für mich (und andere, die sich mit dem "alten Freetz" befassen) jedesmal zusätzlicher Aufwand ist, erst einmal zu ermitteln, welche Spielchen jetzt wieder beim "freetz-ng" gestartet wurden, ist das Thema "freetz-ng" für mich jetzt endgültig gestorben und wenn jemand "freetz-ng" benutzen möchte, möge er sich bitte auch an die dortigen Maintainer wenden, wenn er Fragen oder gar Probleme hat. Klingt vielleicht hart, aber ist hoffentlich nachvollziehbar ... das oben Stehende habe ich mir ja nicht ausgedacht, das ist die Zusammenfassung der letzten Entwicklungen.
Wer sich für "freetz-ng" deshalb entscheiden will, weil es dort ein paar Änderungen gibt, deren Nutzen hier niemand abstreiten will, der kann sich ja auch einfach mal einbringen und die eigene Stimme erheben (im GitHub-Repo von "freetz"), welche bei "freetz-ng" vorhandenen Änderungen er gerne benutzen würde (und am besten noch, warum). @f666 hat schon an anderer Stelle an @cuma geschrieben (https://github.com/Freetz/freetz/issues/76#issuecomment-464641054), daß er bestimmte Änderungen gerne in "freetz" übernehmen würde - man kann das ja mal selbst in zeitliche Korrelation zu dieser "Fundstelle" bringen:
Da die Freetz-Lizenz auch @cuma das gemeinsame Veröffentlichen von Freetz und eigenen Änderungen, die nicht unter die GPLv2 fallen, theoretisch verbieten würde und er damit auch automatisch an seinen eigenen Änderungen im "freetz-ng" (auch wenn die in einem Subversion-Repository gemeinsam mit den anderen Freetz-Quellen stehen und nicht in einem "git"-Repo) allen anderen die notwendigen Rechte einräumen muß, wenn er das "anbietet" auf boxmatrix.info, könnte man das "bloß nicht (hin-)gucken" sogar ignorieren ... aber vielleicht findet man an einigen Stellen ja auch eine andere Implementierung. Ich habe mir (schon am Beginn) einige der Commits (damals erfolgten die noch auf GitHub) angesehen und dabei auch viel Fragwürdiges (im wahrsten Sinne des Wortes, daß man dazu schon noch ein paar Fragen haben sollte) gesehen - steht auch im "freetz-ng"-Thread irgendwo weiter vorne, als ich das "wilde Committen" ohne jedwede Prüfung durch einen Dritten (der hier auch ein "Zweiter" sein kann) kritisiert habe und das daraus entstehende "cuma-Image", anstelle einer echten Wahlmöglichkeit für die Freetz-Benutzer, die den Fork verwenden wollten.
Seit 3 Stunden gibt es den "freetz-ng"-Klon auf github.com gar nicht mehr - jedenfalls nicht in einer Form, die beim durchschnittlichen "git"-Benutzer irgendeinen Nutzen entfalten könnte:
Code:
vidar:/tmp $ git clone https://github.com/freetz-ng/freetz-ng.git
Cloning into 'freetz-ng'...
remote: Enumerating objects: 9803, done.
remote: Counting objects: 100% (9803/9803), done.
remote: Compressing objects: 100% (1857/1857), done.
remote: Total 75433 (delta 8929), reused 7947 (delta 7945), pack-reused 65630
Receiving objects: 100% (75433/75433), 20.08 MiB | 9.96 MiB/s, done.
Resolving deltas: 100% (48686/48686), done.
vidar:/tmp $ cd freetz-ng/
vidar:/tmp/freetz-ng $ git status
On branch master
Your branch is up to date with 'origin/master'.
nothing to commit, working tree clean
vidar:/tmp/freetz-ng $ git log
commit 2da775c61ca3e95401b48af27bd8f1cf2515c2e3 (HEAD -> master, origin/master, origin/HEAD)
Author: fda77 <[email protected]>
Date: Sat Feb 23 11:03:41 2019 +0100
README.md
vidar:/tmp/freetz-ng $Ich kann (und will) niemandem "Vorschriften" machen, auf wen er sich künftig bei seinem Freetz verlassen möchte und auf wen nicht.
Aber ich kann meinen eigenen Eindruck festhalten und da erinnert mich das immer mehr an den Dreijährigen im Sandkasten, der in einem Wutanfall zuerst über alles, was da "gebaut" wurde, marschiert - und zwar auch ohne Rücksicht auf Verluste bei den eigenen "Bauwerken" und mit bemerkenswerter Gründlichkeit (EDIT: für sein Alter) - und danach noch akribisch mit seinem Schippchen den Sandkasten planiert, damit die anderen Kinder ja nur keinen Spaß mehr haben und noch irgendetwas davon sehen können, was sie oder er da vorher gebaut hatten. Anschließend setzt er sich mit dem Rücken zu den anderen und versucht - als "Bulle", der er ist mit seinen ~30 cm Schulterbreite - den anderen den Blick auf das zu verwehren, was er jetzt neu baut ... nicht ohne sich alle 10 Sekunden umzusehen und beim geringsten Verdacht, irgendjemand würde da doch an ihm vorbeilinsen, einen neuen Wutausbruch: "DU SOLLST DOCH NICHT GUCKEN!" zu kriegen.
Letztlich muß jeder selbst einschätzen, was er von einem OpenSource-Projekt und denjenigen, die dafür die Maintainer-Rolle übernehmen wollen, erwartet ... in meinen Augen ist das hier mehr Ego-Pflege als alles andere und das, was die "Macher" hier offenbar im Auge haben (ob Singular oder Plural korrekt ist, weiß man gar nicht genau - sowohl bei den Machern als auch bei den Augen), ist garantiert nicht primär der Freetz-Benutzer. Der kommt vielleicht auch irgendwann mal, aber wohl eher nicht an erster Stelle und vermutlich nicht mal an zweiter - deutlicher, als es die Entwicklungen der vergangenen Tage zeigen, geht es m.E. nicht mehr.
Schon das (indirekte) Ultimatum an die Freetz-Benutzer, sie müßten von jetzt an unbedingt ausschließlich den Fork benutzen, wenn sie von irgendeiner der von @cuma eingebrachten Neuerungen profitieren wollten (denn er hat ja explizit darum "gebeten", daß bloß niemand etwas aus seinem Fork in das "Original" übernehmen möge), wäre zumindest etwas, was mich persönlich sofort davon abhalten würde, auf diesen Fork zu setzen.
Die "Selbstkontrolle" ist mir hier bei den handelnden Personen deutlich zu wenig entwickelt und so, wie wir hier schon zweimal einen "Amoklauf" im IPPF erleben mußten, was das Löschen von Beiträgen angeht (wobei ich keinen Beweis erbringen kann, daß @cuma und @opto dieselbe Person waren, aber ich stehe mit dieser Vermutung zumindest nicht alleine, wie man sich in ein paar Beiträgen von @er13 auch ansehen kann) und jetzt das Planieren im GitHub stattgefunden hat - selbstverständlich alles ausschließlich im Interesse der Freetz-Benutzer -, würde es mich auch nicht allzu sehr überraschen, wenn nach dem nächsten "Wutausbruch" (die "Gänsefüßchen" sind Absicht, weil ich das nicht für eine Kurzschlußreaktion, sondern für Kalkül halte) auch das Subversion-Repository auf boxmatrix.info wieder verschwunden sein wird - zumindest das für "freetz-ng", denn das dortige Angebot fürs Mirroring (von Repos) soll ja für jeden Freetz-Fork gelten, was die Zukunft dann irgendwann zeigen wird (https://boxmatrix.info/wiki/SVN-Server).
Aber was ich sagen kann - und das bezieht sich jetzt hier dann auch explizit auf die Frage von @ottohahn - ist, daß ich auch nicht länger bereit bin, diese Spielchen mitzumachen und auch dann die Hilfe "verweigern" werde, wenn es tatsächlich irgendeiner meiner alten Beiträge zum Freetz-Projekt sein sollte, mit dem ein "freetz-ng"-User Probleme hat. Die Macher von "freetz-ng" haben deutlich genug gemacht, daß sie mit denjenigen, die sich weiterhin um den originalen Zweig kümmern wollen, nichts zu tun haben möchten und daß die Freetz-Benutzer gefälligst auch "ihre Seite" wählen sollen in einem vollkommen unnötigen "Konflikt".
Von einer "Zusammenarbeit" sehe ich da nichts ... und da es am Ende auch für mich (und andere, die sich mit dem "alten Freetz" befassen) jedesmal zusätzlicher Aufwand ist, erst einmal zu ermitteln, welche Spielchen jetzt wieder beim "freetz-ng" gestartet wurden, ist das Thema "freetz-ng" für mich jetzt endgültig gestorben und wenn jemand "freetz-ng" benutzen möchte, möge er sich bitte auch an die dortigen Maintainer wenden, wenn er Fragen oder gar Probleme hat. Klingt vielleicht hart, aber ist hoffentlich nachvollziehbar ... das oben Stehende habe ich mir ja nicht ausgedacht, das ist die Zusammenfassung der letzten Entwicklungen.
Wer sich für "freetz-ng" deshalb entscheiden will, weil es dort ein paar Änderungen gibt, deren Nutzen hier niemand abstreiten will, der kann sich ja auch einfach mal einbringen und die eigene Stimme erheben (im GitHub-Repo von "freetz"), welche bei "freetz-ng" vorhandenen Änderungen er gerne benutzen würde (und am besten noch, warum). @f666 hat schon an anderer Stelle an @cuma geschrieben (https://github.com/Freetz/freetz/issues/76#issuecomment-464641054), daß er bestimmte Änderungen gerne in "freetz" übernehmen würde - man kann das ja mal selbst in zeitliche Korrelation zu dieser "Fundstelle" bringen:
Man kann natürlich die Welt auch schwarz/weiß sehen und jeden, der einem selbst nicht 100% zustimmen mag, als "Feind" einstufen und auszugrenzen versuchen ... aber man kann (ohne Patente, die hier vermutlich nicht erteilt wurden) nicht verhindern, daß andere ein gute Idee aufgreifen und dann ihrerseits einfach selbst implementieren - eigentlich ziemlich unnötig, aber man kann ja einfach so tun, als wüßte man das nicht.
Da die Freetz-Lizenz auch @cuma das gemeinsame Veröffentlichen von Freetz und eigenen Änderungen, die nicht unter die GPLv2 fallen, theoretisch verbieten würde und er damit auch automatisch an seinen eigenen Änderungen im "freetz-ng" (auch wenn die in einem Subversion-Repository gemeinsam mit den anderen Freetz-Quellen stehen und nicht in einem "git"-Repo) allen anderen die notwendigen Rechte einräumen muß, wenn er das "anbietet" auf boxmatrix.info, könnte man das "bloß nicht (hin-)gucken" sogar ignorieren ... aber vielleicht findet man an einigen Stellen ja auch eine andere Implementierung. Ich habe mir (schon am Beginn) einige der Commits (damals erfolgten die noch auf GitHub) angesehen und dabei auch viel Fragwürdiges (im wahrsten Sinne des Wortes, daß man dazu schon noch ein paar Fragen haben sollte) gesehen - steht auch im "freetz-ng"-Thread irgendwo weiter vorne, als ich das "wilde Committen" ohne jedwede Prüfung durch einen Dritten (der hier auch ein "Zweiter" sein kann) kritisiert habe und das daraus entstehende "cuma-Image", anstelle einer echten Wahlmöglichkeit für die Freetz-Benutzer, die den Fork verwenden wollten.
Zuletzt bearbeitet:
Code:
fatal: Remote-Branch yp_patchkernel nicht im Upstream-Repository origin gefundenund dieser Branch gibt es dort nicht;
auch verstehe ich den Sinn nicht, warum gehst Du nicht nach Anleitung von PeterPawn vor und verwendest die dort angegebenen Repositories und Pfade ?
PeterPawn
IPPF-Urgestein
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,275
- Punkte für Reaktionen
- 1,751
- Punkte
- 113
Da mein Fork im Moment NICHT mit dem originalen Freetz-Repo übereinstimmt (ich habe mir einfach bisher die Zeit zum Rebase nicht genommen, weil ich noch auf das Committen einiger Änderungen warte), stimmt die alte Empfehlung ja auch nicht mehr wirklich, man solle einfach mein Repo klonen.
Wer das jetzt probieren will, sollte vermutlich den "staging"-Branch aus dem "freetz/freetz"-Repo benutzen, auch wenn ich noch nicht so richtig durchblicke, wohin sich das nach dem Willen von @f666 entwickeln soll. Oder - als Alternative - den Freetz-Master und dann meinen "yf_patchkernel"-Branch dazumischen, wie ich es hier irgendwo ausführlich erklärt habe.
Wer das jetzt probieren will, sollte vermutlich den "staging"-Branch aus dem "freetz/freetz"-Repo benutzen, auch wenn ich noch nicht so richtig durchblicke, wohin sich das nach dem Willen von @f666 entwickeln soll. Oder - als Alternative - den Freetz-Master und dann meinen "yf_patchkernel"-Branch dazumischen, wie ich es hier irgendwo ausführlich erklärt habe.
Hallo Community,
ich habe heute endlich meinen neuen Glasfaser-Anschluß aktiviert bekommen. Die Fritzbox muß dafür jetzt vom DSL in den WAN-Modus umgestellt werden. Dafür hat die 7590 einen eigenen Anschluß. Aus irgendeinen Grund kommt jetzt keine Internetverbindung zustande.
Wenn ich die Betriebsart wechsle auf „Vorhandene Internetverbindung mitbenutzen (WLAN Mesh / IP-Client-Modus)“ funktioniert der Anschluß, aber ich bekomme auf der WLAN-Seite IP-Adressen aus dem Public-Netzwerk zugewiesen.
Meines Erachtens muß das mit der Fritzbox-Firewall und der in diesem Abschnitt beschrieben VPN-Workaround liegen.
Hat jemand eine Idee woran das liegen kann?
Otto
//edit by stoney: Bild geschrumpft
ich habe heute endlich meinen neuen Glasfaser-Anschluß aktiviert bekommen.
Die Fritzbox muß dafür jetzt vom DSL in den WAN-Modus umgestellt werden. Dafür hat die 7590 einen eigenen Anschluß. Aus irgendeinen Grund kommt jetzt keine Internetverbindung zustande.Wenn ich die Betriebsart wechsle auf „Vorhandene Internetverbindung mitbenutzen (WLAN Mesh / IP-Client-Modus)“ funktioniert der Anschluß, aber ich bekomme auf der WLAN-Seite IP-Adressen aus dem Public-Netzwerk zugewiesen.
Meines Erachtens muß das mit der Fritzbox-Firewall und der in diesem Abschnitt beschrieben VPN-Workaround liegen.
Hat jemand eine Idee woran das liegen kann?
Otto
//edit by stoney: Bild geschrumpft
Micha0815
IPPF-Promi
- Mitglied seit
- 25 Feb 2008
- Beiträge
- 5,344
- Punkte für Reaktionen
- 467
- Punkte
- 83
Achso. Ich dachte es wäre OT und müsste auf AT via XT unter LT eingestellt werden?
LG+Sorry
Hallo zusammen,
nun ist die finale Version 7.10 für die 7590 erschienen...
Ist diese Patch noch kompatibel oder muss er angepasst werden?
Leider gab es bei der 7.08 Beta Probleme mit Reboots der Box aufgrund OpenVPN...(leider keine logs)
Und ich muss nichts starten oder anderen?
Also nur:
make oldconfig" sowohl das "tun"-Module als auch "yf_patchkernel" auswählen... Sowie meine OpenVPN Pakete etc...,
Danke für die Hilfe
nun ist die finale Version 7.10 für die 7590 erschienen...
Ist diese Patch noch kompatibel oder muss er angepasst werden?
Leider gab es bei der 7.08 Beta Probleme mit Reboots der Box aufgrund OpenVPN...(leider keine logs)
Und ich muss nichts starten oder anderen?
Also nur:
make oldconfig" sowohl das "tun"-Module als auch "yf_patchkernel" auswählen... Sowie meine OpenVPN Pakete etc...,
Danke für die Hilfe
Also ich hab keine ausführliche Erklärung dazu gefunden...
Insbesondere wie man einen Branch dazu mischt...
Aber egal, ich nutze einfach das Skript weiter, hoffe es funktioniert noch...
PeterPawn
IPPF-Urgestein
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,275
- Punkte für Reaktionen
- 1,751
- Punkte
- 113
Inzwischen ist das doch längst im Freetz-Master gelandet; https://github.com/Freetz/freetz/commit/0a6f98285cb233e6f94f5e681daee6bac07d7d91 ... wenn man das "openvpn-cgi v2" benutzt, wird das LKM auch automatisch geladen. Dann braucht man also nur ein neues Image, bei dem man die Verwendung von "openvpn" und "openvpn-cgi v2" ausgewählt hat, dann sollte das seinen Gang gehen.
-------------------------------------------------------------------------------------------------------------
Wie man zwei Branches mit "git" mischt, steht z.B.
- hier: https://github.com/Freetz/freetz/pull/115#issuecomment-470972390 oder
- hier: https://www.ip-phone-forum.de/threads/freetz-ng.302327/page-6#post-2317780 oder
- man kann auch einfach ein "git pull <url_repo> <branch>" machen bei einem GitHub-Repo, wenn man nicht erst mit "git remote" eine weitere Quelle definieren will
und es gibt garantiert noch ein paar weitere Stellen, wo ich das zumindest "zeige" in irgendeinem Code-Block.
Das ist alles sehr simpel, weil das zu den "bread&butter"-Aktionen bei der Verwendung von "git" gehört, daß man zwei unabhängig entwickelte Zweige (genau für diese verteilte Entwicklung ist "git" ja gedacht) zusammenführt.
-------------------------------------------------------------------------------------------------------------
Wie man zwei Branches mit "git" mischt, steht z.B.
- hier: https://github.com/Freetz/freetz/pull/115#issuecomment-470972390 oder
- hier: https://www.ip-phone-forum.de/threads/freetz-ng.302327/page-6#post-2317780 oder
- man kann auch einfach ein "git pull <url_repo> <branch>" machen bei einem GitHub-Repo, wenn man nicht erst mit "git remote" eine weitere Quelle definieren will
und es gibt garantiert noch ein paar weitere Stellen, wo ich das zumindest "zeige" in irgendeinem Code-Block.
Das ist alles sehr simpel, weil das zu den "bread&butter"-Aktionen bei der Verwendung von "git" gehört, daß man zwei unabhängig entwickelte Zweige (genau für diese verteilte Entwicklung ist "git" ja gedacht) zusammenführt.
Ah gut zu wissen,
wo finde ich denn das openvpn-cgi v2
Unter Web Interfaces kann ich es nicht finden
hab http://github.com/Freetz/freetz.git gepullt.
wo finde ich denn das openvpn-cgi v2
Unter Web Interfaces kann ich es nicht finden
hab http://github.com/Freetz/freetz.git gepullt.
PeterPawn
IPPF-Urgestein
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,275
- Punkte für Reaktionen
- 1,751
- Punkte
- 113
Sorry, nicht wirklich mein Tisch ... aber garantiert auch nicht schwer zu finden, denn man kann in "mconf" (das ist das Programm, was bei "make menuconfig" die Funktion übernimmt) auch mit einem einfachen Schrägstrich als Eingabe eine Suche starten ... bei den Ergebnissen steht dann auch dabei, in welchem Abschnitt sich eine Einstellung befindet.
Hallo zusammen,
hat jemand Erfahrung mit IPV6 und OpenVPN. Ich habe letzten Monat einen Glasfaseranschluß (FTTH) erhalten und damit jetzt keine mehr von Außen erreichbare IPV4-Adresse.
Hat jemand Erfahrung damit?
Otto
I
hat jemand Erfahrung mit IPV6 und OpenVPN. Ich habe letzten Monat einen Glasfaseranschluß (FTTH) erhalten und damit jetzt keine mehr von Außen erreichbare IPV4-Adresse.
Hat jemand Erfahrung damit?
Otto
I
Neueste Beiträge
-
[Problem] Tonwahl beim T48S- Letzte: NDiIPP
-
[Frage] Dect-WS500S Verbindungen an Compact 4000
- Letzte: oezi
-
Analoges Wählgerät einer Alarmanlage an VoIP betreiben ...
- Letzte: provisorischerFtmmsch
