Aktueller Status zu iptables und Freetz?

Okay.

Dann müßt Ihr versuchen, die /make/iptables/standard-modules.in und die /make/iptables/config.in zunächst mal so händisch anzupassen, daß die benötigten Module für Eur'n Kernel 2.6.28.10 sicher gebaut werden.
Beispielsweise steht in der Config.in u.A.
Code:
config FREETZ_MODULE_ip_nat
	bool "ip_nat.ko"
	depends on FREETZ_KERNEL_VERSION_2_6_19 && FREETZ_REPLACE_KERNEL
Das wird mit Eur'm Kernel schonmal in der "Standard-Konfiguration" sicher nicht im Image landen.
 
Okay.

Dann müßt Ihr versuchen, die /make/iptables/standard-modules.in und die /make/iptables/config.in zunächst mal so händisch anzupassen, daß die benötigten Module für Eur'n Kernel 2.6.28.10 sicher gebaut werden.
Beispielsweise steht in der Config.in u.A.
Code:
config FREETZ_MODULE_ip_nat
	bool "ip_nat.ko"
	depends on FREETZ_KERNEL_VERSION_2_6_19 && FREETZ_REPLACE_KERNEL
Das wird mit Eur'm Kernel schonmal in der "Standard-Konfiguration" sicher nicht im Image landen.

Habe ich versucht, nun startet die Box nicht mehr. Ein derartiger Eingriff übersteigt meine Kenntnisse aber dann wohl auch, so dass ich wohl festhalten muss, da iptables und damit VOIP-routing über VPN derzeit wohl einfach nicht geht....
 
Das Modul ip_nat war nur ein Beispiel ...
Du brauchst auf jeden Fall das Modul nf_nat auf Deiner Box.

Schau Dir den von mir verlinkten Thread an, lade die Patche herunter und versuche, die Kernel-Config unter /make/linux/Config.iks.7390_06.01 enstprechend dem Patch anzupassen.
Danach ein neues make kernel-menuconfig und ein neues make. Im Idealfall landet dann nf_nat auf der Box und kann geladen werden. Desweiteren solltest Du dann auch das von Dir benötigte ipt_REDIRECT auf die Box bringen und laden können.
Das hat bisher offensichtlich für eine 7270v3 und eine 7360 funktioniert. Es ist zwar mit ein wenig TryAndError verbunden, aber es sollte wohl zu machen sein.
 
Also für die 7390 06.01 kann ich kurz NICHT-Funktion zurückmelden.
Es reicht bei mir ein Aufruf von "iptables -t nat -L" um die Box reproduzierbar zum Reboot zu bringen:

