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

[PeterPawn]

Na ja, einer von dreien ist wohl nicht ausreichend ... also trifft wohl Option 1 zu und bei der 7560 mit 07.10 wird anderer (Maschinen-)Code erzeugt, als es das LKM erwartet.

Dann muß ich erst mal schauen, wie das bei der 7580 aussieht ... von der würde ich dann auf die 7590 extrapolieren, weil beide doch sehr ähnlich sind. Allerdings hätte ich auch nichts dagegen, wenn einer der 7590-Besitzer mit einem Freetz-Image auf der Basis der 07.10 und OpenVPN ausgewählt beim Build (nur dann wird das LKM kopiert), mal in seine "dmesg"-Ausgabe schaut und die entsprechenden Zeilen hier einstellt.

Mit #40 habe ich zumindest auch die Adresse im Kernel, an der die Funktionen bei der 7560 beginnen (danke dafür) ... mal sehen, was ich davon im entpackten Kernel (ich habe keine 7560) lokalisieren kann und was der Disassembler an dieser Stelle auswirft.

Kann aber dauern ...

EDIT: Vielleicht kann ja mal jemand bei AVM nach 07.10-Quellen fragen ... ich habe das Gefühl, daß meine Mails an "[email protected]" (das ist die Adresse, an die man sich wenden soll) eher im Spam-Filter hängenbleiben.

 

[CaptainMorgan]

Na ja, einer von dreien ist wohl nicht ausreichend ... also trifft wohl Option 1 zu und bei der 7560 mit 07.10 wird anderer (Maschinen-)Code erzeugt, als es das LKM erwartet.

Das würde bedeuten das ich, als 0815-User erstmal gestranded bin oder? Zurzeit habe ich wieder die neue GUI geladen, beim scheinbar hoffnungslosen Versuch meine Einstellungen zu extrahieren.
Legt openvpn denn nirgendwo eine server.conf an oder so etwas?

Ich habe allerdings jetzt alle Images da und bin vor Ort, also kann ich ein paar Sachen durchspielen wenn ich soll.

Dann muß ich erst mal schauen, wie das bei der 7580 aussieht ... von der würde ich dann auf die 7590 extrapolieren, weil beide doch sehr ähnlich sind. Allerdings hätte ich auch nichts dagegen, wenn einer der 7590-Besitzer mit einem Freetz-Image auf der Basis der 07.10 und OpenVPN ausgewählt beim Build (nur dann wird das LKM kopiert), mal in seine "dmesg"-Ausgabe schaut und die entsprechenden Zeilen hier einstellt.

Mit #40 habe ich zumindest auch die Adresse im Kernel, an der die Funktionen bei der 7560 beginnen (danke dafür) ... mal sehen, was ich davon im entpackten Kernel (ich habe keine 7560) lokalisieren kann und was der Disassembler an dieser Stelle auswirft.

Wenn du mir konkret sagst was du brauchst liefere ich gerne alle Verbose die du benötigst, allerdings eben konkret. Für jemanden der das nicht selbst entwickelt hat sind es eben doch viele Variablen.

Vielleicht kann ja mal jemand bei AVM nach 07.10-Quellen fragen ... ich habe das Gefühl, daß meine Mails an "[email protected]" (das ist die Adresse, an die man sich wenden soll) eher im Spam-Filter hängenbleiben.

Auch hier, wenn du mir eine Blaupause zukommen lässt was genau ich denen schreiben sollte, trete ich gerne deinem "Botnetz" bei
Ich nehme an dass es ein par Stichwörter gibt wie "Sicherheit", "Linux" und "GPL".

 

[feedzapper]

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....

Tut es bei mir ohne Probleme....

 

[PeterPawn]

Ich nehme an dass es ein par Stichwörter gibt wie "Sicherheit", "Linux" und "GPL".

Nö ... einfach nur "Gemäß den Lizenzbestimmungen der verwendeten Open-Source-Software hätte ich gerne von Ihnen das Paket für die FRITZ!Box 7560 mit FRITZ!OS-Version 07.10. Gerne nehme ich auch eine passende URL, mit der ich diese Dateien aus dem Internet laden kann." oder etwas in der Art.

