Hi,
we are using the following configuration in our freifunk network:
B.A.T.M.A.N. advanced 2011.0.0 (compatibility version 12)
ath1 (ad-hoc) as batman-adv-interfaces ath0 (ap), tap0, eth0.1 and bat0 as a bridge
stp is enabled for the bridge. Most of the nodes are connected via tinc and the network runs fine. But if two nodes which have a tinc connection also get a ath1-connection, the whole network crashes.
What are we doing wrong?
regards Bjoern
Hi,
On Mo, 26.09.2011 02:15:46, Bjoern Franke wrote:
ath1 (ad-hoc) as batman-adv-interfaces ath0 (ap), tap0, eth0.1 and bat0 as a bridge
Most of the nodes are connected via tinc and the network runs fine. But if two nodes which have a tinc connection also get a ath1-connection, the whole network crashes.
Did I get you right, that »ath1-connection« refers to a second connction of two tinc hosts over another interface? In this case I suspect it’s a tinc matter, and iptables could be a solution. Is there anything in the tinc logs? Maybe „two“ hosts with the _same_ identity?
Regards P.M.
Hi,
Did I get you right, that »ath1-connection« refers to a second connction of two tinc hosts over another interface?
No, ath1 is the ad-hoc wifi connection.
ath0 and ath1 are wifi interfaces, tap0 is the tinc connection.
regards
Hi,
B.A.T.M.A.N. advanced 2011.0.0 (compatibility version 12)
ath1 (ad-hoc) as batman-adv-interfaces ath0 (ap), tap0, eth0.1 and bat0 as a bridge
stp is enabled for the bridge.
STP is no solution. Did you try enabling the bridge loop avoidance ? http://www.open-mesh.org/wiki/batman-adv/Bridge-loop-avoidance
You might need to upgrade to a later batman-adv version though.
Regards, Marek
STP is no solution. Did you try enabling the bridge loop avoidance ? http://www.open-mesh.org/wiki/batman-adv/Bridge-loop-avoidance
You might need to upgrade to a later batman-adv version though.
Regards, Marek
We did not enable bridge loop avoidance, IIRC we did not run batman on the bridge interface due to overhead on the vpn links.
But we'll enable it on the nodes we have access to.
thx bjo
On Monday, September 26, 2011 14:33:57 Bjoern Franke wrote:
We did not enable bridge loop avoidance, IIRC we did not run batman on the bridge interface due to overhead on the vpn links.
But we'll enable it on the nodes we have access to.
Please give it a try. It sounds like a bridge loop. We are working towards an enhanced bridge loop mechanism which aims to reduce the overhead. Are you interested in testing it when it gets ready ?
Regards, Marek
Am Montag, 26. September 2011, 17:26:37 schrieb Marek Lindner:
On Monday, September 26, 2011 14:33:57 Bjoern Franke wrote:
We did not enable bridge loop avoidance, IIRC we did not run batman on the bridge interface due to overhead on the vpn links.
But we'll enable it on the nodes we have access to.
Please give it a try. It sounds like a bridge loop.
Ok, we have running now the following setup:
ath1 (ad-hoc) as batman-interface br-mesh (ath0 (ap-mode), eth0.1, tap0, bat0) as batman-interface
batman complains about the mtu 1500 of br-mesh, but it can't be set to 1527 because bat0 does not like any mtu setting.
We are working towards an enhanced bridge loop mechanism which aims to reduce the overhead. Are you interested in testing it when it gets ready ?
Yes, this would be nice :)
regards Bjoern
On Tuesday, September 27, 2011 12:45:01 Bjoern Franke wrote:
ath1 (ad-hoc) as batman-interface br-mesh (ath0 (ap-mode), eth0.1, tap0, bat0) as batman-interface
batman complains about the mtu 1500 of br-mesh, but it can't be set to 1527 because bat0 does not like any mtu setting.
Ok, does it solve your loop ?
We are working towards an enhanced bridge loop mechanism which aims to reduce the overhead. Are you interested in testing it when it gets ready ?
Yes, this would be nice :)
Great! We will contact you once we have something testable.
Cheers, Marek
Am Dienstag, 27. September 2011, 13:44:26 schrieb Marek Lindner:
On Tuesday, September 27, 2011 12:45:01 Bjoern Franke wrote:
ath1 (ad-hoc) as batman-interface br-mesh (ath0 (ap-mode), eth0.1, tap0, bat0) as batman-interface
batman complains about the mtu 1500 of br-mesh, but it can't be set to 1527 because bat0 does not like any mtu setting.
Ok, does it solve your loop ?
I don't know, yesterday one of the loop-routers crashed, so I was not able to test it yet.
BTW, how can I solve the MTU issue?
regards Bjoern
On Wednesday, September 28, 2011 00:03:24 Bjoern Franke wrote:
I don't know, yesterday one of the loop-routers crashed, so I was not able to test it yet.
Ok.
BTW, how can I solve the MTU issue?
You probably can't. However, I don't think this is a critical problem. It only means that batman-adv will have to fragment the traffic.
Cheers, Marek
Am Donnerstag, 29. September 2011, 12:08:01 schrieb Marek Lindner:
On Wednesday, September 28, 2011 00:03:24 Bjoern Franke wrote:
I don't know, yesterday one of the loop-routers crashed, so I was not able to test it yet.
Ok.
It's up again, we added br-mesh as bat-if and the loop-protection seems to work now.
regards bjo
Am Donnerstag, 29. September 2011, 12:08:01 schrieb Marek Lindner:
On Wednesday, September 28, 2011 00:03:24 Bjoern Franke wrote:
I don't know, yesterday one of the loop-routers crashed, so I was not able to test it yet.
Ok.
There is something stupid going on. Our network behaves now more unstable as before. I'll try to find out more what's going on.
regards Bjoern
b.a.t.m.a.n@lists.open-mesh.org
-
Bjoern Franke -
Marek Lindner -
P. Mazart