FRITZ!OS7 openvpn auf 7590 => kein tun Modul

CKone

Neuer User
Mitglied seit
1 Nov 2005
Beiträge
23
Punkte für Reaktionen
0
Punkte
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
 
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.
 
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)?
 
Ja, hatte ich auch schon überlegt. Wir brauchen aber erst einmal "replace kernel", dann kann man das testen.
 
Wir brauchen aber erst einmal "replace kernel"
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.
 
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.
 
Zuletzt bearbeitet:
@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.
 
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.
Nur die Ruhe, kann jedem passieren ;)

Was genau verhindert das? Die Quellen für die 7590 sind doch verfügbar ...
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.
 
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.
 
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:
Leider funktionieren alle Programme, die tun/tap benötigen, nicht mehr in FritzOS 7.0, siehe http://freetz.org/ticket/2979
Also meine Box crashed allerdings nicht.
 
Zuletzt bearbeitet:
Ok, korrektur:
Jetzt wo wieder ne Verbindung mit OpenVPN funktioniert, startet die Fritz!Box kurz nach dem Aufbau neu...
 
...
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:
...
...
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:
 
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.
 
@f666

Ich hätte auch Interesse. Habe gerade genau das selbe Problem.
Vielen Dank für deine Unterstützung und Mühe!
 
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.
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.
 
Ich vermute, daß noch mehr Nutzer mit Interesse in den Startlöchern stehen.
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.
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.