iptables unter Freetz/7270

dsteinkopf

Mitglied
Mitglied seit
29 Jul 2005
Beiträge
263
Punkte für Reaktionen
0
Punkte
16
Hallo,

kann es sein, dass die Module nicht zum Kernel passen? Wie ich da drauf komme:

ich habe es jetzt geschafft, alle iptabes-Module zu laden (mittels insmod via NFS oder mit "export DS_MODULES_ALL=y" beim make).


Es schient erstmal alles zu funktionieren, bis mir auffiel, dass die Regeln sich total seltsam verhalten: Keine Matcht da wo ich es erwarten würde.


Mit "cat /dev/debug" kann man auch das Logging sehen (warum eigentlich nicht via syslog?). Hier ein Auszug:
Code:
<4>FORWARD-ACCEPT-INVALID IN=dsl OUT=lan SRC=1.110.13.89 DST=21.155.13.10 LEN=28723 TOS=0x0A PREC=0x00 TTL=108 ID=28718 DF MF FRAG:6253 PROTO=34 
<4>ACCEPT-FORWARD-default IN=dsl OUT=lan SRC=1.110.13.89 DST=21.155.13.10 LEN=28723 TOS=0x0A PREC=0x00 TTL=108 ID=28718 DF MF FRAG:6253 PROTO=34 
<4>FORWARD-ACCEPT-INVALID IN=dsl OUT=lan SRC=51.52.53.54 DST=55.56.57.64 LEN=3364 TOS=0x0A PREC=0x00 TTL=41 ID=9510 MF FRAG:1832 PROTO=48 
<4>ACCEPT-FORWARD-default IN=dsl OUT=lan SRC=51.52.53.54 DST=55.56.57.64 LEN=3364 TOS=0x0A PREC=0x00 TTL=41 ID=9510 MF FRAG:1832 PROTO=48 
<4>FORWARD-ACCEPT-INVALID IN=dsl OUT=lan SRC=51.52.53.54 DST=55.56.57.64 LEN=3364 TOS=0x0A PREC=0x00 TTL=41 ID=9510 MF FRAG:1832 PROTO=48 
<4>ACCEPT-FORWARD-default IN=dsl OUT=lan SRC=51.52.53.54 DST=55.56.57.64 LEN=3364 TOS=0x0A PREC=0x00 TTL=41 ID=9510 MF FRAG:1832 PROTO=48 
<4>FORWARD-ACCEPT-INVALID IN=dsl OUT=lan SRC=106.110.119.7 DST=38.134.140.24 LEN=27489 TOS=0x08 PREC=0x00 TTL=0 ID=5229 CE DF FRAG:2446 PROTO=0 
<4>ACCEPT-FORWARD-default IN=dsl OUT=lan SRC=106.110.119.7 DST=38.134.140.24 LEN=27489 TOS=0x08 PREC=0x00 TTL=0 ID=5229 CE DF FRAG:2446 PROTO=0 
<4>FORWARD-ACCEPT-INVALID IN=dsl OUT=lan SRC=101.58.32.105 DST=0.0.0.72 LEN=28526 TOS=0x02 PREC=0x40 TTL=45 ID=29797 DF MF FRAG:3700 PROTO=84 
<4>ACCEPT-FORWARD-default IN=dsl OUT=lan SRC=101.58.32.105 DST=0.0.0.72 LEN=28526 TOS=0x02 PREC=0x40 TTL=45 ID=29797 DF MF FRAG:3700 PROTO=84 
<4>FORWARD-ACCEPT-INVALID IN=dsl OUT=lan SRC=64.65.66.67 DST=0.0.0.72 LEN=12337 TOS=0x08 PREC=0x20 TTL=54 ID=12851 MF FRAG:5173 PROTO=55 
<4>ACCEPT-FORWARD-default IN=dsl OUT=lan SRC=64.65.66.67 DST=0.0.0.72 LEN=12337 TOS=0x08 PREC=0x20 TTL=54 ID=12851 MF FRAG:5173 PROTO=55 
<4>FORWARD-ACCEPT-INVALID IN=dsl OUT=lan SRC=64.65.66.67 DST=0.0.0.72 LEN=12337 TOS=0x08 PREC=0x20 TTL=54 ID=12851 MF FRAG:5173 PROTO=55 
<4>ACCEPT-FORWARD-default IN=dsl OUT=lan SRC=64.65.66.67 DST=0.0.0.72 LEN=12337 TOS=0x08 PREC=0x20 TTL=54 ID=12851 MF FRAG:5173 PROTO=55

Da stimmt quasi gar nichts: IPs, Protokolle haben mit dem was tatsächlich passiert, nichts zu tun.


Daher meine Theorie, dass da irgendein Header-File nicht stimmt, sodass die Struktur, die bei iptables ankommt und ein Paket beschreibt, falsch interpretiert wird.

