Op di, 31-05-2005 te 21:17 +0200, schreef Louis Croisez:
> I am currently debugging. To have idea of where is the network packet
> in the stack, I use the ebtables/iptables log feature, that show the
> traject of a packet.
> Here is the result of my last test.
> Goal:
>             [PC_A] ping [PC_B] thru [ARM].
> Result:
>             icmp request is even not sent, because first an arp
> request is broadcast on the lan to resolve PC_B hw address. Problem is
> that this arp request never reach PC_B. It is stopped inside ARM.
> Here is the path followed by this packet:
> ebt:BRoute:BRouting
> ebt:Nat:PreRouting
> ipt:Mangle:PreRouting
> ipt:Nat:PreRouting
> ebt:Filter:Input
> 
> I don't understand this behavior of the Bridgin Decision... The arp
> request is a broadcast. It should  not be kept only by br0.
> 
> To workaround this, I have set br0 to promisc mode.
> The result of the test is the following:
> ebt:BRoute:BRouting
> ebt:Nat:PreRouting
> ipt:Mangle:PreRouting
> ipt:Nat:PreRouting
> ebt:Filter:Input
> ebt:Filter:Forward
> ipt:Mangle:Forward
> ipt:Filter:Forward
> ebt:Nat:PostRouting
> 
> The packet is stopped here. I don't know why!!
> 
> I feel there is a config problem, because it cannot be a bridge source
> problem, or a bug.
> I thing about some /proc configuration related to arp. Do you have an
> idea?

Just my 2 cents: make sure arptables doesn't drop the ARP packets...

cheers,
Bart


_______________________________________________
Bridge mailing list
[email protected]
http://lists.osdl.org/mailman/listinfo/bridge

Reply via email to