Das Raussuchen aus dem entpackten Kernel kann ich auch selbst machen (da nutzt mir ein Memory-Dump also auch nichts, zumal der mit "dd if=/dev/kmem" auch schon mal gegen den Baum gehen kann) ... da der ja mit festen Adressen gelinkt ist, wird da auch beim Laden nichts mehr reloziert und man kann das 1:1 im Hexdump sehen.

Da kann man also nur wenig helfen ... ich bin irritiert, daß es bei der 07.10 auf einmal für zwei Patches nicht mehr paßt. Das sollte bei der 07.01 ja noch deutlich anders gewesen sein, nach dem, was man mir so berichtet hat. Ich selbst habe noch kein OpenVPN auf einer 75x0 (also einer der neuen GRX-Boxen) mit FRITZ!OS 07.10 getestet ... es gab bisher keinen Grund für ein Update auf diese 07.10 auf produktiven Boxen.

Wenn es für Dich wichtig ist, bleib halt erst mal bei der 07.01 - die sollte ja noch funktionieren, oder? Wie schnell das für die 07.10 klappt, kann ich Dir nicht (verläßlich) sagen.

EDIT:
@feedzapper:
Das ist ja putzig ... kannst Du mal bitte in der "dmesg"-Ausgabe nachschauen, ob da auch nur einer der drei Patches erfolgreich war bei Deiner 7560?

 

[PeterPawn]

Zumindest mal ergibt sich auf der 7580 mit 07.10 in etwa dasselbe Bild:

~ # cd /var/tmp
/var/tmp # wget -O yf_patchkernel.ko https://github.com/PeterPawn/yf_bin/blob/master/target/mips/3.10.104/yf_patchkernel.ko?raw=true
Connecting to github.com (140.82.118.3:443)
Connecting to github.com (140.82.118.3:443)
Connecting to raw.githubusercontent.com (151.101.112.133:443)
yf_patchkernel.ko    100% |***********************************************************************************| 47712   0:00:00 ETA
/var/tmp # insmod yf_patchkernel.ko
#/var/tmp # dmesg
[...]
[1154262.028000][2][yf_patchkernel] Initialization started
[1154262.028000][2][yf_patchkernel] Any preceding error messages regarding memory allocation are expected and may be ignored.
[1154262.040000][2][yf_patchkernel] Patching kernel function 'ip_forward' at address 0x80abe594.
[1154262.040000][2][yf_patchkernel] Found instruction to patch (0x8c820020) at address 0x80abe5b0, replaced it with 0x24020000.
[1154262.048000][2][yf_patchkernel] Patching kernel function 'netif_receive_skb' at address 0x80a66940.
[1154262.048000][2][yf_patchkernel] No instruction to patch found in function 'netif_receive_skb', patch skipped.
[1154262.060000][2][yf_patchkernel] Patching kernel function '__netif_receive_skb' at address 0x80a668c4.
[1154262.060000][2][yf_patchkernel] No instruction to patch found in function '__netif_receive_skb', patch skipped.
[1154262.060000][2][yf_patchkernel] 1 patches applied.
/var/tmp #

Da kann ich also auch mit der 7580 auf die Suche gehen ... wenn es erforderlich sein sollte. Bei der 7580 weiß ich jetzt, wie es aussieht, bei der 7560 liegen zwei, einander widersprechende Aussagen hinsichtlich der Funktionsfähigkeit vor und für die 7590 würde ich zu gerne mal die "dmesg"-Meldungen sehen und eine dazugehörende Einschätzung, ob das nun läuft oder nicht, lesen.

Was wäre noch? Die 7530 hat wohl auch gerade die 07.10 erhalten ... die 7490 (die mich dann wieder interessiert) ist weiterhin bei der Labor-Version (die ich nicht ernsthaft teste).

 

[feedzapper]

Das ist ja putzig ... kannst Du mal bitte in der "dmesg"-Ausgabe nachschauen, ob da auch nur einer der drei Patches erfolgreich war bei Deiner 7560?

Kein Thema :