Oliver, Du hast ja was geschrieben (s. http://www.freetz.org/ticket/4), dass die Quellen für die 7270 so nicht stimmen - das nährt meine Theorie. Was genau meinst Du damit? Wie ist das denn genau mit den FritzBox-Kernel-Quellen?


Sonst irgendeine Idee?


Dirk
 
Interessant ist noch, dass bei
Code:
cat /proc/net/ip_conntrack
die auftauchenden IP-Nummern stimmen, aber keiner der Ports. Und es sind viel zu viele Einträge.

D.h. auch hier wird etwas missinterpretiert - aber anders :-(


Dirk
 
Ich kenne mich leider nicht genug mit iptables aus, um hier eine Diagnose zu stellen. Das ganze könnte natürlich wieder mit den AVM-Dämons usw. zu tun haben.

MfG Oliver
 
Wie ist das denn mit den Kernel-Quellen?
Kann es sein, dass der laufende Kernel eine andere Version hat als die Quellen, die wir zur Erzeugung der Module verwenden?


Dirk
 
Nein. Dann würden die Module nicht laufen.

MfG Oliver
 
Du schließt das vermutlich aus der Versionstrings (das Problem hatten wir ja schon...). Meinst du also, dass man sich darauf verlassen kann?

Was meintest du dann mit "AVM hat was am Kernel der 7270 geändert"?


Dirk
 
Meine Vermutung ist, daß doch irgend etwas zwischen Kernel und Modulen nicht stimmt. Möglicherweise aufgrund unterschiedlicher Konfiguration. Wenn ich mich richtig erinnere, habe ich auch irgendwo gelesen, daß die genaue Konfiguration des AVM Kernels nicht bekannt ist.
 
@Ralf
Das könnte sein. Gerade der Switch hat bei den letzen Versuchen noch nicht funktioniert. Der fehlende Header ist wohl eher für den Telefonieteil zuständig und sollte nichts mit iptables zu tun haben. Und eine .config war im Open Source Package leider nicht dabei. Dummerweise hatte ich AVM diesbezüglich eine falsche Mail geschrieben... :confused:

MfG Oliver
 
Der hier.

MfG Oliver
 
Ich habe jetzt mal "DS_REPLACE_KERNEL=y" per Hand ins .config gesetzt und mit kernel-dirclean ... alles neu gebaut. Es erscheint auch korrekt
Code:
...
replacing kernel
  replacing kernel-8mb_26-7270 (iln6)
...
...und alles scheint in Ordnung.

Kann ich dieses Image jetzt einfach mal probieren oder habe ich ein Problem, von dem ihr in dem Ticket redet, das ich nicht sehe?



Dirk
 

Anhänge

  • config_dsteinkopf_7270_replace_kernel.gz
    3.4 KB · Aufrufe: 5
"replace kernel" ist deaktiviert, da der selbstgebaute Kernel nicht läuft. Wenn du mir das nicht glaubst, dann kannst du das Image gerne flashen und es selbst merken.

MfG Oliver
 
Sorry, es geht nicht darum, ob ich Dir was glaube - wenn ich Dich eindeutig verstehe, dann glaube ich das natürlich.

Was du schreibst, war ja genau meine Frage: Ob ich auf diese Weise einen Kernel bekomme, der nicht funktioniert, obwohl keine Fehlermeldung kommt. Aber das hast Du mir ja hiermit eindeutig beantwortet.

Ich such halt verzweifelt nach einer Idee...


Dirk
 
Das merk ich.
Aber ohne genaue Kentnisse (.config die wir nicht haben, usw.) wirst du nicht weit kommen. Wenn das Problem einfach wäre, dann hätte ich es gelöst. ;-)

MfG Oliver
 
Kann eigentlich jemand das Problem bestätigen oder widerlegen? Wäre interessant, ob nur ich das Problem habe.


Dirk
 
Weiterer Hinweis für die .config des 7270 Kernels (AVM version .54):

Module "iptable_nat" konnte nicht geladen werden, weil das Symbol "ip_xfrm_me_harder" nicht gefunden wurde. Das Symbol wird nur verwendet, wenn die Option CONFIG_XFRM gesetzt ist, was beim release r1895 auf Y steht. Man kann mit "make kernel-menuconfig", Networking - Networking Options die drei Options "IP: IPsec transport mode", "IP: IPsec tunnel mode" und "IP: IPsec BEET mode" abwählen, dann wird auch CONFIG_XFRM nicht gesetzt.

"make kernel-clean" und "make".

Vermutlich ist im AVM-Kernel die Option auch nicht gesetzt. Vielleicht löst das ja auch andere Probleme...

Alle iptables Module laden jetzt bei mir - die *Funktion* der Filter habe ich nicht getestet.

E.
 
Danke. Habs in r1898 gefixt.

MfG Oliver
 
Danke.
Ich habe das mal bei mir probiert. Leider hat es keine Änderung im beschriebenen Fehlverhalten gebracht. Aber trotzdem würde mich interessieren, wie es bei Dir, Eval, aussieht.

Dirk
 
Mein Posting und die Änderung bezogen sich nur auf die Meldung von Elvar.

MfG Oliver
 
Schon klar. Trotzdem hätte es ja sein können, dass diese Option noch andere (positive) Nebenwirkungen hat.


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