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

[CaptainMorgan]

Ich versuche einen VPN Server auf einer 7560 einzurichten.
Die arbeitet als IP-Client hinter dem Router (192.168.172.1) unter der IP-Adresse 192.168.172.2.
Den Port 1194 kann ich ja dann später ganz normal durchstellen über die AVM GUI.
Zunächst teste ich nur im Netzwerk.
Da der Router ziemlich busy ist und die 7560 etwas neuer habe ich mir vorgenommen das aus Stabilitätsgründen auszulagern.
Das hier ist zur Zeit mein Server Setup:



Meine config.ovpn:

  client
  dev tap
  proto tcp
  remote 192.168.172.2 1194
  nobind
  pull
  ca "C:\\Program Files\\OpenVPN\\easy-rsa\\keys\\ca.crt"
  cert "C:\\Program Files\\OpenVPN\\easy-rsa\\keys\\XXX.crt"
  key "C:\\Program Files\\OpenVPN\\easy-rsa\\keys\\XXX.key"
  remote-cert-tls server
  tls-auth "C:\\Program Files\\OpenVPN\\easy-rsa\\keys\\XXXStaticKey.key" 1
  auth SHA1
  cipher AES-256-CBC
  verb 3

Die Log vom Windows Clienten:

Wed Jan 09 19:14:52 2019 OpenVPN 2.4.6 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Apr 26 2018
Wed Jan 09 19:14:52 2019 Windows version 6.2 (Windows 8 or greater) 64bit
Wed Jan 09 19:14:52 2019 library versions: OpenSSL 1.1.0h  27 Mar 2018, LZO 2.10
Enter Management Password:
Wed Jan 09 19:14:52 2019 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:25340
Wed Jan 09 19:14:52 2019 Need hold release from management interface, waiting...
Wed Jan 09 19:14:52 2019 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:25340
Wed Jan 09 19:14:52 2019 MANAGEMENT: CMD 'state on'
Wed Jan 09 19:14:52 2019 MANAGEMENT: CMD 'log all on'
Wed Jan 09 19:14:52 2019 MANAGEMENT: CMD 'echo all on'
Wed Jan 09 19:14:52 2019 MANAGEMENT: CMD 'bytecount 5'
Wed Jan 09 19:14:52 2019 MANAGEMENT: CMD 'hold off'
Wed Jan 09 19:14:52 2019 MANAGEMENT: CMD 'hold release'
Wed Jan 09 19:14:52 2019 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Wed Jan 09 19:14:52 2019 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Wed Jan 09 19:14:52 2019 TCP/UDP: Preserving recently used remote address: [AF_INET]192.168.172.2:1194
Wed Jan 09 19:14:52 2019 Socket Buffers: R=[65536->65536] S=[65536->65536]
Wed Jan 09 19:14:52 2019 Attempting to establish TCP connection with [AF_INET]192.168.172.2:1194 [nonblock]
Wed Jan 09 19:14:52 2019 MANAGEMENT: >STATE:1547057692,TCP_CONNECT,,,,,,
Wed Jan 09 19:14:53 2019 TCP connection established with [AF_INET]192.168.172.2:1194
Wed Jan 09 19:14:53 2019 TCP_CLIENT link local: (not bound)
Wed Jan 09 19:14:53 2019 TCP_CLIENT link remote: [AF_INET]192.168.172.2:1194
Wed Jan 09 19:14:53 2019 MANAGEMENT: >STATE:1547057693,WAIT,,,,,,
Wed Jan 09 19:14:53 2019 Connection reset, restarting [0]
Wed Jan 09 19:14:53 2019 SIGUSR1[soft,connection-reset] received, process restarting
Wed Jan 09 19:14:53 2019 MANAGEMENT: >STATE:1547057693,RECONNECTING,connection-reset,,,,,
Wed Jan 09 19:14:53 2019 Restart pause, 5 second(s)
Wed Jan 09 19:14:58 2019 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Wed Jan 09 19:14:58 2019 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Wed Jan 09 19:14:58 2019 TCP/UDP: Preserving recently used remote address: [AF_INET]192.168.172.2:1194
Wed Jan 09 19:14:58 2019 Socket Buffers: R=[65536->65536] S=[65536->65536]
Wed Jan 09 19:14:58 2019 Attempting to establish TCP connection with [AF_INET]192.168.172.2:1194 [nonblock]
Wed Jan 09 19:14:58 2019 MANAGEMENT: >STATE:1547057698,TCP_CONNECT,,,,,,
Wed Jan 09 19:14:59 2019 TCP connection established with [AF_INET]192.168.172.2:1194
Wed Jan 09 19:14:59 2019 TCP_CLIENT link local: (not bound)
Wed Jan 09 19:14:59 2019 TCP_CLIENT link remote: [AF_INET]192.168.172.2:1194
Wed Jan 09 19:14:59 2019 MANAGEMENT: >STATE:1547057699,WAIT,,,,,,
Wed Jan 09 19:14:59 2019 Connection reset, restarting [0]
Wed Jan 09 19:14:59 2019 SIGUSR1[soft,connection-reset] received, process restarting
Wed Jan 09 19:14:59 2019 MANAGEMENT: >STATE:1547057699,RECONNECTING,connection-reset,,,,,
Wed Jan 09 19:14:59 2019 Restart pause, 5 second(s)
Wed Jan 09 19:15:01 2019 SIGTERM[hard,init_instance] received, process exiting
Wed Jan 09 19:15:01 2019 MANAGEMENT: >STATE:1547057701,EXITING,init_instance,,,,,

Und die aus der Freetz-Syslog:

Jan  9 19:14:56 XXXX daemon.notice openvpn[20054]: OpenVPN 2.4.6 mips-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [AEAD] built on Jan  5 2019
Jan  9 19:14:56 XXXX daemon.notice openvpn[20054]: library versions: OpenSSL 1.0.2q  20 Nov 2018, LZO 2.10
Jan  9 19:14:56 XXXX daemon.notice openvpn[20054]: Diffie-Hellman initialized with 2048 bit key
Jan  9 19:14:56 XXXX daemon.notice openvpn[20054]: Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Jan  9 19:14:56 XXXX daemon.notice openvpn[20054]: Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Jan  9 19:14:56 XXXX daemon.err openvpn[20054]: ERROR: Cannot open TUN/TAP dev /dev/net/tun: No such file or directory (errno=2)
Jan  9 19:14:56 XXXX daemon.notice openvpn[20054]: Exiting due to fatal error
Jan  9 19:15:02 XXXX daemon.notice openvpn[20055]: OpenVPN 2.4.6 mips-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [AEAD] built on Jan  5 2019
Jan  9 19:15:02 XXXX daemon.notice openvpn[20055]: library versions: OpenSSL 1.0.2q  20 Nov 2018, LZO 2.10
Jan  9 19:15:02 XXXX daemon.notice openvpn[20055]: Diffie-Hellman initialized with 2048 bit key
Jan  9 19:15:02 XXXX daemon.notice openvpn[20055]: Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Jan  9 19:15:02 XXXX daemon.notice openvpn[20055]: Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Jan  9 19:15:02 XXXX daemon.err openvpn[20055]: ERROR: Cannot open TUN/TAP dev /dev/net/tun: No such file or directory (errno=2)
Jan  9 19:15:02 XXXX daemon.notice openvpn[20055]: Exiting due to fatal error

2 Fragen dazu?
1.Sieht meine Konfiguratioin prinzipiell richtig aus?

2. Aus der Syslog geht hervor: /dev/net/tun fehlt
Und dem ist auch so.
Bruacht man das im TAP Modus, und wenn ja warum fehlt es?

//edit by stoney: Bild geschrumpft

 

[PeterPawn]

Zum zweiten Punkt:

https://www.ip-phone-forum.de/threa...60-freetz-14290-avm-6-83.295137/#post-2226673

