[B.A.T.M.A.N.] routing problem?

[B.A.T.M.A.N.] routing problem?

[Stefano Scipioni]

I'm testing batman 0.3 exp rv 777

traceroute give me a problem

root@sala:~$ traceroute  10.0.1.1
traceroute: can't find interface
root@sala:~$ ip route ls tab 66
10.1.5.104 dev ath0  proto static  scope link  src 10.1.5.102
10.1.5.130 via 10.1.5.104 dev ath0  proto static
10.1.5.129 via 10.1.5.1 dev ath0  proto static
10.1.5.1 via 10.1.5.104 dev ath0  proto static
root@sala:~$ ip route ls tab 65
10.0.1.0/24 via 10.1.5.1 dev ath0  proto static
root@sala:~$ traceroute  10.0.1.1
traceroute: can't find interface
root@sala:~$ ping 10.0.1.1
PING 10.0.1.1 (10.0.1.1): 56 data bytes
64 bytes from 10.0.1.1: seq=0 ttl=61 time=9.119 ms
64 bytes from 10.0.1.1: seq=1 ttl=61 time=8.486 ms

traceroute works If I utilize source address option.
What is my mistake?

Also if one of nodes has no batman-exp running on it I can't reach it
from neighbours (I use batmand on ath0 interface, not an alias)?
Perhaps I have to use --no-unreachable-rule?

Stefano

Re: [B.A.T.M.A.N.] routing problem?

[Axel Neumann]

On Freitag 09 November 2007, Stefano Scipioni wrote:
> I'm testing batman 0.3 exp rv 777
>
> traceroute give me a problem
>
> root@sala:~$ traceroute  10.0.1.1
> traceroute: can't find interface
> root@sala:~$ ip route ls tab 66
> 10.1.5.104 dev ath0  proto static  scope link  src 10.1.5.102
> 10.1.5.130 via 10.1.5.104 dev ath0  proto static
> 10.1.5.129 via 10.1.5.1 dev ath0  proto static
> 10.1.5.1 via 10.1.5.104 dev ath0  proto static
> root@sala:~$ ip route ls tab 65
> 10.0.1.0/24 via 10.1.5.1 dev ath0  proto static
> root@sala:~$ traceroute  10.0.1.1
> traceroute: can't find interface
> root@sala:~$ ping 10.0.1.1
> PING 10.0.1.1 (10.0.1.1): 56 data bytes
> 64 bytes from 10.0.1.1: seq=0 ttl=61 time=9.119 ms
> 64 bytes from 10.0.1.1: seq=1 ttl=61 time=8.486 ms
>
> traceroute works If I utilize source address option.
> What is my mistake?

i think theres no mistake, busybox-traceroute is just to stupid to figure out 
the correct src ip. In my test, tcpdump showed that it uses the first 
(non-alias) address of the outgoing interface. No matter if the route to the 
destination specifies the src address or not. Did you use an alias interfaces 
for this scenrio?

And even better, the traceroute on my notebook chooses the correct outgoing 
src address but unless i specify it also manually it does not work either. 
The reason is a corrupted udp checksum which is verified by the final 
destination of the packet.


>
> Also if one of nodes has no batman-exp running on it I can't reach it
> from neighbours (I use batmand on ath0 interface, not an alias)?
> Perhaps I have to use --no-unreachable-rule?

For correct routing between batman-nodes and non-batman nodes you need to set 
routes manually. If a multi-homed node is involved with the same netmask on 
multiple interfaces then you must also specify the src address for the manual 
routing entry like: ip r add 10.0.1.1/32 dev ath0 src 10.1.5.102 
And on the batman-node you must either HNA announce the ip of the non-batman 
node using -a (this will automaticall disable the unreachable rule to hit for 
the ip address of the non-batman node).

Or, just as you suggested, launch batman with the --no-unreachable-rule.


ciao,
axel

>
> Stefano
> _______________________________________________
> 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

Re: [B.A.T.M.A.N.] routing problem?

[Stefano Scipioni]

