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
