6 Sep
2009
6 Sep
'09
5:28 a.m.
Dear B.A.T.M.A.N List,
i've installed BATMAN v0.3.2 in a ethernet network to dynamicly route my
network-informations. Before switching to BATMAN, i've used OLSR.
With OLSR all things went fine. But since my network grows faster as
intended, i like to switch to BATMAN.
NOW TO MY PROBLEM:
I like to announce a gateway that is behind an VPN-Tunnel. The
VPN-Tunnel is established, before BATMAN is running.
When i try to start BATMAN on the Gateway with this options:
batmand -g 30mbit/2mbit
the clients will create a gate0 interface. I do not need this gate0
interface. All routers have static public ip-addresses assigned. The
once that i need is, that BATMAN inserts a DEFAULT-ROUTE to the next
neighbour hop thats reach the gateway.
NETWORK-Setup:
1. i386 Router located on ISP runs batman as gateway-provider
xxx.205.12.0/32 brd 255.255.255.255
<--- VPN-Tunnel over ISP-Network --->
xxx.205.12.4/32 brd 255.255.255.255
2. i386 Router located at home #1
xxx.205.12.17/30 brd xxx.205.12.19
<--- Wireless Bridge-Connection --->
xxx.205.12.18/30 brd xxx.205.12.19
3. i386 Router located at home #2
xxx.205.12.21/30 brd xxx.205.12.23
<--- Wireless Bridge-Connection --->
xxx.205.12.22/30 brd xxx.205.12.23
4. i386 Router located at home #3
How can i tell BATMAN (gateway) to announce 0.0.0.0/0 as HNA?
# batmand -c -a 0.0.0.0/0
Invalid announced network (netmask is invalid): 0.0.0.0/0
I dont like to setup a second VPN / P2P Tunnel, because thats not needed.
Thanks in advance,
Michael
6 Sep
6 Sep
10:50 a.m.
Hello Michael!
Batmand checks and deliberately blocks users from announcing 0.0.0.0/0 - this
could cause the notorious black-hole problem we have experienced in the old
days when using OLSR. Also we think it is important that we can explicitly
tell a Batman node to use Internet gateway functionality or not.
Default routes in a mesh can be really annoying and break network
functionality. If you only have one default gateway in your Batmand network
and really know what you are doing you can actually override this check with a
simple trick.
As a workaround you can announce two subnetworks 0.0.0.0/1 and 128.0.0.0/1
instead of 0.0.0.0/0.
batmand -a 0.0.0.0/1,128.0.0.0/1 <your interface>
Cheers,
Elektra
11:33 a.m.
Hi Elektra,
thanks for your trick. This trick works for me, but it is a bad solution
:-) I switched back to OLSR, although i like the concept of BATMAN more
then that of OLSR.
Announcing 0.0.0.0/0 can really be a problem, but why does BATMAN tunnel
the internet-traffic through gate0?
It will be nice, if there will be a option in the next release, where
users can decide to use routing or tunneling internet-traffic.
Cheers,
Michael.
Am 06.09.2009 12:50, schrieb elektra:
Hello Michael!
Batmand checks and deliberately blocks users from announcing 0.0.0.0/0 - this
could cause the notorious black-hole problem we have experienced in the old
days when using OLSR. Also we think it is important that we can explicitly
tell a Batman node to use Internet gateway functionality or not.
Default routes in a mesh can be really annoying and break network
functionality. If you only have one default gateway in your Batmand network
and really know what you are doing you can actually override this check with a
simple trick.
As a workaround you can announce two subnetworks 0.0.0.0/1 and 128.0.0.0/1
instead of 0.0.0.0/0.
batmand -a 0.0.0.0/1,128.0.0.0/1<your interface>
Cheers,
Elektra
_______________________________________________
B.A.T.M.A.N mailing list
B.A.T.M.A.N(a)lists.open-mesh.net
https://lists.open-mesh.net/mm/listinfo/b.a.t.m.a.n
12:37 p.m.
Hi Michael!
Announcing 0.0.0.0/0 can really be a problem, but why
does BATMAN tunnel
the internet-traffic through gate0?
Because we want to have the means to select the gateway from the gateway
client, rather than ending up somewhere random with our outgoing Internet
traffic. With default route entries in every mesh node all a gateway client node
can determine is its next link-local hop on the path towards one of the
gateways. Hence every node on your path will make its own selection for the
default gateway, so it is not possible to select the gateway from the mesh
gateway client.
Cheers,
Elektra
3:11 p.m.
Hi,
When i try to start BATMAN on the Gateway with this
options:
batmand -g 30mbit/2mbit
the clients will create a gate0 interface. I do not need this gate0
interface. All routers have static public ip-addresses assigned. The
once that i need is, that BATMAN inserts a DEFAULT-ROUTE to the next
neighbour hop thats reach the gateway.
I don't understand why you have the feeling the gate0 interface is a problem.
As Elektra explained choosing a default gateway by "inserting a default route"
is meaningless (in a mesh). If each client should be able to choose its own
gateway there is no way around the tunnel mechanism.
If you dislike the masquerading (which is activated per default) you can learn
here[0] how to disable it. If you really want to have the plain default route
I suggest to use the --policy-routing-script [1] option to modify the routing
tables on the fly.
Regards,
Marek
[0] http://www.open-mesh.net/wiki/InternetTuning
[1] http://www.open-mesh.net/wiki/RoutingVodoo
5:13 p.m.
Am 06.09.2009 17:11, schrieb Marek Lindner:
I don't understand why you have the feeling the gate0 interface is a problem.
As Elektra explained choosing a default gateway by "inserting a default route"
is meaningless (in a mesh). If each client should be able to choose its own
gateway there is no way around the tunnel mechanism.
Sorry but i had not the right view of the tunneling-interface.
Now, the reason for the tunneling-interface is totaly clear. There is no
other solution to route internet-traffic through a specified gatway. The
only solution will be to lable a tcp/ip-packet how MPLS does, but that
is to fancy.
One question: Will the P2P-Interface (gate0) shows up in a traceroute?
The P2P-Interface have a private ip-address 169.x.x.x assigned to it. I
use only public ip-addresses and do not want to show a private
ip-address in a traceroute.
When using the tunneling interface, the MTU is set to a lower value then
1500 bytes (1431 bytes). B.A.T.M.A.N have in addition to the NAT-Helper
set the TCPMSS Flag to something like 1371 bytes (1431 bytes - 20 Bytes
of MAC-Address and - 40 Bytes of TCP/IP Header). I found nothing about
TCPMSS on my firewall-rules (iptables) in the table "mangle".
Without TCPMSS, packages that transport more then 1371 bytes will be
silently dropped in my case.
Now i will give B.A.T.M.A.N a second try and will use the little tricky
solution to add two /1 subnets. Thanks to Elektra.
I suggest to use the --policy-routing-script [1]
option to modify the routing
tables on the fly.
Currently i have my own policy-routing-script, because B.A.T.M.A.N does
not support HOST-Routes xxx.205.12.4/32. But why does B.A.T.M.A.N not
fully support Host-Routes? A mash with only Host-Addresses is easier to
administrate then complete networks. A second goal is, that the ad-hoc
mobile user is free to change his position across the net.
I use only host-addresses to safe ip-addresses.
Michael.
5:47 p.m.
On Monday 07 September 2009 01:13:49 Michael Rack wrote:
Now, the reason for the tunneling-interface is totaly
clear. There is no
other solution to route internet-traffic through a specified gatway. The
only solution will be to lable a tcp/ip-packet how MPLS does, but that
is to fancy.
Well, we have something similar called "batman-adv". It is a kernel module
implementing the batman protocol on layer 2.5 (using mac addresses instead of
IPs). May be you should look into that ?
One question: Will the P2P-Interface (gate0) shows up
in a traceroute?
The P2P-Interface have a private ip-address 169.x.x.x assigned to it. I
use only public ip-addresses and do not want to show a private
ip-address in a traceroute.
I have no test setup at hand but I think you always should see the gateway's
virtual ip (0.0 at the end) if you try to traceroute a host that resides in
the internet.
Keep in mind that the tunneling will make everything appear as a single hop no
matter how many nodes are in between. A traceroute should look like this:
* node ip
* gw virtual ip
* internet ip1
* internet ip2
* ...
When using the tunneling interface, the MTU is set to
a lower value then
1500 bytes (1431 bytes). B.A.T.M.A.N have in addition to the NAT-Helper
set the TCPMSS Flag to something like 1371 bytes (1431 bytes - 20 Bytes
of MAC-Address and - 40 Bytes of TCP/IP Header). I found nothing about
TCPMSS on my firewall-rules (iptables) in the table "mangle".
Without TCPMSS, packages that transport more then 1371 bytes will be
silently dropped in my case.
Not sure how you get to these numbers (1431 / 1371) as the batman tunnel is
running over UDP which costs 29 Bytes [20 Bytes IP + 8 Bytes UDP + 1 Byte
batman stuff] in total, reducing the maximum packet size to 1471.
You are right about the the TCPMSS configuration - batman could set this
automatically as well. I suggest something like this:
iptables -I FORWARD -p tcp --tcp-flags SYN,RST SYN -o gate0 -j TCPMSS --clamp-
mss-to-pmtu
Currently i have my own policy-routing-script, because
B.A.T.M.A.N does
not support HOST-Routes xxx.205.12.4/32. But why does B.A.T.M.A.N not
fully support Host-Routes? A mash with only Host-Addresses is easier to
administrate then complete networks. A second goal is, that the ad-hoc
mobile user is free to change his position across the net.
Your own policy-routing-script ?
Why do you think batman does not support host routes ? I had the feeling
batman supports host routes in all possible ways. :-)
Cheers,
Marek
7 Sep
7 Sep
10:16 a.m.
Am 06.09.2009 19:47, schrieb Marek Lindner:
I got these numbers by "/sbin/ip addr show dev gate0".
gate0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1431 qdisc
pfifo_fast qlen 500
link/[65534]
inet 169.254.0.0/32 scope global gate0
MTU is set to 1431 bytes.
IP-Host #1: 123.205.12.0 / 32
IP-Host #2: 123.205.12.4 / 32
IP RULES ON "HOST #2":
~ $ /sbin/ip rule show
6600: to 123.205.12.4 lookup batman_hosts [66]
6601: from all lookup batman_networks [65]
6700: to 123.205.12.4 lookup batman_unreach [67]
Host #1 (123.205.12.0) is in the routingtable of batman_hosts [66].
But i can not ping 123.205.12.0, because the kernel will not enter the
rule 6600.
When i configure my Host #2 to a /24 network, all went fine. Then the
rule will setuped as follow:
6600: to 123.205.12.4/24 lookup batman_hosts [66]
In this case, i had to write my own routing-policy-script.
Cheers,
Michael.
When using the
tunneling interface, the MTU is set to a lower value then
1500 bytes (1431 bytes). B.A.T.M.A.N have in addition to the NAT-Helper
set the TCPMSS Flag to something like 1371 bytes (1431 bytes - 20 Bytes
of MAC-Address and - 40 Bytes of TCP/IP Header). I found nothing about
TCPMSS on my firewall-rules (iptables) in the table "mangle".
Without TCPMSS, packages that transport more then 1371 bytes will be
silently dropped in my case.
Not sure how you get to these numbers (1431 / 1371) as the batman tunnel is
running over UDP which costs 29 Bytes [20 Bytes IP + 8 Bytes UDP + 1 Byte
batman stuff] in total, reducing the maximum packet size to 1471.
You are right about the the TCPMSS configuration - batman could set this
automatically as well. I suggest something like this:
iptables -I FORWARD -p tcp --tcp-flags SYN,RST SYN -o gate0 -j TCPMSS --clamp-
mss-to-pmtu Currently i
have my own policy-routing-script, because B.A.T.M.A.N does
not support HOST-Routes xxx.205.12.4/32. But why does B.A.T.M.A.N not
fully support Host-Routes? A mash with only Host-Addresses is easier to
administrate then complete networks. A second goal is, that the ad-hoc
mobile user is free to change his position across the net.
Your own policy-routing-script ?
Why do you think batman does not support host routes ? I had the feeling
batman supports host routes in all possible ways. :-)
1:02 p.m.
On Monday 07 September 2009 18:16:47 Michael Rack wrote:
I got these numbers by "/sbin/ip addr show dev
gate0".
gate0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1431 qdisc
pfifo_fast qlen 500
link/[65534]
inet 169.254.0.0/32 scope global gate0
MTU is set to 1431 bytes.
And what is the MTU of the interface batman is running on ?
Did the iptables command I posted help you to fix your MSS problem ?
IP-Host #1: 123.205.12.0 / 32
IP-Host #2: 123.205.12.4 / 32
IP RULES ON "HOST #2":
~ $ /sbin/ip rule show
6600: to 123.205.12.4 lookup batman_hosts [66]
6601: from all lookup batman_networks [65]
6700: to 123.205.12.4 lookup batman_unreach [67]
Host #1 (123.205.12.0) is in the routingtable of batman_hosts [66].
But i can not ping 123.205.12.0, because the kernel will not enter the
rule 6600.
When i configure my Host #2 to a /24 network, all went fine. Then the
rule will setuped as follow:
6600: to 123.205.12.4/24 lookup batman_hosts [66]
Ok, I see your problem. Batman could easily detect whether the host is part of
any existing network and if not modify the routing rules. I see 2 options:
* adding more rules to jump in table 66
* adding the node to table 65 instead of 66
What did you do to make it work ?
Regards,
Marek
1:40 p.m.
Am 07.09.2009 15:02, schrieb Marek Lindner:
Correct. I've added some rules with "to any", and this does the
trick.
In addition i use my own policy-routing-script, because the "throw"
event makes the routing-table a little fuzzy. Now i have only two
routing-tables "batman_hosts" and "batman_networks". In my
policy-routing-script i do the seperation between both tables.
And what is the MTU of the interface batman is running
on ?
Did the iptables command I posted help you to fix your MSS problem ?
The interface where batman is running on have MTU 1460 (Standard
Ethernet - UDP VPN Overload) on HOST #1.
The interface where batman is running on have MTU 1500 (Standard
Ethernet) on HOST #2.
Yes, the iptables-command does the trick for me. This iptalbes-filter
was known before. I added the filter to the mangle-table as the problem
occurs.
My Root-Server (HOST #1) is located at Nuernberg, DE and have access to
the internet with a public ip-space /22 that allocated to me. HOST #2 is
connected to an lowcost ISP-Provider with 30MBits / 2MBits. HOST #2 is
connected by VPN with HOST #1 to route the public ip-addresses.
IP-Host #1:
123.205.12.0 / 32
IP-Host #2: 123.205.12.4 / 32
IP RULES ON "HOST #2":
~ $ /sbin/ip rule show
6600: to 123.205.12.4 lookup batman_hosts [66]
6601: from all lookup batman_networks [65]
6700: to 123.205.12.4 lookup batman_unreach [67]
Host #1 (123.205.12.0) is in the routingtable of batman_hosts [66].
But i can not ping 123.205.12.0, because the kernel will not enter the
rule 6600.
When i configure my Host #2 to a /24 network, all went fine. Then the
rule will setuped as follow:
6600: to 123.205.12.4/24 lookup batman_hosts [66]
Ok, I see your problem. Batman could easily detect whether the host is part
of
any existing network and if not modify the routing rules. I see 2 options:
* adding more rules to jump in table 66
* adding the node to table 65 instead of 66
What did you do to make it work ?
My policy-routing-script is attached.
Michael.
8 Sep
8 Sep
5:57 p.m.
On Monday 07 September 2009 21:40:48 Michael Rack wrote:
The interface where batman is running on have MTU 1460
(Standard
Ethernet - UDP VPN Overload) on HOST #1.
The interface where batman is running on have MTU 1500 (Standard
Ethernet) on HOST #2.
Ok, that is what I expected. Batman will take the 29 Bytes it needs from the
given MTU.
Yes, the iptables-command does the trick for me. This
iptalbes-filter
was known before. I added the filter to the mangle-table as the problem
occurs.
Ok, I'll make a patch to let batman handle this automatically. Thanks for
bringing this up.
Correct. I've added some rules with "to
any", and this does the trick.
In addition i use my own policy-routing-script, because the "throw"
event makes the routing-table a little fuzzy. Now i have only two
routing-tables "batman_hosts" and "batman_networks". In my
policy-routing-script i do the seperation between both tables.
You will need the throw routes as soon as you use the tunneling.
My policy-routing-script is attached.
Nice - happy to see it in action. :-)
Regards,
Marek
30 Oct
30 Oct
10:19 a.m.
Dear B.A.T.M.A.N List,
i do not like to use the -g option, to select the preffered gateway. I
need a complete route-information.
I'm not able to set the HNA-Route 0.0.0.0/0 because a error-message
appears: Invalid announced network (netmask is invalid): 0.0.0.0/0
The current workarround is, to set HNA-Routes for 0.0.0.0/1,128.0.0.0/1.
Is there a chance, that anyone make a patch to add a new option to
"batmand"-command, to allow /0 routes?
The -g option should be disabled, in case the /0-option is enabled.
Liebe Grüße aus Freilassing,
Michael Rack
RSM Freilassing
--
RSM Freilassing Tel.: +49 8654 607110
Nocksteinstr. 13 Fax.: +49 8654 670438
D-83395 Freilassing www.rsm-freilassing.de
12:11 p.m.
Hello Michael -
i do not like to use the -g option, to select the
preffered gateway. I
need a complete route-information.
I'm not able to set the HNA-Route 0.0.0.0/0 because a error-message
appears: Invalid announced network (netmask is invalid): 0.0.0.0/0
The current workarround is, to set HNA-Routes for 0.0.0.0/1,128.0.0.0/1.
Is there a chance, that anyone make a patch to add a new option to
"batmand"-command, to allow /0 routes?
The -g option should be disabled, in case the /0-option is enabled.
*sigh*
This question has been raised and discussed before. Should become part of a
FAQ list. Check the mailing list archive. In 99.9% of the cases it is stupid
to announce /0. Since the project is open source you or anyone else can
modify the code and maintain a patch, for those who think it is smart to have
this "feature". I would consider it a bug.
Cheers,
Elektra
4893
days inactive
4947
days old
b.a.t.m.a.n@lists.open-mesh.org
12 comments
3 participants
participants (3)
-
elektra -
Marek Lindner -
Michael Rack