Re: [Bridge] Bridge not working on arm embedded platform

[Louis Croisez <louis.croisez@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 4422 bytes --]

Hi Stephen,
first of all, thx for helping me :o)

2005/5/31, Stephen Hemminger <shemminger@osdl.org>:
> 
> On Mon, 30 May 2005 11:38:59 +0200
> Louis Croisez <louis.croisez@gmail.com> 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.

[-- Attachment #2: Type: text/html, Size: 6869 bytes --]