Hello,
I have problems with the gateway. The following setup is used:
Laptop: batmand -g 1024/200 -a 104.61.0.0/16 -s 10.12.0.1 --no-unreachable-rule --no-throw-rules --no-prio-rules --no-unresp-gw-check --resist-blocked-send wlan0 bbs /t 1 /i bbc /t 1 /i wrt54gs: batmand batmand -d 4 -r 2 --t 63 --no-unreachable-rule --no-throw-rules --no-prio-rules --no-unresp-gw-check --resist-blocked-send eth1 bbs /t 1 /i bbc /t 1 /i
The laptop uses a proxy (squid) to only allow some URLs. Also the firewall only allows some specific ip ranges. Does this have any influence for the gateway detection? -------------------------- Laptop:Linux 0-1.ddmesh 2.6.22.1 #1 Tue Jul 17 23:43:32 CEST 2007 i686 GNU/Linux
During start the laptop produces the following syslog entries. Oct 18 21:54:53 0-1 batmand[13603]: Warning - batgat kernel modul interface (/dev/batgat) not usable: No such file or directory This may decrease the performance of batman! Oct 18 21:54:53 0-1 batmand[13603]: Warning - batgat kernel modul interface (/dev/batgat) not usable: No such file or directory This may decrease the performance of batman! Oct 18 21:54:53 0-1 batmand[13603]: Trying to name tunnel to bat0 ... Oct 18 21:54:53 0-1 kernel: bat0: Disabled Privacy Extensions Oct 18 21:54:53 0-1 batmand[13603]: success! Oct 18 21:54:53 0-1 batmand[13603]: Trying to name tunnel to bat0 ... Oct 18 21:54:53 0-1 batmand[13603]: Warning - batgat kernel modul interface (/dev/batgat) not usable: No such file or directory This may decrease the performance of batman! Oct 18 21:54:53 0-1 batmand[13603]: Trying to name tunnel to bat0 ... Oct 18 21:54:53 0-1 batmand[13603]: Error - can't create tun device (TUNSETIFF): Device or resource busy Oct 18 21:54:53 0-1 batmand[13603]: Trying to name tunnel to bat1 ... Oct 18 21:54:53 0-1 kernel: bat1: Disabled Privacy Extensions Oct 18 21:54:53 0-1 batmand[13603]: success! Oct 18 21:54:53 0-1 batmand[13603]: Error - can't create tun device (TUNSETIFF): Device or resource busy Oct 18 21:54:53 0-1 batmand[13603]: Trying to name tunnel to bat2 ... Oct 18 21:54:53 0-1 kernel: bat2: Disabled Privacy Extensions Oct 18 21:54:53 0-1 batmand[13603]: success!
I have running openvpn that also use some tun and tap devices (using kmod_tun). All tunnel interfaces that are using kmod_tun have names different to tunX. Only one interface is using tap0.
ip route 192.168.100.2 dev vpn3 proto kernel scope link src 192.168.100.1 10.203.71.21 dev vpn1 proto kernel scope link src 10.203.71.22 192.168.99.2 dev vpn2 proto kernel scope link src 192.168.99.1 192.168.100.0/24 via 192.168.100.2 dev vpn3 192.168.178.0/24 dev eth0 proto kernel scope link src 192.168.178.2 169.254.2.0/24 dev bat2 proto static 169.254.0.0/24 dev bat0 proto static 192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.2 169.254.1.0/24 dev bat1 proto static 192.168.99.0/24 via 192.168.99.2 dev vpn2 10.203.71.0/24 via 10.203.71.21 dev vpn1 104.61.0.0/16 via 10.203.71.21 dev vpn1 172.16.0.0/16 dev bbs proto kernel scope link src 172.16.0.1 172.16.0.0/16 dev bbc proto kernel scope link src 172.16.0.2 10.63.0.0/16 via 10.203.71.21 dev vpn1 105.61.0.0/16 via 10.203.71.21 dev vpn1 10.0.0.0/8 dev wlan0 proto kernel scope link src 10.12.0.1 default via 192.168.178.1 dev eth0
0-1:/home/ffdevel/ff-build/open-mesh.net# ip route list table bat_route 10.12.10.1 dev wlan0 proto static scope link src 10.12.0.1 10.12.10.17 dev wlan0 proto static scope link src 10.12.0.1 throw 104.61.0.0/16 proto static
0-1:/home/ffdevel/ff-build/open-mesh.net# ip route list table bat_hna 10.12.10.0/28 via 10.12.10.1 dev wlan0 proto static 10.12.10.16/28 via 10.12.10.17 dev wlan0 proto static throw 104.61.0.0/16 proto static
0-1:/home/ffdevel/ff-build/open-mesh.net# ip route list table bat_default throw 104.61.0.0/16 proto static
B.A.T.M.A.N. 0.3-exp, MainIF/IP: wlan0 10.12.0.1, WindSize: 128, BLT: 2, OGI: 1000, UT: 0d 0h 2m Originator viaIF Router (brc rcvd lseq lvld) [ viaIF RTQ RQ TQ].. alternatives... 10.12.10.1 wlan0 10.12.10.1 (126 128 39555 0) [ wlan0 118 127 118] 10.12.10.17 ( 2) 10.12.10.17 wlan0 10.12.10.17 (128 128 49229 0) [ wlan0 123 128 123]
-------------------------- wrt54gs:
The wrt54gl shows always: Gateway Router (#/128) => 10.12.0.1 10.12.0.1 (123), gw_class 33 - 1024KBit/256KBit, reliability: 0
But the ip route list table bat_default contains only a throw entry and not the default route. ip addr lists the interfaces but always without an ip address assigned. The batman revision I use is the batman-experimental Rev724. also some revisions before have the same result.
Despite the presens of --no-throw-rules throw rules are added to the batman routing tables to throw the hna entries. Is this wanted?
In older version I got a tunnel but this has be removed by batman. Perhaps because the client didn't not use it to much?
If I try to add a tunnl manually (ip route add default dev bat0 table bat_default) and try to ping an internet address the client logread shows :kern.err batmand[6649]: Error - can't receive ip from gateway: number of maximum retries reached
The manually added default route is removed after a while by batmand.
Has anyone an idea what I have done wrong.
Regards Stephan
Hello
On Donnerstag 18 Oktober 2007, Freifunk Dresden wrote:
Hello,
I have problems with the gateway. The following setup is used:
Laptop: batmand -g 1024/200 -a 104.61.0.0/16 -s 10.12.0.1 --no-unreachable-rule --no-throw-rules --no-prio-rules --no-unresp-gw-check --resist-blocked-send wlan0 bbs /t 1 /i bbc /t 1 /i wrt54gs: batmand
batmand -d 4 -r 2 --t 63 --no-unreachable-rule --no-throw-rules --no-prio-rules --no-unresp-gw-check --resist-blocked-send eth1 bbs /t 1 /i bbc /t 1 /i
Generally you should announce the ip address of your non-primary interfaces (bbs and bbc) with HNA. Otherwise the traffic you generate on these nodes might leave the node with a source IP address which is simply not known beyond that link. If you really want to completely hide the IP addresses of bbs and bbc then you need to do NAT for all locally generated packets, except for the OGMs.
The laptop uses a proxy (squid) to only allow some URLs. Also the firewall only allows some specific ip ranges. Does this have any influence for the gateway detection? --------------------------
I dont know!
During start the laptop produces the following syslog entries. Oct 18 21:54:53 0-1 batmand[13603]: Warning - batgat kernel modul interface (/dev/batgat) not usable: No such file or directory This may decrease the performance of batman!
Thats OK!
kernel: bat0: Disabled Privacy Extensions
this message I dont know!
Oct 18 21:54:53 0-1 batmand[13603]: Error - can't create tun device (TUNSETIFF): Device or resource busy Oct 18 21:54:53 0-1 batmand[13603]: Trying to name tunnel to bat2 ... Oct 18 21:54:53 0-1 kernel: bat2:
This is usual as well, batmand is searching for an unused tunnel name.
ip route 10.203.71.21 dev vpn1 proto kernel scope link src 10.203.71.22 10.203.71.0/24 via 10.203.71.21 dev vpn1 10.63.0.0/16 via 10.203.71.21 dev vpn1 10.0.0.0/8 dev wlan0 proto kernel scope link src 10.12.0.1
so you have some overlapping IP ranges?
default via 192.168.178.1 dev eth0
0-1:/home/ffdevel/ff-build/open-mesh.net# ip route list table bat_route 10.12.10.1 dev wlan0 proto static scope link src 10.12.0.1 10.12.10.17 dev wlan0 proto static scope link src 10.12.0.1 throw 104.61.0.0/16 proto static
0-1:/home/ffdevel/ff-build/open-mesh.net# ip route list table bat_hna 10.12.10.0/28 via 10.12.10.1 dev wlan0 proto static 10.12.10.16/28 via 10.12.10.17 dev wlan0 proto static throw 104.61.0.0/16 proto static
0-1:/home/ffdevel/ff-build/open-mesh.net# ip route list table bat_default throw 104.61.0.0/16 proto static
ip rule would be also interesting. Since you have used the --no-prio-rules, have you manually configured a rule like ip rule add pref 6600 from all to 10.0.0.0/8 t 66
Can you ping all the other mesh IPs, particulary the GW: 10.12.0.1
B.A.T.M.A.N. 0.3-exp, MainIF/IP: wlan0 10.12.0.1, WindSize: 128, BLT: 2, OGI: 1000, UT: 0d 0h 2m Originator viaIF Router (brc rcvd lseq lvld) [ viaIF RTQ RQ TQ].. alternatives... 10.12.10.1 wlan0 10.12.10.1 (126 128 39555 0) [ wlan0 118 127 118] 10.12.10.17 ( 2) 10.12.10.17 wlan0 10.12.10.17 (128 128 49229 0) [ wlan0 123 128 123]
That looks good.
Gateway Router (#/128)=> 10.12.0.1 10.12.0.1 (123), gw_class 33 - 1024KBit/256KBit, reliability: 0
In the first place, this just indicated that the local batmand has decided for one of the available GWs. It does not necessarily mean, that the connection to that GW was successfull
But the ip route list table bat_default contains only a throw entry and not the default route.
There is no default route until the client has decided for a GW. After the startup, the daemon waits a while before it decides for a GW. This is done to gather some statistics about the available GWs.
ip addr lists the interfaces but always without an ip
The bat0 tunnel interface does not get an IP address until the client node sends some data over the tunnel. But if the GW is not reachable (see above) it can never get one.
address assigned. The batman revision I use is the batman-experimental Rev724. also some revisions before have the same result.
Despite the presens of --no-throw-rules throw rules are added to the batman routing tables to throw the hna entries. Is this wanted?
Probably not :-)
In older version I got a tunnel but this has be removed by batman. Perhaps because the client didn't not use it to much?
??? Which tunnel has been removed by batman and when?
If I try to add a tunnl manually (ip route add default dev bat0 table bat_default) and try to ping an internet address the client logread shows :kern.err batmand[6649]: Error - can't receive ip from gateway: number of maximum retries reached
The manually added default route is removed after a while by batmand.
It really sounds your GW is not reachable. Check your ip rules and if ping 10.12.0.1 works.
ciao /axel
Has anyone an idea what I have done wrong.
Regards Stephan
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,
The laptop uses a proxy (squid) to only allow some URLs. Also the firewall only allows some specific ip ranges. Does this have any influence for the gateway detection? --------------------------
You definitely need to configure your firewall to accept port 4306 for GW and 4307 for visualization support.
regards, axel
Hi,
The laptop uses a proxy (squid) to only allow some URLs. Also the firewall only allows some specific ip ranges. Does this have any influence for the gateway detection? --------------------------
I dont know!
No. The gateway detection itself is only influenced by the batman originator packets.
Oct 18 21:54:53 0-1 batmand[13603]: Error - can't create tun device (TUNSETIFF): Device or resource busy Oct 18 21:54:53 0-1 batmand[13603]: Trying to name tunnel to bat2 ... Oct 18 21:54:53 0-1 kernel: bat2:
This is usual as well, batmand is searching for an unused tunnel name.
But unnecessary and confusing. These errors can be avoided.
Gateway Router (#/128)=> 10.12.0.1 10.12.0.1 (123), gw_class 33 - 1024KBit/256KBit, reliability: 0
In the first place, this just indicated that the local batmand has decided for one of the available GWs. It does not necessarily mean, that the connection to that GW was successfull
Correct. The connection to the gateway itself is triggered as soon as you begin to use the tunnel. This output shows you to which gateway the connection will be established (assuming that the gateway responds).
But the ip route list table bat_default contains only a throw entry and not the default route.
There is no default route until the client has decided for a GW. After the startup, the daemon waits a while before it decides for a GW. This is done to gather some statistics about the available GWs.
But his output shows that the client has selected a gateway. Therefore a default route should exist. I guess you just looked into the wrong table. I assume that "bat_default" is table 67 ?! The batman default route can be found in table 68.
:kern.err batmand[6649]: Error - can't receive ip from gateway: number of
maximum retries reached
The manually added default route is removed after a while by batmand.
It really sounds your GW is not reachable. Check your ip rules and if ping 10.12.0.1 works.
This indicates that port 4306 is blocked at the gateway side. The client will ask for an IP an that port.
Regards, Marek
Hi,
I have got it working and below I copy/paste some text from previous posts of Marek and Axel.
First the problem was the firewall. As you have mentioned you have been an official port number 4305 assigned. Looking into the port list batman uses only port 4305. This is why I have assumed that all packages (at least OGMs and GW) are using this port.
The second problem is that the documentation speeks about three routing tables 65,66,67 where table 67 is used for adding the gateway routes. I haven't added a rule to this table 68 (see ip rule below).
But his output shows that the client has selected a gateway. Therefore a default route should exist. I guess you just looked into the wrong table. I assume that "bat_default" is table 67 ?! The batman default route can be found in table 68.
When table 68 is the table that carries the default route to dev bat0, what is the table 67 for? Are there now four routing tables?
Here are my ip rules just for info (table 68 the the "new" table): root@10-2:~# ip rule 0: from all lookup local 100: from all lookup gateway 200: from all to 192.168.0.0/16 lookup main 201: from all to 169.254.0.0/16 lookup main 202: from all to 10.255.255.255 lookup main 203: from all to 10.12.10.16/28 lookup main 300: from all lookup bat_route 301: from all to 172.16.0.0/12 lookup main 302: from all lookup bat_hna 303: from all lookup bat_default #after adding the next rule it is working 304: from all lookup 68 32766: from all lookup main 32767: from all lookup default
#batman 65 bat_hna 66 bat_route 67 bat_default
Correct. The connection to the gateway itself is triggered as soon as you begin to use the tunnel. This output shows you to which gateway the connection will be established (assuming that the gateway responds).
For my understanding, when batman starts it collects packages to decide what gateway should be used. It then adds the default route via dev bat0 and establishes the tunnel via UDP to port 4306. The connection should be independent of whether a client (pda connected to router or local process) tries to use to connect the internet. If no internet connection was used for weeks, batmand should always have the default route added. If batman removes this default route, because no traffic through the tunnel was present for a while, how does batman detect a client trying to make an internet connection later and add this default route again? Perhaps I didn't get you right.
Axel:
Laptop: batmand -g 1024/200 -a 104.61.0.0/16 -s 10.12.0.1 --no-unreachable-rule --no-throw-rules --no-prio-rules --no-unresp-gw-check --resist-blocked-send wlan0 bbs /t 1 /i bbc /t 1 /i wrt54gs: batmand
batmand -d 4 -r 2 --t 63 --no-unreachable-rule --no-throw-rules --no-prio-rules --no-unresp-gw-check --resist-blocked-send eth1 bbs /t 1 /i bbc /t 1 /i
Generally you should announce the ip address of your non-primary interfaces (bbs and bbc) with HNA. Otherwise the traffic you generate on these nodes might leave the node with a source IP address which is simply not known beyond that link. If you really want to completely hide the IP addresses of bbs and bbc then you need to do NAT for all locally generated packets, except for the OGMs.
I don't understand your idea. Each node in the network has an official ip of the 10.0.0.0/8 network. If I use additional interfaces for backbone (bbs,bbc) these interfaces have there own ip range 172.16.0.0/12. if a node wants to connect a fare away node it will use the "official" ip address from 10.0.0.0/8 range. If the only connection is via bbs or bbc the packages are natted to 172.12.. Only the the routers that are connected directly via the backbone (bbc->bbs) should have routing entries of 172.16.0.0/12. All other nodes in the network do not need to know these addresses and therefore I don't HNA these. This avoids filling up the routing tables with ip addresses that finally point to the same node.
A.eth1-A.bbc=====backbone=========B.bbs-B.eth1 -------------------C.eth1----------D.eth1 10...1 172...1 172...2 10...2 10...3 10...4
Node D with IP 10.12.0.4 can send packages to node 10.12.0.1 The package is NATed in node B to be send over backbone interface (bbs). Node A receives this package with ip 172.12.0.1 and because node A has also an interface with ip 10.12.0.1 the package has reached the target specified by node D (target:10.12.0.1).
The bat0 tunnel interface does not get an IP address until the client node sends some data over the tunnel. But if the GW is not reachable (see above) it can never get one.
This only can be batman privat data that are sent over the tunnel, because a local process needs the routing entry (default route to dev bat0). Right?
??? Which tunnel has been removed by batman and when?
I have tried to add the default route via dev bat0 to table 67 just to check if only the routing entry is missing. durning this tests, batman has removed this route from this table after about one minute. But because it is working now (table 68 and missing to add a rule for this) it is obsolete.
Many thanks to you and you all do a very good job :) Stephan
Hi,
First the problem was the firewall. As you have mentioned you have been an official port number 4305 assigned. Looking into the port list batman uses only port 4305. This is why I have assumed that all packages (at least OGMs and GW) are using this port.
true, we got 4305 assigned. Due to the internal programm design we could not multiplex the the batman originator messages and gateway tunneling over one port without a major rewrite. That is why we "hijacked" 4306 and 4307. This may change with future releases (after 0.3). Let me mention that we clearly stated that fact (from the release announcement): Pay attention to the fact that all ports used by B.A.T.M.A.N. are changing: 4305 for OGMs, 4306 for the tunneling and 4307 for the vis server. Adjust your firewall settings if required.
The second problem is that the documentation speeks about three routing tables 65,66,67 where table 67 is used for adding the gateway routes. I haven't added a rule to this table 68 (see ip rule below).
is the table 67 for? Are there now four routing tables?
Which documentation ? We should fix that. Some time ago we had to redesign the policy routing because the kernel would parse the entries in the wrong order (which was our mistake). This layout change made another table neccessay. In table 67 you (normally) find the unreachable rule which you obviously deactivated. Just start batmand with full policy routing enabled and you will quickly understand the differences.
For my understanding, when batman starts it collects packages to decide what gateway should be used. It then adds the default route via dev bat0 and establishes the tunnel via UDP to port 4306. The connection should be independent of whether a client (pda connected to router or local process) tries to use to connect the internet. If no internet connection was used for weeks, batmand should always have the default route added. If batman removes this default route, because no traffic through the tunnel was present for a while, how does batman detect a client trying to make an internet connection later and add this default route again?
This happens: 1. batmand analyzes the OGMs, selects a gateway and sets a default route towards its tun device (batX/gateX) 2. batmand waits for traffic coming though the tun device 3. on the first packet batmand tries to connect to the gateway and demands an IP for the tun device 4. the tunnel is fully established and data can flow through 5. after a certain idle time the IP is removed from the tun device and batmand returns to step 2
The removal of the default route can only be triggered if the gateway does not hand out an IP or the blackhole detection is reacting. It also happens if you select -r 3 and a better gateway is found.
This only can be batman privat data that are sent over the tunnel, because a local process needs the routing entry (default route to dev bat0). Right?
The default route must be always present so that every traffic can start this process. Otherwise batmand will never know about your requirement of an IP.
Regards, Marek
Hi,
thanks for you quick answer and the explaination how the gateway-ing is working.
The second problem is that the documentation speeks about three routing tables 65,66,67 where table 67 is used for adding the gateway routes. I haven't added a rule to this table 68 (see ip rule below).
is the table 67 for? Are there now four routing tables?
Which documentation ? We should fix that.
Please see bmx.pdf of batman-experimental chapter 4.1.2 and page 27 almost at the end of this page. (https://www.open-mesh.net/batman/doc/BMX/bmx.pdf/view) Also found at the html version at "Customizing the used routing table and priority rules" and batmand --dangerous -H
I'm using experimental revision 724.
Bye Stephan
Hello,
Laptop: batmand -g 1024/200 -a 104.61.0.0/16 -s 10.12.0.1 --no-unreachable-rule --no-throw-rules --no-prio-rules --no-unresp-gw-check --resist-blocked-send wlan0 bbs /t 1 /i bbc /t 1 /i wrt54gs: batmand
batmand -d 4 -r 2 --t 63 --no-unreachable-rule --no-throw-rules --no-prio-rules --no-unresp-gw-check --resist-blocked-send eth1 bbs /t 1 /i bbc /t 1 /i
Generally you should announce the ip address of your non-primary interfaces (bbs and bbc) with HNA. Otherwise the traffic you generate on these nodes might leave the node with a source IP address which is simply not known beyond that link. If you really want to completely hide the IP addresses of bbs and bbc then you need to do NAT for all locally generated packets, except for the OGMs.
I don't understand your idea. Each node in the network has an official ip of the 10.0.0.0/8 network. If I use additional interfaces for backbone (bbs,bbc) these interfaces have there own ip range 172.16.0.0/12. if a node wants to connect a fare away node it will use the "official" ip address from 10.0.0.0/8 range.
Ok if you can ensure this, then there is no problem. But how do you do that?
We observed nodes (also with multiple interfaces and hidden non-primary interfaces) where local application have chosen the ip address of a non-primary interface as the source address for its outgoing traffic.
From my understanding, the default behavior of most applications is to always
use the IP address of the interface via which a packet is routed out, as the source address of an outgoing packet. So in case you send a ping to a node to which batmand has decided to route via your bbs device, the ping packet should by default have the IP address of this bbs device. If the destination node of the ping is link-local for the bbs device, then this is no problem because all link-local neighbors of bbs have learned about the IP address of the bbs device. But if the final destination of the ping packet is more than one hop away, then the destination node does not know anything about the IP address of bbs unless it has been announced with HNA.
If the only connection is via bbs or bbc the packages are natted to 172.12.. Only the the routers that are connected directly via the backbone (bbc->bbs) should have routing entries of 172.16.0.0/12. All other nodes in the network do not need to know these addresses and therefore I don't HNA these.
How could any non-neighboring node respond to a packet with a 172.12.. source address? I would say you better NAT to the IP addresses of your 10.10.0.0/8 because these are the addresses known by any node. But be careful not to NAT any OGMs and any forwarded traffic.
This avoids filling up the routing tables with ip addresses that finally point to the same node.
A.eth1-A.bbc=====backbone=========B.bbs-B.eth1 -------------------C.eth1----------D.eth1 10...1 172...1 172...2 10...2 10...3 10...4
Node D with IP 10.12.0.4 can send packages to node 10.12.0.1 The package is NATed in node B to be send over backbone interface (bbs).
What is the benifit of this NAT here?
Node A receives this package with ip 172.12.0.1 and because node A has also an interface with ip 10.12.0.1 the package has reached the target specified by node D (target:10.12.0.1).
Yes I understand that that works from D to A. But does it also work with a ping send from node A to node D? The source address of the ping request would be 172.12.0.1 and when it finally arrives at node D, the receiver does not know how to reply!
ciao, axel
Hello,
If I use SNAT to change the source address, all other nodes know where to send the ping answers:
The Ip of the wlan is 10.12.0.1 the ip of bbs is 172.16.0.1 iptables -t nat -I POSTROUTING -o bbs -j SNAT --to 10.12.0.1
A.eth1-A.bbc=====backbone=========B.bbs-B.eth1 -------------------C.eth1----------D.eth1 10...1 172...1 172...2 10...2 10...3 10...4
Sendint from A to D is not a problem, all packages the have the ip 172... as source address will be assigned the new 10er IP. Node B,C and D will send answer back to the 10er IP. Node B has a route to A over backbone (bbs).
If the only connection is via bbs or bbc the packages are natted to 172.12.. Only the the routers that are connected directly via the backbone (bbc->bbs) should have routing entries of 172.16.0.0/12. All other nodes in the network do not need to know these addresses and therefore I don't HNA these.
How could any non-neighboring node respond to a packet with a 172.12.. source address? I would say you better NAT to the IP addresses of your 10.10.0.0/8 because these are the addresses known by any node. But be careful not to NAT any OGMs and any forwarded traffic.
What can happen if I do the SNAT? I think that OGMs are not FORWARDED. They only go OUT or come IN. because batmand does not use the iptable roles it does not know about the change of the source address. The OGMs are generated for the original interface ip. OGMs that A sends to B will be received via WLAN and also via BBS. When I understand batmand right it uses the interface where the OGMs are comming from to calulate the routes (not the source ip).
Bye Stephan
Hello,
On Sonntag 21 Oktober 2007, Freifunk Dresden wrote:
Hello,
If I use SNAT to change the source address, all other nodes know where to send the ping answers:
The Ip of the wlan is 10.12.0.1 the ip of bbs is 172.16.0.1 iptables -t nat -I POSTROUTING -o bbs -j SNAT --to 10.12.0.1
A.eth1-A.bbc=====backbone=========B.bbs-B.eth1 -------------------C.eth1----------D.eth1 10...1 172...1 172...2 10...2 10...3 10...4
Sendint from A to D is not a problem, all packages the have the ip 172... as source address will be assigned the new 10er IP. Node B,C and D will send answer back to the 10er IP. Node B has a route to A over backbone (bbs).
If the only connection is via bbs or bbc the packages are natted to 172.12.. Only the the routers that are connected directly via the backbone (bbc->bbs) should have routing entries of 172.16.0.0/12. All other nodes in the network do not need to know these addresses and therefore I don't HNA these.
How could any non-neighboring node respond to a packet with a 172.12.. source address? I would say you better NAT to the IP addresses of your 10.10.0.0/8 because these are the addresses known by any node. But be careful not to NAT any OGMs and any forwarded traffic.
What can happen if I do the SNAT?
If you NAT any forwarded traffic, the source address of related packets is changed :-) Batmand supports asymmetric routing. That means the packets may be routed another way back than they have come. By doing NAT on the forwarded traffic within the mesh you may force packets to also pass along the NATting interface on their way back. But thats not very beautiful. And I am not shure about further side effects. Anyway, forwarded packets will not show any traces from your hidden backbone node. They will be passed along with source and destination addresses in the 10.10.0.0/8 range.
I think that OGMs are not FORWARDED.
Right! They are flooded by being re-broadcasted .
They only go OUT or come IN. because batmand does not use the iptable roles it does not know about the change of the source address. The OGMs are generated for the original interface ip. OGMs that A sends to B will be received via WLAN and also via BBS. When I understand batmand right it uses the interface where the OGMs are comming from
(then batman would have to trac the MAC addresses, but it is IP based )
to calulate the routes (not the source ip).
NO! Batman uses the source IP of each received OGM to identify if the OGM has been received - directly from the originator interface or - from another intermediate interface. This is important for many internal mechanisms.
ciao, /axel
Bye Stephan
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,
If you NAT any forwarded traffic, the source address of related packets is changed :-) Batmand supports asymmetric routing. That means the packets may be routed another way back than they have come. By doing NAT on the forwarded traffic within the mesh you may force packets to also pass along the NATting interface on their way back. But thats not very beautiful. And I am not shure about further side effects.
Hmm... I'm still confused. For instance I have interface bbs with ip 172.0.0.1 and an interface wlan with ip 10.0.0.1 If I ping a node behind the bbs interface the package will be created with ip 172.0.0.1. The SNAT of the initiating node will change this to 10.0.0.1. The next node will receive this package through its bbs interface but sends the answer back to tho the node with ip 10.0.0.1. The outgoing interface is determind by the routing table of the second node. This means that asymetric routing is still possible. Because the routing entries that batman creates in the second node the package goes over bbs or wlan back to the first node. But I see the point that batman internals may be disturbed when I change this source ip for batman packets. See next comment.
They only go OUT or come IN. because batmand does not use the iptable roles it does not know about the change of the source address. The OGMs are generated for the original interface ip. OGMs that A sends to B will be received via WLAN and also via BBS. When I understand batmand right it uses the interface where the OGMs are comming from
(then batman would have to trac the MAC addresses, but it is IP based )
to calulate the routes (not the source ip).
NO! Batman uses the source IP of each received OGM to identify if the OGM has been received
- directly from the originator interface or
- from another intermediate interface.
This is important for many internal mechanisms.
If I mark the batman udp packets for the port (4305) and only SNAT all other packages then batman should be working as designed, isn't it?
You said before that OGMs are not forwarded. So I can setup a firewall rule to avoid forwarding the port 4305. The ports 4306 and 4307 still must be forwarded. Is this right?
Bye Stephan
On Sonntag 21 Oktober 2007, Freifunk Dresden wrote:
Hi,
If you NAT any forwarded traffic, the source address of related packets is changed :-) Batmand supports asymmetric routing. That means the packets may be routed another way back than they have come. By doing NAT on the forwarded traffic within the mesh you may force packets to also pass along the NATting interface on their way back. But thats not very beautiful. And I am not shure about further side effects.
Hmm... I'm still confused. For instance I have interface bbs with ip 172.0.0.1 and an interface wlan with ip 10.0.0.1 If I ping a node behind the bbs interface the package will be created with ip 172.0.0.1. The SNAT of the initiating node will change this to 10.0.0.1. The next node will receive this package through its bbs interface but sends the answer back to tho the node with ip 10.0.0.1. The outgoing interface is determind by the routing table of the second node. This means that asymetric routing is still possible.
its still possible but with limitations. Consider another setup where the path A - B - C _ D - E is just one of many possible paths between A and E. Now the link C _ D is such a "hidden link" and nodes C and D are NATting all packets traveling along. Then, when E receives a packet from A which has passed along ABCDE the source address of that packet indicates that it came from B and not from A. The batmand on E might have choosen a totally different route back from E to A (e.g. E-J-B-A) but because the source address of the packet shows Cs IP it must be routed back along C.
Because the routing entries that batman creates in the second node the package goes over bbs or wlan back to the first node. But I see the point that batman internals may be disturbed when I change this source ip for batman packets. See next comment.
On Sonntag 21 Oktober 2007, Freifunk Dresden wrote:
The Ip of the wlan is 10.12.0.1 the ip of bbs is 172.16.0.1 iptables -t nat -I POSTROUTING -o bbs -j SNAT --to 10.12.0.1
A.eth1-A.bbc=====backbone=========B.bbs-B.eth1 -------------------C.eth1----------D.eth1 10...1 172...1 172...2 10...2 10...3 10...4
Yes this way it should work (assuming you care for your OGMs) But i still suggest something like:
iptables -t nat -A POSTROUTING -o bbs -s 172.16.0.1/32 -p UDP --sport 4305 --dport 4305 -j ACCEPT # rule must be processed before the next one iptables -t nat -A POSTROUTING -o bbs -s 172.16.0.1/32 -j SNAT --to 10.12.0.1
They only go OUT or come IN. because batmand does not use the iptable roles it does not know about the change of the source address. The OGMs are generated for the original interface ip. OGMs that A sends to B will be received via WLAN and also via BBS. When I understand batmand right it uses the interface where the OGMs are comming from
(then batman would have to trac the MAC addresses, but it is IP based )
to calulate the routes (not the source ip).
NO! Batman uses the source IP of each received OGM to identify if the OGM has been received
- directly from the originator interface or
- from another intermediate interface.
This is important for many internal mechanisms.
If I mark the batman udp packets for the port (4305) and only SNAT all other packages then batman should be working as designed, isn't it?
Yes
You said before that OGMs are not forwarded. So I can setup a firewall rule to avoid forwarding the port 4305. The ports 4306 and 4307 still must be forwarded. Is this right?
That should be no problem !
by the way. Since batmand-exp rv 730 the parametrization of --bmx-defaults is now enabled by default (it detects much better routes). This parametrization automatically hides all non-primary interfaces and announces them as HNA. You can revert the HNA announcements for a interface with the interface specific /A switch (since revision 747).
If you really want to stick to the behavior of BATMAN-III (batmand-0.2) then use the --generation-III directive as the first parameter.
See batmand --dangerous for short help.
Also thanks for the hints regarding the documentation of used routing tables.
ciao /axel
Bye Stephan
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,
Consider another setup where the path A - B - C _ D - E is just one of many possible paths between A and E. Now the link C _ D is such a "hidden link" and nodes C and D are NATting all packets traveling along. Then, when E receives a packet from A which has passed along ABCDE the source address of that packet indicates that it came from B and not from A. The batmand on E might have choosen a totally different route back from E to A (e.g. E-J-B-A) but because the source address of the packet shows Cs IP it must be routed back along C.
Only packages for the bbs/bbc interface and 172er ips are considered. This is the same as you have already mentioned. If I SNAT also the OGMs (4305) routing is completely dead.
by the way. Since batmand-exp rv 730 the parametrization of --bmx-defaults is now enabled by default (it detects much better routes). This parametrization automatically hides all non-primary interfaces and announces them as HNA. You can revert the HNA announcements for a interface with the interface specific /A switch (since revision 747).
To be sure, if I add /A behind bbs then no HNA is created for this interface ip?
Bye Stephan
Hello
On Donnerstag 25 Oktober 2007, Freifunk Dresden wrote:
by the way. Since batmand-exp rv 730 the parametrization of --bmx-defaults is now enabled by default (it detects much better routes). This parametrization automatically hides all non-primary interfaces and announces them as HNA. You can revert the HNA announcements for a interface with the interface specific /A switch (since revision 747).
To be sure, if I add /A behind bbs then no HNA is created for this interface ip?
correct!
ciao, /axel
Bye Stephan
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@lists.open-mesh.org
-
Axel Neumann -
Freifunk Dresden -
Marek Lindner