* [B.A.T.M.A.N.] 0.3-beta-rv779 and rv780
@ 2007-11-05 21:14 Predrag Balorda
2007-11-06 8:15 ` Axel Neumann
0 siblings, 1 reply; 3+ messages in thread
From: Predrag Balorda @ 2007-11-05 21:14 UTC (permalink / raw)
To: B.A.T.M.A.N
My test setup comprises 3 dual-radio (a and bg) units running openwrt
kamikaze 7.09.
For some reason (or another?) my middle unit keeps re-creating the gate0
every few seconds. Sometimes it loses it completely and sometimes it keeps
it for 10 seconds or so. The furthest node from the gw keeps it's tunnel
permanently configured (which is nice).
Basically, node-to-node traffic is ok, very stable and very nice but
node-through-gw is flaky.
This above is with bg-only radios.
Also I have tried using a dual-radio setup. I have tried to set bg-radios to
one subnet and a-radios to a different one, I have also
Tried setting them all on the same subnet but all hell breaks loose. I don't
know if it's loops or what but it doesn't seem usable to me.
Yes I know I'm playing with 0.3beta and exp but I believe this would be a
far more usable setup than olsr 5.3 that I also tried.
Any help appreciated in solving this issue.
Pele
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [B.A.T.M.A.N.] 0.3-beta-rv779 and rv780
2007-11-05 21:14 [B.A.T.M.A.N.] 0.3-beta-rv779 and rv780 Predrag Balorda
@ 2007-11-06 8:15 ` Axel Neumann
2007-11-06 12:35 ` Predrag Balorda
0 siblings, 1 reply; 3+ messages in thread
From: Axel Neumann @ 2007-11-06 8:15 UTC (permalink / raw)
To: pele, The list for a Better Approach To Mobile Ad-hoc Networking
Hello
On Montag 05 November 2007, Predrag Balorda wrote:
> My test setup comprises 3 dual-radio (a and bg) units running openwrt
> kamikaze 7.09.
>
> For some reason (or another?) my middle unit keeps re-creating the gate0
> every few seconds. Sometimes it loses it completely and sometimes it keeps
> it for 10 seconds or so. The furthest node from the gw keeps it's tunnel
> permanently configured (which is nice).
One question, does the middle-unit batman operate on two interfaces while the
futhest node (with the stable tunnel) operates on one interface only?
Can you give some more informations about your setup? It sounds like you have
three nodes with the middle unit having two interfaces and the others maybe
only one. All are operating in the same netmask but have individual IP
addresses for each interfaces?
>
> Basically, node-to-node traffic is ok, very stable and very nice but
> node-through-gw is flaky.
>
> This above is with bg-only radios.
>
> Also I have tried using a dual-radio setup. I have tried to set bg-radios
> to one subnet and a-radios to a different one, I have also
> Tried setting them all on the same subnet but all hell breaks loose.
The latter configuration is the usual one. All interfaces in the same
subnet/netmask. This is the default setup which "should?!" work out of the
box.
The non-usual setup: you have different parts of your mesh operating in
different subnets you need an additional ip rule to make the nodes in the
non-homed subnet reachable from a node which has no interface in that subnet.
So for example, if your setup looks like:
A---------------------B1_B2---------------C
10.0.0.1/24 10.0.0.2/24 10.0.1.2/24 10.0.1.3/24
the easiest way to do achieve that at A and C is:
$ ip rule add from all pref 6500 t 66
$ ip rule
at A should then show (among others) the following line:
6500: from all lookup 66
Also check if you can see any
$ ip rule
output at all. The (actually obligatory) advanced routing capabilities are NOT
enabled in all linux systems.
> I
> don't know if it's loops or what but it doesn't seem usable to me.
>
>
> Yes I know I'm playing with 0.3beta and exp
Is exp showing up the same problems?
> but I believe this would be a
> far more usable setup than olsr 5.3 that I also tried.
maybe check 5.4. Because I think that the improvements from 5.3 to 5.4 are
huge, but also because I am always interested in the concrete pros and cons
that people observe between the latest olsr/batman state-of-the art.
ciao,
axel
>
> Any help appreciated in solving this issue.
>
> Pele
>
> _______________________________________________
> B.A.T.M.A.N mailing list
> B.A.T.M.A.N@open-mesh.net
> https://list.open-mesh.net/mm/listinfo/b.a.t.m.a.n
^ permalink raw reply [flat|nested] 3+ messages in thread
* RE: [B.A.T.M.A.N.] 0.3-beta-rv779 and rv780
2007-11-06 8:15 ` Axel Neumann
@ 2007-11-06 12:35 ` Predrag Balorda
0 siblings, 0 replies; 3+ messages in thread
From: Predrag Balorda @ 2007-11-06 12:35 UTC (permalink / raw)
To: 'The list for a Better Approach To Mobile Ad-hoc Networking'
Thank you for your quick replies guys. I just woke up (doh!) so I'll get
back to you with all details shortly, but just to quickly answer axels
question on olsr.
Ok I will also post my setup
Aa ----------------- Ba --------- Ca (a is 11a g is 11bg interface)
105.0.0.1/24 105.0.0.2 105.0.0.3
Ag ----------------- Bg --------- Cg
105.0.1.1/24 105.0.1.2 105.0.1.3
11a is switched OFF on all nodes.
OLSR seems to ALWAYS just go from Ag directly to Cg (I presume it's because
it can see it on g radio) even though route through Bg would be better and
it takes 10-15ms (at least for traceroute output). B.A.T.M.A.N ALLWAYS goes
through Bg and it's all 2ms hops Ag > Bg 2ms, Bg > Cg 2ms. Much better
wouldn't you say?
That's why I've given up on OLSR.
Ok that was the short answer, later I'll get back to you on the gate0 issue.
> but I believe this would be a
> far more usable setup than olsr 5.3 that I also tried.
maybe check 5.4. Because I think that the improvements from 5.3 to 5.4 are
huge, but also because I am always interested in the concrete pros and cons
that people observe between the latest olsr/batman state-of-the art.
ciao,
axel
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2007-11-06 12:35 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-11-05 21:14 [B.A.T.M.A.N.] 0.3-beta-rv779 and rv780 Predrag Balorda
2007-11-06 8:15 ` Axel Neumann
2007-11-06 12:35 ` Predrag Balorda
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox