iptables unter Freetz/7270

dsteinkopf · 15 Feb 2008

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

dsteinkopf · 15 Feb 2008

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

olistudent · 15 Feb 2008

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

dsteinkopf · 15 Feb 2008

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

olistudent · 15 Feb 2008

Nein. Dann würden die Module nicht laufen.

MfG Oliver

dsteinkopf · 15 Feb 2008

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

RalfFriedl · 15 Feb 2008

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.

olistudent · 15 Feb 2008

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

MfG Oliver

RalfFriedl · 15 Feb 2008

Welcher Switch?

olistudent · 15 Feb 2008

Der hier.

MfG Oliver

dsteinkopf · 15 Feb 2008

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

olistudent · 15 Feb 2008

"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

dsteinkopf · 15 Feb 2008

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

olistudent · 15 Feb 2008

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

dsteinkopf · 20 Feb 2008

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

Dirk

Elvar · 22 Feb 2008

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.

olistudent · 22 Feb 2008

Danke. Habs in r1898 gefixt.

MfG Oliver

dsteinkopf · 23 Feb 2008

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

olistudent · 23 Feb 2008

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

MfG Oliver

dsteinkopf · 23 Feb 2008

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

Dirk

iptables unter Freetz/7270

Mitglied

Mitglied

IPPF-Urgestein

Mitglied

IPPF-Urgestein

Mitglied

IPPF-Urgestein

IPPF-Urgestein

IPPF-Urgestein

IPPF-Urgestein

Mitglied

Anhänge

IPPF-Urgestein

Mitglied

IPPF-Urgestein

Mitglied

Neuer User

IPPF-Urgestein

Mitglied

IPPF-Urgestein

Mitglied

Statistik des Forums