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 ======== 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?
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
What is http:// stuff? some filter got it?
expect:
ifconfig eth0 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
> ifconfig eth0 up
unneeded device is already up.
> ifconfig eth1 up
> ifconfig br0 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.