0.3-beta-rv779 and rv780
Quoted 5 lines
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
Quoted 1 line
non-homed subnet reachable from a node which has no interface in that
subnet.
Quoted 6 lines
So for example, if your setup looks like:
A---------------------B1_B2---------------C10.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
Wouldn't be HNA the much better solution ? Node B should announce one of the networks. To not rebroadcast OGMs from the wrong network batman should check if the received originator IP is within the own network.
Regards,
Marek
Jetzt Mails schnell in einem Vorschaufenster überfliegen. Dies und viel mehr bietet das neue Yahoo! Mail - www.yahoo.de/mail
Quoted 14 lines · Marek Lindner
Quoted 3 lines
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
Quoted 1 line
non-homed subnet reachable from a node which has no interface in that
subnet.
Quoted 4 lines
So for example, if your setup looks like:
A---------------------B1_B2---------------C10.0.0.1/24 10.0.0.2/24 10.0.1.2/24 10.0.1.3/24
Quoted 6 lines
Quoted 2 lines
the easiest way to do achieve that at A and C is:
$ ip rule add from all pref 6500 t 66Wouldn't be HNA the much better solution ? Node B should announce one of the networks. To not rebroadcast OGMs from the wrong network batman should check if the received originator IP is within the own network.
I am not sure if I understand you correct. Do you mean that (instead of re-broadcasting As OGMs on interface B2) node B should announce 10.0.0.0/24 as HNA on B2 ?
ciao,
axel
Quoted 16 lines
Regards,
MarekJetzt Mails schnell in einem Vorschaufenster überfliegen. Dies und
viel mehr bietet das neue Yahoo! Mail - www.yahoo.de/mail_______________________________________________
B.A.T.M.A.N mailing list
[email protected]
https://list.open-mesh.net/mm/listinfo/b.a.t.m.a.n
My sincere apologies!
I have gone through the whole setup once again today and now gate0 stays up and running on all client nodes, it was my iptables setup on middle client node that was forwarding nat-ted traffic onto ath1 instead of gate0. Sorry again. Now everything seems stable and nice. I am getting between 600-800KB/s TCP from gateway with 3 nodes which, I presume, is a nice figure, unless -exp offers something more?
I have gone by the advice and put all radios onto the same subnet. Now traceroute from one node onto another takes ages to do (with single-radio setup it was nice and showed me exactly what I was expecting) - I guess it has something to do with two interfaces with the same mask etc etc? Also doesn't this set-up hurt performance if the linux kernel sends packets with the same broadcast address down the first interface it finds, even though that interface might be the radio with worse connectivity than the second one? How should we handle this?
Pele
P.S. who do I complain to about vis not showing ALL my interfaces (dual-radio units) as distinct IP addresses and their connections to others but instead just takes the first interface on the subnet so instead of having 6 nodes on my diagram I only have 3 and each one has a host-hna attached to it (I'd rather not burden this list with mime attachments)?
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Axel Neumann
Sent: Tuesday, November 06, 2007 10:57 AM
To: The list for a Better Approach To Mobile Ad-hoc Networking
Subject: Re: AW: [B.A.T.M.A.N.] 0.3-beta-rv779 and rv780
Quoted 9 lines · Marek Lindner
Quoted 3 lines
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
Quoted 1 line
non-homed subnet reachable from a node which has no interface in that
subnet.