Re: brctrl: nf_hook: hook 0 already set
On Friday 13 April 2007 18:33, Gerhard Brauer wrote:
> Gruesse!
>
> * Michael Renner <michael.renner@gmx.de> schrieb am [13.04.07 15:10]:
> > Ich hab' auf einem anderen Rechner etwas vergleichbares mit usb0 laufen,
> > ohne Probleme. Die 30 Sekunden waren schon lange vorbei. Es geht so los:
> > cassiopeia:~# ifconfig eth0 up
> > br0: port 1(eth0) entering learning state
> > cassiopeia:~# br0: port 1(eth0) entering forwarding state
> > br0: topology change detected, propagating
> > nf_hook: hook 0 already set.
> > skb: pf=2 (unowned) dev=br0 len=56
> > PROTO=17 192.168.5.95:1126 192.168.5.53:53 L=56 S=0x00 I=56468 F=0x0000
> > T=64 nf_hook: hook 0 already set.
> > skb: pf=2 (unowned) dev=br0 len=84
> > PROTO=1 192.168.5.92:0 192.168.5.53:0 L=84 S=0x00 I=591 F=0x4000 T=64
> > nf_hook: hook 0 already set.
> > skb: pf=0 (unowned) dev=br0 len=46
> > nf_hook: hook 0 already set.
> > skb: pf=0 (unowned) dev=br0 len=46
> > nf_hook: hook 0 already set.
> > skb: pf=2 (unowned) dev=br0 len=66
> > PROTO=6 72.51.38.140:8118 192.168.5.53:34867 L=66 S=0x00 I=21080 F=0x4000
> > T=109
> > nf_hook: hook 0 already set.
> >
> > Der .53 ist der Rechner auf dem die Bridge laufen soll (cassiopeia), die
> > anderen sind andere Rechner im Netz.
>
> Eigentlich ist dein Vorgehen AFAIK richtig. Zu diesen Meldungen:
> ist das ein selbstgebauter Kernel?
Ja, ein guter Hinweis, Danke! Daher also der Müll auf der Console. Jetzt sieht
es schon ruhiger aus. Es funktioniert einfach nicht, die Console ist aber
lesbar.
> Laut http://tldp.org/HOWTO/Ethernet-Bridge-netfilter-HOWTO-2.html kommen
> diese Meldungen nur, wenn CONFIG_NETFILTER_DEBUG gesetzt ist, was in den
> Debian-Standard-Kerneln nicht der Fall ist.
> Wenn da netfilter-seitig auf dem Rechner gefiltert wird, evtl. das Modul
> für gebridgtes Netfilter vergessen/nicht geladen? Kannst du netfilter
> (wenn es denn überhaupt) läuft zum Test abschlaten?
Ne, das läuft nicht.
> Hast du ip_forward eingeschaltet?
cassiopeia:~# cat /proc/sys/net/ipv4/ip_forward
0
> Hast du die Route(n) auf das Device br0 gesetzt?
Hhm, guter Punkt. Da es schon im internen Netz nicht funktionierte hab ich die
Route nach draussen gar nicht gesetzt. Nach einigem Spielen bin ich nun
soweit:
br0 bekommt eine IP im selben Subnet 192.168.5.210 (eigentlich nicht geplant)
eth0 bekommt eine Adresse in einem anderen Class-C-Netz (192.168.8.53). Damit
ergibt sich folgendes Bild:
cassiopeia:~# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.5.0 0.0.0.0 255.255.255.0 U 0 0 0 br0
192.168.8.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
0.0.0.0 192.168.5.1 0.0.0.0 UG 0 0 0 br0
Damit lässt sich nach draussen pingen. Und von anderen Rechnern im Netz
192.168.5.0/24 komme ich auf cassiopeia (jetzt mit der IP 192.168.8.53) eine
Verbindunge, vorausgesetzt, das Routing wird verbogen:
lyra:~# route add -net 192.168.8.0 netmask 255.255.255.0 gw 192.168.5.92
Sobald der Server aber seine ursprüngliche IP bekommt (192.168.5.53) ist's
wieder aus. Gleiches, wenn br0 in das Netz 192.168.8.0/24 kommt.
Das ist doch nicht Sinn einer Bridge? Das sieht eher nach klassishen Routing
aus (auch wenn IP Forward abgeschaltet ist). Irgendwo mache ich einen
Denkfehler!
Hast du noch Ideen?
Danke
--
|Michael Renner E-mail: michael.renner@gmx.de |
|D-81541 Munich Germany ICQ: #112280325 |
|Germany Don't drink as root! ESC:wq
Reply to: