FRITZ!OS7 openvpn auf 7590 => kein tun Modul

[KingTutt]

er13 hat just Ticket 2979 in freetz überarbeitet, so dass Freiwillige herzlich eingeladen sind die 7490 mit Replace kernel zu testen.
BITTE beachten: er13 hat nur einen compile-test durchgeführt, keinen Test des Kernels auf der Box selbst! Also nicht gleich meckern wenn es noch nicht funktioniert

@f666 hast Du zusätzlich an der AVM sourcen etwas patchen oder ändern müssen, was in dem Changeset in freetz hier nicht enthalten ist?

 

[slashxxx]

Super das sich hier etwas tut

@KingTutt ist dies auch für die 7590 anzuwenden?

Ich würde gerne unterstützen und testen.

 

[KingTutt]

@KingTutt ist dies auch für die 7590 anzuwenden?
Ich würde gerne unterstützen und testen.

Schön dass Du helfen möchtest, allerdings gibt es bei der 7590 (GRX5-Box) vorher noch andere Probleme zu lösen, wir er13 hier in Post #9 bereits geschrieben hat.

 

[slashxxx]

alles klar, danke für die Info.

Ich werde diesen Thread gespannt mitverfolgen...

 

[f666]

@er13 war schneller, im aktuellen Trunk ist seit r14897 alles Notwendige für die 7490 drin (siehe Ticket #2979).

 

[noob_noob]

AVM hat an 2 Stellen die Zeile

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

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.

vlt kann @matrixspucky hier ja auch für nen licht zum thema ins dunkle tragen ...

 

[JokerGermany]

Was soll denn getestet werden?
Bekomme nur "504 Gateway Time-out"

Nutze meine FB7490 derzeit allerdings nur als WlanRepeater.
Meine FB7590 ist meine Haupt Fritzbox (ohne FritzOS7 wegen diesem Problem...)

 

[slashxxx]

freetz.org ist leider nicht verfügbar. Hat sich bzgl. des Problems schon etwas getan?

 

[Whoopie]

Nein.

 

[hermann72pb]

In #21 wurde berichtet, dass OpenVPN mit ReplaceKernel auf einer 7490 lauffähig sein sollte. Mangels Trac-Verfügbarkeit kenne ich leider die gesamte Diskussion zu dem enstprechenden Ticket nicht. Trotzdem hatte ich gestern mir ein Image mit Replace Kernel generieren können. Dafür musste ich zwar ein Paar Sachen aus meinem alten .config wegnehmen (UMTS- und GSM-Patches, einige Compiler-Optionen, die nun irgendwie obsolete sind) und auch frisch auschecken und neu bauen. Letztendlich wurde aber die Firmware gebaut, die ich heute versucht hatte auf die Box zu laden. Leider lebt diese Firmware nicht länger als 2-3 Minuten auf der Box. Danach rebootet die Box. Vermutlich beim Laden von irgendwelchen FREETZ-Paketen. Welche von den Paketen genau dafür die Ursache sind, konnte ich allerdings in Kürze der Zeit nicht feststellen. Nun habe ich dank NAND-Flash diese Firmware in den Schatten gestellt und bin zur alten Firmware wieder gewechselt, könnte aber jede Zeit die "gebuggte" Firmware zu Testzwecken aus dem Schatten holen.
Meine Fragen:
1. Kann jemand bitte eine funktionsfähige .config hier posten, mit der OpenVPN auf der 7490 mit ReplaceKernel läuft, wie in #21 geschrieben? Ich könnte natürlich auch meine ziemlich volle .config hier bereitstellen, will aber hier eine OT-Diskussion vermeiden, wozu ich Paket XY und YZ denn brauche usw.
2. Kann jemand bitte hier eine etwas OT bzgl. OpenVPN, dennoch für die Allgemeinheit wichtige Information geben, was nachweislich bei 7490 mit der neuen Firmware derzeit Probleme bereitet? Ich meine hier Patches und bestimmte FREETZ-Pakete. Z.B. nutze ich dnsmasq und hatte irgendwo von den Problemen diesbezüglich gehört.
3. Hat jemand einen Tipp für mich, wie ich das Laden der FREETZ-Pakete unterbrechen kann? Denn 2-3 Minuten habe ich, die Box ist auch kurz per SSH erreichbar. Man kann da schon ein Paar Befehle absetzen, bevor sie rebootet.

MfG

EDIT: Dank einer wichtigen Information aus Seit freetzen der 6590 dauernder Neustart über "Erweiterte Supportdatei" (kannte ich nicht), habe ich nun bei mir diese Datei erzeugt und poste hier den Abschnitt mit dem Crash-Report:

##### BEGIN SECTION CRASHLOG /proc/avm/log_sd
==========

BEGIN SECTION '/proc/avm/log_sd/crash'
----------
1970-01-01 01:03:32(1) [Bus error] /usr/bin/avm/ctlmgr([3469]) watchdog expired at 0+0x769c9678 (/lib/libc.so.1 at 00062678)
SIGNO 10 ERRNO 62 CODE 3
Version: 07.01
Watchdog triggered 168 seconds ago
No bugmsg
ze: 00000000 at: 00000000 v0: 00000004 v1: 00000001
a0: 769eb6e4 a1: 00000080 a2: 00000002 a3: 00000001
t0: 00000000 t1: 76127000 t2: fffffffc t3: 00000001
t4: 00000000 t5: 7721f000 t6: 00100000 t7: 8db009a8
s0: 769eb6e4 s1: 00000002 s2: 7721effc s3: 7721c310
s4: 7ff50440 s5: 7ff50980 s6: 77106000 s7: 7ff50900
t8: 00000003 t9: 769c9610 k0: 00000000 k1: 00000000
gp: 769f23c0 sp: 7ff50418 fp: 7ff50450 ra: 769c8dc4
FA ebadebad (stack overflow)
PC 769c9678 0+0x769c9678 (/lib/libc.so.1 at 00062678)
PC Code: 00003821 2402108e 0000000c <1000fff2> 00000000 8fb10004 8fb00000 03e00008 27bd0008
RA 769c8dc4 fork+0x144 (/lib/libc.so.1 at 00061dc4)
RA Code: 8f998170 04110214 02002021 <8fdc0010> ae130008 8e020004 24420001 ae020004 7c03e83b
[bt]  769c9678 [769c9614] <0+0x769c9614>+0x64 (/lib/libc.so.1 at 00062614/0x62678)
                        Code: 00003821 2402108e 0000000c <1000fff2> 00000000 8fb10004 8fb00000 03e00008 27bd0008
[bt]  769c8dbc [769c8d34] <fork+0xb4>+0x88 (/lib/libc.so.1 at 00061d34/0x61dbc)
                        Code: 54800006 ae130008 8f998170 <04110214> 02002021 8fdc0010 ae130008 8e020004 24420001
[bt] caller return <= _ftext: 00000000 00000000 (?)
[bt] finished.
-----
crashreport: FLASH_FS_CRASH: TFFS3_Read() -> result=-2
crashreport: old parsed checksum[2].cs = 00000000 new_sum=05785591 (new_len=1401)
crashreport: crash-variable set to '[0]0,0,0[1]0,0,0[2]5785591,5beb465b,6[3]0,0,0'
(first) sent on: Tue Nov 13 21:47:07 2018 UTC by support data
----------
END SECTION '/proc/avm/log_sd/crash'

Also, libc.so ist anscheinend die Ursache... Die Frage ist nur, in welchem Paket.

 

[f666]

Am hilfreichsten ist es, wenn du dich Schritt für Schritt von einer minimalen .config zu deiner .config durcharbeitest, bis der Fehler auftritt. Wenn wir dann wissen, welches Paket den Fehler verursacht, kann man gezielt versuchen, ihn zu behebn.

 

[hermann72pb]

Danke für den 0815-Tipp. Mit einer produktiven Box (um die es ja bei mir leider geht) und mit der Zeit, die ich dafür habe, diese Fehlersuche zu betreiben, werde ich wahrscheinlich nach 2-3 Durchläufen aufgeben. Wenn man dabei bedenkt, dass alleine das Bauen vom Firmware (mit replace kernel, wohlgemerkt, wie hier ja auch empfohlen wurde) alleine schon mehrere Stunden gedauert hat, wird mir an der Stelle wirklich schnell die Lust vergehen. Mag sein, dass beim Wegnehmen der Pakete alles nicht neu kompiliert werden muss und dadurch schneller abläuft, es ist mir aber trotzdem zu lang und eigentlich nicht besonders intelligent.
Wie ich oben schon angedeutet habe, würde ich eher den Weg bevorzugen, das Laden der FREETZ-Pakete an der gerade startenden Box innerhalb dieser 168 Sekunden (s. oben) zu unterbinden. Denn von der Zeit her scheint es (meiner bescheidenen Meinung nach) was mit dem Laden der Pakete zu tun haben. Ich habe da stark samba im Verdacht oder evtl. meine Manipulationen in rc.custom mit dem killen von ftpd und mit dem Starten von vsftp. Ich versuche lieber rc.mod zu killen oder mir den Boot-log live anzeigen zu lassen, um zu sehen, wo rc.mod da gerade unterwegs ist. Zunächst werde ich mir aber ein Bild davon verschaffen, wie es mit der alten Firmware und der gleichen Kombination der Pakete abläuft. Vielleicht werde ich da schon mal über die Ladeabfolge der Pakete schlau und weiß in etwa, was da zum Zeitpunkt der 168 Sekunde geladen werden will.

Ich melde mich, wenn ich was herausgefunden habe.

MfG

 

[PeterPawn]

was da zum Zeitpunkt der 168 Sekunde geladen werden will

Das verstehe ich nicht ... oder ich rechne falsch.

Die Meldung tritt nach 212 Sekunden Laufzeit der Box auf (die Uhrzeit startet um 01:00:00 Uhr und zum Zeitpunkt, wo der Watchdog zuschlägt, ist es 01:03:32 Uhr lt. Protokoll) - ich verstehe das mal so, daß die Meldung:

Watchdog triggered 168 seconds ago

vermutlich den Zeitpunkt angeben soll, wann der zuletzt "zurückgesetzt" bzw. "eingerichtet" wurde (wenn die Aktion erst 168 Sekunden nach Ablauf und "Kippen" des Triggers zum Tragen käme, wäre so ein Watchdog je recht ineffektiv) und das wäre dann der Zeitpunkt 212 Sekunden - 168 Sekunden = 44 Sekunden nach dem Start des Timers im Kernel, wo dieser "wdt" gestartet wurde. Das mag ein paar Sekunden länger sein ab "power-on" (weil auch der Kernel erst mal entpackt werden muß und die "grace period" von EVA, wo auf FTP-Clients gewartet wird, auch noch dazu kommt), aber bis zur 168. Sekunden reicht das dann vermutlich doch nicht.

Wobei der Watchdog ohnehin im "ctlmgr" liegen sollte (wenn ich den "short dump" wieder richtig interpretiere - dort setzt der geforkte Thread für den abgelaufenen Timer dann halt im "ctlmgr"-Kontext fort) und der wird über die "E46-net" schon in etwa zu diesem Zeitpunkt gestartet. Nur scheint eben ein Thread innerhalb dieses Prozesses dann zu hängen und daher den Timer nicht zurückzusetzen - bei AVM läuft in dieser "group 4" in etwa so etwas ab (kein Freetz-Image, nur eigene Modifikationen - auf einer 7490, wobei ich langsam ohnehin nicht mehr durchblicke, weil es ja im Thread eigentlich um die 7590 gehen sollte und da ist das Timing ein wenig anders ... wenn auch nicht kriegsentscheidend):

source files in group 4 ...
[   25.210000][0]udevd[1408]: starting version 175
/etc/init.d/S42-ptest     /etc/init.d/S45-configd
/etc/init.d/S44-hostname  /etc/init.d/S46-usb
source /etc/init.d/S42-ptest
source /etc/init.d/S44-hostname
source /etc/init.d/S45-configd
source /etc/init.d/S46-usb
[   25.550000][1][module-alloc-by-name] give 0x1000 bytes at 0x81246000 to module 'usb_common' (0x6c9000 total bytes left)
[   25.640000][1][ifx_hsnand_command] read block is critical (column: 0x0 page: 0x45d0)
[   25.760000][1][module-alloc-by-name] give 0x39000 bytes at 0x81247000 to module 'usbcore' (0x690000 total bytes left)
[   25.780000][1]usbcore: registered new interface driver usbfs
[   25.780000][1]usbcore: registered new interface driver hub
[   25.790000][1]usbcore: registered new device driver usb
mount: mounting usbfs on /proc/bus/usb failed: No such file or directory
starting XHCI driver
[   26.070000][1][module-alloc-by-name] give 0x1c000 bytes at 0x81280000 to module 'xhci_hcd' (0x674000 total bytes left)
[   26.070000][1]xhci_hcd 0000:01:00.0: xHCI Host Controller
[   26.070000][1]xhci_hcd 0000:01:00.0: new USB bus registered, assigned bus number 1
[   26.150000][1]usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
[   26.150000][1]usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[   26.150000][1]usb usb1: Product: xHCI Host Controller
[   26.150000][1]usb usb1: Manufacturer: Linux 3.10.107 xhci_hcd
[   26.150000][1]usb usb1: SerialNumber: 0000:01:00.0
[   26.150000][1]hub 1-0:1.0: USB hub found
[   26.150000][1]hub 1-0:1.0: 2 ports detected
[   26.150000][1]avm_net_trace: New net trace device 'usb1' registered with minor 161.
[   26.150000][1]xhci_hcd 0000:01:00.0: xHCI Host Controller
[   26.150000][1]xhci_hcd 0000:01:00.0: new USB bus registered, assigned bus number 2
[   26.150000][1]xHCI: delay VBUS POWER on for 100 ms
[   26.150000][1]usb usb2: New USB device found, idVendor=1d6b, idProduct=0003
[   26.150000][1]usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[   26.150000][1]usb usb2: Product: xHCI Host Controller
[   26.150000][1]usb usb2: Manufacturer: Linux 3.10.107 xhci_hcd
[   26.150000][1]usb usb2: SerialNumber: 0000:01:00.0
[   26.170000][1]hub 2-0:1.0: USB hub found
[   26.170000][1]hub 2-0:1.0: 2 ports detected
[   26.170000][1]AVM: disable USB3 bus#2 port#1 config=1
[   26.170000][1]avm_net_trace: New net trace device 'usb2' registered with minor 162.
XHCI USB 3.0 Host with port_config:1 started
[   26.250000][1]xHCI: delayed VBUS POWER on
[   26.420000][0][0]system-load 6 loadavg 0.99 0.24 0.8 - 62 tasks:27 % curr:udevadm(0 %)max:migration/0(21 %, pid:7) pgstat: sum=60199 free=52803 slab=1702 alloc=557/s fault=1270/s (sleep 2)
[   27.200000][1][1]system-load 4 loadavg 0.99 0.24 0.8 - 83 tasks:3 % curr:blkid(0 %)max:udevadm(0 %, pid:1462) pgstat: sum=59983 free=51429 slab=2029 alloc=202/s fault=345/s (sleep 4)
execute files in group 4 ...
/etc/init.d/E40-avmipc     /etc/init.d/E46-net
/etc/init.d/E40-dsl        /etc/init.d/E47-cpunet
/etc/init.d/E41-capi       /etc/init.d/E47-voip
/etc/init.d/E45-avmnexusd  /etc/init.d/E48-mesh
/etc/init.d/E45-psetd
execute /etc/init.d/E40-avmipc
execute /etc/init.d/E40-dsl
[dsl sus] setting up avm_fiber_if!
[   29.730000][0][module-alloc-by-name] give 0x1000 bytes at 0x8129c000 to module 'avm_fiber_if' (0x673000 total bytes left)
[dsl sus] dsl line test calib factory file available
[dsl get xtse] ANNEX=B DSLMODE=0
[dsl get xtse] setting ADSL Annex B/J and VDSL2 oISDN
[dsl get xtse] 10 00 10 40 00 04 01 07
[dsl sus] AVM MEI diag enabled
[dsl sus] starting vr9 dsp...
[dsl sus] ANNEX=B DSLMODE=0
[   30.190000][1][module-alloc-by-name] give 0x2e000 bytes at 0x8129d000 to module 'mei_vr9' (0x645000 total bytes left)
[   30.200000] [dsl_mei] Lantiq (VRX) DSL CPE MEI driver, version 1.4.4, (c) 2013 Lantiq Deutschland GmbH
[   30.210000][1][dsl mei] tried to set GDBG Level to 4
[dsl mei] debug_level=4, Global UsrDbgLevel=4 MEI_DRV UsrDbgLevel=4 MEI_MEI_ACCESS UsrDbgLevel=4

[   30.210000][1][dsl mei] debug_level=4, Global IntDbgLevel=4 MEI_DRV IntDbgLevel=4 MEI_MEI_ACCESS IntDbgLevel=4
[   30.210000][1][dsl_vr9] AVM_MEI_PowerUpDSLSubsystem enable power domain 'DSL + DFE'
[   30.210000][1][AVM_MEI_PowerUpDSLSubsystem] power up 'PPE TC, PPE EMA, LEDC, DFEV1, DFEV0'
[   30.220000][1]usb 1-2: new high-speed USB device number 2 using xhci_hcd
[   30.230000][1][dsl_vr9] AVM_MEI_PowerUpDSLSubsystem unreset 'DSL, DFE, AFE, VOICE, DSLTC, ARC'
[dsl sus] loaded vr9 mei driver: mei_vr9.ko with params: , avmDslDiagEnabled=1
[   30.240000][1]usb 1-2: New USB device found, idVendor=067b, idProduct=2506
[   30.240000][1]usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[   30.240000][1]usb 1-2: Product: Mass Storage Device
[   30.240000][1]usb 1-2: Manufacturer: Prolific Technology Inc.
[   30.240000][1]usb 1-2: SerialNumber: 0
[   30.240000][1]Port#2 connect: AVM Powermeter changed to 100 mA
[   30.250000][1]Port#2 config: AVM Powermeter changed to 100 mA
[   30.490000][1][module-alloc-by-name] give 0x4d000 bytes at 0x812cb000 to module 'dsl_vr9' (0x5f8000 total bytes left)
[dsl sus] loaded vr9 dsl driver: .ko with params:
[dsl sus] created vr9 dsl device node /dev/dsl_vr9/0 (major: 238 , minor: 0)
[dsl sus] created vr9 mei device node /dev/mei_vr9 (major: 239 , minor: 0)
[dsl sus] invoke /sbin/notify_avmnet --broadband_type DSL hw_start_tm_ptm
[   30.840000][0][module-alloc-by-name] give 0x26000 bytes at 0x81318000 to module 'ifxmips_ppa_datapath_vr9_e5' (0x5d2000 total bytes left)
[   30.860000][0]drivers/net/ethernet/avm/avm_cpmac/switch/ifx/vr9/ifxmips_ppa_datapath_vr9_e5.c:3076:init_local_variables: [init_local_variables] g_eth_wan_mode=0
[   30.860000][0]
[   30.860000][0]drivers/net/ethernet/avm/avm_cpmac/switch/ifx/vr9/ifxmips_ppa_datapath_vr9_e5.c:3135:init_local_variables: g_wan_itf=0x80, g_wanqos_en=8
[   30.860000][0]
[   30.880000][0]CPU_TO_WAN_TX_DESC_BASE[0] =0xbe227400
[   30.880000][0][avmnet] [avmnet_swi_7port_disable_learning] Configuring CPU-port to receive all unknown unicast frames 0x48
[   30.880000][0][avmnet] [avmnet_swi_7port_disable_learning] Configuring CPU-port to receive all unknown multicast frames 0x48
[dsl sus] started dsl_control (configuration: -i10_00_10_40_00_04_01_07 -f/lib/modules/dsp_vr9/vr9-B-dsl.bin -n/etc/dsl/notify/dsl_notify.sh  )
nohup: appending output to nohup.out
FIO_MEI_FW_MODE_STAT_GET failed!: Operation not permitted
0
[dsl sus] started dsl_monitor
[dsl sus] ....vr9 dsp started
execute /etc/init.d/E41-capi
[   32.080000][0][module-alloc-by-name] give 0x7c000 bytes at 0x8133e000 to module 'pcmlink' (0x556000 total bytes left)
[   32.690000][0][module-alloc-by-name] give 0x24000 bytes at 0x813ba000 to module 'scsi_mod' (0x532000 total bytes left)
[   32.760000][0]SCSI subsystem initialized
[   32.790000][0][module-alloc-by-name] give 0xb000 bytes at 0x813de000 to module 'sd_mod' (0x527000 total bytes left)
[   32.880000][0][module-alloc-by-name] give 0xe000 bytes at 0x813e9000 to module 'usb_storage' (0x519000 total bytes left)
[   32.890000][0]usb-storage 1-2:1.0: USB Mass Storage device detected
[   32.890000][0]scsi0 : usb-storage 1-2:1.0
[   32.900000][0]usbcore: registered new interface driver usb-storage
[   33.070000][1][module-alloc-by-name] give 0xfd000 bytes at 0x813f7000 to module 'isdn_fbox_fon5' (0x41c000 total bytes left)
[   33.160000][1][capi_oslib]avm_stack_attach: cpu1 -> cpu1
[   33.160000][1][pcmlink]chrony-support
[   33.180000][1][isdn]PCMLINK: (fpga2) Codecslots=13 Slics=2 Pots=1 TE=2 NT=2 DECT=4 (CLARE2)  DSP-EC: 0
[   33.580000][0][module-alloc-by-name] give 0x6a000 bytes at 0x814f4000 to module 'capi_codec' (0x3b2000 total bytes left)
[   33.800000][0][module-alloc-by-name] give 0x5b000 bytes at 0x8155e000 to module 'avm_dect' (0x357000 total bytes left)
[   33.830000][1][module-alloc-by-name] give 0x5000 bytes at 0x815b9000 to module 'dect_io' (0x352000 total bytes left)
[   33.850000][1][DECTDRV_ERR] fpCap ext data queueSize 5120, avmTpui 4096/34305, etsiTpui 38401/2560
execute /etc/init.d/E45-avmnexusd
1970-01-01 01:00:34 avmnexusd[2563]: ready (0sec)
execute /etc/init.d/E45-psetd
execute /etc/init.d/E46-net
Neuroptima unavailable... setting (and upon event resetting) default parameters from file '/etc/psetd.cfg'.
[   34.720000][0][module-alloc-by-name] give 0x3000 bytes at 0x815be000 to module 'cprocfsmod' (0x34f000 total bytes left)
[   34.780000][0][ifx_hsnand_command] read block is critical (column: 0x0 page: 0x4228)
[   35.760000][0][module-alloc-by-name] give 0x1e4000 bytes at 0x815c1000 to module 'kdsldmod' (0x16b000 total bytes left)
[   35.910000][0]kdsldmod: init start (sizeof(struct sk_buff) = 448)
[   35.920000][1]userman: device registerd (userman_url) with major=231
[   35.920000][1]kdsld: ttychannel: ldisc 8 registered
[   35.920000][1]PCP_NL: PCP netlink interface (multicast group 1)
[   35.920000][1]kdsldmod: init done
1970-01-01 01:00:37 l2tpv3d[2714]: ready (0sec)
[   37.760000][0][0]system-load 100% loadavg 1.38 0.35 0.12 - 98 tasks:62 % curr:ctlmgr(3 %)max:dsl_control(6 %, pid:2459) pgstat: sum=59660 free=43098 slab=3682 alloc=3098/s fault=4048/s (sleep 2)
[   37.930000][1]scsi 0:0:0:0: Direct-Access     WDC WD25 00BEVE-00WZT0    01.0 PQ: 0 ANSI: 0
[   37.940000][1]sd 0:0:0:0: [sda] 488397168 512-byte logical blocks: (250 GB/232 GiB)
[   37.950000][1]sd 0:0:0:0: [sda] Write Protect is off
[   37.950000][1]sd 0:0:0:0: [sda] No Caching mode page found
[   37.950000][1]sd 0:0:0:0: [sda] Assuming drive cache: write through
[   38.000000][1]sd 0:0:0:0: [sda] No Caching mode page found
[   38.000000][1]sd 0:0:0:0: [sda] Assuming drive cache: write through
[   38.100000][1] sda: sda1 sda2 sda3
[   38.120000][1]sd 0:0:0:0: [sda] No Caching mode page found
[   38.120000][1]sd 0:0:0:0: [sda] Assuming drive cache: write through
[   38.120000][1]sd 0:0:0:0: [sda] Attached SCSI disk
1970-01-01 01:00:38 upnpd[2748]: ready (0sec)
[   39.340000][1][1]system-load 4 loadavg 1.38 0.35 0.12 - 111 tasks:13 % curr:blkid(0 %)max:ctlmgr(4 %, pid:2730) pgstat: sum=59998 free=41922 slab=3842 alloc=556/s fault=938/s (sleep 4)
Mounting [system] to device /dev/sda2...
MOUNT: use blkid to get device /dev/sda2 data
MOUNT: filesystem type is: ext3
MOUNT:mount -t 'extX' /dev/sda2 /var/media/ftp/system
[   40.040000][0]kjournald starting.  Commit interval 5 seconds
[   40.040000][0]EXT3-fs (sda2): using internal journal
[   40.040000][0]EXT3-fs (sda2): mounted filesystem with writeback data mode
starting hd-idle with 1200 seconds
grep: /var/tmp/medialabels: No such file or directory
killall: ftpd: no process killed
grep: /var/tmp/inetd.conf: No such file or directory
killall: inetd: no process killed
1970-01-01 01:00:42 tr069starter[2958]: ready (0sec)
[   42.390000][0]IPv6: ADDRCONF(NETDEV_UP): lan: link is not ready
[   42.400000][0]IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[   42.420000][0]IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready
killall: nmbd: no process killed
killall: inetd: no process killed
[   42.930000][1]IPv6: ADDRCONF(NETDEV_UP): eth2: link is not ready
[   43.440000][0]IPv6: ADDRCONF(NETDEV_UP): eth3: link is not ready
1970-01-01 01:00:43 multid[2890]: ready (2sec)
1970-01-01 01:00:44 ddnsd[3003]: [3003]: Daemon start failed (0sec)
FATAL: ddnsd not running after started
1970-01-01 01:00:44 pcpd[3026]: ready (0sec)
rc.wlan: Start WLAN...
[   44.810000][1]IPv6: ADDRCONF(NETDEV_UP): wasp: link is not ready
[   44.850000][1]IPv6: ADDRCONF(NETDEV_UP): wasp: link is not ready
WLAND:[03070]:01:00.45/[0045.036]:[VER]Registered new module default, DEFAULT, 0
WLAND:[03070]:01:00.45/[0045.036]:[VER]Registered new module global, GLOBAL, 0
WLAND:[03070]:01:00.45/[0045.036]:[ALW]BUILD: Sep 10 2018, 11:06:51
[   45.470000][1]IPv6: ADDRCONF(NETDEV_CHANGE): wasp: link becomes ready
[   45.470000][1]IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[   45.470000][1]IPv6: ADDRCONF(NETDEV_CHANGE): lan: link becomes ready
[   45.490000][1][dma_device_write] auto open tx_chan_no:2
[   46.130000][0]Re-init AVM Net Common Datapath Driver 7Port Switch ...... [   46.130000][0][init_hw] ppe_hw_init=0xff successful
[   46.140000][0][avmnet] [avmnet_swi_7port_disable_learning] Configuring CPU-port to receive all unknown unicast frames 0x48
[   46.140000][0][avmnet] [avmnet_swi_7port_disable_learning] Configuring CPU-port to receive all unknown multicast frames 0x48
[   46.140000][0][reinit_7port_common_eth] Succeeded!
[   46.170000][0]drivers/net/ethernet/avm/avm_cpmac/switch/ifx/vr9/ifxmips_ppa_datapath_vr9_e5.c:3076:init_local_variables: [init_local_variables] g_eth_wan_mode=3
[   46.170000][0]
[   46.170000][0]drivers/net/ethernet/avm/avm_cpmac/switch/ifx/vr9/ifxmips_ppa_datapath_vr9_e5.c:3135:init_local_variables: g_wan_itf=0x2, g_wanqos_en=8
[   46.170000][0]
[   46.190000][0]CPU_TO_WAN_TX_DESC_BASE[0] =0xbe227400
[   46.190000][0][avmnet] [avmnet_swi_7port_disable_learning] Configuring CPU-port to receive all unknown unicast frames 0x48
[   46.190000][0][avmnet] [avmnet_swi_7port_disable_learning] Configuring CPU-port to receive all unknown multicast frames 0x48
[   46.280000][0][module-alloc-by-name] give 0x13000 bytes at 0x817a5000 to module 'ifxmips_ppa_hal_vr9_e5' (0x158000 total bytes left)
[   46.380000][0][module-alloc-by-name] give 0x16000 bytes at 0x817b8000 to module 'ifx_ppa_mini_sessions' (0x142000 total bytes left)
[   46.390000] [ifx_ppa_mini_session_init]
[   46.390000][0][ifx_ppa_mini_session_init] avm_pa sessionh_lookup table
[   46.390000][0]max_lan_entries       192
[   46.390000][0]max_wan_entries       192
[   46.390000][0]max_mc_entries        32
[   46.390000][0]max_bridging_entries  2048
[   46.390000][0]max_ipv6_addr_entries 128
[   46.390000][0]max_fw_queue          8
[   46.390000][0]max_6rd_entries       4
[   46.440000][1][module-alloc-by-name] give 0x2000 bytes at 0x817ce000 to module 'ifx_ppa_mini_qos' (0x140000 total bytes left)
[   46.450000][0]kdsld: flushing internet sessions
[   46.470000][0]IPv6: ADDRCONF(NETDEV_CHANGE): eth2: link becomes ready
1970-01-01 01:00:46 dsld[3083]: ready (0sec)
Mounting [YourFritz] to device /dev/sda3...
MOUNT: use blkid to get device /dev/sda3 data
MOUNT: filesystem type is: ext3
MOUNT:mount -t 'extX' /dev/sda3 /var/media/ftp/YourFritz
[   47.090000][1]kjournald starting.  Commit interval 5 seconds
[   47.090000][0]EXT3-fs (sda3): using internal journal
[   47.090000][0]EXT3-fs (sda3): mounted filesystem with writeback data mode
cloudmsgd not running after started
[   47.220000][0][dma_device_write] auto open tx_chan_no:2
[   47.360000][1]start slab_allocator-trace now  (use cat /proc/slab_allocators)
1970-01-01 01:00:47 deviceinfod[3184]: ready (0sec)
execute /etc/init.d/E47-cpunet
execute /etc/init.d/E47-voip
[   47.820000][0][0]system-load 100% loadavg 1.86 0.48 0.16 - 99 tasks:63 % curr:ksoftirqd/0(1 %)max:ctlmgr(18 %, pid:2730) pgstat: sum=61068 free=38977 slab=4087 alloc=2798/s fault=5264/s ai_sys:0.60/s 0x804e72c8 skb_flow_dissect+0x1a8)
killall: ftpd: no process killed
[   49.510000][1][1]system-load 9 loadavg 1.86 0.48 0.16 - 100 tasks:23 % curr:multid(1 %)max:ctlmgr(4 %, pid:2730) pgstat: sum=61034 free=38160 slab=4136 alloc=412/s fault=524/s (sleep 4)
killall: inetd: no process killed
1970-01-01 01:00:50 tr069starter[3242]: ready (0sec)
telefon: SIGCHLD PID 3251 received!
telefon: SIGCHLD PID 3273 received!
killall: nmbd: no process killed
killall: inetd: no process killed
[   53.200000][0]lan: received packet on eth0 with own address as source address
[   53.200000][0]lan: received packet on eth0 with own address as source address
[   53.200000][0]lan: received packet on eth0 with own address as source address
[   53.200000][0]lan: received packet on eth0 with own address as source address
[   53.200000][0]lan: received packet on eth0 with own address as source address
[   53.200000][0]lan: received packet on eth0 with own address as source address
[   53.200000][0]lan: received packet on eth0 with own address as source address
[   53.200000][0]lan: received packet on eth0 with own address as source address
[   53.200000][0]lan: received packet on eth0 with own address as source address
[   53.200000][0]lan: received packet on eth0 with own address as source address
[   54.290000][0][DECTDRV_ERR] API_FP_MAC_START_STOP_REQ 255 -> 1
[   54.310000][0][DECTDRV_ERR] fpCap ext data queueSize 5120, avmTpui 4096/34305, etsiTpui 38401/2560
[   54.560000][1][module-alloc-by-name] give 0x43000 bytes at 0x817d0000 to module 'krtp' (0xfd000 total bytes left)
1970-01-01 01:00:54 voipd[3260]: ready (2sec)
execute /etc/init.d/E48-mesh
[   56.160000][1][module-alloc-by-name] give 0xb000 bytes at 0x81813000 to module 'ulpcmlink' (0xf2000 total bytes left)
playerd_tables, find MP3
[   56.200000][0]nla_init
[   56.200000][1]nla_init-Success
playerd_tables, /var/tmp/ffmpeg_mp3.tables written
[   57.860000][0][0]system-load 100% loadavg 3.11 0.80 0.27 - 113 tasks:119 % curr:ksoftirqd/0(6 %)max:ctlmgr(20 %, pid:2730) pgstat: sum=62553 free=32881 slab=4384 alloc=1962/s fault=2765/s ai_sys:1.20/s 0x804e72c8 skb_flow_dissect+0x1)
Mounting [WDCWD25-00BEVE-00WZT0-01] to device /dev/sda1...
MOUNT: use blkid to get device /dev/sda1 data
[   59.110000][1][ifx_hsnand_command] read block is critical (column: 0x0 page: 0x2b0f)
[   59.280000][0]net_ratelimit: 102 callbacks suppressed
[   59.280000][0]lan: received packet on eth0 with own address as source address
[   59.290000][0]lan: received packet on eth0 with own address as source address
[   59.290000][0]lan: received packet on eth0 with own address as source address
[   59.290000][0]lan: received packet on eth0 with own address as source address
[   59.300000][0]lan: received packet on eth0 with own address as source address
[   59.300000][0]lan: received packet on eth0 with own address as source address
[   59.300000][0]lan: received packet on eth0 with own address as source address
[   59.300000][0]lan: received packet on eth0 with own address as source address
[   59.300000][0]lan: received packet on eth0 with own address as source address
[   59.300000][0]lan: received packet on eth0 with own address as source address
MOUNT: filesystem type is: swap
MOUNT: try to add swap
[   59.630000][1][1]system-load 100% loadavg 3.11 0.80 0.27 - 115 tasks:29 % curr:meshd(2 %)max:feedd(4 %, pid:3330) pgstat: sum=62595 free=31576 slab=4409 alloc=498/s fault=598/s (sleep 7)
MOUNT: swap added
[   59.720000][0]Adding 2097148k swap on /dev/sda1.  Priority:-1 extents:1 across:2097148k
2018-11-14 21:04:52 meshd[3321]: ready (1sec)
group 4 done ...