Code:
Jan  1 02:10:50 login[8087]: root login on 'pts/0'
[module-alloc-by-name] give 0xb000 bytes at 0x8166e000 to module 'nf_conntrack'
[module-alloc-by-name] give 0x1000 bytes at 0x81679000 to module 'nf_defrag_ipv4'
[module-alloc-by-name] give 0x3000 bytes at 0x8167a000 to module 'nf_conntrack_ipv4'
[module-alloc-by-name] give 0x4000 bytes at 0x8167d000 to module 'nf_nat'
[module-alloc-by-name] no kseg0-space for module 'iptable_nat' (0x2000 bytes) -> use ksseg
NOHZ: local_softirq_pending 08
CPU 0 Unable to handle kernel paging request at virtual address 00200200, epc == 8166e6c4, ra == 8166e6a8
Oops[#1]:
Cpu 0
$ 0   : 00000000 00000000 00100100 00200200
$ 4   : 859223c8 80373cc0 000f5101 00000100
$ 8   : 804b78e0 ffffffff 00000001 00000000
$12   : 00000001 fffbffff ffffffff ffffffff
$16   : 859223c8 8166e658 804c0000 859223c8
$20   : 804b80e8 00200200 804c0000 80373cc0
$24   : 00000006 8003f918                  
$28   : 80370000 80373c98 00000100 8166e6a8
Hi    : 000f14e8
Lo    : 40000000
epc   : 8166e6c4 __nf_conntrack_find+0x208/0x2b4 [nf_conntrack]
    Tainted: P          
ra    : 8166e6a8 __nf_conntrack_find+0x1ec/0x2b4 [nf_conntrack]
Status: 1100fc03    KERNEL EXL IE 
Cause : 8080000c exc_code:3 TLBS
BadVA : 00200200
epc   : 8166e6c4 __nf_conntrack_find+0x208/0x2b4 [nf_conntrack]
errepc: 810005e0 0x810005e0
    Tainted: P          
ra    : 8166e6a8 __nf_conntrack_find+0x1ec/0x2b4 [nf_conntrack]
PrId  : 0001964c (MIPS 24Kc)
Modules linked in: iptable_nat nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_conntrack ath_pktlog(P) umac userman_mod(P) ath_dev(P) ath_dfs(P) ath_spec)
Process swapper (pid: 0, threadinfo=80370000, task=80374000, tls=00000000)
Stack : 00000001 00000000 804b78e0 811343e8 804b78e0 8003fb74 00000000 003d0900
        000010db 066ff300 80373cc0 80373cc0 00000001 0000000a 00000100 804b0000
        804b0000 804b7778 804b7774 804c0000 804c0000 8003afdc 000010db 066ff300
        00000000 000010db 066ff300 063303a6 80380000 3b9aca00 063303a6 80379250
        000010db 80055778 00000000 80031808 86e6b880 79bfed5b 00000000 7fffffff
        ...
Call Trace:
[<8166e6c4>] __nf_conntrack_find+0x208/0x2b4 [nf_conntrack]


Code: ac430018  8e030060  8e02005c <10400002> ac620000  ac430004  8e030090  3c040020  8e02008c 
Call Trace:
[<802d0688>] dump_stack+0x8/0x38
[<802d07ac>] panic+0x44/0x220
[<8001c3c4>] die+0xd4/0xdc
[<8002290c>] do_page_fault+0x34c/0x5c0
[<80016580>] ret_from_exception+0x0/0x10
[<8166e6c4>] __nf_conntrack_find+0x208/0x2b4 [nf_conntrack]

Kernel panic - not syncing: Fatal exception in interrupt
WARNING: use tffs in panic mode (minor 96)
Rebooting in 5 seconds..
disabling IRQ's and enabling reset bit in all AP's

(AVM) EVA Revision: 1.819 Version: 1819
(C) Copyright 2005 AVM Date: Dec  2 2009 Time: 10:51:29 (1) 2 0x0-0x340D
 
Hallo Jörg,

benutzt Du denn das Modul nf_nat ?
Ich hatte es bei der Kernel-Anpassung für die 7270 (glaube ich) so gelöst, daß ich händisch nf_nat enabled hatte und dann die "Beschwerden" des Compilers über die weiteren Abhängigkeiten im Wesentlichen durch Akzeptieren der entsprechenden Module abgenickt hatte ...
 
Ja, das lädt die Box dann automatisch. Je nach Zustand kommt es dann sofort bis ein paar Sekunden (auch mal eine Minute) später zum Reboot :

Code:
root@fritz:/var/mod/root# 
root@fritz:/var/mod/root# dmesg | tail -n 10 ; echo "###lsmod" ; lsmod | grep -e 'ipt\|ip_t\|xt_\|nf_' ; echo -e "\n\n##### VOR ipta
bles mit NAT ####" ;iptables -t nat -L ; echo -e "\n\n##### NACH iptables mit NAT ####"  ;  dmesg | tail -n 10 ; echo "###lsmod" ;ls
mod | grep -e 'ipt\|ip_t\|xt_\|nf_'
 ieee80211_ioctl_siwmode: imr.ifm_active=66176, new mode=3, valid=1 
sc nodebug 0 
device ath1 entered promiscuous mode
lan: topology change detected, propagating
lan: port 2(ath1) entering forwarding state
system-load 100 % curr: ctlmgr runnable: 6
dfs_attach: use DFS enhancements
DFS min filter rssiThresh = 15
DFS max pulse dur = 151 ticks
stop_current_scan - control chan detects=0 extension channel detects=0 above_dc_detects=0 below_dc_detects=0
###lsmod