2007/11/10, Axel Neumann <axel@open-mesh.net>:
> On Freitag 09 November 2007, Stefano Scipioni wrote:
> > I'm testing batman 0.3 exp rv 777
> >
> > traceroute give me a problem
> >
> > root@sala:~$ traceroute  10.0.1.1
> > traceroute: can't find interface
> > root@sala:~$ ip route ls tab 66
> > 10.1.5.104 dev ath0  proto static  scope link  src 10.1.5.102
> > 10.1.5.130 via 10.1.5.104 dev ath0  proto static
> > 10.1.5.129 via 10.1.5.1 dev ath0  proto static
> > 10.1.5.1 via 10.1.5.104 dev ath0  proto static
> > root@sala:~$ ip route ls tab 65
> > 10.0.1.0/24 via 10.1.5.1 dev ath0  proto static
> > root@sala:~$ traceroute  10.0.1.1
> > traceroute: can't find interface
> > root@sala:~$ ping 10.0.1.1
> > PING 10.0.1.1 (10.0.1.1): 56 data bytes
> > 64 bytes from 10.0.1.1: seq=0 ttl=61 time=9.119 ms
> > 64 bytes from 10.0.1.1: seq=1 ttl=61 time=8.486 ms
> >
> > traceroute works If I utilize source address option.
> > What is my mistake?
>
> i think theres no mistake, busybox-traceroute is just to stupid to figure out
> the correct src ip. In my test, tcpdump showed that it uses the first
> (non-alias) address of the outgoing interface. No matter if the route to the
> destination specifies the src address or not. Did you use an alias interfaces
> for this scenrio?

No, I use master address

> And even better, the traceroute on my notebook chooses the correct outgoing
> src address but unless i specify it also manually it does not work either.
> The reason is a corrupted udp checksum which is verified by the final
> destination of the packet.

I choose to utilize tcptraceroute in kamikaze packages


Now I have other question about routing...

I have 4 nodes: A,B,C and D


A-------B-------D
 \-------C-------/

fromA> D via B dev ath0 proto static
fromD> A via C dev ath0 proto static

When A talk to D choose B while when D talk to A choose C.
In this scenario node D can't talk to A for example with ping.

Is correct this type of routing?

Re: [B.A.T.M.A.N.] routing problem? / Changes in exp rv790

[Axel Neumann]

Hi

> Now I have other question about routing...
>
> I have 4 nodes: A,B,C and D
>
>
> A-------B-------D
>  \-------C-------/
>
> fromA> D via B dev ath0 proto static
> fromD> A via C dev ath0 proto static
I have difficulties to clearly understand the last two lines.
Is this what routing table 66 or table 65 tells you at node A and D. Perhaps 
its easier if you just paste the command and output of the command which 
revealed this information, might also simplify to find other reasons for 
strange behavior.

In this sense, one question? Do you use different networks/netmasks for the 
different links. Because this might be one reason for problems. 

The thing is:
when the batman network of node A is different from the batman networks used 
by node D then D will not search its routing table 66 for the appropriate 
route to node A. Even if the correct route form D to A is listed by the 
command: ip r ls t 66

The problem are the rules which are configured by the batman daemon.
The command: "ip rule" on node D might show something like:
0:      from all lookup local
6599:   from all lookup 65
6600:   from all to x.y.D.0/24 lookup 66
32766:  from all lookup main
32767:  from all lookup default

while on node A it might show the same except for one line:
6600:   from all to x.y.A.0/24 lookup 66

