Hi Stephen, first of all, thx for helping me :o) 2005/5/31, Stephen Hemminger <shemminger@xxxxxxxx>: > > On Mon, 30 May 2005 11:38:59 +0200 > Louis Croisez <louis.croisez@xxxxxxxxx> wrote: > > > Hi, > > i want to implement the bridging feature on an arm (cpu intel ixp425), > > running busybox+linux kernel 2.6.11. > > For this, I have recompiled the kernel to enable bridging and ebtables, > and > > I have compiled and installed brctl utility for arm. > > > > Here is my network setup: > > [PC_A] eth0 10.0.0.10/24 <http://10.0.0.10/24> ======== eth0 --+-- eth1 > ======== [PC_B] eth0 10.10.0.1/24 <http://10.10.0.1/24> > > | > > br0 > > [ARM] > > What is IP address of bridge? (br0) or do you not > want the ARM box to be IP accessible? It is not well sure that the bridge is to be accessible. But it is not forbidden. In fact, a requirement is that the bridge worked with or without IP address on br0 iface. On my linux bridge test box, whether to have or not an IP on br0 does not makes the difference. > > > Here is how I setup my bridge on the ARM: > > brctl addbr br0 > > brctl addif br0 eth0 > > brctl addif br0 eth1 > > brctl setfd br0 1 > why set forwarding delay so low, please don't Could please you explain me the consequence of setting this parameter too low? > ifconfig eth0 promisc > Don't do this you don't need to, unless something is > broken in driver. 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? Concerning ICMP packets, I have verified that the bridge is well working with it, because if I set static ARP information inside PC_A and PC_B, the bridge is working well, whether an IP is defined on br0 or not. > ifconfig eth1 promisc > > ifconfig eth0 0.0.0.0 <http://0.0.0.0> > What is http:// stuff? some filter got it? > expect: > ifconfig eth0 0.0.0.0 <http://0.0.0.0> > to bring up without IP address Don't worry, it is some auto-formatting added by gmail smtp engine. I had well encoded 0dot0dot0dot0. > ifconfig eth1 0.0.0.0 <http://0.0.0.0> > > ifconfig eth0 up > unneeded device is already up. > > ifconfig eth1 up > > ifconfig br0 0.0.0.0 <http://0.0.0.0> > > You forgot to assign IP address to bridge, expect: > ifconfig br0 > > > ifconfig br0 up > Likewise unneeded. > > > ip route add default dev br0 > > In addition to configuration issues, I would also suspect the ARM ethernet > driver. Possible issues: > 1) Does each ethernet device have a valid unique ethernet address? > (ifconfig -a) > 2) Does promiscuous work correctly? > Can you snoop the net correctly with tcpdump without the bridge and > without forcing > eth into promiscuous mode. 1) Yes, they have. It is not silly to ask this, because it is software-modifiable. 2) I have verified with tcpdump that I can well snoop traffic that is not target specifically to the ARM board, and that successivelly on eth0 and eth1 of ARM board, and without forcing promisc mode on the ifaces. My first conclusion is that this is not a lowlevel network driver problem. To summarize, my problem is due to the behavior of the bridge concerning arp resolution. I need a way to unlock this. Best Regards, /Louis Croisez. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.osdl.org/pipermail/bridge/attachments/20050531/8a1ccc69/attachment.htm