Wenn ich selbst hier irgendetwas suchen sollte, würde ich mit der "libctlmgr" beginnen - die soll ja als Hook für die Benutzerverwaltung des "ctlmgr" dienen und bedient sich des "preloadings" über "LD_PRELOAD" für die C-Library (neue Version uClibc-ng 1.0.14 seit 07.0x), um die "rename"-Funktion zu überladen. Da braucht bloß irgendwas im Interface der C-Library nicht mehr wie bisher funktionieren (ich habe die beiden "rename"-Implementierungen (https://git.uclibc.org/uClibc/tree/libc/sysdeps/linux/common/rename.c vs. https://github.com/wbx-github/uclibc-ng/blob/master/libc/sysdeps/linux/common/rename.c) nicht weiter untersucht, nur grob verglichen) und es knallt beim Überlagern.

Das kennt sicherlich jeder, der solche Libs zum Erkunden fremder Software ohne Quellen einsetzt und damit Funktionsaufrufe protokollieren läßt, zur Genüge, daß das immer eine "echte Fummelei" ist, so etwas korrekt zu überlagern, auch wenn hier die Aufrufparameter nicht erst geraten werden müssen für das "rename".

Das vermute ich aber alles auch nur aus der Überlegung heraus, wo sich der "ctlmgr" in Freetz von dem originalen bei AVM unterscheiden könnte und was den dazu veranlassen könnte, daß eine gestartete Aktivität (für die ja auch etwas mehr Zeit eingeplant war, denn 168 Sekunden wären schon ein deutliche Zeitspanne - wenn auch eine "ziemlich krumme") nicht rechtzeitig beendet wurde. Etwas komisch (und wieder in den Zusammenhang mit LD_PRELOAD und dem DSO-Handling passend) finde ich aber auch diese Zeile im "back-trace":

[bt] caller return <= _ftext: 00000000 00000000 (?)

... wobei ich keine Lust habe, mir das von AVM verwendete Backtrace-Modul, aus dem dieser Dump ja stammen muß, genauer anzusehen. Das kann also genauso gut auch eine wunderbare Sackgasse sein, in die ich da steuern würde - das ist nun mal Schicksal bei solchen Fehleranalysen, wenn man die Quellen der Software nicht kennt.

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

Gestartet wird der "ctlmgr" jedenfalls in etwa zu diesem Zeitpunkt (hier taucht er in Sekunde 37 das erste Mal bei der Auslastung auf) und bis zum Ende von "group 4" ist er auch einigermaßen gut beschäftigt ... in irgendeinem Thread wirft er wohl einen Watchdog für eine Aktivität an, die verzögert zum Abschluß kommen müßte und das aber nach diesen ominösen 168 Sekunden noch nicht getan hat. Ein Kandidat könnte aber auch der "avmnexusd" sein oder der "wland" - beide starten in etwas zum fraglichen Zeitpunkt und die wären ja auch neu (bzw. heftigst überarbeitet von AVM) seit der 06.93.

Andererseits kann das auch so etwas simples wie ein fehlschlagendes "mount" für ein Volume sein, weil das Fehler hat ... worauf der "ctlmgr" genau ein Auge wirft im Startprozess, ist ja weitgehend nur durch Deduktion zu ermitteln und die Zeitspanne, bis der Watchdog auslöst, paßt ja eher zu längeren Aktionen, die keine definierte Dauer haben - dazu gehört das Mounten von mehreren Volumes eben auch.

Ich würde hier also auch die größten Variablen mal aus dem Spiel nehmen - dazu gehört dann der gesamte USB-Stack (bei einer 7490 braucht man (auch mit "externals") ja nicht unbedingt ein solches Volume), auch wenn der asynchron über den "udevd" weiterläuft nach dem Starten desselben.

Außerdem hat AVM bei der 07.0x am Startvorgang dahingehend geändert, daß die Ausführung der letzten Schritte jetzt etwas anders erfolgt ... falls es doch der initiale Watchdog füt den Boot-Prozess sein sollte - wobei der eigenttlich so gg. Sekunde 10-11 gestartet werden sollte mit 240 Sekunden, nachdem der Kernel so gg. Sekunde 6-7 initialisiert ist; also das "rootfs" ist gemountet (hier bei der 7490 ist das der Wrapper) und der "unused kernel memory" aus der Initialisierung wird freigegeben. Damit kann es der hier:

[   10.940000] AVM_WATCHDOG: System Init Ueberwachung 240 Sekunden

eigentlich nicht sein, denn der wäre nach 212 Sekunden total (wovon noch mal die knapp 11 Sekunden abgehen für den Zeitpunkt, wann der überhaupt aktiviert wurde - dann sind wir eher bei 200 Sekunden) noch etwas sehr früh dran. Damit glaube ich erst mal auch nicht wirklich an ein Problem, bei dem der Initialisierungsprozess nicht zum Ende kommt.

 

[hermann72pb]

Danke für die ausführliche Aufklärung! Mit 168 Sekunden habe ich nicht so tief gedacht. Man liest erstmal die Zahl und denkt, sie würde schon stimmen. 3 Minuten und noch ein Paar Sekunden passen eher (aus dem Zeitstempel). Denn WebIF von FREETZ wird bis dahin geladen, auch dropbear dnsmasq und ein Paar weitere Pakete sind gestartet und geladen. Es könnte natürlich sein, dass ich einfach zu viele Pakete habe, sodass diese 168 Sekunden einfach dafür nicht ausreichen, dass alles geladen ist und ctlmgr den nächsten Stoss dem watchdog gibt.
Was mir natürlich bei der Suche helfen würde: Wenn ich durch irgendeinen nicht dokumentierten Befehl den watchdog händisch anstoßen könnte. Irgendwie "ctlmgr xxx yyy" oder so ähnlich.
Wir weichen aber hier vom eigentlichen Thema des Threads mächtig ab. Das stimmt schon. Macht es Sinn, diese Diskussion irgendwo separat auszulagern?
Ich würde ja gerne meine Erkentnisse in einem Trac-Ticket verewigen, wenn Trac denn funktionieren würde...

EDIT: Neue Erkenntnisse. Es scheint callmonitor zu sein. Wobei es mir schon seit Anfang an gelungen war, den Start von Callmonitor als Dienst auf "manuell" umzustellen, sodass es eigentlich nicht gestartet wird. Beim ersten Laden der Pakete werden da aber wahrscheinlich einige Initialisierungen vom Callmonitor ausgefüht, die anscheinend ins Leere gehen, sodass rc.S nicht beendet wird.
Hier ist der Auszug aus dem ps:

 4752 root      1356 S    {rc.callmonitor} /bin/ash /etc/init.d/rc.callmonitor
 4798 root      1472 S    {phonebook} /bin/ash /usr/bin/phonebook init
 4816 root      1348 S    {sipnames} /bin/ash /mod/pkg/callmonitor/usr/lib/callmonitor/sipnames
 4829 root      1472 S    {phonebook} /bin/ash /usr/bin/phonebook --local exists
[email protected]
 4840 root      1472 S    {phonebook} /bin/ash /usr/bin/phonebook --local exists
[email protected]
 4842 root      1472 S    {phonebook} /bin/ash /usr/bin/phonebook --local exists
[email protected]
 4843 root      1472 S    {phonebook} /bin/ash /usr/bin/phonebook --local exists
[email protected]
 4846 root      1392 S    {busybox} cat
 4847 root      1472 S    {phonebook} /bin/ash /usr/bin/phonebook --local exists
[email protected]
 4848 root      1472 S    {phonebook} /bin/ash /usr/bin/phonebook --local exists
[email protected]
 4849 root      1472 S    {phonebook} /bin/ash /usr/bin/phonebook --local exists [email protected]
 4850 root      1472 S    {phonebook} /bin/ash /usr/bin/phonebook --local exists [email protected]
 4851 root      1344 S    {busybox} sed -n -e  /keine Tarife gespeichert/ { s/.*/NA:/; p; q } s/^.*zur Rufnummer[^[]*\[\([^]]*\)\].*$/\1/ t found b :found  s
 4854 root      1404 S    {busybox} wget -U callmonitor/98d3ccce65 http://www.billiger-telefonieren.de/vorwahlrechner/?num=000ZENSIERT00000000000 -q -O -

Ich hatte dann rc.callmonitor gekillt und auch die phonebook-Prozesse. Dies führte dazu, dass rc.S anscheinend durchlaufen konnte. Vorher hatte ich etwas radikaler versucht rc.S zu killen. Dies hatte aber zu keinem Erfolg geführt. Anschliessend konnte ich über FREETZ WebIF sehen, dass alle Pakete geladen wurden und die, die auf "auto" standen auch als Dienst gestartet. Selbst FREETZMOUNT mit dem "mount by label" lief erfolgreich über alle Partitionen des USB-Sticks (ext, fat, swap) durch. Also, entweder habe ich zu viele externe Nummern und Callmonitor einfach zu lange braucht, sich mit all diesem Nummern zu initialisieren oder es gibt grundsätzlich irgendein Problem mit dem Callmonitor. Ich werde es näher untersuchen und evtl. eine Firmware ohne callmonitor bauen, für dieses Thread ist es aber definitiv OT. Openvpn konnte ich übrigens dann auch als Dienst starten. Ob OpenVPN auch richtig funktioniert, muss ich noch testen.

MfG

 

[dipsy]

Hallo,
ich hab es getestet und hatte auch Erfolg bis ich feststellen musste, dass laut syslog keine komplettes DHCP Paket vom Wlan an dnsmasq übergeben wird. Damit wäre das Wlan der Box für mich nicht nutzbar. Ich hänge mal meine . config an. Gern kann ich auch das Image bereitstellen.

greetz dipsy

 

[slashxxx]

Ich habe den OpenVPN Client auf einer FritzBox 6490 Freetz 7.01 laufen.. hier gibt es keine Probleme und ist sehr stabil. Ich dachte dieses BUG_ON "Feature" ist in allen neues OS vorhanden. Falls es hilft, kann ich gerne logs zur Verfügung stellen.

Zur 7590 gibt es noch nicht neues oder? :/

 

[PeterPawn]

Die Puma-Boxen haben mit der 07.0x keinen neuen Kernel gekriegt - damit auch die Änderung im Code für das Senden von Paketen nicht.

 

[PeterPawn]

Ich habe mir das Thema mit dem "BUG_ON" von AVM noch einmal angesehen und dafür ein Shell-Skript eingecheckt, was in der Lage sein sollte, diese beiden Statements live aus dem laufenden Kernel herauszupatchen: https://github.com/PeterPawn/YourFritz/blob/master/patch_kernel/patch_netif_receive_functions

Damit kann man (a) auch bei dern GRX-Boxen, wo Freetz noch kein "replace kernel" unterstützt und (b) auch bei den VR9-Modellen ohne "replace kernel" versuchen, sein eigenes OpenVPN-Paket zu benutzen.

Da man nicht 100% weiß, was den AVM-Kernelquellen noch alles fehlt (zumindest beim "avm_kernel_config"-Area ist das ja "bewiesen", daß AVM Teile nicht bereitstellt), ist das Ersetzen des Kernels auch immer ein gewisses Risiko, daß andere Probleme auftreten. Solange man den Kernel nur wegen dieser beiden "BUG_ON(skb->sk)"-Statements im AVM-Kernel ersetzen müßte, kann man dem Skript ja zumindest mal eine Chance geben.

Das ist nur der "erste Wurf" (man macht das besser mit einem kleinen Programm in C und nicht in Shell-Code) ... aber es funktioniert auch nur dann, wenn man beim Bau seiner BusyBox für das eigene Image auch das "devmem"-Applet hinzufügt - denn damit greift das Skript auf den Kernel-Speicher zu.

Kurz zur Arbeitsweise ... beim Übersetzen des BUG_ON-Makros entsteht der Code, mit dem der Inhalt des Feldes "sk" (die Socket-Nummer) aus der "skbuff"-Struktur, die beim Aufruf der betreffenden Kernel-Funktionen der einzige Parameter ist, in ein Register geladen wird. Welches Register das konkret ist, hängt von der Optimierung ab und davon, was der Compiler an dieser Stelle für die beste Wahl hält. Allerdings wird dann (weil hier die Ausnahme ausgelöst werden soll, wenn der Wert eben nicht 0 ist) für den Vergleich einfach ein

TNE zero, <register>, 12

verwendet, was in dem Moment eine "trap" (also eine Ausnahme) auslöst, wo der Inhalt von "<register>" nicht null ist - die "12" dient dem Handler nur noch zur Unterscheidung, welche Trap ausgelöst wurde. Das Format der Instruktion kann man sich z.B. hier ansehen (Seite 274): https://ti.tuwien.ac.at/cps/teaching/courses/cavo/files/MIPS32-IS.pdf

Das Skript geht also hin, sucht sich aus den Kernel-Symbolen die Adressen zu den Namen der beiden Funktionen, in denen das überflüssige "BUG_ON"-Statement enthalten ist (zu Nebenwirkungen, die sich aus dem Freetz-Patch oder eben aus diesem hier ergeben, ist m.W. noch nicht "geforscht" worden) und sucht - von dieser Adresse an - in einer (konfigurierbaren) max. Entfernung nach der TNE-Instruktion. Welches Register diese konkret vergleicht, wird dabei maskiert ... es funktioniert also immer auf demselben Weg, solange das erste Register ("rs" in der Beschreibung) das "leere" Register "zero" ist.

Findet es die TNE-Instruktion, wird sie durch ein "NOP" (4 Byte aus Nullen, das ist in Wirklichkeit ein Befehl "sll r0,r0,0", der nichts am Zustand des Systems ändert) ersetzt und die Verarbeitung beendet. Findet es hingegen zuerst diese NOP-Instruktion, wird davon ausgegangen, daß der Patch bereits angewendet wurde.

Das Skript durchsucht in seiner derzeitigen Form max. 10 MIPS-Instruktionen ab der jeweiligen Einsprungadresse und patcht sowohl die Funktion "netif_receive_skb" als auch "__netif_receive_skb".

Getestet habe ich bisher nur, daß dieses Patchen sowohl auf einer 7490 als auch auf einer 7580 fuinktioniert und es auch bei mehrfachem Aufruf keine Probleme bereitet. Ob und wie sich dieser Patch dann am Ende auswirkt bei irgendwelchen Treibern (vorzugsweise dem TUN-Driver für OpenVPN, um das es hier ja geht), habe ich noch nicht weiter getestet ... ich benutze nur selten OpenVPN auf FRITZ!Boxen.

Wer es sich also zutraut und die Hinweise berücksichtigt (in erster Linie den zum "devmem"-Applet, was bei Freetz nicht automatisch ausgewählt ist), kann ja mal versuchen, ob er mit diesem Patch (der dann natürlich vor dem Start von OpenVPN aufgerufen werden sollte - einmal pro Systemstart reicht aber, mehrere Male schaden auch nicht) sein OpenVPN auch auf GRX-Boxen wieder nutzen kann.

Wenn das funktionieren sollte, denke ich über das oben erwähnte C-Programm nach ...

 

[Whoopie]

Hi,

ich habe es mal ausprobiert, die FB crasht weiterhin.

Hier der Output des Skriptes:

root@SERVER:/var/mod/root# /tmp/flash/openvpn/patch_kernel.sh
Found symbol 'netif_receive_skb' at memory address 0x80A62474.
Looking for TNE instruction with max. distance of 10.
Found TNE instruction (0x00020336) at 0x80A62490, replacing it with a NOP (all bits zero means => sll r0,r0,0).
Found symbol '__netif_receive_skb' at memory address 0x80A623F0.
Looking for TNE instruction with max. distance of 10.
Found TNE instruction (0x00030336) at 0x80A623F8, replacing it with a NOP (all bits zero means => sll r0,r0,0).

Gruß,
Whoopie

 

[slashxxx]

Wow vielen Dank PeterPawn. Ich bin noch bis zum 23.12 im Urlaub und werde den Patch danach auf einer 7590 testen und Rückmeldung geben.