Jan  1 01:00:57 fritz user.notice FREETZMOD: Starting dropbear SSH server ... done.
Jan  1 01:00:58 fritz kern.err kernel: [   58.612000] [module-alloc-by-name] give 0x1000 bytes at 0x8a4f0000 to module 'yf_patchkernel' (0x79000 total bytes left)
Jan  1 01:00:58 fritz kern.err kernel: [   58.624000] module_alloc_size_list_alloc: error: module 'yf_patchkernel' reserved size 0 too small for demand size 4096 - need 4096 more (module_alloc_waste=-20480)
Jan  1 01:00:58 fritz kern.info kernel: [   58.640000] [yf_patchkernel] Initialization started
Jan  1 01:00:58 fritz kern.info kernel: [   58.640000] [yf_patchkernel] Any preceding error messages regarding memory allocation are expected and may be ignored.
Jan  1 01:00:58 fritz kern.info kernel: [   58.656000] [yf_patchkernel] Patching kernel function 'ip_forward' at address 0x80abe594.
Jan  1 01:00:58 fritz kern.info kernel: [   58.656000] [yf_patchkernel] Found instruction to patch (0x8c820020) at address 0x80abe5b0, replaced it with 0x24020000.
Jan  1 01:00:58 fritz kern.info kernel: [   58.676000] [yf_patchkernel] Patching kernel function 'netif_receive_skb' at address 0x80a66940.
Jan  1 01:00:58 fritz kern.info kernel: [   58.676000] [yf_patchkernel] No instruction to patch found in function 'netif_receive_skb', patch skipped.
Jan  1 01:00:58 fritz kern.info kernel: [   58.692000] [yf_patchkernel] Patching kernel function '__netif_receive_skb' at address 0x80a668c4.
Jan  1 01:00:58 fritz kern.info kernel: [   58.692000] [yf_patchkernel] No instruction to patch found in function '__netif_receive_skb', patch skipped.
Jan  1 01:00:58 fritz kern.info kernel: [   58.692000] [yf_patchkernel] 1 patches applied.
Jan  1 01:00:59 fritz kern.warn kernel: [   59.504000] [3]system-load 6 loadavg 1.68 0.45 0.15 - 136 tasks:60 % curr:ctlmgr(3 %) max:kworker/1:1(6 %, pid:126) pgstat: sum=49085 free=4762 slab=4901 alloc=1145/s fault=10716/s ai_sys:0.53/s 0x8a4c1644 ath_getstats+0x108/
Jan  1 01:00:59 fritz daemon.notice openvpn[3396]: OpenVPN 2.4.7 mips-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [AEAD] built on May 12 2019
Jan  1 01:00:59 fritz daemon.notice openvpn[3396]: library versions: OpenSSL 1.0.2r  26 Feb 2019, LZO 2.10
Jan  1 01:00:59 fritz daemon.warn openvpn[3397]: WARNING: Your certificate is not yet valid!
Jan  1 01:00:59 fritz user.notice FREETZMOD: Starting openvpn ... done.

funktioniert jedenfalls hier seit etlichen Tagen mit 7.10...

 

[CaptainMorgan]

Ich selbst habe noch kein OpenVPN auf einer 75x0 (also einer der neuen GRX-Boxen) mit FRITZ!OS 07.10 getestet ... es gab bisher keinen Grund für ein Update auf diese 07.10 auf produktiven Boxen.

Wenn es für Dich wichtig ist, bleib halt erst mal bei der 07.01 - die sollte ja noch funktionieren, oder? Wie schnell das für die 07.10 klappt, kann ich Dir nicht (verläßlich) sagen.

Werde dann mal den Downgrade antreten. Interressant war 7.10 für mich weil nun endlich ein manierliches AP-Steering vorhanden sein sollte.
Interressant deshalb weil ich die alten Boxen (1&1 will die letztendlich doch nie zurück) immer als WLAN Repeater recycle.
Und in diesem Fall aus Loadbalancing -Gründen einzelne Funktionen auslagere. Habe eine 7632SL als Telefon/Router/Mesh-Master etc. Die soll möglichst unangetastet bleiben.
Und da vsftpd auf der 7560 (scheinbar allen GRX-Boxen, ich erinnere an den Thread dazu, Stichwort "500:OOPS munmap") nur so solala läuft, muss die 7560 halt für OpenVPN herhalten. Sollte ja auch die "Rechenstärkste" sein.

Wenn ich jetzt den Downgrade antrete, muss ich dann wieder denn manuellen Patch verwenden, oder sollte Freetz das in dem Fall automatisch machen?
Der "AVM-Kernel" sollte ja für die Version schon auseinandergenommen worden sein.