##### VOR iptables mit NAT ####
[module-alloc-by-name] give 0xb000 bytes at 0x8166e000 to module 'nf_conntrack'
[module-alloc-by-name] give 0x1000 bytes at 0x81679000 to module 'nf_defrag_ipv4'
[module-alloc-by-name] give 0x3000 bytes at 0x8167a000 to module 'nf_conntrack_ipv4'
[module-alloc-by-name] give 0x4000 bytes at 0x8167d000 to module 'nf_nat'
[module-alloc-by-name] give 0x2000 bytes at 0x81681000 to module 'iptable_nat'
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination         

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         


##### NACH iptables mit NAT ####
DFS min filter rssiThresh = 15
DFS max pulse dur = 151 ticks
stop_current_scan - control chan detects=0 extension channel detects=0 above_dc_detects=0 below_dc_detects=0
system-load 9 curr: ar7cfgctl runnable: 3
[module-alloc-by-name] give 0xb000 bytes at 0x8166e000 to module 'nf_conntrack'
nf_conntrack version 0.5.0 (1903 buckets, 7612 max)
[module-alloc-by-name] give 0x1000 bytes at 0x81679000 to module 'nf_defrag_ipv4'
[module-alloc-by-name] give 0x3000 bytes at 0x8167a000 to module 'nf_conntrack_ipv4'
[module-alloc-by-name] give 0x4000 bytes at 0x8167d000 to module 'nf_nat'
[module-alloc-by-name] give 0x2000 bytes at 0x81681000 to module 'iptable_nat'
###lsmod
iptable_nat             4688  0 
nf_nat                 14176  1 iptable_nat
nf_conntrack_ipv4      11264  3 iptable_nat,nf_nat
nf_defrag_ipv4          1184  1 nf_conntrack_ipv4
nf_conntrack           44992  3 iptable_nat,nf_nat,nf_conntrack_ipv4
root@fritz:/var/mod/root# CPU 0 Unable to handle kernel paging request at virtual address 00100140, epc == 8166e684, ra == 8003fb74
Oops[#1]:
Cpu 0
$ 0   : 00000000 00000000 00100100 00000080
$ 4   : 87a56618 87a56a54 ffffb747 1ff2b600
$ 8   : 3b9aca00 0000000d 6a1341a3 00000000
$12   : 7ffffe75 858eb324 ffffffff ffffffff
$16   : 87a56618 8166e658 804c0000 87a56618
$20   : 804b80e8 00200200 804c0000 80373d10
$24   : 00000005 8001f450                  
$28   : 80370000 80373ce8 00000100 8003fb74
Hi    : 000f1bb8
Lo    : 00000000
epc   : 8166e684 __nf_conntrack_find+0x1c8/0x2b4 [nf_conntrack]
    Tainted: P          
ra    : 8003fb74 run_timer_softirq+0x15c/0x20c
Status: 1100fc03    KERNEL EXL IE 
Cause : 00800008 exc_code:2 TLBL
BadVA : 00100140
epc   : 8166e684 __nf_conntrack_find+0x1c8/0x2b4 [nf_conntrack]
errepc: 80011cb0 fusiv_restart+0x1bc/0x1c4
    Tainted: P          
ra    : 8003fb74 run_timer_softirq+0x15c/0x20c
PrId  : 0001964c (MIPS 24Kc)
Modules linked in: iptable_nat nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_conntrack ath_pktlog(P) umac userman_mod(P) ath_dev(P) ath_dfs(P) ath_spectral(P) ath_rate_atheros(P) ath_hal(P) asf(P) adf(P) sch_sfq ulpcmlink(P) sch_llq sch_tbf avm_pa_fusiv(P) aae(P) kdsldmod(P) ohci_hcd ehci_hcd usbcore ramzswap lzo_compress lzo_decompress nls_utf8 vfat fat dect_io(P) avm_dect(P) capi_codec(P) isdn_fbox_fon5(P) pcmlink(P) Piglet_noemif(P) bmedrv(P) opensrc_lkm aclap_driver_lkm(P) sysKCode_lkm(P) ethdriver_lkm(P) periap_driver_lkm(P) timers_lkm(P) bmdriver_lkm(P) ap2ap_lkm(P) fusivlib_lkm(P) rtc_avm rtc_core led_modul_Fritz_Box_7390(P)
Process swapper (pid: 0, threadinfo=80370000, task=80374000, tls=00000000)
Stack : 804b9890 80373d38 804b78e0 0000000a 804b78e0 8003fb74 00000000 003d0900
        000000e1 1ff2b600 87a56a54 81135478 00000001 0000000a 00000100 804b0000
        804b0000 804b7778 804b7774 804c0000 804c0000 8003afdc 000000e1 1ff2b600
        00000000 000000e1 1ff2b600 1fb5ce0b 80380000 3b9aca00 1fb5ce0b 80379250
        000000e1 80055778 83040000 00010000 86e6b880 6e5bf566 00000000 7fffffff
        ...
Call Trace:
[<8166e684>] __nf_conntrack_find+0x1c8/0x2b4 [nf_conntrack]


Code: 00000000  0859b9a7  3c028004 <8c420040> 10400003  00000000  0040f809  00000000  3c028004 
Call Trace:
[<802d0688>] dump_stack+0x8/0x38
[<802d07ac>] panic+0x44/0x220
[<8001c3c4>] die+0xd4/0xdc
[<8002290c>] do_page_fault+0x34c/0x5c0
[<80016580>] ret_from_exception+0x0/0x10
[<8166e684>] __nf_conntrack_find+0x1c8/0x2b4 [nf_conntrack]

Kernel panic - not syncing: Fatal exception in interrupt
WARNING: use tffs in panic mode (minor 96)
Rebooting in 5 seconds..
disabling IRQ's and enabling reset bit in all AP's

(AVM) EVA Revision: 1.819 Version: 1819
(C) Copyright 2005 AVM Date: Dec  2 2009 Time: 10:51:29 (1) 2 0x0-0x340D

[FLASH:] MACRONIX Uniform-Flash 16MB 64 Bytes WriteBuffer
[FLASH:](Eraseregion [0] 128 sectors a 128kB) 
[SYSTEM:] IKANOS on 500MHz/166MHz
[RESERVED:] 0x6000000 - 0x6800000

Eva_AVM >
Eva_AVM >
 
Hm, schade .... :-/

Hast Du den packet accelerator an- oder abgeschaltet ? Und könntest Du das Ganze (vorbehaltlich Zeit und Lust) nochmal für die 84.05.53 testen ?
 
Hab beides versucht. Keine Änderung zu erkenne mit deaktiviertem PA.
Mal schauen, ob ich es bei Gelegenheit mit der "alten" ;-) FW versuchen kann.
 