Wenn danach die Box beim Empfang von Paketen über OpenVPN in "kernel panic" verfällt, hat AVM vermutlich auch dort entsprechende BUG_ON-Statements im Kernel vergessen (die Source-Pakete für die 07.01 bei der 7560 liegen noch nicht vor auf osp.avm.de) und man (oder ich) müßte wohl noch die passende Shell-Datei zum Patchen des Kernels bereitstellen, sofern ich bis dahin das LKM nicht fertig habe. Aber ein Schritt nach dem anderen ... kommt's tatsächlich zur "kernel panic", hätte ich gerne erst mal die Adressen aus der /proc/kallsyms bei der 7560 für die entsprechenden Funktionen (siehe der andere Thread) ... denn die liegen eher nicht an denselben Adressen wie bei der 7580/7590, weil es ja nur 1/4 des RAM gibt.

EDIT:
Wer das Laden des TUN-Drivers automatisieren möchte, könnte z.B. die Zeile

modprobe tun

vor dieser Zeile: https://github.com/Freetz/freetz/bl...n-v2-cgi/files/root/etc/init.d/rc.openvpn#L42 einfügen (wenn man das V2-CGI benutzen will) oder vor dieser: https://github.com/Freetz/freetz/blob/master/make/openvpn-cgi/files/root/etc/init.d/rc.openvpn#L36 bei der älteren CGI-Variante.

Das "modprobe tun" ist unschädlich, wenn das LKM bereits geladen ist oder auch, wenn es gar nicht existiert, weil der TUN-Driver direkt in den Kernel gelinkt wurde. Das gibt dann zwar ggf. eine Fehlermeldung, aber die stört nicht wirklich. Spätestens beim Laden des LKM wird dann auch (passende Regeln für den udevd vorausgesetzt) das notwendige Device-File erzeugt ... wenn das zu lange brauchen sollte nach dem "modprobe" (das läuft asynchron), kann man auch noch ein "sleep" für 2-3 Sekunden dahinterhängen - das kann man dann sogar mittels "&& sleep 3" hinter das "modprobe" hängen, damit es nur dann ausgeführt wird, wenn das LKM tatsächlich existiert und der Code nicht in den Kernel gelinkt ist.

 

[CaptainMorgan]

hätte ich gerne erst mal die Adressen aus der /proc/kallsyms bei der 7560 für die entsprechenden Funktionen

Ich muss gestehen dass ich auch beim dritten und vierten Lesen vieles nicht verstanden habe...
Soll ich dir meine kallsyms (41573 Zeilen) hier posten, oder über einen Drittanbieter schicken?

Das "modprobe tun" ist unschädlich, wenn das LKM bereits geladen ist oder auch, wenn es gar nicht existiert, weil der TUN-Driver direkt in den Kernel gelinkt wurde. Das gibt dann zwar ggf. eine Fehlermeldung, aber die stört nicht wirklich.

Bei meinem config tut es erstmal gar nichts(scheinbar?), wenn man es in die Konsole eingibt.

https://www.ip-phone-forum.de/threa...60-freetz-14290-avm-6-83.295137/#post-2226673

Seit 2017 hat sich viel getan, im Punkt web-if findet man kein tun-modul mehr.
Ich habe aber alles durchforstet und spiele sobald ich die Box entbehren kann alles ein was sich danach anhört.
config.compressed:

Spoiler

FREETZ_USER_LEVEL_EXPERT=y
FREETZ_TYPE_7560=y
FREETZ_TYPE_FIRMWARE_07_0X=y
FREETZ_ENABLE_LED_DEACTIVATION=y
FREETZ_PACKAGE_BRIDGE_UTILS=y
FREETZ_PACKAGE_OPENSSL=y
FREETZ_PACKAGE_OPENSSL_TRACE=y
FREETZ_PACKAGE_OPENSSL_STATIC=y
FREETZ_PACKAGE_OPENVPN=y
FREETZ_PACKAGE_OPENVPN_STATIC=y
FREETZ_PACKAGE_SAMBA=y
FREETZ_SAMBA_VERSION_3_6=y
FREETZ_PACKAGE_SAMBA_NMBD=y
FREETZ_PACKAGE_VSFTPD=y
FREETZ_PACKAGE_VSFTPD_WITH_SSL=y
FREETZ_PACKAGE_VSFTPD_STATIC=y
FREETZ_PACKAGE_VTUN=y
FREETZ_PACKAGE_VTUN_STATIC=y
FREETZ_BUSYBOX_TUNCTL=y
FREETZ_BUSYBOX_FEATURE_TUNCTL_UG=y
FREETZ_SECURITY_LEVEL=0
FREETZ_FWMOD_SIGN=y
FREETZ_FWMOD_SIGN_PRIVATE_KEY_PASSWORD="XxxxxxXxxxxxx"

EDIT 00:40:
Ich habe jetzt die Packages VTUN und BRIDGE_UTIL, und das busybox feature TUNCTL aufgenommen.
Die Syslog ändert sich damit:

Jan  1 01:00:58 XxxxxXxxXxxxxx user.notice FREETZMOD: openvpn is updating inetd ... active.
Jan 10 00:29:03 XxxxxXxxXxxxxx daemon.warn openvpn[6384]: disabling NCP mode (--ncp-disable) because not in P2MP client or server mode
Jan 10 00:29:03 XxxxxXxxXxxxxx daemon.err openvpn[6384]: Options error: You must define TUN/TAP device (--dev)
Jan 10 00:29:03 XxxxxXxxXxxxxx daemon.warn openvpn[6384]: Use --help for more information.
Jan 10 00:29:08 XxxxxXxxXxxxxx daemon.warn openvpn[6444]: disabling NCP mode (--ncp-disable) because not in P2MP client or server mode
Jan 10 00:29:08 XxxxxXxxXxxxxx daemon.err openvpn[6444]: Options error: You must define TUN/TAP device (--dev)
Jan 10 00:29:08 XxxxxXxxXxxxxx daemon.warn openvpn[6444]: Use --help for more information.
Jan 10 00:29:14 XxxxxXxxXxxxxx daemon.warn openvpn[6456]: disabling NCP mode (--ncp-disable) because not in P2MP client or server mode
Jan 10 00:29:14 XxxxxXxxXxxxxx daemon.err openvpn[6456]: Options error: You must define TUN/TAP device (--dev)
Jan 10 00:29:14 XxxxxXxxXxxxxx daemon.warn openvpn[6456]: Use --help for more information.
Jan 10 00:29:20 XxxxxXxxXxxxxx daemon.warn openvpn[6469]: disabling NCP mode (--ncp-disable) because not in P2MP client or server mode
Jan 10 00:29:20 XxxxxXxxXxxxxx daemon.err openvpn[6469]: Options error: You must define TUN/TAP device (--dev)
Jan 10 00:29:20 XxxxxXxxXxxxxx daemon.warn openvpn[6469]: Use --help for more information.
Jan 10 00:29:26 XxxxxXxxXxxxxx daemon.warn openvpn[6470]: disabling NCP mode (--ncp-disable) because not in P2MP client or server mode
Jan 10 00:29:26 XxxxxXxxXxxxxx daemon.err openvpn[6470]: Options error: You must define TUN/TAP device (--dev)
Jan 10 00:29:26 XxxxxXxxXxxxxx daemon.warn openvpn[6470]: Use --help for more information.

Ich bin mir wiedermal nicht genau sicher was da von mir gefordert wird?
Ich habe tap0 in der ar7.cfg eth0 zugeordnet, ist mehr zu tun?

 

[PeterPawn]

In dem Ausschnitt der ".config" ist ja nicht mal ein "FREETZ_MODULE_tun=y" zu sehen (mag sein, daß das die Standardeinstellung wäre und deshalb in der ".config.compressed" nicht auftaucht - andererseits ist das schon komisch, weil der TUN-Driver eigentlich als "Standard" nicht gebraucht würde und nur bei Auswahl von FREETZ_PACKAGE_OPENVPN - was hier ja offenbar aktiviert ist - auch entsprechend gesetzt werden sollte), was zumindest mal vorhanden sein sollte, damit der TUN-Driver überhaupt als LKM gebaut wird.

Du hast nicht zufällig die verwendete Konfiguration von irgendeiner anderen Box oder einem älteren Freetz-Build einfach nur kopiert?

