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
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
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?
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
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
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
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
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
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
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
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
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!
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
b.a.t.m.a.n@lists.open-mesh.org
-
Axel Neumann -
Marek Lindner -
Michael Burmeister-Brown -
Predrag Balorda -
Stefano Scipioni