"Gemäß den Lizenzbestimmungen der verwendeten Open-Source-Software hätte ich gerne von Ihnen das Paket für die FRITZ!Box 7560 mit FRITZ!OS-Version 07.10. Gerne nehme ich auch eine passende URL, mit der ich diese Dateien aus dem Internet laden kann."

Ich hänge noch "Hallo" und "Tschüss" dran und versuche es mal.

Das ist ja putzig ... kannst Du mal bitte in der "dmesg"-Ausgabe nachschauen, ob da auch nur einer der drei Patches erfolgreich war bei Deiner 7560?

Ich auch nochmal? Zur Erinnerung, feedzapper nutzt freetz-ng.....

 

[er13]

Die relevanten Änderungen zwischen 07.0x und 07.1x sind

--- 7590_07.01/linux-3.10/net/core/dev.c
+++ 7583_07.10/linux-3.10/net/core/dev.c
@@ -3729,7 +3729,6 @@
 {
     int ret;
-   BUG_ON(skb->sk);
     if (sk_memalloc_socks() && skb_pfmemalloc(skb)) {
         unsigned long pflags = current->flags;
@@ -3771,7 +3770,6 @@
     int ret;
     BUG_ON(!in_softirq());
-   BUG_ON(skb->sk);
     net_timestamp_check(netdev_tstamp_prequeue, skb);
     if (skb_defer_rx_timestamp(skb))
--- 7590_07.01/linux-3.10/net/ipv6/ip6_output.c
+++ 7583_07.10/linux-3.10/net/ipv6/ip6_output.c
@@ -468,6 +468,9 @@
     if (net->ipv6.devconf_all->forwarding == 0)
         goto error;
+   if (unlikely(skb->sk))
+       goto drop;
+
     if (skb_warn_if_lro(skb))
         goto drop;

D.h. die beiden BUG_ON's (s. 010-non_null_sbk_sk.patch) sind wieder rausgeflogen (daher ist es OK, dass die 2 Patches von 3 fehlschlagen). Dafür ist aber ein zusätzlicher Drop in net/ipv6/ip6_output.c hinzugekommen.

Edit: die Kernel-Quellen sind die einer 7583 (auch eine GRX5-Box). Alles unter der Annahme, dass bei den anderen GRX5-Boxen die relevanten Stellen genauso geändert wurden.

Edit2: dass es bei manchen geht, kann also damit zusammenhängen, dass diese nur IPv4 verwenden. Die, bei denen es nicht geht, müssten dagegen IPv6 verwenden.

 

[Marthzion]

Hallo miteinander,

ich habe eine 7590 im Einsatz und bei mir läuft openvpn seit der 7.10 wieder ohne Problem.
Hatte jetzt aufgrund dieser Diskussion mal die "dmesg" Ausgabe angesehen und erstaunt festgestellt, dass gar kein yf_patchkernel Eintrag vorhanden ist.
Nach kurzer Suche ist mir aufgefallen, dass ich nicht die openvpn-gui-v2 ausgewählt hatte und damit auch nie die Patches geladen wurden.

Nach manuellem laden des yf_patchkernel bekomme ich jetzt ebenfalls diese Ausgabe:

[1638590.980000][3][module-alloc-by-name] give 0x1000 bytes at 0x8a68d000 to module 'yf_patchkernel' (0x75000 total bytes left)
[1638590.980000][3]module_alloc_size_list_alloc: error: module 'yf_patchkernel' reserved size 0 too small for demand size 4096 - need 4096 more (module_alloc_waste=-20480)
[1638590.980000][3][yf_patchkernel] Initialization started
[1638590.980000][3][yf_patchkernel] Any preceding error messages regarding memory allocation are expected and may be ignored.
[1638590.992000][3][yf_patchkernel] Patching kernel function 'ip_forward' at address 0x80abe594.
[1638590.992000][3][yf_patchkernel] Found instruction to patch (0x8c820020) at address 0x80abe5b0, replaced it with 0x24020000.
[1638591.004000][3][yf_patchkernel] Patching kernel function 'netif_receive_skb' at address 0x80a66940.
[1638591.004000][3][yf_patchkernel] No instruction to patch found in function 'netif_receive_skb', patch skipped.
[1638591.016000][3][yf_patchkernel] Patching kernel function '__netif_receive_skb' at address 0x80a668c4.
[1638591.016000][3][yf_patchkernel] No instruction to patch found in function '__netif_receive_skb', patch skipped.
[1638591.016000][3][yf_patchkernel] 1 patches applied.

Mit der Firmware 7.10 für die FB7590 muss AVM wieder irgendwas in ihrem Code "geradegerückt" haben, dass zumindest openvpn wieder normal (ohne Patches) starten kann.
Allerdigns macht bei mir noch (wie in einer Anderen Diskussion hier im Forum erwähnt) die Kindersicherung Probleme im openvpn. Vielleicht ein Zusammenhang?

Gruß

 

[feedzapper]

Edit2: dass es bei manchen geht, kann also damit zusammenhängen, dass diese nur IPv4 verwenden. Die, bei denen es nicht geht, müssten dagegen IPv6 verwenden.

Stimmt ! Ich nutze nur IPv4 - IPv6 ist deaktiviert ...

 

[PeterPawn]

@er13:
OK, ich suche mir die Stelle mit dem IPv6-BugOn() dann mal in den Quellen der 7583, damit ich das Pattern finde (ich brauche ja die Funktion in C, damit ich über das Symbol den Einstieg im Speicher finde).

@all:
Witzig ist ja #49 - was passiert denn bei anderen, wenn sie das LKM entladen? Dann werden die Patches ja wieder rückgängig gemacht - das war einer der Vorteile des LKM ggü. dem Skript mit "devmem". Kommt es dann zur Kernel-Panic oder braucht's den Patch vielleicht tatsächlich gar nicht mehr?

damit auch nie die Patches geladen wurden.

Das "tun"-Module hast Du dann "von Hand" (also über "Freetz-Modules") geladen?

Alles sehr komisch ... wenn #49 verifiziert werden kann (@feedzapper?), wird vielleicht für IPv4 der Patch gar nicht mehr benötigt und stattdessen jetzt einer für IPv6 (weil AVM auch da jetzt die Buffer-Verwaltung über die Hardware macht?).

EDIT:
Ggf. macht es auch einen Unterschied, ob der Traffic vom/fürs OpenVPN lokal verarbeitet wird oder ob es sich um "forwards" handelt? Die BUG_ON-Statements sind ja offensichtlich jeweils in den "forward"-Routinen, während die beiden in "receive..." wieder draußen sind.

 

[Marthzion]

Stimmt ! Ich nutze nur IPv4 - IPv6 ist deaktiviert ...

Bei mir ist ebenfalls ipv6 deaktiviert

 

[Marthzion]

Das "tun"-Module hast Du dann "von Hand" (also über "Freetz-Modules") geladen?

Ja.
Allerdings unbewusst und nicht über die Freetz modules.
Bei mir stand noch aus früheren Tests und Spielereien der Befehl "modprobe tun" in der.... haltet euch fest.... debug.cfg.

War viel Zufall dabei.

 

[feedzapper]

Witzig ist ja #49 - was passiert denn bei anderen, wenn sie das LKM entladen? Dann werden die Patches ja wieder rückgängig gemacht - das war einer der Vorteile des LKM ggü. dem Skript mit "devmem". Kommt es dann zur Kernel-Panic oder braucht's den Patch vielleicht tatsächlich gar nicht mehr?

geht auch ohne Patch nun (wie gesagt nur ipv4 hier) :

May 16 05:56:37 fritz authpriv.info dropbear[1203]: Child connection from 192.168.0.3:63394
May 16 05:56:37 fritz kern.warn kernel: [26816.840000][3][3]system-load 1 loadavg 0.21 0.14 0.10 - 135 tasks:2 % curr:dropbear(0 %) max:kworker/1:2(1 %, pid:31151) pgstat: sum=47656 free=10529 slab=4622 alloc=0/s fault=147/s ai_sys:0.18/min 0x8a4c1644 ath_getstats+0x1
May 16 05:56:42 fritz authpriv.notice dropbear[1203]: Password auth succeeded for 'root' from 192.168.0.3:63394
May 16 05:57:24 fritz kern.warn kernel: [26864.144000][3][3]system-load 1 loadavg 0.10 0.12 0.9 - 136 tasks:4 % curr:dnsmasq(0 %) max:kworker/1:2(1 %, pid:31151) pgstat: sum=47688 free=10240 slab=4650 alloc=1/s fault=311/s ai_sys:0.04/s 0x8a4c1644 ath_getstats+0x108/0
May 16 05:57:30 fritz kern.warn kernel: [26869.760000][0][0]system-load 1 loadavg 0.9 0.12 0.9 - 138 tasks:0 % curr:dnsmasq(0 %) max:dnsmasq(0 %, pid:22767) pgstat: sum=47646 free=4237 slab=4662 alloc=0/s fault=22/s (sleep 0)
May 16 05:58:12 fritz kern.info kernel: [26911.548000][3][yf_patchkernel] Module will be removed now.
May 16 05:58:12 fritz kern.info kernel: [26911.548000][3][yf_patchkernel] Reversed patch in 'ip_forward' at address 0x80abe5b0 to original value 0x8c820020.
May 16 05:58:12 fritz kern.info kernel: [26911.548000][3][yf_patchkernel] All applied patches have been reversed.
May 16 05:58:12 fritz kern.err kernel: [26911.564000][0]release_bug_debug_table: warning: 'yf_patchkernel' not found! (driver maybe bugfree)
May 16 05:58:53 fritz kern.info kernel: [26952.528000][0]/proc/tffs: info request: success

 

[PeterPawn]

geht auch ohne Patch nun (wie gesagt nur ipv4 hier)

Wer benutzt jetzt OpenVPN auf seiner Box nur dazu, die Daten, die ein spezieller Daemon über einen angeschlossenen Kartenleser von einer Chipkarte gelesen hat, irgendwohin zu übertragen? Solange das alles auf der FRITZ!Box läuft, wäre das eben lokaler Traffic und müßte von der Hardware ohnehin bei der CPU abgeliefert werden. Ansonsten könnte (zumindest unverschlüsselter) Traffic ja direkt zum betreffenden LAN-Client gehen und käme mit der CPU gar nicht erst in Berührung.

Die Hardware-Verschlüsselung der CPU und die IPSec-Unterstützung der MPE (m.E. sollten die mind. bei den "großen" GRX-Modellen vorhanden sein) wird wohl bisher von AVM nicht genutzt, auch nicht mit der 07.10 - es sind aber erste Ansätze (u.a. die "net/ipv4/avm_eip97.c") schon seit einiger Zeit zu sehen, meines Wissens seit 06.98 bzw. 07.00, wo AVM die Kernel-Sources rausgerückt hat.

Warum man sich bei AVM offenbar mit dem vorhandenen Personal auf Dinge wie Mesh und WLAN konzentriert und die vorhandenen Ansätze mit der Hardware-Verschlüsselung liegen bleiben, kann man auch nur raten. Entweder die ersten Ergebnisse waren eher enttäuschend oder das paßt dann alles nicht so recht zum AVM-MPR-Stackoder man will das dem Kunden irgendwann vielleicht doch noch als "gewaltigen Fortschritt" verkaufen ... denkbar sind sicherlich viele Erklärungen. Fakt ist aber, daß der Crypto-Durchsatz der FRITZ!Boxen einigermaßen erbärmlich ist und AVM das offenbar nicht richtig (zumindest nicht mit dem nötigen Nachdruck) in Angriff nimmt.

Vielleicht haben ja ab und ab tatsächlich mal ein paar Inhouse-Versionen die notwendigen Module an Bord ("cat /proc/config.gz | gunzip | grep '\(LTQ_CRYPTO=\|INET_ESP=\)'" sollte dann zwei Zeilen mit "y" ergeben) und AVM testet auf diesem Weg die Crypto-Hardware und was sie bringt - dann wird das wohl bei der 7590 erfolgen, denn die 7580 kriegt ja keine regelmäßigen Inhouse-Versionen. Vielleicht ja doch ein Grund, sich mal nach einer 7590 umzusehen, auch wenn man den ganzen anderen AVM-Sche*** aus dieser Box weder braucht noch will.

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

Aber zurück zum OpenVPN ... kann mal bitte jeder mit einem "geht / geht nicht" ohne das LKM noch dazuschreiben (bitte nicht einfach editieren, sondern mit neuem Beitrag), ob er sein OpenVPN ausschließlich auf der Box nutzt oder ob da auch Pakete von (bzw. für) andere Clients im LAN transportiert werden?

Wer ansonsten nur die Box selbst nutzt und trotzdem eine passende Konfiguration für den Zugriff auf das LAN dahinter hat, könnte mal mit einem "ping" o.ä. versuchen, ob er auch da ohne LKM problemlos zugreifen kann oder ob die Box dann abstürzt oder ob das nicht mehr funktioniert.

Erwarten würde ich letzteres, denn das sind ja nicht länger "BUG_ON"-Statements (mit der Folge, daß eine "trap" ausgelöst würde), sondern die Pakete werden einfach mit dem Hinweis "Annahme verweigert" (NET_RX_DROP) verworfen.

Damit funktioniert dann zwar die OpenVPN-Verbindung nicht (bzw. wohl eher die innerhalb des Tunnels transportierte Verbindung, denn deren Pakete dürften hier betroffen sein), aber es kommt nicht mehr zur "kernel panic", wie bei den BUG_ONs.

Wenn die Frage, ob das bei IPv4-Traffic, der durchs Forwarding muß, weiterhin notwendig ist oder nicht, geklärt ist, würde ich auch wieder in den anderen Thread (https://www.ip-phone-forum.de/threads/fritz-os7-openvpn-auf-7590-kein-tun-modul.300433/page-6) umziehen wollen mit der weiteren Bearbeitung des Themas ... sonst gibt es wieder zwei und in dem zur 7590 steht dann gar nichts mehr zum Thema bei der 07.10.

 

[CaptainMorgan]

Aber zurück zum OpenVPN ... kann mal bitte jeder mit einem "geht / geht nicht" ohne das LKM noch dazuschreiben (bitte nicht einfach editieren, sondern mit neuem Beitrag), ob er sein OpenVPN ausschließlich auf der Box nutzt oder ob da auch Pakete von (bzw. für) andere Clients im LAN transportiert werden?

Wer ansonsten nur die Box selbst nutzt und trotzdem eine passende Konfiguration für den Zugriff auf das LAN dahinter hat, könnte mal mit einem "ping" o.ä. versuchen, ob er auch da ohne LKM problemlos zugreifen kann oder ob die Box dann abstürzt oder ob das nicht mehr funktioniert.

Für meine 7560 mit aktuellem freetz-master:
Mit LKM (7.10 + alte Gui + Manuell geladene yf-patchkernel & tun) geht nicht.
Mit LKM ((7.10 + neue Gui) läuft der Daemon an, die Konfiguration bekomme ich aber nicht hin und in der Log sieht man dass nur 1 von 3 patches appliziert wird. Das ist bei mir und Feedzapper ja im Grunde gleich. Aber feedzapper hat sich glaube ich noch nicht geäußert welche GUI er verwendet.
Ohne (7.01 + alte Gui + vpnpatch.sh + tun manuell geladen) geht.
Möchte damit durchaus echten ipv4 traffic realisieren, zugriff auf im Netzwerk freigebene smb Freigaben oder Zugriff auf andere Netzwerkressourcen.
Zum Crash kommt es aber beim starten des openvpn-daemon, nicht bei den ersten ipv4 paketen.


Edit: Wichtig, bearbeitet!!!! Sonderfall LKM+alte GUI. Betroffender Part in fett.

 

[PeterPawn]

Zum Crash kommt es aber beim starten des openvpn-daemon

Wie sieht dieser Crash konkret aus? Kernel-Panic und Reboot? Wenn ja, bitte mal das "panic.log" nach einem solchen Reboot auslesen (Supportdaten am besten, steht dann ziemlich am Ende) und zeigen. Wenn nein, genauer beschreiben. Danke.

Zumindest geht es hier dann wohl tatsächlich um Forward-Traffic - da könnte reiner Ingress-Traffic aus Sicht der Box dann immer noch funktionieren.

Ohne "BUG_ON"-Statements sollte es eigentlich nicht zum Crash kommen ... ggf. stimmen die 7583-Quellen dann doch nicht so ganz für die 7560. Aber erst mal würde ich die Ursache gerne genau kennen, bevor ich weiter spekuliere.

 

[feedzapper]

Aber zurück zum OpenVPN ... kann mal bitte jeder mit einem "geht / geht nicht" ohne das LKM noch dazuschreiben (bitte nicht einfach editieren, sondern mit neuem Beitrag), ob er sein OpenVPN ausschließlich auf der Box nutzt oder ob da auch Pakete von (bzw. für) andere Clients im LAN transportiert werden?

Die 7560 läuft als OpenVPN Client mit LZ4-V2 compression und tunnelt ihr gesamtes 192.168.178.0 Netz zum Server incl. aller an der Box angeschlossenen Geräte (Rechner,Netzwerkdrucker,voip daten e.t.c)
Die Box läuft nun OHNE Neustart mit entladenem LKM seit nunmehr 16 Stunden (siehe kernel Log in #54) als TIMESTAMP...

Zum alten/neuen GUI :
(ich weiß zwar nicht genau was damit gemeint ist) - nehme aber an, dass es sich
um das GUI vom OpenVPN handelt.
Ich benutze das "NEW simple GUI" wo man alle Einstellungen selbst vornimmt...

 

[CaptainMorgan]

Wie sieht dieser Crash konkret aus? Kernel-Panic und Reboot? Wenn ja, bitte mal das "panic.log" nach einem solchen Reboot auslesen (Supportdaten am besten, steht dann ziemlich am Ende) und zeigen. Wenn nein, genauer beschreiben. Danke.

Bin jetzt wieder dran, war zwischenzeitlich anderweitig gebunden, und würde gerne die Supportdaten übermitteln, aber ich weiß nicht welchen Teil.
Die erweiterten Supportdaten sind 30k Zeilen lang und enthalten eine Menge persönliche Daten.
"panic.log" gibt es keine auf der Box, und die die erweiterten Supportdaten enthalten das Wort panic nicht.
Auch in den Freetz Supportdaten gibt es eine "crash.log" und eine "panic" Datei, beide sind allerdings 0 Bytes.
Wenn ich den openvpn daemon manuell starte, bricht die Box direkt zusammen, bis auf den Switch und den WLAN AP.
Es gibt keinen weiteren Eintrag in der Syslog mehr, nachdem ich den Knopf gedrückt habe. Ich kriege noch den Anfang des Seitenaufbaus, den gestrichelten Kasten in dem normalerweise "openvpn was started" stehen sollte, allerdings bleibt der leer und der Seitenaufbau bricht ab. Danach ist keine weitere GUI mehr verfügbar, weder AVM noch Freetz.
So verhält es sich mit FreetzMaster, 7.10 und der alten GUI.
"yf_patchkernel" und "tun" wurden zusätzlich in die "modules"-UI eingetragen.
Im Anhang noch die Konfiguration dafür als "config.txt".

Werde den Beitrag nachher editieren und das selbe für die neue GUI durchspielen:
Mit der neuen GUI startet der OpenVPN daemon problemlos, allerdings wird auch hier nur einer von drei Patches appliziert. Ich nehme an dass OpenVPN dann auch funktionieren würde, aber es scheitert an meinem Verständnis dieser GUI open auch wirklich Pakete durchgereicht werden, es ergibt sich keine Verbindung.

 

[PeterPawn]

Klingt für mich eher nach CPU-Schleife, wo nur noch die Hardware des Switches funktioniert und der Rest nicht mehr reagieren kann.

Ich würde hier mal eine Shell-Session parallel laufen lassen - am besten mit einem "top" - und erst dann den OpenVPN-Daemon starten.

Wenn das bei der 7560 am Ende auch nur die beiden "NET_RX_DROP"-Bedingungen sind, müßte praktisch gar nichts passieren ... es kommen halt empfangene Pakete nicht beim zuständigen Daemon an. Der kann das aber kaum von der Situation unterscheiden, wenn die Daten die Box gar nicht erst erreichen.

Nachdem das bei anderen auch noch funktioniert (wenn auch nur mit IPv4), ohne daß das LKM geladen ist, muß man schon erst mal richtig verstehen, woher diese Abstürze (oder nennen wir es erst mal "Probleme", denn da stürzt wahrscheinlich ja nichts wirklich ab) jetzt kommen.

Hat schon jemand eine Reaktion von AVM auf die Anforderung von Quellen für 7590, 7580 oder 7560 erhalten?