Wenn das so sein sollte, dann funktioniert das halt (an so vielen Stellen) nicht ohne entsprechende Probleme (darum gab es ja von mir den PR hier: https://github.com/Freetz/freetz/pull/55) ... bei einer "frischen" Installation sollte dann tatsächlich auch "FREETZ_MODULE_tun=y" gesetzt werden, weil es zuvor noch keinen Wert hatte (egal, ob der nun "y" oder "n" war) oder der alte Wert gegen irgendwelche Einschränkungen verstößt. Das sollte bei der 7560 aber sogar automatisch der Fall sein, denn da müßte eigentlich "FREETZ_AVM_HAS_BUILTIN_TUN" auf "n" stehen und damit sollte sich für "FREETZ_MODULE_tun" ein "y" ergeben. Warum das dann nicht als "geändert" in die ".config.compressed" geschrieben wird, ist mir schleierhaft ... aber auch das kann durchaus noch sein.

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

Du mußt am Ende jedenfalls selbst sehen, ob Dein Image den TUN-Driver nun als LKM enthält ("tun.ko" irgendwo unterhalb von "modules") und wenn Du den per Shell von Hand lädst (notfalls kennt das "modprobe" noch eine "--verbose"-Option, iirc - aber auch das hat garantiert einen "usage screen"), dann sollte man ihn auch in der "lsmod"-Ausgabe sehen bzw. der "udevd" sollte das passende Device-File anlegen. Wenn das erst einmal der Fall ist, kann man sich über das weitere Vorgehen Gedanken machen ... ansonsten klemmt es schon deutlich früher.

Und genau weil man das nicht wirklich sehen kann in der ".config.compressed", lautet die Forderung eigentlich auch immer, daß man die ".config" hier anhängen sollte bei Fehlern (dafür gibt es die Funktion zum Anhängen von Textdateien, weil dann der Leser entscheiden kann, ob und wo er das laden bzw. lesen will) und nicht die "kleine Version". Die bringt nämlich nur dann irgendwelche Erkenntnisse, wenn man mit ihr die Konifguration selbst nachstellen will ... beim reinen "Ansehen" müßte man immer noch 100% sicher wissen, welchen Standardwert eine Einstellung (in Abhängigkeit von vielen anderen) eigentlich hat - denn diese "komprimierte Version" enthält eben nur die von den Standardeinstellungen abweichenden Werte und da sind offenbar diejenigen gar nicht berücksichtigt, die durch implizites Setzen ihren Wert geändert haben. Ansonsten sollte das "FREETZ_MODULE_tun=y" da ja auch dabei sein ...

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

Seit 2017 hat sich viel getan, im Punkt web-if findet man kein tun-modul mehr.

Der erste Link in #2 sollte Dich eigentlich auch nur mit der Nase darauf stoßen, daß Du ganz offensichtlich den TUN-Driver nicht geladen hast und daß der bei den GRX-Boxen eben nicht mehr automatisch im Kernel enthalten ist - was man durch eigene Suche auch hätte feststellen können (und müssen), denn dieser Thread bezieht sich ja auch explizit auf OpenVPN auf der 7560 und die Fehlermeldung dort ist dieselbe - ergo sollte der Thread auch auffindbar gewesen sein, wenn man ihn nicht kennt und danach suchen muß.

Soll ich dir meine kallsyms (41573 Zeilen) hier posten, oder über einen Drittanbieter schicken?

Nein, das sollst Du nicht. Denn diese Frage stellt sich eben frühestens dann, wenn Du das OpenVPN irgendwie mal erfolgreich gestartet kriegst und die Box dann (aber erst dann) mit einer "kernel panic" darauf reagiert ... aber das steht nun mal deutlich da:

Wenn danach die Box beim Empfang von Paketen über OpenVPN in "kernel panic" verfällt,

und ich verstehe nicht so richtig, wie man das nicht verstehen kann bzw. warum man sich jetzt Gedanken über dieses "danach" macht, wenn man noch gar nicht bis zu diesem Punkt gekommen ist.

Ich habe Dir das ja eigentlich nur aufgeschrieben, damit es hinterher nicht heißt: "Das hättest Du ja auch gleich sagen können, dann hätte ich gar nicht erst angefangen." - an der Reihenfolge der Aktionen, die Du nun erst einmal erfolgreich zum Abschluß bringen mußt, bevor dieser Zeitpunkt "danach" überhaupt erreicht ist, ändert das mal genau gar nichts.

Und selbst dann kann ich ein "Ich verstehe das nicht." irgendwie nicht so richtig nachvollziehen ... hier ist eindeutig von zwei "grep"-Befehlen die Rede und wo diese zu finden wären. Das (absolut komplette) Lesen des anderen Threads muß vielleicht nicht sein ... aber zumindest das Lesen weiterer Beiträge sollte drin sein und mehr als dorthin verlinken will und kann ich auch nicht. Dein "Angebot", mir jetzt die gesamte Ausgabe von "/proc/kallsyms" zu senden (wobei ich Dir durchaus noch zugute halte, daß Du erst einmal gefragt hast und das nicht einfach gleich machst), wälzt ja schon die Arbeit damit eher auf mich ab, findest Du nicht auch? Drei Beiträge nach dem direkt verlinkten (und da geht mein Link nicht mal auf den ersten Beitrag des Threads) steht dann wieder, wo die beiden "grep"-Befehle zu finden sind im anderen Thread.

EDIT 01:31 Uhr:

Ich habe jetzt die Packages VTUN [...] aufgenommen.

Das ist mal der größte Quatsch, denn OpenVPN und VTun sind Antagonisten und für OpenVPN braucht man kein VTun-Paket. Das TUNCTL-Feature der BusyBox braucht man am Ende auch nicht wirklich, denn OpenVPN kümmert sich (bei vorhandenem "clone device" /dev/net/tun) schon selbst um das Einrichten der passenden Device-Files. Und ein "brctl" (um das TAP-Device mit den Ethernet-Ports in eine Bridge zu stecken) gibt es entweder im AVM-Image bereits oder es reicht auch das aus der BusyBox.

Irgendwie ergeben damit alle drei Änderungen an der Freetz-Konfiguration nur begrenzten Sinn.

Wie wäre es denn mit planvollem Vorgehen anstelle von "wildem Probieren"? Verstehe mich bitte nicht falsch ... aber ich bin nur zur Hilfestellung bereit, wenn das tatsächlich systematisch erfolgt und dann ist der erste Schritt immer noch die Feststellung, ob der TUN-Driver vorhanden ist und geladen werden kann von Hand. Beim "Herumprobieren" treten dann wieder so viele andere Probleme auf (gerade dann, wenn sich der "Testende" gar nicht wirklich sicher ist, was er da eigentlich macht), daß mir das am Ende zu mühsam wird.

 

[CaptainMorgan]

In dem Ausschnitt der ".config" ist ja nicht mal ein "FREETZ_MODULE_tun=y" zu sehen (mag sein, daß das die Standardeinstellung wäre und deshalb in der ".config.compressed" nicht auftaucht

Im Anhang nun .config und .config.compressed. Von dem Image was zur Zeit geladen ist, aus meinem letzten Post um 00:40 Uhr. In Zeile 1138 heißt es "FREETZ_MODULE_tun=y".

Du hast nicht zufällig die verwendete Konfiguration von irgendeiner anderen Box oder einem älteren Freetz-Build einfach nur kopiert?

Nein. Es wurde ein eigener Pull gemacht in einen neuen Ordner, nur für die 7560, und das waren die zweite und dritte Konfiguration seid der Standardeinstellung. Auch die Linux-VM ist so gut wie frisch.

Das sollte bei der 7560 aber sogar automatisch der Fall sein, denn da müßte eigentlich "FREETZ_AVM_HAS_BUILTIN_TUN" auf "n" stehen und damit sollte sich für "FREETZ_MODULE_tun" ein "y" ergeben. Warum das dann nicht als "geändert" in die ".config.compressed" geschrieben wird, ist mir schleierhaft ... aber auch das kann durchaus noch sein.

"FREETZ_AVM_HAS_BUILTIN_TUN" kommt in meiner .config gar nicht vor.
Steht aber dennoch auf n, denn:

Du mußt am Ende jedenfalls selbst sehen, ob Dein Image den TUN-Driver nun als LKM enthält ("tun.ko" irgendwo unterhalb von "modules")

Ist in "make menuconfig" vorhanden, und als FREETZ_MODULE_tun=y in der config.

-->Kernel modules --> net
Defined at config/.ache.in:41576
Depends on: FREETZ_REPLACE_MODULE_AVAILABLE [=y] && !FREETZ_AVM_HAS_TUN_BUILTIN [=n]
Selected by: FREETZ_PACKAGE_OPENVPN [=y] && !FREETZ_AVM_HAS_TUN_BUILTIN [=n]

Bis dahin stimmt also alles. Abgesehen von einer etwas "schleierhaften" Übernahme in die .config.compressed.

Und genau weil man das nicht wirklich sehen kann in der ".config.compressed", lautet die Forderung eigentlich auch immer, daß man die ".config" hier anhängen sollte bei Fehlern (dafür gibt es die Funktion zum Anhängen von Textdateien, weil dann der Leser entscheiden kann, ob und wo er das laden bzw. lesen will) und nicht die "kleine Version". Die bringt nämlich nur dann irgendwelche Erkenntnisse, wenn man mit ihr die Konifguration selbst nachstellen will ... beim reinen "Ansehen" müßte man immer noch 100% sicher wissen, welchen Standardwert eine Einstellung (in Abhängigkeit von vielen anderen) eigentlich hat - denn diese "komprimierte Version" enthält eben nur die von den Standardeinstellungen abweichenden Werte und da sind offenbar diejenigen gar nicht berücksichtigt, die durch implizites Setzen ihren Wert geändert haben. Ansonsten sollte das "FREETZ_MODULE_tun=y" da ja auch dabei sein ...

Meine erste Intuition war erstmal zu beweisen dass ich möglichst wenig selbst verstellt habe, aber seid ich den Dateianhang gefunden habe werden selbstverständlich ab hier immer beide angehängt.

Denn diese Frage stellt sich eben frühestens dann, wenn Du das OpenVPN irgendwie mal erfolgreich gestartet kriegst und die Box dann (aber erst dann) mit einer "kernel panic" darauf reagiert ...

OpenVPN startet erfolgreich, zwar nur über inetd, aber es startet. Die gezeigten Fehlermeldungen in der Syslog erscheinen synchron mit dem Versuch sich zu verbinden.
Keine kernel_panic, evtl langsam etwas Panik bei mir, aber ich arbeite an einem Patch.

Der erste Link in #2 sollte Dich eigentlich auch nur mit der Nase darauf stoßen, daß Du ganz offensichtlich den TUN-Driver nicht geladen hast und daß der bei den GRX-Boxen eben nicht mehr automatisch im Kernel enthalten ist - was man durch eigene Suche auch hätte feststellen können (und müssen), denn dieser Thread bezieht sich ja auch explizit auf OpenVPN auf der 7560 und die Fehlermeldung dort ist dieselbe - ergo sollte der Thread auch auffindbar gewesen sein, wenn man ihn nicht kennt und danach suchen muß.

Das ist mal der größte Quatsch, denn OpenVPN und VTun sind Antagonisten und für OpenVPN braucht man kein VTun-Paket. Das TUNCTL-Feature der BusyBox braucht man am Ende auch nicht wirklich, denn OpenVPN kümmert sich (bei vorhandenem "clone device" /dev/net/tun) schon selbst um das Einrichten der passenden Device-Files. Und ein "brctl" (um das TAP-Device mit den Ethernet-Ports in eine Bridge zu stecken) gibt es entweder im AVM-Image bereits oder es reicht auch das aus der BusyBox.
Irgendwie ergeben damit alle drei Änderungen an der Freetz-Konfiguration nur begrenzten Sinn.

Ich lade also beizeiten wieder ein sinnvolleres, minimales Image, nur OpenVPN, samba, vsftpd, openssl.
Was ich mir zugute halten möchte ist dass es die Fehlermeldung wenigstens beeinflusst hat, es war nunmal eben ein "semieducated guess".
Man hat mir gesagt das wahrscheinlch was fehlt, also habe ich das passendste dazu getan. Ich komme aus dem dem Maschinenbau, falls das die Denkweise erklärt. (hoffentlich werde ich nicht gebannt)

Wie wäre es denn mit planvollem Vorgehen anstelle von "wildem Probieren"? Verstehe mich bitte nicht falsch ... aber ich bin nur zur Hilfestellung bereit, wenn das tatsächlich systematisch erfolgt und dann ist der erste Schritt immer noch die Feststellung, ob der TUN-Driver vorhanden ist und geladen werden kann von Hand. Beim "Herumprobieren" treten dann wieder so viele andere Probleme auf (gerade dann, wenn sich der "Testende" gar nicht wirklich sicher ist, was er da eigentlich macht), daß mir das am Ende zu mühsam wird.

Andererseits werden nur so aus Blinden Sehende. Ich und das ganze Forum sind dir wirklich dankbar.

Nur eine Amerkung: Wenn man einer des Meister seines Faches ist, kann es sein das der Laie manchmal jedes dritte Wort nachschlagen muss. Dass dann einiges durcheinander geht bitte ich zu entschuldigen. Man möchte ja auch einigermaßen zügig eine Rückmeldung geben, also tüftelt man schonmal auf eigene Faust.

ob Dein Image den TUN-Driver nun als LKM enthält ("tun.ko" irgendwo unterhalb von "modules") und wenn Du den per Shell von Hand lädst (notfalls kennt das "modprobe" noch eine "--verbose"-Option, iirc - aber auch das hat garantiert einen "usage screen"), dann sollte man ihn auch in der "lsmod"-Ausgabe sehen bzw. der "udevd" sollte das passende Device-File anlegen.

Das ist so ein Satz, an dem Anfänger doch zu knabbern haben

Und selbst dann kann ich ein "Ich verstehe das nicht." irgendwie nicht so richtig nachvollziehen ... hier ist eindeutig von zwei "grep"-Befehlen die Rede und wo diese zu finden wären. Das (absolut komplette) Lesen des anderen Threads muß vielleicht nicht sein ... aber zumindest das Lesen weiterer Beiträge sollte

Ein "Ich verstehe / verstehe nicht" zu verstehen oder nicht zu verstehen wäre auch ein "Hermeneutischer Zirkel"-schluss. Jeder kann nunmal nicht aus seinem Kopf raus.


Edit: Default für eine 7560 ist kein tun.ko, wird aber angeschaltet bei der Wahl von OpenVPN, soweit stimmt alles.

 

[PeterPawn]

"banned" gibt es bei mir nicht, solange meine Worte (bzw. die damit transportierten Ideen und Haltungen) Dich erreichen - Du mußt auch Dein Gegenüber verstehen, wenn (auch anerkanntermaßen in dem Bemühen einer "zügigen Reaktion") das Ganze sich mit Vollgas in die falsche Richtung bewegt. Dann lieber gleich deutliche Sprache und Ansage, als irgendwelches Wischiwaschi und steigende Unlust, solchen "Abwegen" geistig zu folgen. "Dankbarkeit" ist gar nicht das Thema ... schön, wenn man helfen kann, ggf. klappt das manchmal auch erst bei weiteren Lesern. Eine Konkretisierung dessen, was man nicht versteht, ermöglicht die ausführlichere Beschreibung dieses bestimmten Punktes ... ein generelles "ist mir zu hoch" bietet diese Möglichkeit nicht und beinhaltet (nach meiner Erfahrung) immer die Möglichkeit, daß der solchermaßen Aussagende die Lust verliert - mit der Folge, daß alle bisher investierten Anstrengungen dann auch für die Katz sind. Daher bin ich bei solchen Aussagen per se schon skeptisch ... denn auch für jemanden, der helfen will, sind solche Umkehrentscheidungen auf halber Strecke (bzw. manchmal sogar kurz vor dem Ziel, das der Ungeduldige dann nur noch nicht sehen kann) extrem frustrierend - zumindest geht das mir immer so. Daher lieber gleich deutliche Worte und wer das übersteht ohne blaue Flecken auf der Seele, bei dem hat man dann auch gute Chancen, daß "Stamina" vorhanden ist und sich die investierte Zeit lohnen kann.

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

Zurück zum Thema:

Was sagt denn nun ein "modprobe -v tun" bzw. ein anschließendes "lsmod"? Zumindest in der "dmesg"-Ausgabe sollte sich auch die Kernelspeicher-Verwaltung darüber empören, daß für "tun.ko" kein Eintrag in der AVM-Module-Tabelle zu finden ist (zumindest mit dem originalen AVM-Kernel). Wird der TUN-Driver erfolgreich geladen, sollte auch "/dev/net/tun" im Dateisystem auftauchen, daß das ja vom "udevd" eingerichtet wird.

Wenn diese Schritte alle zeigen, daß "tun.ko" erfolgreich geladen wurde, sollte auch (bei korrekter Client-/Server-Konfiguration) der OpenVPN-Daemon starten ... und sich nicht länger darüber beschweren, daß er - wie in #1 bei "Frage 2" - "/dev/net/tun" nicht finden kann. Da versucht der Daemon nämlich dann seinerseits, das passende Gerät für die OpenVPN-Konfiguration zu erzeugen - hier wäre das ein TAP-Device (also L2-Ethernet).

EDIT: OK, das "-v" ist beim BusyBox-"modprobe" jetzt nicht so der Brüller ... da kommen wohl nur Fehlermeldungen, wenn "tun.ko" nicht in der "modules.dep" stehen sollte. Aber in der "lsmod"-Ausgabe sollte man das Ergebnis sehen können.

 

[CaptainMorgan]

Also, habe nun wieder ein simpleres Image geladen, .config und .config.compressed im Anhang.
OpenVPN startet also doch nicht wirklich, beim Starten über Manuell oder Automatisch kommt dieselbe Fehlermeldung.

Dann habe ich ein paar der erwähnten Konsolenausgaben getestet.
grep netif_receive_skb, grep ip_forward und lsmod:

Spoiler

root@XxxxxXxxXxxxxx:/# grep netif_receive_skb /proc/kallsyms
80a61da0 t __netif_receive_skb_core
80a623f0 t __netif_receive_skb
80a62474 T netif_receive_skb
root@XxxxxXxxXxxxxx:/# grep ip_forward /proc/kallsyms
80ab9574 t ip_forward_finish
80ab97a4 T ip_forward
80abb06c T ip_forward_options
root@XxxxxXxxXxxxxx:/var/mod/root# lsmod
Module                  Size  Used by    Tainted: P
spdmon                 18026  0
hwmon                   1065  1 spdmon
qca_da                195199  0
qca_ol               1036972  0
ath_dev               318429  1 qca_da
ath_rate_atheros       33116  2 qca_da,ath_dev
ath_hal               356519  3 qca_da,ath_dev,ath_rate_atheros
umac                 1545771  3 qca_da,qca_ol,ath_dev
krtp                  226943  0
ath_spectral           40116  4 qca_da,qca_ol,ath_dev
ath_dfs                76389  3 qca_da,qca_ol,umac
qdf                    23789  8 qca_da,qca_ol,ath_dev,ath_rate_atheros,ath_hal,umac,ath_spectral,ath_dfs
asf                     7534  7 qca_da,qca_ol,ath_dev,ath_hal,umac,ath_spectral,ath_dfs
mem_manager             7006  2 qca_ol,umac
aae                   116695  6 qca_da,qca_ol,ath_dev,ath_hal,umac,ath_dfs
kdsldmod             1614611  4
cprocfsmod              7042  1 kdsldmod
dect_io                17443  0
avm_dect              320285  1 dect_io
capi_codec            379977  0
isdn_fbox_fon5        894480  6 krtp
pcmlink               412372  4 avm_dect,capi_codec,isdn_fbox_fon5
vrx318_tc             190940  0
xhci_hcd               95121  0
sch_tbf                 4979  1
sch_hw                  7256  0
ppa_api_proc           33447  0
ppa_api               388402  1 ppa_api_proc
ltq_directpath_datapath    28361  0
ltq_tmu_hal_drv       180535  1 ltq_directpath_datapath
ltq_pae_hal            68166  0
nls_utf8                1040  0
vfat                   10593  0
Piglet_noemif          41845  0
rtc_avm                 4604  1 pcmlink
led_modul_Fritz_Box_HW221   175620  6

dsmeg im Anhang.

Dann habe ich modprobe -v tun probiert, wie erwartet ohne jedes verbose.

Im Anschluss war tun im lsmod zu sehen:

root@XxxxxXxxXxxxxxx:/# lsmod
Module                  Size  Used by    Tainted: P
tun                    18479  0
spdmon                 18026  0
hwmon                   1065  1 spdmon
.......

Nun startet OpenVPN auch erstmal manierlich.
Und PeterPawn hatte wie immer die richtige Vorahnung.
Beim Versuch einer Verbindung geht anschließend einiges schief:
Syslog/OpenVPN:

Spoiler

Jan 11 14:14:23 XxxxxXxxXxxxxx daemon.notice openvpn[5284]: OpenVPN 2.4.6 mips-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [AEAD] built on Jan 10 2019
Jan 11 14:14:23 XxxxxXxxXxxxxx daemon.notice openvpn[5284]: library versions: OpenSSL 1.0.2q  20 Nov 2018, LZO 2.10
Jan 11 14:14:23 XxxxxXxxXxxxxx daemon.notice openvpn[5285]: Diffie-Hellman initialized with 2048 bit key
Jan 11 14:14:24 XxxxxXxxXxxxxx daemon.notice openvpn[5285]: Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Jan 11 14:14:24 XxxxxXxxXxxxxx daemon.notice openvpn[5285]: Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Jan 11 14:14:24 XxxxxXxxXxxxxx daemon.notice openvpn[5285]: TUN/TAP device tap0 opened
Jan 11 14:14:24 XxxxxXxxXxxxxx daemon.notice openvpn[5285]: TUN/TAP TX queue length set to 100
Jan 11 14:14:24 XxxxxXxxXxxxxx daemon.warn openvpn[5285]: Could not determine IPv4/IPv6 protocol. Using AF_INET6
Jan 11 14:14:24 XxxxxXxxXxxxxx daemon.notice openvpn[5285]: Socket Buffers: R=[87380->87380] S=[16384->16384]
Jan 11 14:14:24 XxxxxXxxXxxxxx daemon.notice openvpn[5285]: setsockopt(IPV6_V6ONLY=0)
Jan 11 14:14:24 XxxxxXxxXxxxxx daemon.notice openvpn[5285]: Listening for incoming TCP connection on [AF_INET6][undef]:1194
Jan 11 14:14:24 XxxxxXxxXxxxxx daemon.notice openvpn[5285]: TCPv6_SERVER link local (bound): [AF_INET6][undef]:1194
Jan 11 14:14:24 XxxxxXxxXxxxxx daemon.notice openvpn[5285]: TCPv6_SERVER link remote: [AF_UNSPEC]
Jan 11 14:14:24 XxxxxXxxXxxxxx daemon.notice openvpn[5285]: chroot to '/var/tmp/openvpn' and cd to '/' succeeded
Jan 11 14:14:24 XxxxxXxxXxxxxx daemon.notice openvpn[5285]: GID set to openvpn
Jan 11 14:14:24 XxxxxXxxXxxxxx daemon.notice openvpn[5285]: UID set to openvpn
Jan 11 14:14:24 XxxxxXxxXxxxxx daemon.notice openvpn[5285]: MULTI: multi_init called, r=256 v=256
Jan 11 14:14:24 XxxxxXxxXxxxxx daemon.notice openvpn[5285]: IFCONFIG POOL: base=192.168.172.240 size=15, ipv6=0
Jan 11 14:14:24 XxxxxXxxXxxxxx daemon.notice openvpn[5285]: MULTI: TCP INIT maxclients=15 maxevents=19
Jan 11 14:14:24 XxxxxXxxXxxxxx daemon.notice openvpn[5285]: Initialization Sequence Completed
Jan 11 14:14:37 XxxxxXxxXxxxxx daemon.notice openvpn[5285]: TCP connection established with [AF_INET6]::ffff:192.168.172.58:54823
Jan 11 14:14:38 XxxxxXxxXxxxxx daemon.notice openvpn[5285]: 192.168.172.58 TLS: Initial packet from [AF_INET6]::ffff:192.168.172.58:54823, sid=e9887873 e0099af0
Jan 11 14:14:38 XxxxxXxxXxxxxx kern.warn kernel: [36718.212000][0][0]system-load 1 loadavg 1.17 1.6 1.6 - 128 tasks:0 % curr:openvpn(0 %)max:psetd(0 %, pid:1905) pgstat: sum=46498 free=13205 slab=5546 alloc=0/s fault=39/s ai_sys:20.57/h 0x8a4a0624 ath_getstats+0x108/0x1d8 [qca
Jan 11 14:14:39 XxxxxXxxXxxxxx daemon.notice openvpn[5285]: 192.168.172.58 VERIFY OK: depth=1, C=DE, ST=XxxxxxxxxxXxxxx, L=Xxxxxxxx, O=OpenVPN, OU=XxxxxXxxXxxxxx, CN=XxxxxXxxXxxxxx, name=Xxxxxx Xxxxxxx, emailAddress=xxxxxxxxxxxxxxxxxxxxxx
Jan 11 14:14:39 XxxxxXxxXxxxxx daemon.notice openvpn[5285]: 192.168.172.58 VERIFY OK: depth=0, C=DE, ST=XxxxxxxxxxXxxxx, L=Xxxxxxxx, O=OpenVPN, OU=XxxxxxxXxxxxxx, CN=XxxxxxxXxxxxxx, name=Xxxxxx Xxxxxxx, emailAddress=xxxxxxxxxxxxxxxxxxxxxx
Jan 11 14:14:39 XxxxxXxxXxxxxx daemon.notice openvpn[5285]: 192.168.172.58 peer info: IV_VER=2.4.6
Jan 11 14:14:39 XxxxxXxxXxxxxx daemon.notice openvpn[5285]: 192.168.172.58 peer info: IV_PLAT=win
Jan 11 14:14:39 XxxxxXxxXxxxxx daemon.notice openvpn[5285]: 192.168.172.58 peer info: IV_PROTO=2
Jan 11 14:14:39 XxxxxXxxXxxxxx daemon.notice openvpn[5285]: 192.168.172.58 peer info: IV_NCP=2
Jan 11 14:14:39 XxxxxXxxXxxxxx daemon.notice openvpn[5285]: 192.168.172.58 peer info: IV_LZ4=1
Jan 11 14:14:39 XxxxxXxxXxxxxx daemon.notice openvpn[5285]: 192.168.172.58 peer info: IV_LZ4v2=1
Jan 11 14:14:39 XxxxxXxxXxxxxx daemon.notice openvpn[5285]: 192.168.172.58 peer info: IV_LZO=1
Jan 11 14:14:39 XxxxxXxxXxxxxx daemon.notice openvpn[5285]: 192.168.172.58 peer info: IV_COMP_STUB=1
Jan 11 14:14:39 XxxxxXxxXxxxxx daemon.notice openvpn[5285]: 192.168.172.58 peer info: IV_COMP_STUBv2=1
Jan 11 14:14:39 XxxxxXxxXxxxxx daemon.notice openvpn[5285]: 192.168.172.58 peer info: IV_TCPNL=1
Jan 11 14:14:39 XxxxxXxxXxxxxx daemon.notice openvpn[5285]: 192.168.172.58 peer info: IV_GUI_VER=OpenVPN_GUI_11
Jan 11 14:14:39 XxxxxXxxXxxxxx daemon.notice openvpn[5285]: 192.168.172.58 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 4096 bit RSA
Jan 11 14:14:39 XxxxxXxxXxxxxx daemon.notice openvpn[5285]: 192.168.172.58 [XxxxxxxXxxxxxx] Peer Connection Initiated with [AF_INET6]::ffff:192.168.172.58:54823
Jan 11 14:14:39 XxxxxXxxXxxxxx daemon.notice openvpn[5285]: XxxxxxxXxxxxxx/192.168.172.58 MULTI_sva: pool returned IPv4=192.168.172.240, IPv6=(Not enabled)
Jan 11 14:14:39 XxxxxXxxXxxxxx daemon.err openvpn[5285]: XxxxxxxXxxxxxx/192.168.172.58 MULTI: no --ifconfig-pool netmask parameter is available to push to XxxxxxxXxxxxxx/192.168.172.58
Jan 11 14:14:39 XxxxxXxxXxxxxx daemon.err openvpn[5285]: XxxxxxxXxxxxxx/192.168.172.58 MULTI: no dynamic or static remote --ifconfig address is available for XxxxxxxXxxxxxx/192.168.172.58
Jan 11 14:14:40 XxxxxXxxXxxxxx daemon.notice openvpn[5285]: XxxxxxxXxxxxxx/192.168.172.58 PUSH: Received control message: 'PUSH_REQUEST'
Jan 11 14:14:40 XxxxxXxxXxxxxx daemon.notice openvpn[5285]: XxxxxxxXxxxxxx/192.168.172.58 SENT CONTROL [XxxxxxxXxxxxxx]: 'PUSH_REPLY,route-gateway 192.168.172.2,route 192.168.178.0 255.255.255.0,route 192.168.172.0 255.255.255.0,ping 10,ping-restart 120,peer-id 0,cipher AES-256-GCM
Jan 11 14:14:40 XxxxxXxxXxxxxx daemon.notice openvpn[5285]: XxxxxxxXxxxxxx/192.168.172.58 Data Channel: using negotiated cipher 'AES-256-GCM'
Jan 11 14:14:40 XxxxxXxxXxxxxx daemon.notice openvpn[5285]: XxxxxxxXxxxxxx/192.168.172.58 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Jan 11 14:14:40 XxxxxXxxXxxxxx daemon.notice openvpn[5285]: XxxxxxxXxxxxxx/192.168.172.58 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Jan 11 14:14:40 XxxxxXxxXxxxxx daemon.notice openvpn[5285]: XxxxxxxXxxxxxx/192.168.172.58 MULTI: Learn: 00:ff:20:2f:5a:91 -> XxxxxxxXxxxxxx/192.168.172.58
Jan 11 14:14:40 XxxxxXxxXxxxxx kern.err kernel: [36720.688000][3][kernel-trap] pc=0x80a623f8(0x80a623f8 __netif_receive_skb+0x8/0x84) addr=0x00000001 task=openvpn pid=5285 ra=0x80a63448(0x80a63448 process_backlog+0xcc/0x1f8)
Jan 11 14:14:40 XxxxxXxxXxxxxx kern.warn kernel: [36720.692000][3]CPU: 3 PID: 5285 Comm: openvpn Tainted: P           O 3.10.104 #2
Jan 11 14:14:40 XxxxxXxxXxxxxx kern.err kernel: [36720.868000][3] $28 : 85c84000 [threadinfo(openvpn): 85c84000+0x0]
Jan 11 14:14:40 XxxxxXxxXxxxxx kern.err kernel: [36720.876000][3] $29 : 85c87c20 [stack(openvpn): 85c84000+0x3c20]
Jan 11 14:14:41 XxxxxXxxXxxxxx kern.warn kernel: [36720.932000][3]Process openvpn (pid: 5285, threadinfo=85c84000, task=8da8f060, tls=77c17460)
Jan 11 14:14:41 XxxxxXxxXxxxxx kern.warn kernel: [36721.004000][3][3]system-load 2 loadavg 1.24 1.7 1.6 - 128 tasks:0 % curr:openvpn(0 %)max:openvpn(0 %, pid:5285) pgstat: sum=46505 free=13184 slab=5537 alloc=0/s fault=0/s (sleep 17)
Jan 11 14:14:41 XxxxxXxxXxxxxx kern.err kernel: [36721.028000][3]85c87ca8 [stack(openvpn): 85c84000+0x3ca8]
Jan 11 14:14:41 XxxxxXxxXxxxxx kern.err kernel: [36721.064000][3]85c87d00 [stack(openvpn): 85c84000+0x3d00]
Jan 11 14:14:42 XxxxxXxxXxxxxx kern.emerg kernel: [36721.772000][3]  5285     6   3448    376   2168    648    136   1780   1780      0      0 {openvpn}
Jan 11 14:16:05 XxxxxXxxXxxxxx daemon.notice openvpn[3715]: OpenVPN 2.4.6 mips-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [AEAD] built on Jan 10 2019
Jan 11 14:16:05 XxxxxXxxXxxxxx daemon.notice openvpn[3715]: library versions: OpenSSL 1.0.2q  20 Nov 2018, LZO 2.10
Jan 11 14:16:05 XxxxxXxxXxxxxx daemon.notice openvpn[3725]: Diffie-Hellman initialized with 2048 bit key
Jan 11 14:16:05 XxxxxXxxXxxxxx daemon.notice openvpn[3725]: Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Jan 11 14:16:05 XxxxxXxxXxxxxx daemon.notice openvpn[3725]: Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Jan 11 14:16:05 XxxxxXxxXxxxxx daemon.err openvpn[3725]: ERROR: Cannot open TUN/TAP dev /dev/net/tun: No such file or directory (errno=2)
Jan 11 14:16:05 XxxxxXxxXxxxxx daemon.notice openvpn[3725]: Exiting due to fatal error
Jan 11 14:16:05 XxxxxXxxXxxxxx user.notice FREETZMOD: Starting openvpn ... done.

Ich nehme an "kern.emerg" und ein anschließender Neustart ist was man unter kernelpanic versteht.

Nach dem Neustart ist tun wieder aus der lsmod verschwunden.

Dass das Ganze etwas unregelmäßg und schwallartig kommt bitte ich zu entschuldigen, die 7560 ist mittlerweile AP und Switch für eine ganze Etage, daher müssen die Experimente gut getimed sein.

 

[PeterPawn]

Der Ausgabe aus "/proc/kallsyms" nach zu urteilen, verwendet der Kernel dieselben Adressen (gut, dafür gibt es ja schließlich auch eine MMU) und daher habe ich mal ein Skript für die HWRevision der 7560 auch noch eingecheckt (s. anderer Thread zu den Hintergründen).

Zuerst den Driver laden, dann das Skript aufrufen (natürlich muß das Image eine BusyBox mit dem "devmem"-Applet enthalten - wieder siehe anderer Thread) und dann könnte OpenVPN auch funktionieren, wenn man mal unterstellt, daß dieselben Adressen der Funktionen (eigentlich geht es eher um die "Verschiebung" der Einsprungadressen, die hier fehlt) darauf hinweisen, daß bei der 7560 dieselben Kernel-Patches angewendet wurden, wie bei der 7580 und 7590.

Das Skript muß man selbst in das Image kopieren (notfalls über "own-files", wenn man es anders nicht kennt) und auch den Aufruf muß man noch selbst ausführen lassen - eine automatisierte (bzw. automatisierbare) Lösung braucht noch etwas (es ist schon wieder etwas "im Anflug", was da wohl dazwischen grätschen könnte bei der vorhandenen Zeit).

 

[CaptainMorgan]

Muss das Skript in zwangsläufig in das Image?
Sonst würde ich einfach ein neues Image mit devmem-applet laden, und das Skript auf den USB Stick oder den Geräteigenen ftp-Bereich.
Anschließend dann "modprobe -tun" und das ausführen des Skriptes in die rc.custom. Oder kann ich auch modprobe -tun mit in dein Skript packen? Ist ja /bin/sh...
Kann man auch das starten von Open VPN so manuell nachholen, so dass die Einstellung zwar manuell bleibt, über rc.custom aber damit, sagen wir, halbautomatisch?
Wie gesagt Linux-Anfänger, aber stell ich mir das so richtig vor? Muss ich evtl "Verzögerungen" einfügen dass das Skript etwas auf den Treiber wartet, und OpenVPN etwas auf das Skript?

Off-Topic-Edit:
Habe dich jetzt paar mal das LKM erwähnen sehen, was ein großes wichtiges DIng zu sein scheint, aber ein überfliegen von Yourfritz.de und eine Suche im Forum brachten nichts(da zu kurz), wenn du mir kurz sagen würdest wofür die drei Buchstaben stehen wäre mir geholfen

 

[PeterPawn]

LKM steht für "loadable kernel module" und ist ein Weg, wie man einem existierenden Linux-Kernel weiteren Code hinzufügen kann. Praktisch jeder Linux-Treiber (sofern er als "module" übersetzt wurde und nicht fest in den Kernel gelinkt ist) stellt ein solches LKM dar. Aber auch eine Google-Suche nach "LKM" (ggf. noch mit "linux" als "Garnitur") sollte Dir da passende Ergebnisse (und weitere Erläuterungen) bringen.

Das Skript MUSS nicht in das Image hinein, solange man die passenden Vorkehrungen trifft, daß auch Dateien von USB-Volumes ausführbar sind (da gehört inzwischen auch der NAS-Bereich im Flash dazu) oder man den passenden Aufruf verwendet. Aber es muß natürlich auch nach jedem Systemstart erneut ausgeführt werden ... die Änderungen erfolgen nur im Hauptspeicher (absichtlich) und sind beim Neustart auch wieder weg.

Wartezeiten muß man nicht berücksichtigen, man kann auch das Patch-Skript problemlos mehrfach aufrufen, wobei es nur beim ersten Mal etwas zum Ändern finden kann.

Die "rc.custom" kann man selbstverständlich dafür auch benutzen ... wie der Name schon sagt, dient sie ja zur Ausführung von "custom commands", was i.d.R. "benutzerdefinierte Befehle" (im Gegensatz zu solchen, die vom "System" vorgegeben werden) sind. Das Eintragen der Kommandos in diese "rc.custom" meinte ich auch, wenn ich von "Handarbeit" spreche ... bei einer (halb-)automatischen Lösung würde man das wohl eher mit in das Start-Skript integrieren (für passende Stellen siehe #2), wobei die Reihenfolge zwischen "modprobe tun" und dem Patchen (in diesem konkreten Fall) auch egal ist, weil die zu patchenden Stellen sich nicht im "tun"-LKM befinden.

EDIT:
Allerdings darf man das OpenVPN dann auch erst in der "rc.custom" starten, wenn man das Laden des Treibers und das Patchen des Kernels erst dort implementiert ... die Abarbeitung dieser "rc.custom" erfolgt erst ziemlich am Ende der Initialisierung des Systems und wenn man davor schon das OpenVPN-Paket antreten will, wird das - absehbar - scheitern. Das also auf "manuell" gestellt und über den passenden "start"-Aufruf des "rc"-Skripts in der "rc.custom" im Nachhinein erst anschieben ... das wäre der "richtige" Weg (obwohl es so etwas selten gibt und "funktioniert" der Prüfstein sein sollte).

 

[CaptainMorgan]

Vielen Dank Peter! Dein Patch scheint zu funktionieren.
Das starten von OpenVPN kann man einfach auch auf Inetd schieben, ist im Grunde noch intelligenter.
Jetzt muss ich alles nur noch manierlich konfigurieren.

Eine Kleinigkeit:
Wenn ich das Skript über Telnet mit root aufrufe funktioniert es, aber über die rc.customs bekomme ich es nicht hin.
Ich habe es dann in der Rudi-Shell versucht, weil ich annehme dass die mit den gleichen Rechten läuft. Aber da kommt eine andere Ausgabe als in der Konsole:

./var/media/ftp/vpn_patch.sh
-->
Firmware version  is not in the list of supported versions.

Habe das Skript der Einfachhalthalber umbenannt. Chmod ist 777.
Das selbe mit "sh" oder "exec"

...solange man die passenden Vorkehrungen trifft, daß auch Dateien von USB-Volumes ausführbar sind (da gehört inzwischen auch der NAS-Bereich im Flash dazu) oder man den passenden Aufruf verwendet...

Mit welchen Rechten läuft die rc.customs, oder wie muss ein Skript-Aufruf darin aussehen?

 

[PeterPawn]

Das liest sich wie ein unvollständiges (Shell-)Environment beim Aufruf des Patches ... das Skript liest "HWRevision" nicht direkt aus dem Urlader aus, sondern es verläßt sich darauf, daß es im Shell-Environment die gleichnamige Variable gibt, die in der "rc.conf" eigentlich gesetzt werden müßte.

Wenn das in der "rc.custom" nicht der Fall ist, liegt das ggf. an der Art, wie dieses Skript aufgerufen wird ... ich nutze kein Freetz und müßte mich da auch erst einlesen.

Dann ist es wohl einfacher, wenn Du (nach positivem Test) die Abfrage von "HWRevision" im Skript einfach abschaltest ... die diente nur dazu, damit man nicht mit einem falschen Skript auf eine Box losgehen kann, wenn die Kernel doch unterschiedlich sind (an den wichtigen Stellen).

Wobei ich noch nicht so richtig verstanden habe anhand Deiner Beschreibung, was nun "über die rc.customs bekomme ich es nicht hin" (heißt die nicht "rc.custom"?) heißen soll ... vielleicht wäre die Angabe, was Du da wie aufzurufen versuchst, hilfreich.

Die Rechte der "rc.custom" spielen (iirc) keine Rolle, auch Freetz verwendet praktisch nur den Benutzer "root" bei der Initialisierung. Wahrscheinlich klemmt es hier doch eher wieder am "noexec"-Mount durch AVM und wie man dem entgegenwirkt bzw. wie man den erst mal feststellt (in der Ausgabe von "mount" oder "cat /proc/self/mounts") und was Freetz dagegen anbietet bzw. unternimmt, steht wieder in anderen Threads. Zu den "Gegenmaßnahmen" durch Freetz müßte ich auch wieder selbst erst suchen ... ich befasse mich nur nebenbei und am Rande mit Freetz und benutze es selbst nirgends (früher hatte ich mal zwei, drei Boxen "in the wild", wo das lief). Daher sind hier andere Leser vielleicht hilfreicher ... solange es nicht um die originale AVM-Firmware geht, da helfe ich dann gerne weiter.

Zumal ich hier wieder den Faden verloren habe, welches Fehlerbild jetzt zu welchem Aufruf gehört ... die in der "rc.custom" eingetragenen Kommandos mit den zugehörigen Fehlermeldungen (man kann beim Aufruf eines anderen Skripts z.B. die Debug-Ausgaben mittels "sh -x script &> logfile" in die Datei "logfile" schreiben lassen - natürlich mit absolutem Pfad am besten) und die Protokolle (m.W. wird doch sogar die Ausführung der "rc.custom" entsprechend protokolliert) werden auch darüber genauer Aufschluß geben.

 

[Shirocco88]

Das starten von OpenVPN kann man einfach auch auf Inetd schieben, ist im Grunde noch intelligenter.

das gilt eigentlich nur, wenn OpenVPN im "Responder-Mode" betrieben wird;
bei "Initiator-Mode" ist IMHO das Starten des OpenVPN als Daemon zweckmäßig.

 

[CaptainMorgan]

Wenn die Box ausschließlich Server ist, müsste das ja fürs erste in Ordnung sein, bis Peter's LKM fertig ist, oder sich jemand vom restlichen Freetz-Team der Sache annimmt.
Den doofen Zufall dass sich jemand in den 10 Sekunden zwischen dem Start von inetd und dem Abarbeiten der rc.customs versucht einzuloggen, den kann man fast vernachlässigen. Besonders da die Box kein Router ist und ein UPS hat hoffe ich dass die Uptime ganz manierlich bleibt.

Eine Frage hätte ich noch rein zur Konfiguration:
Ich habe auch einen IP-Pool angegeben, den ignoriert OpenVPN aber geflissentlich, die IP ordnet der Router zu als wäre nichts gewesen.
Die Ausnahme ist wenn ich speziellen Clienten unter der "erweiterten Clientenkonfiguration" IP-Adressen direkt zuweise.
Das sagt mir dass das Package dazu in der Lage ist IP-Adresse selbstständig anzufordern/vergeben, aber es nicht gerne freiwillig tut.
Habe ich da was fehlkonfiguriert oder ist das ein bekannter Bug?

 

[feedzapper]

Bei der 7560 mit OS 7.01 und Freetz führt jeder Aufruf über die rc.custom zu einem reboot der Box.
Jedenfalls bei mir ist das so.
Egal was da auch für Befehle bei mir drin stehen. Die Box läuft nur durch, wenn die rc.custom leer bleibt.
Unabhängig davon ob dort nun OPENVPN mit compiliert wurde oder nicht.
Vielleicht ist das bei eurer Fehlersuche hilfreich .. ?

 

[Shirocco88]

Bei der 7560 mit OS 7.01 und Freetz führt jeder Aufruf über die rc.custom zu einem reboot der Box.

Um hier eine Analyse durchführen zu können, fehlen Angaben:
wie hast du die rc.config befüllt, bzw. welcher Inhalt hat die rc.config ?
cat /path_to/rc.config

wurden die Vorgaben für rc.config beachtet ?
https://freetz.github.io/wiki/packages/mod
Auszug:
rc.custom
Die Befehle in dieser Datei werden nach dem Bootvorgang ausgeführt.

Es dürfen keine Befehle eingetragen sein, die im Vordergrund bleiben oder sehr lange brauchen. Dies könnte Probleme beim Starten der FritzBox verursachen. Bei Befehlen in Verbindung mit einen USB-Stick, bitte die Erweiterung rc.external verwenden.

 

[feedzapper]

Ich hatte bis OS 6.92 in der rc.custom eingetragen :

sleep 240
voipd -R

damit gab es nie Probleme - auch mit anderen Boxen nicht.
Auch wenn man das SLEEP raus nimmt, besteht der selbe Effekt - reboot
Habe es dann im nachhinein über einen crontab Eintrag gelöst.
OpenVPN läuft bis zum heutigen Tage leider nicht mit OS 7.01 auf einer 7560.
Ich benutze nach wie vor OS 6.92 damit.
Für mich gilt immer noch die Aussage von hier :
https://www.ip-phone-forum.de/threads/os70-bei-7580-und-7590.300436/#post-2290552

 

[CaptainMorgan]

Bei der 7560 mit OS 7.01 und Freetz führt jeder Aufruf über die rc.custom zu einem reboot der Box.
Jedenfalls bei mir ist das so.

Bei mir definitiv nicht so.
Habe darin im Moment das Starten eines Webserver, das Laden eines Treibers und das Ausführen zweier Skripte.

 

[PeterPawn]

OpenVPN läuft bis zum heutigen Tage leider nicht mit OS 7.01 auf einer 7560.

Das steht zumindest mal in direktem Widerspruch zu #11 - wenn das hingegen heißen müßte: "Ohne den Patch läuft es nicht.", dann ist das sicherlich wenig verwunderlich.

Hier wäre etwas mehr Präzision sicherlich hilfreich, weil dann andere Benutzer nicht verwirrt werden und sich ggf. selbst ein Bild machen (können).

Wenn ich #11 richtig verstanden habe (und auf anderen Boxen - 7490 und 7580/7590 - gibt es ja auch entsprechende Berichte), dann funktioniert mit Hilfe des Patches auch OpenVPN sehr wohl (erst mal mit manuellem Start). Wenn das hingegen generell anders sein sollte, kann ich mir das gesamte Vorhaben mit dem LKM schenken ...

 

[feedzapper]

=". Wenn das hingegen generell anders sein sollte, kann ich mir das gesamte Vorhaben mit dem LKM schenken ...

Nein Nein, ich denke es wird funktionieren (wie ja oben auch bestätigt). Ich habe mir gerade mal eine entsprechende Freetz Version compiliert. Ich könnte sie nun auch mit dem Patch "just moment" (zeitnah) Hochladen und testen.
Die Box steht aber leider "entfernt". Wobei sich "entfernt" auf "entfernt" von meinem Standort bezieht.
Um dort nun eben gerade mal Ad-Hoc solch einen Test zu machen ist mir zu riskant.
Eventuell dann mal zum WE, wenn man vor Ort ist.