[Bridge] Bridge not working on arm embedded platform

[Bridge] Bridge not working on arm embedded platform

[Louis Croisez]

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

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] 

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
ifconfig eth0 promisc
ifconfig eth1 promisc
ifconfig eth0 0.0.0.0 <http://0.0.0.0>
ifconfig eth1 0.0.0.0 <http://0.0.0.0>
ifconfig eth0 up
ifconfig eth1 up
ifconfig br0 0.0.0.0 <http://0.0.0.0>
ifconfig br0 up
ip route add 0.0.0.0/0 <http://0.0.0.0/0> dev br0


On PC_A, I ping PC_B. It does not work
[pc_a]# ping 10.0.0.10 <http://10.0.0.10>

Then, I verified with tcpdump on the arm platform where the problem could 
be:
[arm]# tcpdump -i br0
listening on br0, link-type EN10MB (Ethernet), capture size 68 bytes
arp who-has 10.10.0.1 <http://10.10.0.1> tell 10.0.0.10 <http://10.0.0.10> 
3 packets captured 
3 packets received by filter 
0 packets dropped by kernel 

[arm]# tcpdump -i eth0
listening on eth0, link-type EN10MB (Ethernet), capture size 68 bytes
arp who-has 10.10.0.1 <http://10.10.0.1> tell 10.0.0.10 <http://10.0.0.10> 
3 packets captured 
3 packets received by filter 
0 packets dropped by kernel 


[arm]# tcpdump -i eth1 
listening on eth1, link-type EN10MB (Ethernet), capture size 68 bytes
0 packets captured 
0 packets received by filter 
0 packets dropped by kernel 

The ICMP packet is not sent because the arp resolution is not completed.
Finally, the problem is: why does the bridge not forward the arp request 
from PC_A (10.0.0.10 <http://10.0.0.10>) to PC_B (10.10.0.1<http://10.10.0.1>
)
This is a broadcast packet, and it should be forwarded on the other 
interface of the bridge.

What I have done to find the problem:

   - I have verified that both eth0 and eth1 on the bridge are well 
   working in promiscuous mode. 
   - I have statically defined an arp entry for PC_A inside PC_B, and an 
   arp entry for PC_B inside PC_A; the result is that the ICMP packet (ping) is 
   well bridged through the two interfaces of the ARM platform. Thus the 
   problem is related to the arp resolution.
    

If someone could help me, it would be great because I am completely locked. 
Replacing the ARM by a standard PC make the things working.

--L.Croisez.

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

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

[Stephen Hemminger]

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  ======== eth0 --+-- eth1 ======== [PC_B] eth0 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?

> 
> 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
> ifconfig eth0 promisc
Don't do this you don't need to, unless something is
broken in driver.

> 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
to bring up without IP address

> 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 0.0.0.0/0 <http://0.0.0.0/0> 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.
 

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

[Louis Croisez]

[-- 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 --]

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

[Stephen Hemminger]

On Tue, 31 May 2005 21:17:17 +0200
Louis Croisez <louis.croisez@gmail.com> wrote:

> 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
>
Does the bridge without any ebtables or iptables filtering at all? 
That is might be where the problem is.

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

[Mark S. Mathews]

This is xscale, right?

The last time I checked, an extra patch to the ixp425 ethernet driver 
was required if you were running with ebtables enabled.  That was on a 
2.4.x kernel and several months ago, I don't know if it's still necessary.

My 0.02 credits,
-M

On Tue, 31 May 2005, Stephen Hemminger wrote:

> On Tue, 31 May 2005 21:17:17 +0200
> Louis Croisez <louis.croisez@gmail.com> wrote:
>
>> 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
>>
> Does the bridge without any ebtables or iptables filtering at all?
> That is might be where the problem is.
>

-- 

Mark S. Mathews

AbsoluteValue Systems      Web:    http://www.linux-wlan.com
721-D North Drive          e-mail: mark@linux-wlan.com
Melbourne, FL 32934        Phone:  321.259.0737
USA                        Fax:    321.259.0286

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

[Bart De Schuymer]

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

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

[Louis Croisez]

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

Hi Bart, Hi kind bridge listers,

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

How can I be sure that arptables is not interferring?
is it by putting 0 inside /proc/sys/net/bridge/bridge-nf-call-arptables ?

The symptom is : the arp broadcast (not the unicast arp response) is blocked 
just after ebt:Nat:PostRouting.
Note: ebt:Nat:PostRouting is the trace printed by the following ebtable 
entry:
> ebtables -t nat -A POSTROUTING -j ACCEPT --log --log-prefix=" 
ebt:Nat:PostRouting "

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