.titleBar { margin-bottom: 5px!important; }

FRITZ!OS7 openvpn auf 7590 => kein tun Modul

Dieses Thema im Forum "Freetz" wurde erstellt von CKone, 4 Aug. 2018.

  1. CKone

    CKone Neuer User

    Registriert seit:
    1 Nov. 2005
    Beiträge:
    23
    Zustimmungen:
    0
    Punkte für Erfolge:
    1
    Hallo

    versuche ich ein freetz aus dem Trunc mit openvpn zu bauen warnt er in der menuconfig das er es mangels vorhandenem Kernelsource nicht hinbekommt das tun Modul zu bauen.

    Gibt es hier irgendwie Abhilfe, weil beim letzten Labor gehts ja auch. Und warum kann ich kein statisch verlinktes binary wählen, bei der 7490 mit 6.30 gabs ja seinerzeit auch nicht die Notwendigkeit eines modularen Aufbaus?

    Jemand ne Idee wie man das hinbekommt?

    Danke
    CKone
     
  2. er13

    er13 Aktives Mitglied

    Registriert seit:
    20 Dez. 2005
    Beiträge:
    999
    Zustimmungen:
    19
    Punkte für Erfolge:
    18
    Weder in den letzten Labors noch in der 07.XX-Release-Version ist es möglich das tun-Modul zu bauen (die Aussage gilt für alle GRX5-Boxen). Daher kann ich Deine Aussage "beim letzten Labor gehts ja auch" nicht nachvollziehen.

    Auch das statische Linken von OpenVPN ist weiterhin möglich. Oder andersrum auch diese Aussage kann ich nicht nachvolziehen.
     
  3. Whoopie

    Whoopie Aktives Mitglied

    Registriert seit:
    19 Okt. 2004
    Beiträge:
    818
    Zustimmungen:
    4
    Punkte für Erfolge:
    18
  4. f666

    f666 Mitglied

    Registriert seit:
    6 Apr. 2016
    Beiträge:
    217
    Zustimmungen:
    26
    Punkte für Erfolge:
    28
    Ich habe mir die Änderungen noch nicht im Kontext des ganzen Moduls angesehen, aber kann man die beiden BUG_ON Zeilen nicht wieder löschen (versuchen)?
     
  5. Whoopie

    Whoopie Aktives Mitglied

    Registriert seit:
    19 Okt. 2004
    Beiträge:
    818
    Zustimmungen:
    4
    Punkte für Erfolge:
    18
    Ja, hatte ich auch schon überlegt. Wir brauchen aber erst einmal "replace kernel", dann kann man das testen.
     
  6. PeterPawn

    PeterPawn IPPF-Urgestein

    Registriert seit:
    10 Mai 2006
    Beiträge:
    11,363
    Zustimmungen:
    576
    Punkte für Erfolge:
    113
    Beruf:
    IT-Freelancer
    Ort:
    Berlin
    Was genau verhindert das? Die Quellen für die 7590 sind doch verfügbar ...

    Meines Erachtens sollte man stattdessen aber ohnehin erkunden, wie da ein "sk_buff" ohne passenden Socket (also ohne "Besitzer") auftauchen kann, als "so empfangen" (ja, in welchem Kontext denn bitte?) ... das ganze Recycling von "sk_buff"-Strukturen ist ja auch eine Lantiq-Spezialität (FAST_SKB und SKB_RECYCLE), die AVM m.E. gar nicht nutzt und da wäre für mich dann doch wieder die Frage, warum vom "tun"-Device eine solche Struktur ohne "sk"-Member überhaupt übergeben wird oder ob die nicht bei irgendeinem PA-Hook in der weiteren Verarbeitung einfach nur falsch interpretiert wurde (die werden ja teilweise auch rein zum Zählen von Paketen aufgerufen) und als "beschleunigt, damit bereits erledigt" abgehakt wird, woraufhin dann der Buffer fälschlicherweise "orphaned" wird und hier aber trotzdem weiterhin in den Mühlen der Verarbeitung verbleibt.

    Ansonsten wird in "tun.c" ein solcher "sk_buff" ja nur dann "orphaned" (und zwar absichtlich), wenn er erfolgreich gesendet wurde und da wäre dann die Frage, wie der es wieder in irgendeine Receive-Queue geschafft haben soll mit seinem Socket == NULL.

    Was man mal testen könnte (zur Eingrenzung des Fehlers), wäre die Reaktion des Systems mit unterschiedlichen Stufen der Paket-Beschleunigung ... bei den neuen Versionen ist die ja über die Support-Seite zu steuern. Tritt das Problem dann nicht auf, liegt es vermutlich wirklich an irgendeinem der AVM-Hooks, die da alle mit "avm_pa_irgendwas" beginnen.

    Wenn das dann doch keinen Hinweis liefert, bräuchte man mal einen echten Stack-Trace und vielleicht noch ein paar printk-Erweiterungen vor diesem "BUG_ON", damit man z.B. einen Hex-Dump des "sk_buff" mal sieht und erkennen kann, woher der kommt (AVM packt ja zusätzlich noch das Source-Device in den Header) und wohin er eigentlich gehen sollte ... dann kann man auch besser verfolgen (in Kombination mit dem Stack-Trace), wo hier der eigentliche Fehler liegt.

    Was nutzt es einem, wenn man die "BUG_ON"s von AVM wieder entfernt und dann stürzt es irgendwo dahinter ab, weil "sk_buff->sk" der Pointer auf die "sock"-Struktur sein soll (und nicht noch einmal geprüft wird, z.B. bei irgendwelchen Konstrukten, die dann über mehrfache Pointer-Referenzen auf "sock"-Member zugreifen wollen - ein "grep" mit "->sk->" über die Sourcen zeigt schnell, daß es solche Stellen gibt - auch wenn natürlich damit nicht auf den ersten Blick geklärt ist, ob da nicht noch eine Abfrage davor erfolgt ist) und es aber nicht ist ... so ganz aus Jux und Tollerei wird AVM das da vorne nicht eingebaut haben, immerhin kann man dann anhand des Stack-Traces noch sehen, wie dieser "sk_buff" seinen Weg zu der Stelle fand.
     
  7. er13

    er13 Aktives Mitglied

    Registriert seit:
    20 Dez. 2005
    Beiträge:
    999
    Zustimmungen:
    19
    Punkte für Erfolge:
    18
    #7 er13, 14 Aug. 2018
    Zuletzt bearbeitet: 14 Aug. 2018
    Peter, Du hast da a bisserl was missverstanden.

    AVM hat an 2 Stellen die Zeile
    Code:
    BUG_ON(skb->sk);
    
    eingebaut (BUG_ON Doku). D.h. sie erwarten, dass der Socket eben nicht gesetzt ist.

    An einer anderen Stelle haben sie die Zeilen eingebaut
    Code:
    if (unlikely(skb->sk))
            goto drop;
    
    (s. LikelyUnlikely Doku). D.h., wenn der Socket gesetzt ist, dann soll sowas nicht weiter geforwarded, sondern gedropped werden.

    Der BUG_ON ist definitiv völliger Schwachsinn, aber scheinbar schlägt die Assertion beim AVM-Code nicht fehl, da eben alles mit AVM_PA am eigentlichen Network-Stack vorbei geschleust wird.

    Edit: es ist für mich echt ein Rätsel, wie man diese Missgeburt namens AVM_PA überhaupt ernsthaft der IT-Welt zeigen kann und dabei auch noch als eine Optimierung verkaufen kann. Denn die Optimierung von AVM_PA bestünde darin, dass alle Daten (von irgendeinem Device) direkt an die diese Daten verarbeitentenden "Empfänger" weitergereicht werden. Und direkt heißt an der Stelle - an dem gesamten Network-Stack vorbei. Grüße Richtung OSI-Modell, auch, wenn man dieses in seiner reinen Form nie umgesetzt hat.
     
  8. PeterPawn

    PeterPawn IPPF-Urgestein

    Registriert seit:
    10 Mai 2006
    Beiträge:
    11,363
    Zustimmungen:
    576
    Punkte für Erfolge:
    113
    Beruf:
    IT-Freelancer
    Ort:
    Berlin
    @er13:
    Stimmt, ich Rindvieh habe die Berichte über die Assertion genau falsch herum interpretiert und gar nicht nach dem konkreten "BUG_ON"-Statement geschaut, sondern mich nur mit den denkbaren Folgen befaßt, wenn so ein "sk_buff" tatsächlich "orphaned" wäre und das nicht richtig geprüft wird beim Zugriff.

    Das macht es ja noch rätselhafter ... dann müßte ja auch bei abgeschalteter Paketbeschleunigung so ein Paket (beim Empfang der Daten) immer noch irgendwie durch den PA-Code, damit die Assertion auch bei AVM-Code nicht greift.

    Der Witz am TUN-Device ist es ja, daß da eigentlich keine PA-Session mit verbunden sein kann (zumindest nicht beim unverschlüsselten Traffic), denn die Pakete müssen ja über die CPU gehen und entsprechend verschlüsselt werden ... was hat so eine Verbindung dann mit dem PA überhaupt zu tun?

    Ich schaue mir das noch mal an, diesmal aber etwas gründlicher als zuvor ... das ist ja reichlich blamabel, was ich mir da als "Fehltritt" geleistet habe.
     
  9. er13

    er13 Aktives Mitglied

    Registriert seit:
    20 Dez. 2005
    Beiträge:
    999
    Zustimmungen:
    19
    Punkte für Erfolge:
    18
    Nur die Ruhe, kann jedem passieren ;)

    Und auf die Frage, warum es denn immer noch kein Replace-Kernel für die GRX5-Boxen gibt (obwohl die Sources ja verfügbar wären), folgende Antwort:

    Das kernel.image hat bei den GRX5-Boxen ein neues (EVA-)Format, welches lzma2eva noch nicht beherrscht. Bzw. ich würde es gar nicht lzma2eva beibringen wollen, sondern ein neues Tool dafür schreiben, so wie f-666 es für die Kabel-Boxen gemacht hat (s. r14809).

    In dem kernel.image von GRX5-Boxen sind 2 Kernels enthalten:
    • der erste ist der, der uns eigentlich interessiert und den wir hoffentlich (insbesondere im Sinne der avm_kernel_config_area) bauen können.
    • und der zweite (wo ich schon vergessen habe, wofür er überhaupt da ist, aber Peter kann mir bestimmt auf die Sprünge helfen), für den wir keine Quellen haben. Der denkbare Ansatz bei diesem wäre es diesen 1-zu-1 aus AVM's kernel.image zu übernehmen. Dafür müssten wir ihn extrahieren können. Das unpack-kernel Script kann es schon.

    Es fehlt also nur das Tool, welches den selbstgebauten 1.ten Kernel und den extrahierten 2.ten Kernel in dem richtigen Format wieder "zusammenpackt".

    Das neue "2-Kernel-Format" ist, soweit ich mich erinnern kann, nirgends vernünftig dokumentiert, kann aber dem unpack-kernel abgelesen werden.
     
  10. PeterPawn

    PeterPawn IPPF-Urgestein

    Registriert seit:
    10 Mai 2006
    Beiträge:
    11,363
    Zustimmungen:
    576
    Punkte für Erfolge:
    113
    Beruf:
    IT-Freelancer
    Ort:
    Berlin
    Der zweite Kernel ist (meiner Theorie zufolge und auf der Basis der Tatsache, daß er wohl bei allen drei GRX-Boxen exakt derselbe ist) wohl so etwas wie der "Hypervisor" für die Virtualisierung des GRX500, der dann erst den zweiten Kernel startet (auspacken wird ihn vermutlich der Bootloader, aber auch das könnte theoretisch der erste Kernel übernehmen). In den Quellen hört das Ganze m.W. auf den Namen "BOOTCORE" (man kann wohl sogar die serielle Console zwischen beiden "Systemen" hin- und herschalten, dem Code nach zu urteilen) und es sollte sich - rein theoretisch - sogar mit diesem Symbol ein passender Kernel übersetzen lassen, denn das hatte ich sogar irgendwo in einem Makefile als Target (mit entsprechend weniger Modulen beim Linken) gesehen - alles ohne Gewähr und aus dem Kopf.
    Code:
    user@host:/tmp/GPL/linux$ grep -r BOOTCORE
    init/main.c:#ifdef CONFIG_SOC_GRX500_BOOTCORE
    init/main.c:#ifdef CONFIG_SOC_GRX500_BOOTCORE
    init/initramfs.c:#ifdef CONFIG_SOC_GRX500_BOOTCORE
    init/initramfs.c:#ifdef CONFIG_SOC_GRX500_BOOTCORE
    arch/mips/boot/dts/Fritz_Box_HW0225-1.dts:      model = "GRX350 ANYWAN BOOTCORE (MIPS 4Kec)";
    arch/mips/boot/dts/Fritz_Box_HW0226.dts:      model = "GRX350 ANYWAN BOOTCORE (MIPS 4Kec)";
    arch/mips/boot/dts/Fritz_Box_HW0239.dts:      model = "GRX350 ANYWAN BOOTCORE (MIPS 4Kec)";
    arch/mips/boot/dts/Fritz_Box_HW0226-1.dts:      model = "GRX350 ANYWAN BOOTCORE (MIPS 4Kec)";
    arch/mips/boot/dts/Fritz_Box_HW0221-1.dts:      model = "GRX350 ANYWAN BOOTCORE (MIPS 4Kec)";
    arch/mips/boot/dts/Fritz_Box_HW0225.dts:      model = "GRX350 ANYWAN BOOTCORE (MIPS 4Kec)";
    arch/mips/boot/dts/Fritz_Box_HW0226-100.dts:      model = "GRX350 ANYWAN BOOTCORE (MIPS 4Kec)";
    arch/mips/boot/dts/easy350_anywan_bootcore.dts:      model = "GRX350 ANYWAN BOOTCORE (MIPS 4Kec)";
    arch/mips/boot/dts/Makefile:ifdef CONFIG_SOC_GRX500_BOOTCORE
    arch/mips/boot/dts/Fritz_Box_HW0221-255.dts:      model = "GRX350 ANYWAN BOOTCORE (MIPS 4Kec)";
    arch/mips/boot/dts/Fritz_Box_HW0221.dts:      model = "GRX350 ANYWAN BOOTCORE (MIPS 4Kec)";
    arch/mips/boot/dts/Fritz_Box_HW0239-255.dts:      model = "GRX350 ANYWAN BOOTCORE (MIPS 4Kec)";
    arch/mips/lantiq/Platform:      ifdef CONFIG_SOC_GRX500_BOOTCORE
    arch/mips/lantiq/Platform:              ifdef CONFIG_BOOTCORE_LOAD_ADDR
    arch/mips/lantiq/Platform:                      load-$(CONFIG_LANTIQ)           = $(CONFIG_BOOTCORE_LOAD_ADDR)
    arch/mips/lantiq/Platform:cflags-$(CONFIG_SOC_GRX500_BOOTCORE)           += -I$(srctree)/arch/mips/include/asm/mach-lantiq/grx500
    arch/mips/lantiq/Kconfig.grx5:if GRX5 || SOC_GRX500_BOOTCORE # == SOC_GRX500 (?)
    arch/mips/lantiq/avm_switch_console.c:#ifdef CONFIG_SOC_GRX500_BOOTCORE
    arch/mips/lantiq/Kconfig:config SOC_GRX500_BOOTCORE
    arch/mips/lantiq/Kconfig:       bool "GRX500_BOOTCORE"
    arch/mips/lantiq/Kconfig:       depends on SOC_GRX500_BOOTCORE
    arch/mips/lantiq/grx500_bootcore/timer.c:       if (irq == GRX500_BOOTCORE_GPTC2_TIMER2_OUT_INDEX)
    arch/mips/lantiq/grx500_bootcore/timer.c:       else if (irq == GRX500_BOOTCORE_GPTC2_TIMER1_OUT_INDEX)
    arch/mips/lantiq/grx500_bootcore/timer.c:       grx500_bootcore_register_static_irq(GRX500_BOOTCORE_GPTC2_TIMER2_IN_INDEX,
    arch/mips/lantiq/grx500_bootcore/timer.c:                                               GRX500_BOOTCORE_GPTC2_TIMER2_OUT_INDEX, &gptc2_timer2_irqaction,
    arch/mips/lantiq/grx500_bootcore/timer.c:       grx500_bootcore_register_static_irq(GRX500_BOOTCORE_GPTC2_TIMER1_IN_INDEX,
    arch/mips/lantiq/grx500_bootcore/timer.c:                                               GRX500_BOOTCORE_GPTC2_TIMER1_OUT_INDEX,
    arch/mips/lantiq/grx500_bootcore/irq.c:        irq_mask = (1<<GRX500_BOOTCORE_SERIAL_IRQ_OUT_INDEX) |
    arch/mips/lantiq/grx500_bootcore/irq.c:                    (1<<GRX500_BOOTCORE_TIMER_IRQ_OUT_INDEX) |
    arch/mips/lantiq/grx500_bootcore/irq.c:                    (1<<GRX500_BOOTCORE_SYNOP_ETHER_IRQ_OUT_INDEX) |
    arch/mips/lantiq/grx500_bootcore/irq.c:                    (1<<GRX500_BOOTCORE_SYNOP_ETHER_IRQ_GMAC2_OUT_INDEX) |
    arch/mips/lantiq/grx500_bootcore/irq.c:                    (1<<GRX500_BOOTCORE_WIRELESS_IRQ_OUT_INDEX);
    arch/mips/lantiq/grx500_bootcore/irq.c:#ifdef GRX500_BOOTCORE_DEBUG_UART
    arch/mips/lantiq/grx500_bootcore/irq.c:#ifdef GRX500_BOOTCORE_DEBUG_UART
    arch/mips/lantiq/grx500_bootcore/irq.c:        .name     = "Lantiq GRX500_BOOTCORE Ext IRQ Controller",
    arch/mips/lantiq/grx500_bootcore/irq.c:        do_IRQ(GRX500_BOOTCORE_SERIAL_IRQ_OUT_INDEX/*0x1*/);
    arch/mips/lantiq/grx500_bootcore/irq.c:        do_IRQ(GRX500_BOOTCORE_SYNOP_ETHER_IRQ_OUT_INDEX/*0x3*/);
    arch/mips/lantiq/grx500_bootcore/irq.c:        do_IRQ(GRX500_BOOTCORE_SYNOP_ETHER_IRQ_GMAC2_OUT_INDEX/*0x4*/);
    arch/mips/lantiq/grx500_bootcore/irq.c:        do_IRQ(GRX500_BOOTCORE_WIRELESS_IRQ_OUT_INDEX);
    arch/mips/lantiq/grx500_bootcore/irq.c:        do_IRQ(GRX500_BOOTCORE_GPTC2_TIMER2_OUT_INDEX);
    arch/mips/lantiq/grx500_bootcore/irq.c:        do_IRQ(GRX500_BOOTCORE_GPTC2_TIMER1_OUT_INDEX);
    arch/mips/lantiq/grx500_bootcore/irq.c:                 do_IRQ(GRX500_BOOTCORE_MPS2_OUT_INDEX);
    arch/mips/lantiq/grx500_bootcore/irq.c:                if ((irq!= GRX500_BOOTCORE_SYNOP_ETHER_IRQ_IN_INDEX) |
    arch/mips/lantiq/grx500_bootcore/irq.c:                        (irq!= GRX500_BOOTCORE_SERIAL_IRQ_IN_INDEX) |
    arch/mips/lantiq/grx500_bootcore/irq.c:                            (irq!= GRX500_BOOTCORE_SYNOP_ETHER_IRQ_GMAC2_IN_INDEX) |
    arch/mips/lantiq/grx500_bootcore/irq.c:                                (irq!= GRX500_BOOTCORE_WIRELESS_IRQ_IN_INDEX) |
    arch/mips/lantiq/grx500_bootcore/irq.c:                                    (irq!= GRX500_BOOTCORE_TIMER_IRQ_IN_INDEX))
    arch/mips/lantiq/grx500_bootcore/early_printk.c:#ifdef CONFIG_SOC_GRX500_BOOTCORE
    arch/mips/lantiq/grx500_bootcore/early_printk.c:#undef GRX500_BOOTCORE_DEBUG_EARLY
    arch/mips/lantiq/grx500_bootcore/early_printk.c:        divisor = ((GRX500_BOOTCORE_SYSTEM_CLK) / (UART_BAUD_RATIO_DIV*baud)) - 1;
    arch/mips/lantiq/grx500_bootcore/early_printk.c:                divisor = ((GRX500_BOOTCORE_SYSTEM_CLK/10) / (UART_BAUD_RATIO_DIV*baud)) - 1;
    arch/mips/lantiq/grx500_bootcore/early_printk.c:#ifdef GRX500_BOOTCORE_DEBUG_EARLY
    arch/mips/lantiq/Makefile:obj-$(CONFIG_SOC_GRX500_BOOTCORE) += grx500_bootcore/
    arch/mips/lantiq/Makefile:obj-$(CONFIG_SOC_GRX500_BOOTCORE) += avm_switch_console.o avm_hw_config.o
    arch/mips/Kconfig:        select CPU_MIPSR2_IRQ_VI if SOC_GRX500_BOOTCORE
    arch/mips/Kconfig:        select CPU_MIPSR2_IRQ_EI if SOC_GRX500_BOOTCORE
    arch/mips/Kconfig:        select SYS_SUPPORTS_LITTLE_ENDIAN if SOC_GRX500 || SOC_GRX500_BOOTCORE
    arch/mips/Kconfig:      select SYS_SUPPORTS_MULTITHREADING if !SOC_GRX500_BOOTCORE
    arch/mips/Kconfig:      select SYS_HAS_EARLY_PRINTK if !SOC_GRX500_BOOTCORE
    arch/mips/Kconfig:      depends on SOC_GRX500 || SOC_GRX500_BOOTCORE
    arch/mips/Kconfig:      depends on SOC_GRX500_BOOTCORE
    arch/mips/Kconfig:config BOOTCORE_LOAD_ADDR
    arch/mips/Kconfig:      depends on SOC_GRX500_BOOTCORE
    arch/mips/kernel/head.S:#if defined(CONFIG_SOC_GRX500)||defined(CONFIG_SOC_GRX500_BOOTCORE)
    arch/mips/kernel/setup.c:#if !defined(CONFIG_OF_AVM_DT_ENV) && !defined(CONFIG_SOC_GRX500_BOOTCORE)
    arch/mips/Makefile:ifdef CONFIG_SOC_GRX500_BOOTCORE
    arch/mips/Makefile:cflags-$(CONFIG_SOC_GRX500_BOOTCORE) += -mno-dsp
    arch/mips/include/asm/mach_avm.h:#if !defined(CONFIG_SOC_GRX500_BOOTCORE)
    arch/mips/include/asm/mach_avm.h:#if defined(CONFIG_SOC_GRX500) || defined(CONFIG_SOC_GRX500_BOOTCORE)
    arch/mips/include/asm/mach-lantiq/cpu-feature-overrides.h:#ifdef CONFIG_SOC_GRX500_BOOTCORE
    arch/mips/include/asm/mach-lantiq/grx500/grx500_bootcore_chadr.h:#define GRX500_BOOTCORE_SYS_SHARED_REGS_OFFSET       0x001c0000
    arch/mips/include/asm/mach-lantiq/grx500/grx500_bootcore_chadr.h:#define GRX500_BOOTCORE_SYS_RESET_REG_OFFSET         0x00000008
    arch/mips/include/asm/mach-lantiq/grx500/grx500_bootcore_chadr.h:#define GRX500_BOOTCORE_SPI_MODE_ADDR                (MT_LOCAL_MIPS_BASE_ADDRESS+0x130)
    arch/mips/include/asm/mach-lantiq/grx500/grx500_bootcore_chadr.h:#define GRX500_BOOTCORE_SPI_MODE_SW_BIT              (0x400) //When this bit is set, FLASH is accessed in SW mode
    arch/mips/include/asm/mach-lantiq/grx500/grx500_bootcore_chadr.h:#define GRX500_BOOTCORE_RESET_OFFSET                 8
    arch/mips/include/asm/mach-lantiq/grx500/grx500_bootcore_chadr.h:#define GRX500_BOOTCORE_RESET_ADDR                   (MT_LOCAL_MIPS_BASE_ADDRESS+GRX500_BOOTCORE_SYS_SHARED_REGS_OFFSET+GRX500_BOOTCORE_RESET_OFFSET)
    arch/mips/include/asm/mach-lantiq/grx500/grx500_bootcore_chadr.h:#define GRX500_BOOTCORE_REBOOT_DATA                  0
    arch/mips/include/asm/mach-lantiq/grx500/grx500_bootcore_chadr.h:#define GRX500_BOOTCORE_REBOOT_BIT_MASK_NOT          0xfffeffff
    arch/mips/include/asm/mach-lantiq/grx500/grx500_bootcore_chadr.h:#define GRX500_BOOTCORE_SHARED_GMAC_BASE_ADDR        (MT_LOCAL_MIPS_BASE_ADDRESS+GRX500_BOOTCORE_SYS_SHARED_REGS_OFFSET)
    arch/mips/include/asm/mach-lantiq/grx500/grx500_bootcore_chadr.h:#define GRX500_BOOTCORE_GMAC_MODE_REG_OFFSET         0x68
    arch/mips/include/asm/mach-lantiq/grx500/grx500_bootcore_chadr.h:#define GRX500_BOOTCORE_GMAC_MODE_REG_ADDR           (MT_LOCAL_MIPS_BASE_ADDRESS+GRX500_BOOTCORE_SYS_SHARED_REGS_OFFSET+GRX500_BOOTCORE_GMAC_MODE_REG_OFFSET)
    arch/mips/include/asm/mach-lantiq/grx500/grx500_bootcore_chadr.h:#define GRX500_BOOTCORE_GMAC_MODE_2_REG_OFFSET       0x80
    arch/mips/include/asm/mach-lantiq/grx500/grx500_bootcore_chadr.h:#define GRX500_BOOTCORE_GMAC_MODE_2_REG_ADDR         (MT_LOCAL_MIPS_BASE_ADDRESS+GRX500_BOOTCORE_SYS_SHARED_REGS_OFFSET+GRX500_BOOTCORE_GMAC_MODE_2_REG_OFFSET)
    arch/mips/include/asm/mach-lantiq/grx500/grx500_bootcore_chadr.h:#define GRX500_BOOTCORE_DLY_PGM_REG_OFFSET           0x64
    arch/mips/include/asm/mach-lantiq/grx500/grx500_bootcore_chadr.h:#define GRX500_BOOTCORE_DLY_PGM_REG_ADDR             (MT_LOCAL_MIPS_BASE_ADDRESS+GRX500_BOOTCORE_SYS_SHARED_REGS_OFFSET+GRX500_BOOTCORE_DLY_PGM_REG_OFFSET)
    arch/mips/include/asm/mach-lantiq/grx500/grx500_bootcore_chadr.h:#define GRX500_BOOTCORE_HCYCLE_CALIB_IND_REG_OFFSET  0x90
    arch/mips/include/asm/mach-lantiq/grx500/grx500_bootcore_chadr.h:#define GRX500_BOOTCORE_HCYCLE_CALIB_IND_REG_ADDR    (MT_LOCAL_MIPS_BASE_ADDRESS+GRX500_BOOTCORE_SYS_SHARED_REGS_OFFSET+GRX500_BOOTCORE_HCYCLE_CALIB_IND_REG_OFFSET)
    arch/mips/include/asm/mach-lantiq/grx500/grx500_bootcore_time.h:#ifndef __GRX500_BOOTCORE_TIME_H__
    arch/mips/include/asm/mach-lantiq/grx500/grx500_bootcore_time.h:#define __GRX500_BOOTCORE_TIME_H__
    arch/mips/include/asm/mach-lantiq/grx500/grx500_bootcore_time.h:/*for real system undefine GRX500_BOOTCORE_SCALE_DOWN*/
    arch/mips/include/asm/mach-lantiq/grx500/grx500_bootcore_time.h:#define GRX500_BOOTCORE_SCALE_DOWN
    arch/mips/include/asm/mach-lantiq/grx500/grx500_bootcore_time.h:#ifdef GRX500_BOOTCORE_SCALE_DOWN
    arch/mips/include/asm/mach-lantiq/grx500/grx500_bootcore_time.h:#define GRX500_BOOTCORE_SCALE_VAL 10
    arch/mips/include/asm/mach-lantiq/grx500/grx500_bootcore_time.h:#define GRX500_BOOTCORE_SCALE_VAL 1
    arch/mips/include/asm/mach-lantiq/grx500/grx500_bootcore_time.h:#define GRX500_BOOTCORE_SYSTEM_CLK  6000000
    arch/mips/include/asm/mach-lantiq/grx500/grx500_bootcore_time.h:#define GRX500_BOOTCORE_CPU_CLK     6000000; //480000000
    arch/mips/include/asm/mach-lantiq/grx500/grx500_bootcore_time.h:#define GRX500_BOOTCORE_SYSTEM_CLK CLOCK_300M
    arch/mips/include/asm/mach-lantiq/grx500/grx500_bootcore_time.h:#define GRX500_BOOTCORE_CPU_CLK    CLOCK_300M
    arch/mips/include/asm/mach-lantiq/grx500/grx500_bootcore_time.h:#define GRX500_BOOTCORE_SYSTEM_CLK  (24000000*GRX500_BOOTCORE_SCALE_VAL)
    arch/mips/include/asm/mach-lantiq/grx500/grx500_bootcore_time.h:#define GRX500_BOOTCORE_CPU_CLK     (48000000*GRX500_BOOTCORE_SCALE_VAL)
    arch/mips/include/asm/mach-lantiq/grx500/grx500_bootcore_time.h:#define GRX500_BOOTCORE_CPU_CLK     (GRX500_BOOTCORE_SYSTEM_CLK *system_to_cpu_multiplier)
    arch/mips/include/asm/mach-lantiq/grx500/grx500_bootcore_time.h:/* Note - the timer used is GRX500_BOOTCORE, run 24000000M
    arch/mips/include/asm/mach-lantiq/grx500/grx500_bootcore_time.h:* If we use the MIPS timer, change to  GRX500_BOOTCORE_CPU_CLK
    arch/mips/include/asm/mach-lantiq/grx500/grx500_bootcore_time.h://#define TICK_DIV (GRX500_BOOTCORE_CPU_CLK/HZ)
    arch/mips/include/asm/mach-lantiq/grx500/grx500_bootcore_time.h:#define TICK_DIV (GRX500_BOOTCORE_SYSTEM_CLK/HZ)
    arch/mips/include/asm/mach-lantiq/grx500/grx500_bootcore_time.h:#endif /* __GRX500_BOOTCORE_TIME_H__ */
    arch/mips/include/asm/mach-lantiq/grx500/grx500_bootcore_interrupt.h:#ifndef __GRX500_BOOTCORE_INTERRUPT_H__
    arch/mips/include/asm/mach-lantiq/grx500/grx500_bootcore_interrupt.h:#define __GRX500_BOOTCORE_INTERRUPT_H__
    arch/mips/include/asm/mach-lantiq/grx500/grx500_bootcore_interrupt.h:#define GRX500_BOOTCORE_SERIAL_IRQ_IN_INDEX       28
    arch/mips/include/asm/mach-lantiq/grx500/grx500_bootcore_interrupt.h:#define GRX500_BOOTCORE_TIMER_IRQ_IN_INDEX        28
    arch/mips/include/asm/mach-lantiq/grx500/grx500_bootcore_interrupt.h:#define GRX500_BOOTCORE_SYNOP_ETHER_IRQ_IN_INDEX  1
    arch/mips/include/asm/mach-lantiq/grx500/grx500_bootcore_interrupt.h:#define GRX500_BOOTCORE_SYNOP_ETHER_IRQ_GMAC2_IN_INDEX  3
    arch/mips/include/asm/mach-lantiq/grx500/grx500_bootcore_interrupt.h:#define GRX500_BOOTCORE_WIRELESS_IRQ_IN_INDEX     9
    arch/mips/include/asm/mach-lantiq/grx500/grx500_bootcore_interrupt.h:#define GRX500_BOOTCORE_SERIAL_IRQ_OUT_INDEX      8
    arch/mips/include/asm/mach-lantiq/grx500/grx500_bootcore_interrupt.h:#define GRX500_BOOTCORE_TIMER_IRQ_OUT_INDEX       2
    arch/mips/include/asm/mach-lantiq/grx500/grx500_bootcore_interrupt.h:#define GRX500_BOOTCORE_SYNOP_ETHER_IRQ_OUT_INDEX 3
    arch/mips/include/asm/mach-lantiq/grx500/grx500_bootcore_interrupt.h:#define GRX500_BOOTCORE_SYNOP_ETHER_IRQ_GMAC2_OUT_INDEX 3
    arch/mips/include/asm/mach-lantiq/grx500/grx500_bootcore_interrupt.h:#define GRX500_BOOTCORE_SYNOP_ETHER_IRQ_GMAC2_OUT_INDEX 4
    arch/mips/include/asm/mach-lantiq/grx500/grx500_bootcore_interrupt.h:#define GRX500_BOOTCORE_WIRELESS_IRQ_OUT_INDEX    5
    arch/mips/include/asm/mach-lantiq/grx500/grx500_bootcore_interrupt.h:#define GRX500_BOOTCORE_GPTC2_TIMER2_IN_INDEX      1
    arch/mips/include/asm/mach-lantiq/grx500/grx500_bootcore_interrupt.h:#define GRX500_BOOTCORE_GPTC2_TIMER2_OUT_INDEX     9
    arch/mips/include/asm/mach-lantiq/grx500/grx500_bootcore_interrupt.h:#define GRX500_BOOTCORE_GPTC2_TIMER1_IN_INDEX      3
    arch/mips/include/asm/mach-lantiq/grx500/grx500_bootcore_interrupt.h:#define GRX500_BOOTCORE_GPTC2_TIMER1_OUT_INDEX     10
    arch/mips/include/asm/mach-lantiq/grx500/grx500_bootcore_interrupt.h:#define GRX500_BOOTCORE_MPS2_OUT_INDEX  11
    arch/mips/include/asm/mach-lantiq/grx500/grx500_bootcore_interrupt.h:#endif /* __GRX500_BOOTCORE_INTERRUPT_H__ */
    arch/mips/include/asm/mach-lantiq/grx500/grx500_bootcore_uart.h:#define PORT_GRX500_BOOTCORE    82
    arch/mips/include/asm/mach-lantiq/grx500/grx500_bootcore_uart.h:#define GRX500_BOOTCORE_BASE_BAUD (GRX500_BOOTCORE_SYSTEM_CLK / UART_BAUD_RATIO_DIV)
    arch/mips/include/asm/mach-lantiq/grx500/grx500_bootcore_uart.h:#define GRX500_BOOTCORE_UART_IRQ        1
    arch/mips/include/asm/mach-lantiq/grx500/grx500_bootcore_uart.h://GRX500_BOOTCORE_SERIAL_IRQ_OUT_INDEX
    arch/mips/include/asm/mach-lantiq/grx500/grx500_bootcore_uart.h:        { 0, GRX500_BOOTCORE_BASE_BAUD, UART_BASE, GRX500_BOOTCORE_UART_IRQ, STD_COM_FLAGS },   /* ttyS0 */
    arch/mips/lib/avm_membench.c:#elif defined(CONFIG_SOC_GRX500_BOOTCORE)
    avm/conf/linux-3.10.grxB5:CONFIG_SOC_GRX500_BOOTCORE=y
    avm/conf/linux-3.10.grxB5:CONFIG_BOOTCORE_LOAD_ADDR=0xFFFFFFFF8E000000
    avm/conf/linux-3.10.grxB5:CONFIG_SERIAL_GRX500_BOOTCORE_CONSOLE=y
    avm/conf/linux-3.10.grx5:# CONFIG_SOC_GRX500_BOOTCORE is not set
    fs/debugfs/file.c:#if defined(CONFIG_AVM_ENHANCED) || defined(CONFIG_SOC_GRX500_BOOTCORE)
    fs/debugfs/file.c:#if defined(CONFIG_AVM_ENHANCED) || defined(CONFIG_SOC_GRX500_BOOTCORE)
    fs/debugfs/file.c:#if defined(CONFIG_AVM_ENHANCED) || defined(CONFIG_SOC_GRX500_BOOTCORE)
    fs/debugfs/file.c:#if defined(CONFIG_AVM_ENHANCED) || defined(CONFIG_SOC_GRX500_BOOTCORE)
    drivers/crypto/Kconfig.grx500:   depends on LANTIQ && SOC_GRX500_BOOTCORE
    drivers/tty/serial/Kconfig:config SERIAL_GRX500_BOOTCORE_CONSOLE
    drivers/tty/serial/Kconfig:     depends on LANTIQ && SOC_GRX500_BOOTCORE
    drivers/tty/serial/Makefile:obj-$(CONFIG_SERIAL_GRX500_BOOTCORE_CONSOLE) += grx500_bootcore-uart.o
    drivers/tty/serial/grx500_bootcore-uart.c:              divisor = ((GRX500_BOOTCORE_SYSTEM_CLK) / (16*baud)) - 1;
    drivers/tty/serial/grx500_bootcore-uart.c:        divisor = ((GRX500_BOOTCORE_SYSTEM_CLK/GRX500_BOOTCORE_SCALE_VAL) / (16*baud)) - 1;
    drivers/tty/serial/grx500_bootcore-uart.c:      grx500_bootcore_register_static_irq(GRX500_BOOTCORE_SERIAL_IRQ_IN_INDEX, GRX500_BOOTCORE_SERIAL_IRQ_OUT_INDEX, &uart_irqaction, grx500_bootcore_uart_irq);
    drivers/tty/serial/grx500_bootcore-uart.c:    //grx500_bootcore_enable_irq(GRX500_BOOTCORE_SERIAL_IRQ_OUT_INDEX); huanx
    drivers/tty/serial/grx500_bootcore-uart.c:#define GRX500_BOOTCORE_CONSOLE       &grx500_bootcore_console
    drivers/tty/serial/grx500_bootcore-uart.c:   .type       = PORT_GRX500_BOOTCORE,
    drivers/tty/serial/grx500_bootcore-uart.c:      .cons                   = GRX500_BOOTCORE_CONSOLE,
    drivers/of/fdt.c:#ifdef CONFIG_SOC_GRX500_BOOTCORE
    drivers/of/fdt.c:#ifdef CONFIG_SOC_GRX500_BOOTCORE
    drivers/of/fdt.c:#ifdef CONFIG_SOC_GRX500_BOOTCORE
    drivers/net/avm_cpunet/hw.c:#ifdef CONFIG_SOC_GRX500_BOOTCORE
    drivers/net/avm_cpunet/hw.c:#define MPS_MEMPOOL_NAME_BOOTCORE "avm_cpunet_tep"
    drivers/net/avm_cpunet/hw.c:#ifdef CONFIG_SOC_GRX500_BOOTCORE
    drivers/net/avm_cpunet/hw.c:#define MPS_MEMPOOL_NAME_SELF MPS_MEMPOOL_NAME_BOOTCORE
    drivers/net/avm_cpunet/hw.c:#define MPS_MEMPOOL_NAME_OTHER MPS_MEMPOOL_NAME_BOOTCORE
    drivers/net/avm_cpunet/hw.c:#ifdef CONFIG_SOC_GRX500_BOOTCORE
    drivers/net/avm_cpunet/hw.c:#ifndef CONFIG_SOC_GRX500_BOOTCORE
    drivers/net/avm_cpunet/hw.c:#ifndef CONFIG_SOC_GRX500_BOOTCORE
    drivers/net/avm_cpunet/hw.c:#ifndef CONFIG_SOC_GRX500_BOOTCORE
    drivers/net/avm_cpunet/hw.c:#ifdef CONFIG_SOC_GRX500_BOOTCORE
    drivers/net/avm_cpunet/hw.c:#ifdef CONFIG_SOC_GRX500_BOOTCORE
    drivers/net/avm_cpunet/hw.c:#ifdef CONFIG_SOC_GRX500_BOOTCORE
    drivers/net/avm_cpunet/hw.c:#ifdef CONFIG_SOC_GRX500_BOOTCORE
    drivers/net/avm_cpunet/hw.c:#ifdef CONFIG_SOC_GRX500_BOOTCORE
    drivers/net/avm_cpunet/hw.c:#ifdef CONFIG_SOC_GRX500_BOOTCORE
    drivers/net/avm_cpunet/hw.c:#ifdef CONFIG_SOC_GRX500_BOOTCORE
    drivers/net/avm_cpunet/hw.c:#ifdef CONFIG_SOC_GRX500_BOOTCORE
    drivers/net/avm_cpunet/hw.c:#ifdef CONFIG_SOC_GRX500_BOOTCORE
    drivers/net/avm_cpunet/hw.c:                                        GRX500_BOOTCORE_MPS2_OUT_INDEX,
    drivers/char/Kconfig:        depends on SOC_GRX500 || SOC_GRX500_BOOTCORE
    drivers/char/Makefile:ifeq ($(CONFIG_SOC_GRX500_BOOTCORE),y)
    drivers/watchdog/Kconfig:config GRX500_BOOTCORE_WDT
    drivers/watchdog/Kconfig:        depends on SOC_GRX500_BOOTCORE
    drivers/watchdog/Makefile:obj-$(CONFIG_GRX500_BOOTCORE_WDT) += bootcore_wdt.o
    drivers/watchdog/bootcore_wdt.c:        .identity = "Hardware Watchdog for BOOTCORE",
    drivers/watchdog/bootcore_wdt.c:MODULE_DESCRIPTION("GRX500 BOOTCORE Watchdog Driver");
    kernel/printk.c:#if !defined(CONFIG_AVM_IPI_YIELD) && !defined(CONFIG_SOC_GRX500_BOOTCORE)
    kernel/printk.c:#endif/*--- #if !defined(CONFIG_AVM_IPI_YIELD) && !defined(CONFIG_SOC_GRX500_BOOTCORE) --- */
    kernel/printk.c:#if !defined(CONFIG_AVM_IPI_YIELD) && !defined(CONFIG_SOC_GRX500_BOOTCORE)
    kernel/printk.c:#endif/*--- #if !defined(CONFIG_AVM_IPI_YIELD) && !defined(CONFIG_SOC_GRX500_BOOTCORE) --- */
    include/linux/debugfs.h:#if defined(CONFIG_AVM_ENHANCED) || defined(CONFIG_SOC_GRX500_BOOTCORE)
    include/linux/debugfs.h:#if defined(CONFIG_AVM_ENHANCED) || defined(CONFIG_SOC_GRX500_BOOTCORE)
    include/linux/debugfs.h:#if defined(CONFIG_AVM_ENHANCED) || defined(CONFIG_SOC_GRX500_BOOTCORE)
    
    Dieser "boot core" arbeitet auch mit einer "avm_kernel_config", aber mit einer statischen, die offenbar bei allen Modellen und in allen Versionen (vor 07.00, weil sich mit dem Linux-Kernel sicherlich auch das Image geändert hat) dieselbe war.

    Wenn ich mich richtig erinnere, gibt es doch noch so etwas wie einen "äußeren Header" mit einer Signatur, der die beiden Kerne in der "kernel.image" von AVM "umschließt"? M.E. müßte es (für erste Tests per Hand) schon ausreichen, den "echten" Kernel auszutauschen bzw. dem "lzma2eva" eine Kombination aus dem gepackten, eigenen Kernel und dem zweiten Image anzubieten und dann diesen Header entsprechend anzupassen (ist halt von Hand etwas Rechnerei).

    Irgendwo hier müßte es nach meiner Erinnerung auch noch einen Thread geben, wo das Thema war, nachdem @er13 den zweiten Header in den Daten gefunden hatte und die Länge im ersten Header nicht mit der Gesamtgröße des Images übereinstimmen wollte.
     
  11. f666

    f666 Mitglied

    Registriert seit:
    6 Apr. 2016
    Beiträge:
    217
    Zustimmungen:
    26
    Punkte für Erfolge:
    28
  12. PeterPawn

    PeterPawn IPPF-Urgestein

    Registriert seit:
    10 Mai 2006
    Beiträge:
    11,363
    Zustimmungen:
    576
    Punkte für Erfolge:
    113
    Beruf:
    IT-Freelancer
    Ort:
    Berlin
  13. JokerGermany

    JokerGermany Mitglied

    Registriert seit:
    7 Aug. 2007
    Beiträge:
    476
    Zustimmungen:
    1
    Punkte für Erfolge:
    18
    #13 JokerGermany, 20 Aug. 2018
    Zuletzt bearbeitet: 20 Aug. 2018
    Also ich habe tun auf einer 7590 genutzt ohne replace Kernel...

    OpenVPN Config:
    Code:
    proto tcp-server
    #proto udp4
    dev tun
    ca /tmp/flash/openvpn/ca.crt
    cert /tmp/flash/openvpn/box.crt
    key /tmp/flash/openvpn/box.key
    dh /tmp/flash/openvpn/dh.pem
    tls-server
    tls-auth /tmp/flash/openvpn/static.key 0
    port 1194
    #port 443
    ifconfig 192.168.200.1 255.255.255.0
    push "route-gateway 192.168.200.1"
    topology subnet
    push "topology subnet"
    push "route 192.168.2.0 255.255.255.0"
    max-clients 9
    mode server
    ifconfig-pool 192.168.200.100 192.168.200.250
    push "route 192.168.200.1"
    route 192.168.188.0 255.255.255.0 192.168.200.2
    tun-mtu 1500
    mssfix
    log /var/tmp/debug_openvpn.out
    verb 3
    #ncp-disable
    #cipher none
    cipher AES-128-CBC
    comp-lzo
    float
    keepalive 10 120
    status /var/log/openvpn.log
    client-config-dir /var/tmp/flash/openvpn/clients_openvpn
    persist-tun
    persist-key
    
    Dann noch in den Freetz Modulen ( fritz.box:81/cgi-bin/file/mod/modules )
    Code:
    tun
    
    eingetragen und alles hat funktioniert.
    Mit Fritz!OS7 ist allerdings irgendwo der Wurm drin...

    Ich als leihe würde allerdings sagen mein Problem mit Fritz!OS7 liegt nicht am tun modul:
    Code:
    Mon Aug 20 12:17:13 2018 OpenVPN 2.4.6 mips-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [AEAD] built on Aug 17 2018
    Mon Aug 20 12:17:13 2018 library versions: OpenSSL 1.0.2o  27 Mar 2018, LZO 2.10
    Mon Aug 20 12:17:13 2018 Diffie-Hellman initialized with 2048 bit key
    Mon Aug 20 12:17:13 2018 Your OpenSSL library was built without elliptic curve support. Skipping ECDH parameter loading.
    Mon Aug 20 12:17:13 2018 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
    Mon Aug 20 12:17:13 2018 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
    Mon Aug 20 12:17:13 2018 TUN/TAP device tun0 opened
    Mon Aug 20 12:17:13 2018 TUN/TAP TX queue length set to 100
    Mon Aug 20 12:17:13 2018 do_ifconfig, tt->did_ifconfig_ipv6_setup=0
    Mon Aug 20 12:17:13 2018 /sbin/ifconfig tun0 192.168.200.1 netmask 255.255.255.0 mtu 1500 broadcast 192.168.200.255
    Mon Aug 20 12:17:13 2018 /sbin/route add -net 192.168.188.0 netmask 255.255.255.0 gw 192.168.200.2
    Mon Aug 20 12:17:13 2018 Socket Buffers: R=[87380->87380] S=[16384->16384]
    Mon Aug 20 12:17:13 2018 Listening for incoming TCP connection on [AF_INET][undef]:1194
    Mon Aug 20 12:17:13 2018 TCPv4_SERVER link local (bound): [AF_INET][undef]:1194
    Mon Aug 20 12:17:13 2018 TCPv4_SERVER link remote: [AF_UNSPEC]
    Mon Aug 20 12:17:13 2018 MULTI: multi_init called, r=256 v=256
    Mon Aug 20 12:17:13 2018 IFCONFIG POOL: base=192.168.200.100 size=151, ipv6=0
    Mon Aug 20 12:17:13 2018 MULTI: TCP INIT maxclients=9 maxevents=13
    Mon Aug 20 12:17:13 2018 Initialization Sequence Completed
    
    €dit:
    Also meine Box crashed allerdings nicht.
     
  14. JokerGermany

    JokerGermany Mitglied

    Registriert seit:
    7 Aug. 2007
    Beiträge:
    476
    Zustimmungen:
    1
    Punkte für Erfolge:
    18
    Ok, korrektur:
    Jetzt wo wieder ne Verbindung mit OpenVPN funktioniert, startet die Fritz!Box kurz nach dem Aufbau neu...
     
  15. KingTutt

    KingTutt Mitglied

    Registriert seit:
    15 Sep. 2005
    Beiträge:
    343
    Zustimmungen:
    2
    Punkte für Erfolge:
    18
    Ich muss gestehen, dass ich zwar schon mal einen Linux Kernel für mein Notebook selbstgebaut habe, aber noch niemals für freetz. Was müsste man denn für die etwas ältere 7490 machen, um einen Replace-Kernel zu erstellen, jetzt wo die Sourcen verfügbar sind? Die zwei problematischen Zeilen im Code rauszupatchen dürfte ja vermutlich das kleinste Problem sein.
    Wenn ich mich an PetersPawns Aussage hier erinnere ist es ja nicht mit einem gpl_compile_kernel.sh getan :eek:
     
  16. f666

    f666 Mitglied

    Registriert seit:
    6 Apr. 2016
    Beiträge:
    217
    Zustimmungen:
    26
    Punkte für Erfolge:
    28
    Ich habe es testweise probiert, und kann sagen: seit über einem Tag läuft OpenVPN auf meiner 7490 FritzOS 7.01 ohne Abstürze.
    Ich kenne die Pläne von @er13 nicht, aber wenn es Bedarf gibt, kann ich meinen Testbranch veröffentlichen.
     
  17. jacktherussel

    jacktherussel Neuer User

    Registriert seit:
    9 Jan. 2016
    Beiträge:
    4
    Zustimmungen:
    0
    Punkte für Erfolge:
    1
    @f666
    Also ich hätte Interesse an der funktionierenden Version!
    mfG
     
  18. slashxxx

    slashxxx Neuer User

    Registriert seit:
    29 Mai 2017
    Beiträge:
    9
    Zustimmungen:
    0
    Punkte für Erfolge:
    1
    @f666

    Ich hätte auch Interesse. Habe gerade genau das selbe Problem.
    Vielen Dank für deine Unterstützung und Mühe!
     
  19. KingTutt

    KingTutt Mitglied

    Registriert seit:
    15 Sep. 2005
    Beiträge:
    343
    Zustimmungen:
    2
    Punkte für Erfolge:
    18
    Vielleicht kannst Du auch einen Patch zwischen den originalen AVM Sourcen und Deinen notwendigen Modifikationen erstellen, dann könnte ich die im zugehörigen Freetz-Ticket mit anhängen? Ich vermute, dass noch mehr Nutzer mit Interesse in den Startlöchern stehen.
     
  20. Herbie_2005

    Herbie_2005 Mitglied

    Registriert seit:
    31 März 2007
    Beiträge:
    291
    Zustimmungen:
    0
    Punkte für Erfolge:
    16
    Genau so ist es. Ich habe da auch schon mein Glück versucht – und es nicht hinbekommen. Bei mir ist es nach wie vor so, daß die Fritzbox sich neustartet, sobald man die Openvpn-Verbindung tatsächlich herstellt.