Rule 6600 tells the network layer to only search table 66 for certain 
destinations. And if D is searching for a destination in x.y.A.0/24 it will 
not fit :-(. 

Anyway, because there has been so much confusion about this, i changed this 
with exp 0.3 revision 790. The daemon now configures the critical rule as:
6600:   from all lookup 66
No more restrictions for table 66. This should always fit.

Since revision 790, also the unreachable rule is omitted by default, which has 
been another reason for confusion.

If you (or others) want to have back the old unreachable rules or the 
restrictive mask for table 66, the daemon may be started with the 
--more-rules switch.


>
> When A talk to D choose B while when D talk to A choose C.
> In this scenario node D can't talk to A for example with ping.
does ping really not work?
>
> Is correct this type of routing?
Why not? According to your setup, both routes would work. This would be a 
typical case for asymmetric routing. But generally nothing speaks against 
such a route.

ciao
/axel

> _______________________________________________
> 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

[B.A.T.M.A.N.] batmand crash / core dump

[Michael Burmeister-Brown]

Hi,

We are seeing a crash in batmand (beta, rv767-792) on kamikaze 7.09 /
atheros 2.6 / mips.

I am trying to get a core dump for Marek, but no file is created despite
doing ulimit -c 20000.

Does anyone know what must be done to get a core dump on this platform?

Thanks!

-----Original Message-----
From: b.a.t.m.a.n-bounces@open-mesh.net
[mailto:b.a.t.m.a.n-bounces@open-mesh.net] On Behalf Of Axel Neumann
Sent: Sunday, November 11, 2007 9:16 AM
To: The list for a Better Approach To Mobile Ad-hoc Networking
Subject: Re: [B.A.T.M.A.N.] routing problem? / Changes in exp rv790

Hi

> Now I have other question about routing...
>
> I have 4 nodes: A,B,C and D
>
>
> A-------B-------D
>  \-------C-------/
>
> fromA> D via B dev ath0 proto static
> fromD> A via C dev ath0 proto static
I have difficulties to clearly understand the last two lines.
Is this what routing table 66 or table 65 tells you at node A and D.
Perhaps 
its easier if you just paste the command and output of the command which

revealed this information, might also simplify to find other reasons for

strange behavior.

In this sense, one question? Do you use different networks/netmasks for
the 
different links. Because this might be one reason for problems. 

The thing is:
when the batman network of node A is different from the batman networks
used 
by node D then D will not search its routing table 66 for the
appropriate 
route to node A. Even if the correct route form D to A is listed by the 
command: ip r ls t 66

The problem are the rules which are configured by the batman daemon.
The command: "ip rule" on node D might show something like:
0:      from all lookup local
6599:   from all lookup 65
6600:   from all to x.y.D.0/24 lookup 66
32766:  from all lookup main
32767:  from all lookup default

while on node A it might show the same except for one line:
6600:   from all to x.y.A.0/24 lookup 66

Rule 6600 tells the network layer to only search table 66 for certain 
destinations. And if D is searching for a destination in x.y.A.0/24 it
will 
not fit :-(. 

Anyway, because there has been so much confusion about this, i changed
this 
with exp 0.3 revision 790. The daemon now configures the critical rule
as:
6600:   from all lookup 66
No more restrictions for table 66. This should always fit.

Since revision 790, also the unreachable rule is omitted by default,
which has 
been another reason for confusion.

If you (or others) want to have back the old unreachable rules or the 
restrictive mask for table 66, the daemon may be started with the 
--more-rules switch.


>
> When A talk to D choose B while when D talk to A choose C.
> In this scenario node D can't talk to A for example with ping.
does ping really not work?
>
> Is correct this type of routing?
Why not? According to your setup, both routes would work. This would be
a 
typical case for asymmetric routing. But generally nothing speaks
against 
such a route.

ciao
/axel

> _______________________________________________
> 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


_______________________________________________
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

[B.A.T.M.A.N.] batman gw nodes and routing (rv792)

[Predrag Balorda]

This is my setup - I sincerely hope ascii-art holds up as it took some time
to create! :-)

                 gateway
Internet ---- 123.456.789.100      router1
                     10.0.0.1 --- 10.0.0.10             router2
router3
                         (ath0)   105.0.0.1 --batman-- 105.0.0.2 --batman--
105.0.0.3
                         (eth0)    10.0.1.0             10.0.2.0
10.0.3.0
                         (bat0) 169.254.0.0 --PtP-- 169.254.2.79
                         (bat0) 169.254.0.0 --------------PtP-----------
169.254.2.80

I have read the bmx pdf and it is excellent. Everything works as it should
on batman-exp  rv792. But I have a problem. The guide assumes that your
gateway to the public internet is my 'router1' and it also assumes that you
have a firewall running on all those routers.

It also ends up with double-nat (well, actually triple-nat in my case). I
have gotten rid of one level of nat (on router1). But I'm still left with a
double nat.

Nat happens when default route traffic from batman nodes is sent down bat0
tunnel and then once again when my gateway passes it onto the public ip
space.

I have succeeded in creating a setup where no nat is done when client nodes
connect to 10.0.0.0/24 network (10.0.0.0/24 hna on router1) but if I want to
go out onto the internet I simply have to do 

iptables -t nat -A POSTROUTING -o bat0 -j MASQUERADE

on each batman node, otherwise nodes themselves can get out but their eth0
clients cannot (i.e. from 10.0.2.0/24 or 10.0.3.0/24 - 10.0.1.0/24 doesn't
have this problem as it has a default route entry in the output of 'route' -
other batman nodes don't)

Can someone with a bit more experience in these matters give me a hand. I
will probably end up having to use batman on gateway node as well but I'd
rather have this possibility of a gw node not runnig batman.

Thanks again!

Pele

[B.A.T.M.A.N.] vis and batman-exp (rv780-792)

[Predrag Balorda]

Does batman-exp work with vis (B.A.T.M.A.N. visualisation server 0.3-beta)?
I don't seem to be getting any topology info but batman beta 0.3 was working
with the same setup.

Pele 

Re: [B.A.T.M.A.N.] vis and batman-exp (rv780-792)

[Stefano Scipioni]

2007/11/11, Predrag Balorda <predrag.balorda@gmail.com>:
> Does batman-exp work with vis (B.A.T.M.A.N. visualisation server 0.3-beta)?
> I don't seem to be getting any topology info but batman beta 0.3 was working
> with the same setup.
>
> Pele


I changed in vis.h:
#define VIS_COMPAT_VERSION 21

Stefano

Re: [B.A.T.M.A.N.] vis and batman-exp (rv780-792)

[Axel Neumann]

thanks for the tip. Now changed this in rv 794

Modified:
   trunk/batman-experimental/batman.h
Log:
change VIS_COMPAT_VERSION to 21

/axel

On Montag 12 November 2007, Stefano Scipioni wrote:
> 2007/11/11, Predrag Balorda <predrag.balorda@gmail.com>:
> > Does batman-exp work with vis (B.A.T.M.A.N. visualisation server
> > 0.3-beta)? I don't seem to be getting any topology info but batman beta
> > 0.3 was working with the same setup.
> >
> > Pele
>
> I changed in vis.h:
> #define VIS_COMPAT_VERSION 21
>
> Stefano
> _______________________________________________
> 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

RE: [B.A.T.M.A.N.] vis and batman-exp (rv780-792)

[Predrag Balorda]

Thanks, works now!

Pele

-----Original Message-----
From: b.a.t.m.a.n-bounces@open-mesh.net
[mailto:b.a.t.m.a.n-bounces@open-mesh.net] On Behalf Of Axel Neumann
Sent: Monday, November 12, 2007 2:54 PM
To: The list for a Better Approach To Mobile Ad-hoc Networking
Subject: Re: [B.A.T.M.A.N.] vis and batman-exp (rv780-792)

thanks for the tip. Now changed this in rv 794

Modified:
   trunk/batman-experimental/batman.h
Log:
change VIS_COMPAT_VERSION to 21

/axel

On Montag 12 November 2007, Stefano Scipioni wrote:
> 2007/11/11, Predrag Balorda <predrag.balorda@gmail.com>:
> > Does batman-exp work with vis (B.A.T.M.A.N. visualisation server
> > 0.3-beta)? I don't seem to be getting any topology info but batman beta
> > 0.3 was working with the same setup.
> >
> > Pele
>
> I changed in vis.h:
> #define VIS_COMPAT_VERSION 21
>
> Stefano
> _______________________________________________
> 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



_______________________________________________
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

Re: [B.A.T.M.A.N.] batman gw nodes and routing (rv792)

[Axel Neumann]

Hi,

On Sonntag 11 November 2007, Predrag Balorda wrote:
> This is my setup - I sincerely hope ascii-art holds up as it took some time
> to create! :-)

           gateway
Inet -- 123.456.789.100     router1
             10.0.0.1 --- 10.0.0.10             router2              router3
                 (ath0)   105.0.0.1 --batman-- 105.0.0.2 --batman-- 105.0.0.3
                 (eth0)    10.0.1.0             10.0.2.0             10.0.3.0
                 (bat0) 169.254.0.0 --PtP-- 169.254.2.79
                 (bat0) 169.254.0.0 --------------PtP-----------  169.254.2.80

>
> I have read the bmx pdf and it is excellent. Everything works as it should
> on batman-exp  rv792. But I have a problem. The guide assumes that your
> gateway to the public internet is my 'router1' and it also assumes that you
> have a firewall running on all those routers.

just an idea...

The document does not yet mention the option for the old, stateless, 
batmand-0.2-based one-way-tunnel. The one-way-tunnel only entunnel uplink 
internet data (from the client node to the gw node). No tunnels are used for 
downlink internet data (from the GW node to the client). For downlink 
traffic, the GW node just forwards the data. Therefore the inner IP address 
must be a valid and known IP address in your mesh - usually the batman 
address of the client node. 
With rv 795, the source address of the entunneled packets at the client side 
can also be an addresses from a non-batman interface (like eth0 in your 
setup) if this address ranges have been HNA announced by the client node.


You can enable them at the gw side with --one-way-tunnel 1
At the client side, you can enable --one-way-tunnel <value> with a value 
larger than 0. The value defines a preference for the tunnel types offerred 
by the selected GW (higher value = more preferred). You can disable the 
0.3-default-two-way-tunnel with --two-way-tunnel 0 
(see also --dangerous for very short help)

This way it should be possible to:

- do SNAT only on your gateway. No (S)NAT on any batman node

- configure a default route at router 1 to your gateway 

- configure a 10.0.0.0/16 route at the gateway to router 1 

- for the uplink traffic packets from client-node-dhcp-clients are entunnelled 
at the client-node but with the original client-node-dhcp-clients ip address 
as the inner tunnel src address.

- the client-node-dhcp-clients ip address ranges are announced by the 
corresponding clients

- for the downlink traffic let the batman daemon on router 1 choose the 
correct next hop towards the client node which announced the correspoding 
network destination address.

- maybe other (dis)advantages, depending on your personal preferences like: no 
blackhole-GW-detection, no means for a GW node to control the maximum number 
of connected client nodes, less tunnel-protocol-overhead,...

happy routing,
/axel


>
> It also ends up with double-nat (well, actually triple-nat in my case). I
> have gotten rid of one level of nat (on router1). But I'm still left with a
> double nat.
>
> Nat happens when default route traffic from batman nodes is sent down bat0
> tunnel and then once again when my gateway passes it onto the public ip
> space.
>
> I have succeeded in creating a setup where no nat is done when client nodes
> connect to 10.0.0.0/24 network (10.0.0.0/24 hna on router1) but if I want
> to go out onto the internet I simply have to do
>
> iptables -t nat -A POSTROUTING -o bat0 -j MASQUERADE
>
> on each batman node, otherwise nodes themselves can get out but their eth0
> clients cannot (i.e. from 10.0.2.0/24 or 10.0.3.0/24 - 10.0.1.0/24 doesn't
> have this problem as it has a default route entry in the output of 'route'
> - other batman nodes don't)
>
> Can someone with a bit more experience in these matters give me a hand. I
> will probably end up having to use batman on gateway node as well but I'd
> rather have this possibility of a gw node not runnig batman.
>
> Thanks again!
>
> 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

Re: [B.A.T.M.A.N.] batmand crash / core dump

[Axel Neumann]

Hi,

i've also experienced this problem - on mips and mipsel kamikaze. I also 
remember that it causually worked but not today :-(
If you find any solution to this problem please let me know

thanks,
axel

On Sonntag 11 November 2007, Michael Burmeister-Brown wrote:
> Hi,
>
> We are seeing a crash in batmand (beta, rv767-792) on kamikaze 7.09 /
> atheros 2.6 / mips.
>
> I am trying to get a core dump for Marek, but no file is created despite
> doing ulimit -c 20000.
>
> Does anyone know what must be done to get a core dump on this platform?
>
> Thanks!

Re: [B.A.T.M.A.N.] batmand crash / core dump

[Marek Lindner]

Hi,

> i've also experienced this problem - on mips and mipsel kamikaze. I also
> remember that it causually worked but not today :-(
> If you find any solution to this problem please let me know

I reproduced this *exact* error on my notebook (debian unstable) and I get a 
core dump. This problem of not getting a core dump must be related to 
OpenWRT.

Greetings,
Marek