Hallo,

mit 04.xx Firmware geht es sicher bei 7270 und 7390. Das habe ich auch schon getestet und stabil am laufen gehabt. Diese FW ist allerdings sehr alt. Beim Downgrade der 7390 auf 04.xx können Probleme auftretten!

ab 05.xx FW kollidiert das Modul nf_conntrack mit einem AVM Modul. So ist es anscheinend immer noch :( Sehr schade! Ich frage mich mittlerweile, ob es die Absicht von AVM ist...

Gruß
 
ab 05.xx FW kollidiert das Modul nf_conntrack mit einem AVM Modul. So ist es anscheinend immer noch :( Sehr schade!

Ja, das habe ich gerade auch leider entdeckt. Hatte mich gefreut, dass 05.xx anscheinend iptables anbietet, aber wieder nichts.... Sehr, sehr schade.
 
ab 05.xx FW kollidiert das Modul nf_conntrack mit einem AVM Modul

Vielleicht blöde Frage: Wird das Modul nf_conntrack überhaupt benötigt ? Mir ist klar, daß dieses bei der Standard-Konfiguration mit ausgewählt wird, sobald nf_nat mit ins Image soll (als Modul oder fest), aber was passiert denn, wenn ich dieses in der Kernel-Config der Box händisch disable ? Einfaches Beispiel: Ich dachte bisher auch, das xt_state nicht ohne conntrack funktionieren könnte, aber siehe da: Es wird doch geladen und REDIRECT und MASQUERADE funktionieren einwandfrei...

Edit: Ich habe die Kernel-Konfigurationen der 84.06.01 und meiner modifizierten 74.05.51/53 nochmal gedifft, und was mir im Netfilter-Teil auffiel war, daß in der 06er-Version viele einige Module direkt im Kernel waren, welche in der 05er-FW per default als Modul gebaut wurden. Ich hab' diese jetzt auch mal in der 06er als Modul bauen lassen, werde ein Image flashen und wieder berichten.
 
Zuletzt bearbeitet:
nf_contrack ist eins der Abhängigkeiten von nf_nat:
Code:
$ cat ./source/kernel/ref-ur8-7270_05.50/lib/modules/2.6.32.41/modules.dep | grep nf_nat
kernel/net/ipv4/netfilter/nf_nat.ko: kernel/net/ipv4/netfilter/nf_conntrack_ipv4.ko kernel/net/netfilter/nf_conntrack.ko kernel/net/ipv4/netfilter/nf_defrag_ipv4.ko
kernel/net/ipv4/netfilter/iptable_nat.ko: kernel/net/ipv4/netfilter/ip_tables.ko kernel/net/ipv4/netfilter/nf_nat.ko kernel/net/netfilter/x_tables.ko kernel/net/ipv4/netfilter/nf_conntrack_ipv4.ko kernel/net/netfilter/nf_conntrack.ko kernel/net/ipv4/netfilter/nf_defrag_ipv4.ko
kernel/net/ipv4/netfilter/ipt_MASQUERADE.ko: kernel/net/ipv4/netfilter/nf_nat.ko kernel/net/ipv4/netfilter/nf_conntrack_ipv4.ko kernel/net/ipv4/netfilter/nf_defrag_ipv4.ko kernel/net/netfilter/x_tables.ko kernel/net/netfilter/nf_conntrack.ko

das war auf der 7270 mit FW 05.50. So würde mich brennend interessieren, wie du es denn ohne nf_conntrack geschaft hast? oder ist es bei dir fest im Kern gewesen?
 
Ich dachte bisher auch, das xt_state nicht ohne conntrack funktionieren könnte, aber siehe da: Es wird doch geladen und REDIRECT und MASQUERADE funktionieren einwandfrei...
Das glaube ich nicht ganz, denn es wird zwar das Modul nicht geladen, aber du hast es auch fest in den Kernel hineinkompiliert, wie man an der dort angehängten Konfig sieht:
Code:
...
-# CONFIG_NF_CONNTRACK is not set
+CONFIG_NF_CONNTRACK=y
...
Beachte: mit "y" fest im Kernel, muss also nicht als Modul geladen werden (das wäre "m").

Ich muss allerdings gestehen, das ist noch ein Unterscheid zu meinen Tests, ich hatte es dabei als Modul gebaut.
Ich teste es bei Gelegenheit mal "fest drin".

EDIT:

Auf einer 7390 mit 05.53 geht es auch nicht. Conntrack als Modul: Reboot nach Laden des Moduls wie oben bei 06.01 zu sehen.
Config wie bei dir (conntrack fest gewählt): Box startet nicht und stürzt gleich mit "conntrack" Fehler ab:
Code:
...
Loglevel set to 4
[module-alloc-by-name] give 0x3000 bytes at 0x814bc000 to module 'asf'
[module-alloc-by-name] give 0x76000 bytes at 0x814bf000 to module 'ath_hal'
[module-alloc-by-name] give 0xd000 bytes at 0x81535000 to module 'ath_rate_atheros'
[module-alloc-by-name] give 0xf000 bytes at 0x81542000 to module 'ath_spectral'
[module-alloc-by-name] give 0xe000 bytes at 0x81551000 to module 'ath_dfs'
[module-alloc-by-name] give 0x31000 bytes at 0x8155f000 to module 'ath_dev'
rc.mod version freetz-devel-11538M
[module-alloc-by-name] give 0x94000 bytes at 0x81590000 to module 'umac'
crond is disabled.
AVM telnetd is started by phone, failed.
Starting Freetz webinterface ... done.
swap is disabled.
CPU 0 Unable to handle kernel paging request at virtual address 00200200, epc == 8021d834, ra == 8021d814
Oops[#1]:
Cpu 0
$ 0   : 00000000 00000000 00100100 00200200
$ 4   : 86b1d154 00000044 ffffffff 804b521c
$ 8   : 0000000a 0000002d 00000000 00000000
$12   : 00000000 aaaa0300 ffffff00 00000000
$16   : 86b1d154 872ff090 86a9e3a0 00000000
$20   : 802ac2e0 00000000 85053800 00000000
$24   : 00000000 8021d77c                  
$28   : 83208000 8320ba30 831a7d00 8021d814
Hi    : 00000004
Lo    : 00000000
epc   : 8021d834 destroy_conntrack+0xb8/0x14c
    Tainted: P          
ra    : 8021d814 destroy_conntrack+0x98/0x14c
Status: 1100fc03    KERNEL EXL IE 
Cause : 8080000c
BadVA : 00200200
PrId  : 0001964c (MIPS 24Kc)
Modules linked in: umac ath_dev(P) ath_dfs(P) ath_spectral(P) ath_rate_atheros(P) ath_hal(P) asf(P) adf ulpcmlink(P) aae(P) kdsldmod(P) ohci_hc)
Process rc.smbd (pid: 1525, threadinfo=83208000, task=83205b68, tls=00000000)
Stack : 5c279d47 802f1210 8320b954 00000000 831b06c0 801ea93c 80229cd0 80000000
        831b06c0 872ff090 831b06c0 801ea6f8 802ac2e0 00000000 85053800 00000000
        831b06c0 8022a038 831a7d00 8022a77c 00000000 8320ba90 86a9e000 80000000
        00000000 80229cd0 80000000 831b06c0 86a9e3a0 831a7d00 831b06c0 831a7d00
        831b06c0 86a9e3a0 00000000 802ac434 802ac2e0 00000001 8051287c 00000000
        ...
Call Trace:
[<8021d834>] destroy_conntrack+0xb8/0x14c
[<801ea93c>] skb_release_head_state+0xe8/0x164
[<801ea6f8>] __kfree_skb+0x14/0x120
[<8022a038>] ip_rcv_finish+0x368/0x3a8
[<802ac434>] br_handle_frame_finish+0x154/0x1b0
[<802b0fa0>] br_nf_pre_routing_finish+0x310/0x344
[<802b1b08>] br_nf_pre_routing+0x768/0x7b0
[<8021b4a8>] nf_iterate+0x90/0xfc
[<8021b5a8>] nf_hook_slow+0x94/0x140
[<802ac690>] br_handle_frame+0x200/0x250
[<801f0e2c>] netif_receive_skb+0x28c/0x3fc
[<801f1038>] process_backlog+0x9c/0x14c
[<801eff8c>] net_rx_action+0xb4/0x1fc
[<800443cc>] __do_softirq+0x90/0x180
[<80044504>] do_softirq+0x48/0x68
[<800447fc>] irq_exit+0x40/0x88
[<8001c6e0>] adi_6843_dispatch_irq+0x31c/0x3d0
[<80010e98>] plat_irq_dispatch+0xd8/0x100


Code: 2c620001  00028036  8e02002c <10400002> ac620000  ac430004  3c020010  24420100  ae02002c 
Call Trace:
[<80024df0>] dump_stack+0x8/0x34
[<8003eab4>] panic+0x44/0x220
[<80024ff4>] die+0xa4/0xd8
[<8002a92c>] do_page_fault+0x334/0x564
[<80010ec0>] ret_from_exception+0x0/0xc
[<8021d834>] destroy_conntrack+0xb8/0x14c
[<801ea93c>] skb_release_head_state+0xe8/0x164
[<801ea6f8>] __kfree_skb+0x14/0x120
[<8022a038>] ip_rcv_finish+0x368/0x3a8
[<802ac434>] br_handle_frame_finish+0x154/0x1b0
[<802b0fa0>] br_nf_pre_routing_finish+0x310/0x344
[<802b1b08>] br_nf_pre_routing+0x768/0x7b0
[<8021b4a8>] nf_iterate+0x90/0xfc
[<8021b5a8>] nf_hook_slow+0x94/0x140
[<802ac690>] br_handle_frame+0x200/0x250
[<801f0e2c>] netif_receive_skb+0x28c/0x3fc
[<801f1038>] process_backlog+0x9c/0x14c
[<801eff8c>] net_rx_action+0xb4/0x1fc
[<800443cc>] __do_softirq+0x90/0x180
[<80044504>] do_softirq+0x48/0x68
[<800447fc>] irq_exit+0x40/0x88
[<8001c6e0>] adi_6843_dispatch_irq+0x31c/0x3d0
[<80010e98>] plat_irq_dispatch+0xd8/0x100

Kernel panic - not syncing: Fatal exception in interrupt
WARNING: use tffs in panic mode (minor 96)
Rebooting in 5 seconds..system-load 100 % curr: rc.smbd runnable: 33

disabling IRQ's and enabling reset bit in all AP's

(AVM) EVA Revision: 1.819 Version: 1819
(C) Copyright 2005 AVM Date: Dec  2 2009 Time: 10:51:29 (1) 2 0x0-0x340D

[FLASH:] MACRONIX Uniform-Flash 16MB 64 Bytes WriteBuffer
[FLASH:](Eraseregion [0] 128 sectors a 128kB) 
[SYSTEM:] IKANOS on 500MHz/166MHz
[RESERVED:] 0x6000000 - 0x6800000

Fehlt noch der Versuch mit 06.01 und fest eingebautem conntrack, aber da habe ich offen gestanden auch wenig Hoffnung...
 
Zuletzt bearbeitet:
Hallo Jörg,

hattest Du Dir mal den Patch im ander'n Thread angeguckt ? Child_of_Sun hatte auch noch einen Patch für eine 7360 und die 53er-FW angehängt ....
Könnte es evtl. doch an den unterschiedlichen Kerneln liegen (2.6.32.41 vs. 2.6.28.10) ? Soll ich nochmal die Kernel-Config der 7270v3 anhängen ?
 
Ja, dort ist conntrack als Modul gewählt, das ging bei mir ja auch nicht.
Auch 6.01 mit fest eingebautem conntrack läuft nicht stabil, sondern rebootet nach kurzer Zeit, im Calltrace taucht immer was mit nf_conntrack auf :-(.

Vielleicht liegt es wirklich an der neueren Kenel-Version bei euren Tests..
 
Hmm, sch..e.

Wieso hat denn die "neuere" 7390 einen "älteren" Kernel als die 7270 ?
Gibt es irgendeine Konstellation einer 7390 mit der 53er-FW, die noch sinnvoll zu testen wäre ? Eigentlich braucht man das conntrack doch "nur" für stateful-Regeln, also etwas der Art
Code:
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
Wenn also nicht gerade ein FTP-Server auf der Box läuft oder man REDIRECT o.Ä. verwenden will, sollte es doch auch ohne xt_state usw. gehen ... (?)
 
Genau, conntrack braucht man immer wenn es "statefull" ist, und damit leider auch für die häufuge Anwendung NAT.

Und wenn es überhaupt gleichzeitig mit AVMs eigenem Konstrukt ("Generic connection tracking interface (AVM)") läuft, ist das eher "netter Zufall".
AVM schreibt dazu in der Hilfe:
Code:
This allows the use of a connection tracking with
a generic interface to access the connection tracking
entries. [B]Do not use together with NETFILTER connection
tracking.[/B]
(Hervorhebung von mir)
 
Zuletzt bearbeitet:
Okay, dann haben wir also bisher die 7360 und die 7270, auf der es zumindest mit einer 53er-FW läuft und eine 7390, mit der es weder mit einer 53er noch einer 6.01er-FW funktioniert.
Wäre dann noch interessant zu wissen, wie es mit einer 3270, einer 7240 und/oder 7330 läuft .... vorausgesetzt, die Kernel-These stimmt.
Leider besitze ich diese Boxen nicht...
 
Zuletzt bearbeitet:
Hallo zusammen,

kleines Update: Mit der Kernel-Config im Anhang bekomme ich seit heute Syslogs der Art:
Code:
Jan 15 20:58:08 fritz kern.warn kernel: CT not confirmed ct=96d7f7b8
Jan 15 20:58:08 fritz kern.warn kernel: CT not confirmed ct=96d7f7b8
Jan 15 20:58:08 fritz kern.warn kernel: CT not confirmed ct=96d7f7b8
Jan 15 20:58:08 fritz kern.warn kernel: CT not confirmed ct=96d7f7b8
Jan 15 20:58:08 fritz kern.warn kernel: CT not confirmed ct=96d7f7b8
Jan 15 20:58:08 fritz kern.warn kernel: CT not confirmed ct=96d7f7b8
Jan 15 20:58:08 fritz kern.warn kernel: CT not confirmed ct=96d7f7b8
Jan 15 20:58:08 fritz kern.warn kernel: CT not confirmed ct=96d7f7b8
Jan 15 20:58:09 fritz kern.warn kernel: CT not confirmed ct=94bbb548
Jan 15 20:58:09 fritz kern.warn kernel: CT not confirmed ct=94bbb548
Jan 15 20:58:09 fritz kern.warn kernel: CT not confirmed ct=94bbb548
Jan 15 20:58:09 fritz kern.warn kernel: CT not confirmed ct=94bbb548
Jan 15 20:58:09 fritz kern.warn kernel: CT not confirmed ct=94bbb548

Die Box befindet sich dann in einem "zombi-"artigen Zustand: Surfen aus dem Heimnetz ist sporadisch möglich, Zugriff von außen unmöglich. Die Telefonie funktioniert (teilweise).
Ich bin daraufhin in der Kerne-Konfig wieder einen Schritt zurück gegangen (ohne das Modul nf_nat) und werde wieder berichten.
Grüße,

JD.
 

Anhänge

  • Config.ur8.7270_05.21_defect.txt
    46.4 KB · Aufrufe: 0
Hallo zusammen,

ich hoffe, einen Schritt weiter gekommen zu sein. Eine entscheidende Rolle bei der Funktion eines ersetzten Kernels inklusive der Module nf_nat, nf_conntrack und/oder ipt_MASQUERADE und ipt_REDIRECT scheint die Kernel-Option CONFIG_NF_CONNTRACK_COMPAT zu spielen. Ist diese fest im Kernel aktiviert (CONFIG_NF_CONNTRACK_COMPAT=y), läuft zumindest meine 7270v3 stabil, ohne die im vorherigen Post genannten "Aussetzer".
Ich versuche das ganze in den nächsten Tagen nochmal mit einer 7360 und werde dann wieder berichten.
Grüße,

JD.

Edit:

Nach diesem und diesem scheint diese Option standardmäßig zum Linux-Kernel zu gehören.
Code:
config NF_CONNTRACK_PROC_COMPAT
	bool "proc/sysctl compatibility with old connection tracking"
	depends on NF_CONNTRACK
	default y
	help
	  This option enables /proc and sysctl compatibility with the old
	  layer 3 dependant connection tracking. This is needed to keep
	  old programs that have not been adapted to the new names working.

	  If unsure, say Y.

In den aktuellen Kernel-Configs für die 7270v3 (05.21, 05.51) und der 7360 (05.51) taucht sie allerdings garnicht erst auf....
 
Zuletzt bearbeitet:

Statistik des Forums

Themen
246,171
Beiträge
2,247,421
Mitglieder
373,714
Neuestes Mitglied
Panicmaker
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.